<p>The LAMMPS “version” is the date when it was released, such as 1 May
2010. LAMMPS is updated continuously. Whenever we fix a bug or add a
feature, we release it immediately, and post a notice on <a class="reference external" href="http://lammps.sandia.gov/bug.html">this page of the WWW site</a>. Each dated copy of LAMMPS contains all the
features and bug-fixes up to and including that version date. The
version date is printed to the screen and logfile every time you run
LAMMPS. It is also in the file src/version.h and in the LAMMPS
directory name created when you unpack a tarball, and at the top of
the first page of the manual (this page).</p>
<ul class="simple">
<li>If you browse the HTML doc pages on the LAMMPS WWW site, they always
describe the most current version of LAMMPS.</li>
<li>If you browse the HTML doc pages included in your tarball, they
describe the version you have.</li>
<li>The <a class="reference external" href="Manual.pdf">PDF file</a> on the WWW site or in the tarball is updated
about once per month. This is because it is large, and we don’t want
it to be part of every patch.</li>
<li>There is also a <a class="reference external" href="Developer.pdf">Developer.pdf</a> file in the doc
directory, which describes the internal structure and algorithms of
LAMMPS.</li>
</ul>
<p>LAMMPS stands for Large-scale Atomic/Molecular Massively Parallel
Simulator.</p>
<p>LAMMPS is a classical molecular dynamics simulation code designed to
run efficiently on parallel computers. It was developed at Sandia
National Laboratories, a US Department of Energy facility, with
funding from the DOE. It is an open-source code, distributed freely
under the terms of the GNU Public License (GPL).</p>
<p>The primary developers of LAMMPS are <a class="reference external" href="http://www.sandia.gov/~sjplimp">Steve Plimpton</a>, Aidan
Thompson, and Paul Crozier who can be contacted at
sjplimp,athomps,pscrozi at sandia.gov. The <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a> at
<a class="reference external" href="http://lammps.sandia.gov">http://lammps.sandia.gov</a> has more information about the code and its
uses.</p>
<hr class="docutils" />
<p>The LAMMPS documentation is organized into the following sections. If
you find errors or omissions in this manual or have suggestions for
useful information to add, please send an email to the developers so
we can improve the LAMMPS documentation.</p>
<p>Once you are familiar with LAMMPS, you may want to bookmark <a class="reference internal" href="Section_commands.html#comm"><span class="std std-ref">this page</span></a> at Section_commands.html#comm since
it gives quick access to documentation for all LAMMPS commands.</p>
<p><a class="reference external" href="Manual.pdf">PDF file</a> of the entire manual, generated by
<li class="toctree-l2"><a class="reference internal" href="Section_start.html#what-s-in-the-lammps-distribution">2.1. What’s in the LAMMPS distribution</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_start.html#making-lammps">2.2. Making LAMMPS</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_start.html#making-lammps-with-optional-packages">2.3. Making LAMMPS with optional packages</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_start.html#building-lammps-via-the-make-py-tool">2.4. Building LAMMPS via the Make.py tool</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_start.html#building-lammps-as-a-library">2.5. Building LAMMPS as a library</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_accelerate.html#general-strategies">5.2. General strategies</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_accelerate.html#packages-with-optimized-styles">5.3. Packages with optimized styles</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_accelerate.html#comparison-of-various-accelerator-packages">5.4. Comparison of various accelerator packages</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#tip3p-water-model">6.7. TIP3P water model</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#tip4p-water-model">6.8. TIP4P water model</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#spc-water-model">6.9. SPC water model</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#coupling-lammps-to-other-codes">6.10. Coupling LAMMPS to other codes</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#calculating-a-diffusion-coefficient">6.22. Calculating a diffusion coefficient</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#using-chunks-to-calculate-system-properties">6.23. Using chunks to calculate system properties</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#setting-parameters-for-the-kspace-style-pppm-disp-command">6.24. Setting parameters for the <code class="docutils literal"><span class="pre">kspace_style</span> <span class="pre">pppm/disp</span></code> command</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#submitting-new-features-for-inclusion-in-lammps">10.15. Submitting new features for inclusion in LAMMPS</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a><ul>
<li class="toctree-l2"><a class="reference internal" href="Section_python.html#overview-of-running-lammps-from-python">11.1. Overview of running LAMMPS from Python</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_python.html#overview-of-using-python-from-a-lammps-script">11.2. Overview of using Python from a LAMMPS script</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_python.html#building-lammps-as-a-shared-library">11.3. Building LAMMPS as a shared library</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_python.html#installing-the-python-wrapper-into-python">11.4. Installing the Python wrapper into Python</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_python.html#extending-python-with-mpi-to-run-in-parallel">11.5. Extending Python with MPI to run in parallel</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_python.html#testing-the-python-lammps-interface">11.6. Testing the Python-LAMMPS interface</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_python.html#using-lammps-from-python">11.7. Using LAMMPS from Python</a></li>
<li class="toctree-l2"><a class="reference internal" href="Section_python.html#example-python-scripts-that-use-lammps">11.8. Example Python scripts that use LAMMPS</a></li>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<a class="reference internal" href="if.html"><span class="doc">if</span></a>, and <a class="reference internal" href="python.html"><span class="doc">python</span></a> commands for examples.</p>
<p>A “#” or “$” character that is between quotes will not be treated as a
comment indicator in (2) or substituted for as a variable in (3).</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If the argument is itself a command that requires a quoted
argument (e.g. using a <a class="reference internal" href="print.html"><span class="doc">print</span></a> command as part of an
<a class="reference internal" href="if.html"><span class="doc">if</span></a> or <a class="reference internal" href="run.html"><span class="doc">run every</span></a> command), then single, double, or
triple quotes can be nested in the usual manner. See the doc pages
for those commands for examples. Only one of level of nesting is
allowed, but that should be sufficient for most use cases.</p>
<p>This section describes the structure of a typical LAMMPS input script.
The “examples” directory in the LAMMPS distribution contains many
sample input scripts; the corresponding problems are discussed in
<a class="reference internal" href="Section_example.html"><span class="doc">Section_example</span></a>, and animated on the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a>.</p>
<p>A LAMMPS input script typically has 4 parts:</p>
<ol class="arabic simple">
<li>Initialization</li>
<li>Atom definition</li>
<li>Settings</li>
<li>Run a simulation</li>
</ol>
<p>The last 2 parts can be repeated as many times as desired. I.e. run a
simulation, change some settings, run some more, etc. Each of the 4
parts is now described in more detail. Remember that almost all the
commands need only be used if a non-default value is desired.</p>
<ol class="arabic simple">
<li>Initialization</li>
</ol>
<p>Set parameters that need to be defined before atoms are created or
read-in from a file.</p>
<p>The relevant commands are <a class="reference internal" href="units.html"><span class="doc">units</span></a>,
<p>Output options are set by the <a class="reference internal" href="thermo.html"><span class="doc">thermo</span></a>, <a class="reference internal" href="dump.html"><span class="doc">dump</span></a>,
and <a class="reference internal" href="restart.html"><span class="doc">restart</span></a> commands.</p>
<ol class="arabic simple" start="4">
<li>Run a simulation</li>
</ol>
<p>A molecular dynamics simulation is run using the <a class="reference internal" href="run.html"><span class="doc">run</span></a>
command. Energy minimization (molecular statics) is performed using
the <a class="reference internal" href="minimize.html"><span class="doc">minimize</span></a> command. A parallel tempering
(replica-exchange) simulation can be run using the
<p>This section lists all LAMMPS commands alphabetically, with a separate
listing below of styles within certain commands. The <a class="reference internal" href="#cmd-4"><span class="std std-ref">previous section</span></a> lists the same commands, grouped by category. Note
that some style options for some commands are part of specific LAMMPS
packages, which means they cannot be used unless the package was
included when LAMMPS was built. Not all packages are included in a
default LAMMPS build. These dependencies are listed as Restrictions
<p>See the <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> command for one-line descriptions of
each style or click on the style itself for a full description. Some
of the styles have accelerated versions, which can be used if LAMMPS
is built with the <a class="reference internal" href="Section_accelerate.html"><span class="doc">appropriate accelerated package</span></a>. This is indicated by additional
letters in parenthesis: g = GPU, i = USER-INTEL, k =
<p>These are additional compute styles in USER packages, which can be
used if <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">LAMMPS is built with the appropriate package</span></a>.</p>
<p>See the <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> command for an overview of pair
potentials. Click on the style itself for a full description. Many
of the styles have accelerated versions, which can be used if LAMMPS
is built with the <a class="reference internal" href="Section_accelerate.html"><span class="doc">appropriate accelerated package</span></a>. This is indicated by additional
letters in parenthesis: g = GPU, i = USER-INTEL, k =
<p>These are additional pair styles in USER packages, which can be used
if <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">LAMMPS is built with the appropriate package</span></a>.</p>
<p>See the <a class="reference internal" href="bond_style.html"><span class="doc">bond_style</span></a> command for an overview of bond
potentials. Click on the style itself for a full description. Some
of the styles have accelerated versions, which can be used if LAMMPS
is built with the <a class="reference internal" href="Section_accelerate.html"><span class="doc">appropriate accelerated package</span></a>. This is indicated by additional
letters in parenthesis: g = GPU, i = USER-INTEL, k =
<p>These are additional bond styles in USER packages, which can be used
if <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">LAMMPS is built with the appropriate package</span></a>.</p>
<p>See the <a class="reference internal" href="angle_style.html"><span class="doc">angle_style</span></a> command for an overview of
angle potentials. Click on the style itself for a full description.
Some of the styles have accelerated versions, which can be used if
LAMMPS is built with the <a class="reference internal" href="Section_accelerate.html"><span class="doc">appropriate accelerated package</span></a>. This is indicated by additional
letters in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o =
<p>These are additional angle styles in USER packages, which can be used
if <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">LAMMPS is built with the appropriate package</span></a>.</p>
<p>See the <a class="reference internal" href="dihedral_style.html"><span class="doc">dihedral_style</span></a> command for an overview
of dihedral potentials. Click on the style itself for a full
description. Some of the styles have accelerated versions, which can
be used if LAMMPS is built with the <a class="reference internal" href="Section_accelerate.html"><span class="doc">appropriate accelerated package</span></a>. This is indicated by additional
letters in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o =
<p>These are additional dihedral styles in USER packages, which can be
used if <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">LAMMPS is built with the appropriate package</span></a>.</p>
<p>See the <a class="reference internal" href="improper_style.html"><span class="doc">improper_style</span></a> command for an overview
of improper potentials. Click on the style itself for a full
description. Some of the styles have accelerated versions, which can
be used if LAMMPS is built with the <a class="reference internal" href="Section_accelerate.html"><span class="doc">appropriate accelerated package</span></a>. This is indicated by additional
letters in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o =
<p>These are additional improper styles in USER packages, which can be
used if <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">LAMMPS is built with the appropriate package</span></a>.</p>
<p>See the <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command for an overview of
Kspace solvers. Click on the style itself for a full description.
Some of the styles have accelerated versions, which can be used if
LAMMPS is built with the <a class="reference internal" href="Section_accelerate.html"><span class="doc">appropriate accelerated package</span></a>. This is indicated by additional
letters in parenthesis: g = GPU, i = USER-INTEL, k = KOKKOS, o =
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<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 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 “gpu” style corresponds to the
GPU package, the “intel” style to the USER-INTEL package, the “kk”
style to the KOKKOS package, the “opt” style to the OPT package, and
the “omp” style to the USER-OMP package. The hybrid style is the only
style that accepts arguments. It allows for two packages to be
specified. The first package specified is the default and will be used
if it is available. If no style is available for the first package,
the style for the second package will be used if available. For
example, “-suffix hybrid intel omp” will use styles from the
USER-INTEL package if they are installed and available, but styles for
the USER-OMP package otherwise.</p>
<p>Along with the “-package” command-line switch, this is a convenient
mechanism for invoking accelerator packages and their options without
having to edit an input script.</p>
<p>As an example, all of the packages provide a <a class="reference internal" href="pair_lj.html"><span class="doc">pair_style lj/cut</span></a> variant, with style names lj/cut/gpu,
lj/cut/intel, lj/cut/kk, lj/cut/omp, and lj/cut/opt. A variant style
can be specified explicitly in your input script, e.g. pair_style
lj/cut/gpu. If the -suffix switch is used the specified suffix
(gpu,intel,kk,omp,opt) is automatically appended whenever your input
script command creates a new <a class="reference internal" href="atom_style.html"><span class="doc">atom</span></a>,
<a class="reference internal" href="run_style.html"><span class="doc">run</span></a> style. If the variant version does not exist,
the standard version is created.</p>
<p>For the GPU package, using this command-line switch also invokes the
default GPU settings, as if the command “package gpu 1” were used at
the top of your input script. These settings can be changed by using
the “-package gpu” command-line switch or the <a class="reference internal" href="package.html"><span class="doc">package gpu</span></a> command in your script.</p>
<p>For the USER-INTEL package, using this command-line switch also
invokes the default USER-INTEL settings, as if the command “package
intel 1” were used at the top of your input script. These settings
can be changed by using the “-package intel” command-line switch or
the <a class="reference internal" href="package.html"><span class="doc">package intel</span></a> command in your script. If the
USER-OMP package is also installed, the hybrid style with “intel omp”
arguments can be used to make the omp suffix a second choice, if a
requested style is not available in the USER-INTEL package. It will
also invoke the default USER-OMP settings, as if the command “package
omp 0” were used at the top of your input script. These settings can
be changed by using the “-package omp” command-line switch or the
<a class="reference internal" href="package.html"><span class="doc">package omp</span></a> command in your script.</p>
<p>For the KOKKOS package, using this command-line switch also invokes
the default KOKKOS settings, as if the command “package kokkos” were
used at the top of your input script. These settings can be changed
by using the “-package kokkos” command-line switch or the <a class="reference internal" href="package.html"><span class="doc">package kokkos</span></a> command in your script.</p>
<p>For the OMP package, using this command-line switch also invokes the
default OMP settings, as if the command “package omp 0” were used at
the top of your input script. These settings can be changed by using
the “-package omp” command-line switch or the <a class="reference internal" href="package.html"><span class="doc">package omp</span></a> command in your script.</p>
<p>The <a class="reference internal" href="suffix.html"><span class="doc">suffix</span></a> command can also be used within an input
script to set a suffix, or to turn off or back on any suffix setting
<p>Specify a variable that will be defined for substitution purposes when
the input script is read. This switch can be used multiple times to
define multiple variables. “Name” is the variable name which can be a
single character (referenced as $x in the input script) or a full
string (referenced as ${abc}). An <a class="reference internal" href="variable.html"><span class="doc">index-style variable</span></a> will be created and populated with the
subsequent values, e.g. a set of filenames. Using this command-line
option is equivalent to putting the line “variable name index value1
value2 ...” at the beginning of the input script. Defining an index
variable as a command-line argument overrides any setting for the same
index variable in the input script, since index variables cannot be
re-defined. See the <a class="reference internal" href="variable.html"><span class="doc">variable</span></a> command for more info on
defining index and other kinds of variables and <a class="reference internal" href="Section_commands.html#cmd-2"><span class="std std-ref">this section</span></a> for more info on using variables
in input scripts.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Currently, the command-line parser looks for arguments that
start with “-” to indicate new switches. Thus you cannot specify
multiple variable values if any of they start with a “-”, e.g. a
negative numeric value. It is OK if the first value1 starts with a
“-”, since it is automatically skipped.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-If you get an error message about an invalid command in your input
-script, you can determine what command is causing the problem by
-looking in the log.lammps file or using the :doc:`echo command <echo>`
-to see it on the screen. If you get an error like "Invalid ...
-style", with ... being fix, compute, pair, etc, it means that you
-mistyped the style name or that the command is part of an optional
-package which was not compiled into your executable. The list of
-available styles in your executable can be listed by using :ref:`the -h command-line argument <start_7>`. The installation
-and compilation of optional packages is explained in the :ref:`installation instructions <start_3>`.
-
-For a given command, LAMMPS expects certain arguments in a specified
-order. If you mess this up, LAMMPS will often flag the error, but it
-may also simply read a bogus argument and assign a value that is
-valid, but not what you wanted. E.g. trying to read the string "abc"
-as an integer value of 0. Careful reading of the associated doc page
-for the command should allow you to fix these problems. Note that
-some commands allow for variables to be specified in place of numeric
-constants so that the value can be evaluated and change over the
-course of a run. This is typically done with the syntax *v_name* for
-a parameter, where name is the name of the variable. This is only
-allowed if the command documentation says it is.
-
-Generally, LAMMPS will print a message to the screen and logfile and
-exit gracefully when it encounters a fatal error. Sometimes it will
-print a WARNING to the screen and logfile and continue on; you can
-decide if the WARNING is important or not. A WARNING message that is
-generated in the middle of a run is only printed to the screen, not to
-the logfile, to avoid cluttering up thermodynamic output. If LAMMPS
-crashes or hangs without spitting out an error message first then it
-could be a bug (see :ref:`this section <err_2>`) or one of the following
-cases:
-
-LAMMPS runs in the available memory a processor allows to be
-allocated. Most reasonable MD runs are compute limited, not memory
-limited, so this shouldn't be a bottleneck on most platforms. Almost
-all large memory allocations in the code are done via C-style malloc's
-which will generate an error message if you run out of memory.
-Smaller chunks of memory are allocated via C++ "new" statements. If
-you are unlucky you could run out of memory just when one of these
-small requests is made, in which case the code will crash or hang (in
-parallel), since LAMMPS doesn't trap on those errors.
-
-Illegal arithmetic can cause LAMMPS to run slow or crash. This is
-typically due to invalid physics and numerics that your simulation is
-computing. If you see wild thermodynamic values or NaN values in your
-LAMMPS output, something is wrong with your simulation. If you
-suspect this is happening, it is a good idea to print out
-thermodynamic info frequently (e.g. every timestep) via the
-:doc:`thermo <thermo>` so you can monitor what is happening.
-Visualizing the atom movement is also a good idea to insure your model
-is behaving as you expect.
-
-In parallel, one way LAMMPS can hang is due to how different MPI
-implementations handle buffering of messages. If the code hangs
-without an error message, it may be that you need to specify an MPI
-setting or two (usually via an environment variable) to enable
-buffering or boost the sizes of messages that can be buffered.
-
-
-----------
-
-
-.. _err_2:
-
-Reporting bugs
---------------
-
-If you are confident that you have found a bug in LAMMPS, follow these
-steps.
-
-Check the `New features and bug fixes <http://lammps.sandia.gov/bug.html>`_ section of the `LAMMPS WWW site <lws_>`_ to see if the bug has already been reported or fixed or the
-`Unfixed bug <http://lammps.sandia.gov/unbug.html>`_ to see if a fix is
-pending.
-
-Check the `mailing list <http://lammps.sandia.gov/mail.html>`_
-to see if it has been discussed before.
-
-If not, send an email to the mailing list describing the problem with
-any ideas you have as to what is causing it or where in the code the
-problem might be. The developers will ask for more info if needed,
-such as an input script or data files.
-
-The most useful thing you can do to help us fix the bug is to isolate
-the problem. Run it on the smallest number of atoms and fewest number
-of processors and with the simplest input script that reproduces the
-bug and try to identify what command or combination of commands is
-causing the problem.
-
-As a last resort, you can send an email directly to the
- This is not allowed if the kspace_modify overlap setting is no.
-
-*PPPM order < minimum allowed order*
- The default minimum order is 2. This can be reset by the
- kspace_modify minorder command.
-
-*PPPM order cannot be < 2 or > than %d*
- This is a limitation of the PPPM implementation in LAMMPS.
-
-*PPPMDisp Coulomb grid is too large*
- The global PPPM grid is larger than OFFSET in one or more dimensions.
- OFFSET is currently set to 4096. You likely need to decrease the
- requested accuracy.
-
-*PPPMDisp Dispersion grid is too large*
- The global PPPM grid is larger than OFFSET in one or more dimensions.
- OFFSET is currently set to 4096. You likely need to decrease the
- requested accuracy.
-
-*PPPMDisp can only currently be used with comm_style brick*
- This is a current restriction in LAMMPS.
-
-*PPPMDisp coulomb order cannot be greater than %d*
- This is a limitation of the PPPM implementation in LAMMPS.
-
-*PPPMDisp used but no parameters set, for further information please see the pppm/disp documentation*
- An efficient and accurate usage of the pppm/disp requires settings via the kspace_modify command. Please see the pppm/disp documentation for further instructions.
-
-*PRD command before simulation box is defined*
- The prd command cannot be used before a read_data,
- read_restart, or create_box command.
-
-*PRD nsteps must be multiple of t_event*
- Self-explanatory.
-
-*PRD t_corr must be multiple of t_event*
- Self-explanatory.
-
-*Package command after simulation box is defined*
- The package command cannot be used afer a read_data, read_restart, or
- create_box command.
-
-*Package cuda command without USER-CUDA package enabled*
- The USER-CUDA package must be installed via "make yes-user-cuda"
- before LAMMPS is built, and the "-c on" must be used to enable the
- package.
-
-*Package gpu command without GPU package installed*
- The GPU package must be installed via "make yes-gpu" before LAMMPS is
- built.
-
-*Package intel command without USER-INTEL package installed*
- The USER-INTEL package must be installed via "make yes-user-intel"
- before LAMMPS is built.
-
-*Package kokkos command without KOKKOS package enabled*
- The KOKKOS package must be installed via "make yes-kokkos" before
- LAMMPS is built, and the "-k on" must be used to enable the package.
-
-*Package omp command without USER-OMP package installed*
- The USER-OMP package must be installed via "make yes-user-omp" before
- LAMMPS is built.
-
-*Pair body requires atom style body*
- Self-explanatory.
-
-*Pair body requires body style nparticle*
- This pair style is specific to the nparticle body style.
-
-*Pair brownian requires atom style sphere*
- Self-explanatory.
-
-*Pair brownian requires extended particles*
- One of the particles has radius 0.0.
-
-*Pair brownian requires monodisperse particles*
- All particles must be the same finite size.
-
-*Pair brownian/poly requires atom style sphere*
- Self-explanatory.
-
-*Pair brownian/poly requires extended particles*
- One of the particles has radius 0.0.
-
-*Pair brownian/poly requires newton pair off*
- Self-explanatory.
-
-*Pair coeff for hybrid has invalid style*
- Style in pair coeff must have been listed in pair_style command.
-
-*Pair coul/wolf requires atom attribute q*
- The atom style defined does not have this attribute.
-
-*Pair cutoff < Respa interior cutoff*
- One or more pairwise cutoffs are too short to use with the specified
- rRESPA cutoffs.
-
-*Pair dipole/cut requires atom attributes q, mu, torque*
- The atom style defined does not have these attributes.
-
-*Pair dipole/cut/gpu requires atom attributes q, mu, torque*
- The atom style defined does not have this attribute.
-
-*Pair dipole/long requires atom attributes q, mu, torque*
- The atom style defined does not have these attributes.
-
-*Pair dipole/sf/gpu requires atom attributes q, mu, torque*
- The atom style defined does not one or more of these attributes.
-
-*Pair distance < table inner cutoff*
- Two atoms are closer together than the pairwise table allows.
-
-*Pair distance > table outer cutoff*
- Two atoms are further apart than the pairwise table allows.
-
-*Pair dpd requires ghost atoms store velocity*
- Use the comm_modify vel yes command to enable this.
-
-*Pair gayberne epsilon a,b,c coeffs are not all set*
- Each atom type involved in pair_style gayberne must
- have these 3 coefficients set at least once.
-
-*Pair gayberne requires atom style ellipsoid*
- Self-explanatory.
-
-*Pair gayberne requires atoms with same type have same shape*
- Self-explanatory.
-
-*Pair gayberne/gpu requires atom style ellipsoid*
- Self-explanatory.
-
-*Pair gayberne/gpu requires atoms with same type have same shape*
- Self-explanatory.
-
-*Pair granular requires atom attributes radius, rmass*
- The atom style defined does not have these attributes.
-
-*Pair granular requires ghost atoms store velocity*
- Use the comm_modify vel yes command to enable this.
-
-*Pair granular with shear history requires newton pair off*
- This is a current restriction of the implementation of pair
- granular styles with history.
-
-*Pair hybrid single calls do not support per sub-style special bond values*
- Self-explanatory.
-
-*Pair hybrid sub-style does not support single call*
- You are attempting to invoke a single() call on a pair style
- that doesn't support it.
-
-*Pair hybrid sub-style is not used*
- No pair_coeff command used a sub-style specified in the pair_style
- command.
-
-*Pair inner cutoff < Respa interior cutoff*
- One or more pairwise cutoffs are too short to use with the specified
- rRESPA cutoffs.
-
-*Pair inner cutoff >= Pair outer cutoff*
- The specified cutoffs for the pair style are inconsistent.
-
-*Pair line/lj requires atom style line*
- Self-explanatory.
-
-*Pair lj/long/dipole/long requires atom attributes mu, torque*
- The atom style defined does not have these attributes.
-
-*Pair lubricate requires atom style sphere*
- Self-explanatory.
-
-*Pair lubricate requires ghost atoms store velocity*
- Use the comm_modify vel yes command to enable this.
-*Pair style hbond/dreiding requires newton pair on*
- See the newton command for details.
-
-*Pair style hybrid cannot have hybrid as an argument*
- Self-explanatory.
-
-*Pair style hybrid cannot have none as an argument*
- Self-explanatory.
-
-*Pair style is incompatible with KSpace style*
- If a pair style with a long-range Coulombic component is selected,
- then a kspace style must also be used.
-
-*Pair style is incompatible with TIP4P KSpace style*
- The pair style does not have the requires TIP4P settings.
-
-*Pair style lj/charmm/coul/charmm requires atom attribute q*
- The atom style defined does not have these attributes.
-
-*Pair style lj/charmm/coul/long requires atom attribute q*
- The atom style defined does not have these attributes.
-
-*Pair style lj/charmm/coul/long/gpu requires atom attribute q*
- The atom style defined does not have this attribute.
-
-*Pair style lj/class2/coul/cut requires atom attribute q*
- The atom style defined does not have this attribute.
-
-*Pair style lj/class2/coul/long requires atom attribute q*
- The atom style defined does not have this attribute.
-
-*Pair style lj/class2/coul/long/gpu requires atom attribute q*
- The atom style defined does not have this attribute.
-
-*Pair style lj/cut/coul/cut requires atom attribute q*
- The atom style defined does not have this attribute.
-
-*Pair style lj/cut/coul/cut/gpu requires atom attribute q*
- The atom style defined does not have this attribute.
-
-*Pair style lj/cut/coul/debye/gpu requires atom attribute q*
- The atom style defined does not have this attribute.
-
-*Pair style lj/cut/coul/dsf requires atom attribute q*
- The atom style defined does not have these attributes.
-
-*Pair style lj/cut/coul/dsf/gpu requires atom attribute q*
- The atom style defined does not have this attribute.
-
-*Pair style lj/cut/coul/long requires atom attribute q*
- The atom style defined does not have this attribute.
-
-*Pair style lj/cut/coul/long/gpu requires atom attribute q*
- The atom style defined does not have this attribute.
-
-*Pair style lj/cut/tip4p/cut requires atom IDs*
- This is a requirement to use this potential.
-
-*Pair style lj/cut/tip4p/cut requires atom attribute q*
- The atom style defined does not have this attribute.
-
-*Pair style lj/cut/tip4p/cut requires newton pair on*
- See the newton command. This is a restriction to use this
- potential.
-
-*Pair style lj/cut/tip4p/long requires atom IDs*
- There are no atom IDs defined in the system and the TIP4P potential
- requires them to find O,H atoms with a water molecule.
-
-*Pair style lj/cut/tip4p/long requires atom attribute q*
- The atom style defined does not have these attributes.
-
-*Pair style lj/cut/tip4p/long requires newton pair on*
- This is because the computation of constraint forces within a water
- molecule adds forces to atoms owned by other processors.
-
-*Pair style lj/gromacs/coul/gromacs requires atom attribute q*
- An atom_style with this attribute is needed.
-
-*Pair style lj/long/dipole/long does not currently support respa*
- This feature is not yet supported.
-
-*Pair style lj/long/tip4p/long requires atom IDs*
- There are no atom IDs defined in the system and the TIP4P potential
- requires them to find O,H atoms with a water molecule.
-
-*Pair style lj/long/tip4p/long requires atom attribute q*
- The atom style defined does not have these attributes.
-
-*Pair style lj/long/tip4p/long requires newton pair on*
- This is because the computation of constraint forces within a water
- molecule adds forces to atoms owned by other processors.
-
-*Pair style lj/sdk/coul/long/gpu requires atom attribute q*
- The atom style defined does not have this attribute.
-
-*Pair style nb3b/harmonic requires atom IDs*
- This is a requirement to use this potential.
-
-*Pair style nb3b/harmonic requires newton pair on*
- See the newton command. This is a restriction to use this potential.
-
-*Pair style nm/cut/coul/cut requires atom attribute q*
- The atom style defined does not have this attribute.
-
-*Pair style nm/cut/coul/long requires atom attribute q*
- The atom style defined does not have this attribute.
-
-*Pair style peri requires atom style peri*
- Self-explanatory.
-
-*Pair style polymorphic requires atom IDs*
- This is a requirement to use the polymorphic potential.
-
-*Pair style polymorphic requires newton pair on*
- See the newton command. This is a restriction to use the polymorphic
- potential.
-
-*Pair style reax requires atom IDs*
- This is a requirement to use the ReaxFF potential.
-
-*Pair style reax requires atom attribute q*
- The atom style defined does not have this attribute.
-
-*Pair style reax requires newton pair on*
- This is a requirement to use the ReaxFF potential.
-
-*Pair style requires a KSpace style*
- No kspace style is defined.
-
-*Pair style requires use of kspace_style ewald/disp*
- Self-explanatory.
-
-*Pair style sw/gpu requires atom IDs*
- This is a requirement to use this potential.
-
-*Pair style sw/gpu requires newton pair off*
- See the newton command. This is a restriction to use this potential.
-
-*Pair style tersoff/gpu requires atom IDs*
- This is a requirement to use the tersoff/gpu potential.
-
-*Pair style tersoff/gpu requires newton pair off*
- See the newton command. This is a restriction to use this pair style.
-
-*Pair style tip4p/cut requires atom IDs*
- This is a requirement to use this potential.
-
-*Pair style tip4p/cut requires atom attribute q*
- The atom style defined does not have this attribute.
-
-*Pair style tip4p/cut requires newton pair on*
- See the newton command. This is a restriction to use this potential.
-
-*Pair style tip4p/long requires atom IDs*
- There are no atom IDs defined in the system and the TIP4P potential
- requires them to find O,H atoms with a water molecule.
-
-*Pair style tip4p/long requires atom attribute q*
- The atom style defined does not have these attributes.
-
-*Pair style tip4p/long requires newton pair on*
- This is because the computation of constraint forces within a water
- molecule adds forces to atoms owned by other processors.
-
-*Pair table cutoffs must all be equal to use with KSpace*
- When using pair style table with a long-range KSpace solver, the
- cutoffs for all atom type pairs must all be the same, since the
- long-range solver starts at that cutoff.
-
-*Pair table parameters did not set N*
- List of pair table parameters must include N setting.
-
-*Pair tersoff/zbl requires metal or real units*
- This is a current restriction of this pair potential.
-
-*Pair tersoff/zbl/kk requires metal or real units*
- This is a current restriction of this pair potential.
-
-*Pair tri/lj requires atom style tri*
- Self-explanatory.
-
-*Pair yukawa/colloid requires atom style sphere*
- Self-explantory.
-
-*Pair yukawa/colloid requires atoms with same type have same radius*
- Self-explantory.
-
-*Pair yukawa/colloid/gpu requires atom style sphere*
- Self-explanatory.
-
-*PairKIM only works with 3D problems*
- This is a current limitation.
-
-*Pair_coeff command before pair_style is defined*
- Self-explanatory.
-
-*Pair_coeff command before simulation box is defined*
- The pair_coeff command cannot be used before a read_data,
- read_restart, or create_box command.
-
-*Pair_modify command before pair_style is defined*
- Self-explanatory.
-
-*Pair_modify special setting for pair hybrid incompatible with global special_bonds setting*
- Cannot override a setting of 0.0 or 1.0 or change a setting between
- 0.0 and 1.0.
-
-*Pair_write command before pair_style is defined*
- Self-explanatory.
-
-*Particle on or inside fix wall surface*
- Particles must be "exterior" to the wall in order for energy/force to
- be calculated.
-
-*Particle outside surface of region used in fix wall/region*
- Particles must be inside the region for energy/force to be calculated.
- A particle outside the region generates an error.
-
-*Per-atom compute in equal-style variable formula*
- Equal-style variables cannot use per-atom quantities.
-
-*Per-atom energy was not tallied on needed timestep*
- You are using a thermo keyword that requires potentials to
- have tallied energy, but they didn't on this timestep. See the
- variable doc page for ideas on how to make this work.
-
-*Per-atom fix in equal-style variable formula*
- Equal-style variables cannot use per-atom quantities.
-
-*Per-atom virial was not tallied on needed timestep*
- You are using a thermo keyword that requires potentials to have
- tallied the virial, but they didn't on this timestep. See the
- variable doc page for ideas on how to make this work.
-
-*Per-processor system is too big*
- The number of owned atoms plus ghost atoms on a single
- processor must fit in 32-bit integer.
-
-*Potential energy ID for fix neb does not exist*
- Self-explanatory.
-
-*Potential energy ID for fix nvt/nph/npt does not exist*
- A compute for potential energy must be defined.
-
-*Potential file has duplicate entry*
- The potential file has more than one entry for the same element.
-
-*Potential file is missing an entry*
- The potential file does not have a needed entry.
-
-*Power by 0 in variable formula*
- Self-explanatory.
-
-*Pressure ID for fix box/relax does not exist*
- The compute ID needed to compute pressure for the fix does not
- exist.
-
-*Pressure ID for fix modify does not exist*
- Self-explanatory.
-
-*Pressure ID for fix npt/nph does not exist*
- Self-explanatory.
-
-*Pressure ID for fix press/berendsen does not exist*
- The compute ID needed to compute pressure for the fix does not
- exist.
-
-*Pressure ID for fix rigid npt/nph does not exist*
- Self-explanatory.
-
-*Pressure ID for thermo does not exist*
- The compute ID needed to compute pressure for thermodynamics does not
- exist.
-
-*Pressure control can not be used with fix nvt*
- Self-explanatory.
-
-*Pressure control can not be used with fix nvt/asphere*
- Self-explanatory.
-
-*Pressure control can not be used with fix nvt/body*
- Self-explanatory.
-
-*Pressure control can not be used with fix nvt/sllod*
- Self-explanatory.
-
-*Pressure control can not be used with fix nvt/sphere*
- Self-explanatory.
-
-*Pressure control must be used with fix nph*
- Self-explanatory.
-
-*Pressure control must be used with fix nph/asphere*
- Self-explanatory.
-
-*Pressure control must be used with fix nph/body*
- Self-explanatory.
-
-*Pressure control must be used with fix nph/small*
- Self-explanatory.
-
-*Pressure control must be used with fix nph/sphere*
- Self-explanatory.
-
-*Pressure control must be used with fix nphug*
- A pressure control keyword (iso, aniso, tri, x, y, or z) must be
- provided.
-
-*Pressure control must be used with fix npt*
- Self-explanatory.
-
-*Pressure control must be used with fix npt/asphere*
- Self-explanatory.
-
-*Pressure control must be used with fix npt/body*
- Self-explanatory.
-
-*Pressure control must be used with fix npt/sphere*
- Self-explanatory.
-
-*Processor count in z must be 1 for 2d simulation*
- Self-explanatory.
-
-*Processor partitions do not match number of allocated processors*
- The total number of processors in all partitions must match the number
- of processors LAMMPS is running on.
-
-*Processors command after simulation box is defined*
- The processors command cannot be used after a read_data, read_restart,
- or create_box command.
-
-*Processors custom grid file is inconsistent*
- The vales in the custom file are not consistent with the number of
- processors you are running on or the Px,Py,Pz settings of the
- processors command. Or there was not a setting for every processor.
-
-*Processors grid numa and map style are incompatible*
- Using numa for gstyle in the processors command requires using
- cart for the map option.
-
-*Processors part option and grid style are incompatible*
- Cannot use gstyle numa or custom with the part option.
-
-*Processors twogrid requires proc count be a multiple of core count*
- Self-explanatory.
-
-*Pstart and Pstop must have the same value*
- Self-explanatory.
-
-*Python function evaluation failed*
- The Python function did not run succesfully and/or did not return a
- value (if it is supposed to return a value). This is probably due to
- some error condition in the function.
-
-*Python function is not callable*
- The provided Python code was run successfully, but it not
- define a callable function with the required name.
-
-*Python invoke of undefined function*
- Cannot invoke a function that has not been previously defined.
-
-*Python variable does not match Python function*
- This matching is defined by the python-style variable and the python
- command.
-
-*Python variable has no function*
- No python command was used to define the function associated with the
- python-style variable.
-
-*QEQ with 'newton pair off' not supported*
- See the newton command. This is a restriction to use the QEQ fixes.
-
-*R0 < 0 for fix spring command*
- Equilibrium spring length is invalid.
-
-*RATTLE coordinate constraints are not satisfied up to desired tolerance*
- Self-explanatory.
-
-*RATTLE determinant = 0.0*
- The determinant of the matrix being solved for a single cluster
- specified by the fix rattle command is numerically invalid.
-
-*RATTLE failed*
- Certain constraints were not satisfied.
-
-*RATTLE velocity constraints are not satisfied up to desired tolerance*
- Self-explanatory.
-
-*Read data add offset is too big*
- It cannot be larger than the size of atom IDs, e.g. the maximum 32-bit
- integer.
-
-*Read dump of atom property that isn't allocated*
- Self-explanatory.
-
-*Read rerun dump file timestep > specified stop*
- Self-explanatory.
-
-*Read restart MPI-IO input not allowed with % in filename*
- This is because a % signifies one file per processor and MPI-IO
- creates one large file for all processors.
-
-*Read_data shrink wrap did not assign all atoms correctly*
- This is typically because the box-size specified in the data file is
- large compared to the actual extent of atoms in a shrink-wrapped
- dimension. When LAMMPS shrink-wraps the box atoms will be lost if the
- processor they are re-assigned to is too far away. Choose a box
- size closer to the actual extent of the atoms.
-
-*Read_dump command before simulation box is defined*
- The read_dump command cannot be used before a read_data, read_restart,
- or create_box command.
-
-*Read_dump field not found in dump file*
- Self-explanatory.
-
-*Read_dump triclinic status does not match simulation*
- Both the dump snapshot and the current LAMMPS simulation must
- be using either an orthogonal or triclinic box.
-
-*Read_dump xyz fields do not have consistent scaling/wrapping*
- Self-explanatory.
-
-*Reading from MPI-IO filename when MPIIO package is not installed*
- Self-explanatory.
-
-*Reax_defs.h setting for NATDEF is too small*
- Edit the setting in the ReaxFF library and re-compile the
- library and re-build LAMMPS.
-
-*Reax_defs.h setting for NNEIGHMAXDEF is too small*
- Edit the setting in the ReaxFF library and re-compile the
- library and re-build LAMMPS.
-
-*Receiving partition in processors part command is already a receiver*
- Cannot specify a partition to be a receiver twice.
-
-*Region ID for compute chunk/atom does not exist*
- Self-explanatory.
-
-*Region ID for compute reduce/region does not exist*
- Self-explanatory.
-
-*Region ID for compute temp/region does not exist*
- Self-explanatory.
-
-*Region ID for dump custom does not exist*
- Self-explanatory.
-
-*Region ID for fix addforce does not exist*
- Self-explanatory.
-
-*Region ID for fix atom/swap does not exist*
- Self-explanatory.
-
-*Region ID for fix ave/spatial does not exist*
- Self-explanatory.
-
-*Region ID for fix aveforce does not exist*
- Self-explanatory.
-
-*Region ID for fix deposit does not exist*
- Self-explanatory.
-
-*Region ID for fix efield does not exist*
- Self-explanatory.
-
-*Region ID for fix evaporate does not exist*
- Self-explanatory.
-
-*Region ID for fix gcmc does not exist*
- Self-explanatory.
-
-*Region ID for fix heat does not exist*
- Self-explanatory.
-
-*Region ID for fix setforce does not exist*
- Self-explanatory.
-
-*Region ID for fix wall/region does not exist*
- Self-explanatory.
-
-*Region ID for group dynamic does not exist*
- Self-explanatory.
-
-*Region ID in variable formula does not exist*
- Self-explanatory.
-
-*Region cannot have 0 length rotation vector*
- Self-explanatory.
-
-*Region for fix oneway does not exist*
- Self-explanatory.
-
-*Region intersect region ID does not exist*
- Self-explanatory.
-
-*Region union or intersect cannot be dynamic*
- The sub-regions can be dynamic, but not the combined region.
-
-*Region union region ID does not exist*
- One or more of the region IDs specified by the region union command
- does not exist.
-
-*Replacing a fix, but new style != old style*
- A fix ID can be used a 2nd time, but only if the style matches the
- previous fix. In this case it is assumed you with to reset a fix's
- parameters. This error may mean you are mistakenly re-using a fix ID
- when you do not intend to.
-
-*Replicate command before simulation box is defined*
- The replicate command cannot be used before a read_data, read_restart,
- or create_box command.
-
-*Replicate did not assign all atoms correctly*
- Atoms replicated by the replicate command were not assigned correctly
- to processors. This is likely due to some atom coordinates being
- outside a non-periodic simulation box.
-
-*Replicated system atom IDs are too big*
- See the setting for tagint in the src/lmptype.h file.
-
-*Replicated system is too big*
- See the setting for bigint in the src/lmptype.h file.
-
-*Required border comm not yet implemented with Kokkos*
- There are various limitations in the communication options supported
- by Kokkos.
-
-*Rerun command before simulation box is defined*
- The rerun command cannot be used before a read_data, read_restart, or
- create_box command.
-
-*Rerun dump file does not contain requested snapshot*
- Self-explanatory.
-
-*Resetting timestep size is not allowed with fix move*
- This is because fix move is moving atoms based on elapsed time.
-
-*Respa inner cutoffs are invalid*
- The first cutoff must be <= the second cutoff.
-
-*Respa levels must be >= 1*
- Self-explanatory.
-
-*Respa middle cutoffs are invalid*
- The first cutoff must be <= the second cutoff.
-
-*Restart file MPI-IO output not allowed with % in filename*
- This is because a % signifies one file per processor and MPI-IO
- creates one large file for all processors.
-
-*Restart file byte ordering is not recognized*
- The file does not appear to be a LAMMPS restart file since it doesn't
- contain a recognized byte-orderomg flag at the beginning.
-
-*Restart file byte ordering is swapped*
- The file was written on a machine with different byte-ordering than
- the machine you are reading it on. Convert it to a text data file
- instead, on the machine you wrote it on.
-
-*Restart file incompatible with current version*
- This is probably because you are trying to read a file created with a
- version of LAMMPS that is too old compared to the current version.
- Use your older version of LAMMPS and convert the restart file
- to a data file.
-
-*Restart file is a MPI-IO file*
- The file is inconsistent with the filename you specified for it.
-
-*Restart file is a multi-proc file*
- The file is inconsistent with the filename you specified for it.
-
-*Restart file is not a MPI-IO file*
- The file is inconsistent with the filename you specified for it.
-
-*Restart file is not a multi-proc file*
- The file is inconsistent with the filename you specified for it.
-
-*Restart variable returned a bad timestep*
- The variable must return a timestep greater than the current timestep.
-
-*Restrain atoms %d %d %d %d missing on proc %d at step %ld*
- The 4 atoms in a restrain dihedral specified by the fix restrain
- command are not all accessible to a processor. This probably means an
- atom has moved too far.
-
-*Restrain atoms %d %d %d missing on proc %d at step %ld*
- The 3 atoms in a restrain angle specified by the fix restrain
- command are not all accessible to a processor. This probably means an
- atom has moved too far.
-
-*Restrain atoms %d %d missing on proc %d at step %ld*
- The 2 atoms in a restrain bond specified by the fix restrain
- command are not all accessible to a processor. This probably means an
- atom has moved too far.
-
-*Reuse of compute ID*
- A compute ID cannot be used twice.
-
-*Reuse of dump ID*
- A dump ID cannot be used twice.
-
-*Reuse of molecule template ID*
- The template IDs must be unique.
-
-*Reuse of region ID*
- A region ID cannot be used twice.
-
-*Rigid body atoms %d %d missing on proc %d at step %ld*
- This means that an atom cannot find the atom that owns the rigid body
- it is part of, or vice versa. The solution is to use the communicate
- cutoff command to insure ghost atoms are acquired from far enough away
- to encompass the max distance printed when the fix rigid/small command
- was invoked.
-
-*Rigid body has degenerate moment of inertia*
- Fix poems will only work with bodies (collections of atoms) that have
- non-zero principal moments of inertia. This means they must be 3 or
- more non-collinear atoms, even with joint atoms removed.
-
-*Rigid fix must come before NPT/NPH fix*
- NPT/NPH fix must be defined in input script after all rigid fixes,
- else the rigid fix contribution to the pressure virial is
- incorrect.
-
-*Rmask function in equal-style variable formula*
- Rmask is per-atom operation.
-
-*Run command before simulation box is defined*
- The run command cannot be used before a read_data, read_restart, or
- create_box command.
-
-*Run command start value is after start of run*
- Self-explanatory.
-
-*Run command stop value is before end of run*
- Self-explanatory.
-
-*Run_style command before simulation box is defined*
- The run_style command cannot be used before a read_data,
- read_restart, or create_box command.
-
-*SRD bin size for fix srd differs from user request*
- Fix SRD had to adjust the bin size to fit the simulation box. See the
- cubic keyword if you want this message to be an error vs warning.
-
-*SRD bins for fix srd are not cubic enough*
- The bin shape is not within tolerance of cubic. See the cubic
- keyword if you want this message to be an error vs warning.
-
-*SRD particle %d started inside big particle %d on step %ld bounce %d*
- See the inside keyword if you want this message to be an error vs
- warning.
-
-*SRD particle %d started inside wall %d on step %ld bounce %d*
- See the inside keyword if you want this message to be an error vs
- warning.
-
-*Same dimension twice in fix ave/spatial*
- Self-explanatory.
-
-*Sending partition in processors part command is already a sender*
- Cannot specify a partition to be a sender twice.
-
-*Set command before simulation box is defined*
- The set command cannot be used before a read_data, read_restart,
- or create_box command.
-
-*Set command floating point vector does not exist*
- Self-explanatory.
-
-*Set command integer vector does not exist*
- Self-explanatory.
-
-*Set command with no atoms existing*
- No atoms are yet defined so the set command cannot be used.
-
-*Set region ID does not exist*
- Region ID specified in set command does not exist.
-
-*Shake angles have different bond types*
- All 3-atom angle-constrained SHAKE clusters specified by the fix shake
- command that are the same angle type, must also have the same bond
- types for the 2 bonds in the angle.
-
-*Shake atoms %d %d %d %d missing on proc %d at step %ld*
- The 4 atoms in a single shake cluster specified by the fix shake
- command are not all accessible to a processor. This probably means
- an atom has moved too far.
-
-*Shake atoms %d %d %d missing on proc %d at step %ld*
- The 3 atoms in a single shake cluster specified by the fix shake
- command are not all accessible to a processor. This probably means
- an atom has moved too far.
-
-*Shake atoms %d %d missing on proc %d at step %ld*
- The 2 atoms in a single shake cluster specified by the fix shake
- command are not all accessible to a processor. This probably means
- an atom has moved too far.
-
-*Shake cluster of more than 4 atoms*
- A single cluster specified by the fix shake command can have no more
- than 4 atoms.
-
-*Shake clusters are connected*
- A single cluster specified by the fix shake command must have a single
- central atom with up to 3 other atoms bonded to it.
-
-*Shake determinant = 0.0*
- The determinant of the matrix being solved for a single cluster
- specified by the fix shake command is numerically invalid.
-
-*Shake fix must come before NPT/NPH fix*
- NPT fix must be defined in input script after SHAKE fix, else the
- SHAKE fix contribution to the pressure virial is incorrect.
-
-*Shear history overflow, boost neigh_modify one*
- There are too many neighbors of a single atom. Use the neigh_modify
- command to increase the max number of neighbors allowed for one atom.
- You may also want to boost the page size.
-
-*Small to big integers are not sized correctly*
- This error occurs whenthe sizes of smallint, imageint, tagint, bigint,
- as defined in src/lmptype.h are not what is expected. Contact
- the developers if this occurs.
-
-*Smallint setting in lmptype.h is invalid*
- It has to be the size of an integer.
-
-*Smallint setting in lmptype.h is not compatible*
- Smallint stored in restart file is not consistent with LAMMPS version
- you are running.
-
-*Special list size exceeded in fix bond/create*
- See the read_data command for info on setting the "extra special per
- atom" header value to allow for additional special values to be
- stored.
-
-*Specified processors != physical processors*
- The 3d grid of processors defined by the processors command does not
- match the number of processors LAMMPS is being run on.
-
-*Specified target stress must be uniaxial or hydrostatic*
- Self-explanatory.
-
-*Sqrt of negative value in variable formula*
- Self-explanatory.
-
-*Subsequent read data induced too many angles per atom*
- See the create_box extra/angle/per/atom or read_data "extra angle per
- atom" header value to set this limit larger.
-
-*Subsequent read data induced too many bonds per atom*
- See the create_box extra/bond/per/atom or read_data "extra bond per
- atom" header value to set this limit larger.
-
-*Subsequent read data induced too many dihedrals per atom*
- See the create_box extra/dihedral/per/atom or read_data "extra
- dihedral per atom" header value to set this limit larger.
-
-*Subsequent read data induced too many impropers per atom*
- See the create_box extra/improper/per/atom or read_data "extra
- improper per atom" header value to set this limit larger.
-
-*Substitution for illegal variable*
- Input script line contained a variable that could not be substituted
- for.
-
-*Support for writing images in JPEG format not included*
- LAMMPS was not built with the -DLAMMPS_JPEG switch in the Makefile.
-
-*Support for writing images in PNG format not included*
- LAMMPS was not built with the -DLAMMPS_PNG switch in the Makefile.
-
-*Support for writing movies not included*
- LAMMPS was not built with the -DLAMMPS_FFMPEG switch in the Makefile
-
-*System in data file is too big*
- See the setting for bigint in the src/lmptype.h file.
-
-*System is not charge neutral, net charge = %g*
- The total charge on all atoms on the system is not 0.0.
- For some KSpace solvers this is an error.
-
-*TAD nsteps must be multiple of t_event*
- Self-explanatory.
-
-*TIP4P hydrogen has incorrect atom type*
- The TIP4P pairwise computation found an H atom whose type does not
- agree with the specified H type.
-
-*TIP4P hydrogen is missing*
- The TIP4P pairwise computation failed to find the correct H atom
- within a water molecule.
-
-*TMD target file did not list all group atoms*
- The target file for the fix tmd command did not list all atoms in the
- fix group.
-
-*Tad command before simulation box is defined*
- Self-explanatory.
-
-*Tagint setting in lmptype.h is invalid*
- Tagint must be as large or larger than smallint.
-
-*Tagint setting in lmptype.h is not compatible*
- Format of tagint stored in restart file is not consistent with LAMMPS
- version you are running. See the settings in src/lmptype.h
-
-*Target pressure for fix rigid/nph cannot be < 0.0*
- Self-explanatory.
-
-*Target pressure for fix rigid/npt/small cannot be < 0.0*
- Self-explanatory.
-
-*Target temperature for fix nvt/npt/nph cannot be 0.0*
- Self-explanatory.
-
-*Target temperature for fix rigid/npt cannot be 0.0*
- Self-explanatory.
-
-*Target temperature for fix rigid/npt/small cannot be 0.0*
- Self-explanatory.
-
-*Target temperature for fix rigid/nvt cannot be 0.0*
- Self-explanatory.
-
-*Target temperature for fix rigid/nvt/small cannot be 0.0*
- Self-explanatory.
-
-*Temper command before simulation box is defined*
- The temper command cannot be used before a read_data, read_restart, or
- create_box command.
-
-*Temperature ID for fix bond/swap does not exist*
- Self-explanatory.
-
-*Temperature ID for fix box/relax does not exist*
- Self-explanatory.
-
-*Temperature ID for fix nvt/npt does not exist*
- Self-explanatory.
-
-*Temperature ID for fix press/berendsen does not exist*
- Self-explanatory.
-
-*Temperature ID for fix rigid nvt/npt/nph does not exist*
- Self-explanatory.
-
-*Temperature ID for fix temp/berendsen does not exist*
- Self-explanatory.
-
-*Temperature ID for fix temp/csld does not exist*
- Self-explanatory.
-
-*Temperature ID for fix temp/csvr does not exist*
- Self-explanatory.
-
-*Temperature ID for fix temp/rescale does not exist*
- Self-explanatory.
-
-*Temperature compute degrees of freedom < 0*
- This should not happen if you are calculating the temperature
- on a valid set of atoms.
-
-*Temperature control can not be used with fix nph*
- Self-explanatory.
-
-*Temperature control can not be used with fix nph/asphere*
- Self-explanatory.
-
-*Temperature control can not be used with fix nph/body*
- Self-explanatory.
-
-*Temperature control can not be used with fix nph/sphere*
- Self-explanatory.
-
-*Temperature control must be used with fix nphug*
- The temp keyword must be provided.
-
-*Temperature control must be used with fix npt*
- Self-explanatory.
-
-*Temperature control must be used with fix npt/asphere*
- Self-explanatory.
-
-*Temperature control must be used with fix npt/body*
- Self-explanatory.
-
-*Temperature control must be used with fix npt/sphere*
- Self-explanatory.
-
-*Temperature control must be used with fix nvt*
- Self-explanatory.
-
-*Temperature control must be used with fix nvt/asphere*
- Self-explanatory.
-
-*Temperature control must be used with fix nvt/body*
- Self-explanatory.
-
-*Temperature control must be used with fix nvt/sllod*
- Self-explanatory.
-
-*Temperature control must be used with fix nvt/sphere*
- Self-explanatory.
-
-*Temperature control must not be used with fix nph/small*
- Self-explanatory.
-
-*Temperature for fix nvt/sllod does not have a bias*
- The specified compute must compute temperature with a bias.
-
-*Tempering could not find thermo_pe compute*
- This compute is created by the thermo command. It must have been
- explicitly deleted by a uncompute command.
-
-*Tempering fix ID is not defined*
- The fix ID specified by the temper command does not exist.
-
-*Tempering temperature fix is not valid*
- The fix specified by the temper command is not one that controls
- temperature (nvt or langevin).
-
-*Test_descriptor_string already allocated*
- This is an internal error. Contact the developers.
-
-*The package gpu command is required for gpu styles*
- Self-explanatory.
-
-*Thermo and fix not computed at compatible times*
- Fixes generate values on specific timesteps. The thermo output
- does not match these timesteps.
-
-*Thermo compute array is accessed out-of-range*
- Self-explanatory.
-
-*Thermo compute does not compute array*
- Self-explanatory.
-
-*Thermo compute does not compute scalar*
- Self-explanatory.
-
-*Thermo compute does not compute vector*
- Self-explanatory.
-
-*Thermo compute vector is accessed out-of-range*
- Self-explanatory.
-
-*Thermo custom variable cannot be indexed*
- Self-explanatory.
-
-*Thermo custom variable is not equal-style variable*
- Only equal-style variables can be output with thermodynamics, not
- atom-style variables.
-
-*Thermo every variable returned a bad timestep*
- The variable must return a timestep greater than the current timestep.
-
-*Thermo fix array is accessed out-of-range*
- Self-explanatory.
-
-*Thermo fix does not compute array*
- Self-explanatory.
-
-*Thermo fix does not compute scalar*
- Self-explanatory.
-
-*Thermo fix does not compute vector*
- Self-explanatory.
-
-*Thermo fix vector is accessed out-of-range*
- Self-explanatory.
-
-*Thermo keyword in variable requires thermo to use/init pe*
- You are using a thermo keyword in a variable that requires
- potential energy to be calculated, but your thermo output
- does not use it. Add it to your thermo output.
-
-*Thermo keyword in variable requires thermo to use/init press*
- You are using a thermo keyword in a variable that requires pressure to
- be calculated, but your thermo output does not use it. Add it to your
- thermo output.
-
-*Thermo keyword in variable requires thermo to use/init temp*
- You are using a thermo keyword in a variable that requires temperature
- to be calculated, but your thermo output does not use it. Add it to
- your thermo output.
-
-*Thermo style does not use press*
- Cannot use thermo_modify to set this parameter since the thermo_style
- is not computing this quantity.
-
-*Thermo style does not use temp*
- Cannot use thermo_modify to set this parameter since the thermo_style
- is not computing this quantity.
-
-*Thermo_modify every variable returned a bad timestep*
- The returned timestep is less than or equal to the current timestep.
-
-*Thermo_modify int format does not contain d character*
- Self-explanatory.
-
-*Thermo_modify pressure ID does not compute pressure*
- The specified compute ID does not compute pressure.
-
-*Thermo_modify temperature ID does not compute temperature*
- The specified compute ID does not compute temperature.
-
-*Thermo_style command before simulation box is defined*
- The thermo_style command cannot be used before a read_data,
- read_restart, or create_box command.
-
-*This variable thermo keyword cannot be used between runs*
- Keywords that refer to time (such as cpu, elapsed) do not
- make sense in between runs.
-
-*Threshhold for an atom property that isn't allocated*
- A dump threshhold has been requested on a quantity that is
- not defined by the atom style used in this simulation.
-
-*Timestep must be >= 0*
- Specified timestep is invalid.
-
-*Too big a problem to use velocity create loop all*
- The system size must fit in a 32-bit integer to use this option.
-
-*Too big a timestep for dump dcd*
- The timestep must fit in a 32-bit integer to use this dump style.
-
-*Too big a timestep for dump xtc*
- The timestep must fit in a 32-bit integer to use this dump style.
-
-*Too few bits for lookup table*
- Table size specified via pair_modify command does not work with your
- machine's floating point representation.
-
-*Too few lines in %s section of data file*
- Self-explanatory.
-
-*Too few values in body lines in data file*
- Self-explanatory.
-
-*Too few values in body section of molecule file*
- Self-explanatory.
-
-*Too many -pk arguments in command line*
- The string formed by concatenating the arguments is too long. Use a
- package command in the input script instead.
-
-*Too many MSM grid levels*
- The max number of MSM grid levels is hardwired to 10.
-
-*Too many args in variable function*
- More args are used than any variable function allows.
-
-*Too many atom pairs for pair bop*
- The number of atomic pairs exceeds the expected number. Check your
- atomic structure to ensure that it is realistic.
-
-*Too many atom sorting bins*
- This is likely due to an immense simulation box that has blown up
- to a large size.
-
-*Too many atom triplets for pair bop*
- The number of three atom groups for angle determinations exceeds the
- expected number. Check your atomic structrure to ensure that it is
- realistic.
-
-*Too many atoms for dump dcd*
- The system size must fit in a 32-bit integer to use this dump
- style.
-
-*Too many atoms for dump xtc*
- The system size must fit in a 32-bit integer to use this dump
- style.
-
-*Too many atoms to dump sort*
- Cannot sort when running with more than 2^31 atoms.
-
-*Too many exponent bits for lookup table*
- Table size specified via pair_modify command does not work with your
- machine's floating point representation.
-
-*Too many groups*
- The maximum number of atom groups (including the "all" group) is
- given by MAX_GROUP in group.cpp and is 32.
-
-*Too many iterations*
- You must use a number of iterations that fit in a 32-bit integer
- for minimization.
-
-*Too many lines in one body in data file - boost MAXBODY*
- MAXBODY is a setting at the top of the src/read_data.cpp file.
- Set it larger and re-compile the code.
-
-*Too many local+ghost atoms for neighbor list*
- The number of nlocal + nghost atoms on a processor
- is limited by the size of a 32-bit integer with 2 bits
- removed for masking 1-2, 1-3, 1-4 neighbors.
-
-*Too many mantissa bits for lookup table*
- Table size specified via pair_modify command does not work with your
- machine's floating point representation.
-
-*Too many masses for fix shake*
- The fix shake command cannot list more masses than there are atom
- types.
-
-*Too many molecules for fix poems*
- The limit is 2^31 = ~2 billion molecules.
-
-*Too many molecules for fix rigid*
- The limit is 2^31 = ~2 billion molecules.
-
-*Too many neighbor bins*
- This is likely due to an immense simulation box that has blown up
- to a large size.
-
-*Too many timesteps*
- The cummulative timesteps must fit in a 64-bit integer.
-
-*Too many timesteps for NEB*
- You must use a number of timesteps that fit in a 32-bit integer
- for NEB.
-
-*Too many total atoms*
- See the setting for bigint in the src/lmptype.h file.
-
-*Too many total bits for bitmapped lookup table*
- Table size specified via pair_modify command is too large. Note that
- a value of N generates a 2^N size table.
-
-*Too many values in body lines in data file*
- Self-explanatory.
-
-*Too many values in body section of molecule file*
- Self-explanatory.
-
-*Too much buffered per-proc info for dump*
- The size of the buffered string must fit in a 32-bit integer for a
- dump.
-
-*Too much per-proc info for dump*
- Number of local atoms times number of columns must fit in a 32-bit
- integer for dump.
-
-*Tree structure in joint connections*
- Fix poems cannot (yet) work with coupled bodies whose joints connect
- the bodies in a tree structure.
-
-*Triclinic box skew is too large*
- The displacement in a skewed direction must be less than half the box
- length in that dimension. E.g. the xy tilt must be between -half and
- +half of the x box length. This constraint can be relaxed by using
- the box tilt command.
-
-*Tried to convert a double to int, but input_double > INT_MAX*
- Self-explanatory.
-
-*Trying to build an occasional neighbor list before initialization completed*
- This is not allowed. Source code caller needs to be modified.
-
-*Two fix ave commands using same compute chunk/atom command in incompatible ways*
- They are both attempting to "lock" the chunk/atom command so that the
- chunk assignments persist for some number of timesteps, but are doing
- it in different ways.
-
-*Two groups cannot be the same in fix spring couple*
- Self-explanatory.
-
-*USER-CUDA mode requires CUDA variant of min style*
- CUDA mode is enabled, so the min style must include a cuda suffix.
-
-*USER-CUDA mode requires CUDA variant of run style*
- CUDA mode is enabled, so the run style must include a cuda suffix.
-
-*USER-CUDA package does not yet support comm_style tiled*
- Self-explanatory.
-
-*USER-CUDA package requires a cuda enabled atom_style*
- Self-explanatory.
-
-*Unable to initialize accelerator for use*
- There was a problem initializing an accelerator for the gpu package
-
-*Unbalanced quotes in input line*
- No matching end double quote was found following a leading double
- quote.
-
-*Unexpected end of -reorder file*
- Self-explanatory.
-
-*Unexpected end of AngleCoeffs section*
- Read a blank line.
-
-*Unexpected end of BondCoeffs section*
- Read a blank line.
-
-*Unexpected end of DihedralCoeffs section*
- Read a blank line.
-
-*Unexpected end of ImproperCoeffs section*
- Read a blank line.
-
-*Unexpected end of PairCoeffs section*
- Read a blank line.
-
-*Unexpected end of custom file*
- Self-explanatory.
-
-*Unexpected end of data file*
- LAMMPS hit the end of the data file while attempting to read a
- section. Something is wrong with the format of the data file.
-
-*Unexpected end of dump file*
- A read operation from the file failed.
-
-*Unexpected end of fix rigid file*
- A read operation from the file failed.
-
-*Unexpected end of fix rigid/small file*
- A read operation from the file failed.
-
-*Unexpected end of molecule file*
- Self-explanatory.
-
-*Unexpected end of neb file*
- A read operation from the file failed.
-
-*Units command after simulation box is defined*
- The units command cannot be used after a read_data, read_restart, or
- create_box command.
-
-*Universe/uloop variable count < # of partitions*
- A universe or uloop style variable must specify a number of values >= to the
- number of processor partitions.
-
-*Unknown angle style*
- The choice of angle style is unknown.
-
-*Unknown atom style*
- The choice of atom style is unknown.
-
-*Unknown body style*
- The choice of body style is unknown.
-
-*Unknown bond style*
- The choice of bond style is unknown.
-
-*Unknown category for info is_active()*
- Self-explanatory.
-
-*Unknown category for info is_available()*
- Self-explanatory.
-
-*Unknown category for info is_defined()*
- Self-explanatory.
-
-*Unknown command: %s*
- The command is not known to LAMMPS. Check the input script.
-
-*Unknown compute style*
- The choice of compute style is unknown.
-
-*Unknown dihedral style*
- The choice of dihedral style is unknown.
-
-*Unknown dump reader style*
- The choice of dump reader style via the format keyword is unknown.
-
-*Unknown dump style*
- The choice of dump style is unknown.
-
-*Unknown error in GPU library*
- Self-explanatory.
-
-*Unknown fix style*
- The choice of fix style is unknown.
-
-*Unknown identifier in data file: %s*
- A section of the data file cannot be read by LAMMPS.
-
-*Unknown improper style*
- The choice of improper style is unknown.
-
-*Unknown keyword in thermo_style custom command*
- One or more specified keywords are not recognized.
-
-*Unknown kspace style*
- The choice of kspace style is unknown.
-
-*Unknown name for info newton category*
- Self-explanatory.
-
-*Unknown name for info package category*
- Self-explanatory.
-
-*Unknown name for info pair category*
- Self-explanatory.
-
-*Unknown pair style*
- The choice of pair style is unknown.
-
-*Unknown pair_modify hybrid sub-style*
- The choice of sub-style is unknown.
-
-*Unknown region style*
- The choice of region style is unknown.
-
-*Unknown section in molecule file*
- Self-explanatory.
-
-*Unknown table style in angle style table*
- Self-explanatory.
-
-*Unknown table style in bond style table*
- Self-explanatory.
-
-*Unknown table style in pair_style command*
- Style of table is invalid for use with pair_style table command.
-
-*Unknown unit_style*
- Self-explanatory. Check the input script or data file.
-
-*Unrecognized lattice type in MEAM file 1*
- The lattice type in an entry of the MEAM library file is not
- valid.
-
-*Unrecognized lattice type in MEAM file 2*
- The lattice type in an entry of the MEAM parameter file is not
- valid.
-
-*Unrecognized pair style in compute pair command*
- Self-explanatory.
-
-*Unrecognized virial argument in pair_style command*
- Only two options are supported: LAMMPSvirial and KIMvirial
-
-*Unsupported mixing rule in kspace_style ewald/disp*
- Only geometric mixing is supported.
-
-*Unsupported order in kspace_style ewald/disp*
- Only 1/r^6 dispersion or dipole terms are supported.
-
-*Unsupported order in kspace_style pppm/disp, pair_style %s*
- Only pair styles with 1/r and 1/r^6 dependence are currently supported.
-
-*Use cutoff keyword to set cutoff in single mode*
- Mode is single so cutoff/multi keyword cannot be used.
-
-*Use cutoff/multi keyword to set cutoff in multi mode*
- Mode is multi so cutoff keyword cannot be used.
-
-*Using fix nvt/sllod with inconsistent fix deform remap option*
- Fix nvt/sllod requires that deforming atoms have a velocity profile
- provided by "remap v" as a fix deform option.
-
-*Using fix nvt/sllod with no fix deform defined*
- Self-explanatory.
-
-*Using fix srd with inconsistent fix deform remap option*
- When shearing the box in an SRD simulation, the remap v option for fix
- deform needs to be used.
-
-*Using pair lubricate with inconsistent fix deform remap option*
- Must use remap v option with fix deform with this pair style.
-
-*Using pair lubricate/poly with inconsistent fix deform remap option*
- If fix deform is used, the remap v option is required.
-
-*Using suffix cuda without USER-CUDA package enabled*
- Self-explanatory.
-
-*Using suffix gpu without GPU package installed*
- Self-explanatory.
-
-*Using suffix intel without USER-INTEL package installed*
- Self-explanatory.
-
-*Using suffix kk without KOKKOS package enabled*
- Self-explanatory.
-
-*Using suffix omp without USER-OMP package installed*
- Self-explanatory.
-
-*Using update dipole flag requires atom attribute mu*
- Self-explanatory.
-
-*Using update dipole flag requires atom style sphere*
- Self-explanatory.
-
-*Variable ID in variable formula does not exist*
- Self-explanatory.
-
-*Variable atom ID is too large*
- Specified ID is larger than the maximum allowed atom ID.
-
-*Variable evaluation before simulation box is defined*
- Cannot evaluate a compute or fix or atom-based value in a variable
- before the simulation has been setup.
-
-*Variable evaluation in fix wall gave bad value*
- The returned value for epsilon or sigma < 0.0.
-
-*Variable evaluation in region gave bad value*
- Variable returned a radius < 0.0.
-
-*Variable for compute ti is invalid style*
- Self-explanatory.
-
-*Variable for create_atoms is invalid style*
- The variables must be equal-style variables.
-
-*Variable for displace_atoms is invalid style*
- It must be an equal-style or atom-style variable.
-
-*Variable for dump every is invalid style*
- Only equal-style variables can be used.
-
-*Variable for dump image center is invalid style*
- Must be an equal-style variable.
-
-*Variable for dump image persp is invalid style*
- Must be an equal-style variable.
-
-*Variable for dump image phi is invalid style*
- Must be an equal-style variable.
-
-*Variable for dump image theta is invalid style*
- Must be an equal-style variable.
-
-*Variable for dump image zoom is invalid style*
- Must be an equal-style variable.
-
-*Variable for fix adapt is invalid style*
- Only equal-style variables can be used.
-
-*Variable for fix addforce is invalid style*
- Self-explanatory.
-
-*Variable for fix aveforce is invalid style*
- Only equal-style variables can be used.
-
-*Variable for fix deform is invalid style*
- The variable must be an equal-style variable.
-
-*Variable for fix efield is invalid style*
- The variable must be an equal- or atom-style variable.
-
-*Variable for fix gravity is invalid style*
- Only equal-style variables can be used.
-
-*Variable for fix heat is invalid style*
- Only equal-style or atom-style variables can be used.
-
-*Variable for fix indent is invalid style*
- Only equal-style variables can be used.
-
-*Variable for fix indent is not equal style*
- Only equal-style variables can be used.
-
-*Variable for fix langevin is invalid style*
- It must be an equal-style variable.
-
-*Variable for fix move is invalid style*
- Only equal-style variables can be used.
-
-*Variable for fix setforce is invalid style*
- Only equal-style variables can be used.
-
-*Variable for fix temp/berendsen is invalid style*
- Only equal-style variables can be used.
-
-*Variable for fix temp/csld is invalid style*
- Only equal-style variables can be used.
-
-*Variable for fix temp/csvr is invalid style*
- Only equal-style variables can be used.
-
-*Variable for fix temp/rescale is invalid style*
- Only equal-style variables can be used.
-
-*Variable for fix wall is invalid style*
- Only equal-style variables can be used.
-
-*Variable for fix wall/reflect is invalid style*
- Only equal-style variables can be used.
-
-*Variable for fix wall/srd is invalid style*
- Only equal-style variables can be used.
-
-*Variable for group dynamic is invalid style*
- The variable must be an atom-style variable.
-
-*Variable for group is invalid style*
- Only atom-style variables can be used.
-
-*Variable for region cylinder is invalid style*
- Only equal-style varaibles are allowed.
-
-*Variable for region is invalid style*
- Only equal-style variables can be used.
-
-*Variable for region is not equal style*
- Self-explanatory.
-
-*Variable for region sphere is invalid style*
- Only equal-style varaibles are allowed.
-
-*Variable for restart is invalid style*
- Only equal-style variables can be used.
-
-*Variable for set command is invalid style*
- Only atom-style variables can be used.
-
-*Variable for thermo every is invalid style*
- Only equal-style variables can be used.
-
-*Variable for velocity set is invalid style*
- Only atom-style variables can be used.
-
-*Variable for voronoi radius is not atom style*
- Self-explanatory.
-
-*Variable formula compute array is accessed out-of-range*
- Self-explanatory.
-
-*Variable formula compute vector is accessed out-of-range*
- Self-explanatory.
-
-*Variable formula fix array is accessed out-of-range*
- Self-explanatory.
-
-*Variable formula fix vector is accessed out-of-range*
- Self-explanatory.
-
-*Variable has circular dependency*
- A circular dependency is when variable "a" in used by variable "b" and
- variable "b" is also used by varaible "a". Circular dependencies with
- longer chains of dependence are also not allowed.
-
-*Variable name between brackets must be alphanumeric or underscore characters*
- Self-explanatory.
-
-*Variable name for compute chunk/atom does not exist*
- Self-explanatory.
-
-*Variable name for compute reduce does not exist*
- Self-explanatory.
-
-*Variable name for compute ti does not exist*
- Self-explanatory.
-
-*Variable name for create_atoms does not exist*
- Self-explanatory.
-
-*Variable name for displace_atoms does not exist*
- Self-explanatory.
-
-*Variable name for dump every does not exist*
- Self-explanatory.
-
-*Variable name for dump image center does not exist*
- Self-explanatory.
-
-*Variable name for dump image persp does not exist*
- Self-explanatory.
-
-*Variable name for dump image phi does not exist*
- Self-explanatory.
-
-*Variable name for dump image theta does not exist*
- Self-explanatory.
-
-*Variable name for dump image zoom does not exist*
- Self-explanatory.
-
-*Variable name for fix adapt does not exist*
- Self-explanatory.
-
-*Variable name for fix addforce does not exist*
- Self-explanatory.
-
-*Variable name for fix ave/atom does not exist*
- Self-explanatory.
-
-*Variable name for fix ave/chunk does not exist*
- Self-explanatory.
-
-*Variable name for fix ave/correlate does not exist*
- Self-explanatory.
-
-*Variable name for fix ave/histo does not exist*
- Self-explanatory.
-
-*Variable name for fix ave/spatial does not exist*
- Self-explanatory.
-
-*Variable name for fix ave/time does not exist*
- Self-explanatory.
-
-*Variable name for fix aveforce does not exist*
- Self-explanatory.
-
-*Variable name for fix deform does not exist*
- Self-explantory.
-
-*Variable name for fix efield does not exist*
- Self-explanatory.
-
-*Variable name for fix gravity does not exist*
- Self-explanatory.
-
-*Variable name for fix heat does not exist*
- Self-explanatory.
-
-*Variable name for fix indent does not exist*
- Self-explanatory.
-
-*Variable name for fix langevin does not exist*
- Self-explanatory.
-
-*Variable name for fix move does not exist*
- Self-explanatory.
-
-*Variable name for fix setforce does not exist*
- Self-explanatory.
-
-*Variable name for fix store/state does not exist*
- Self-explanatory.
-
-*Variable name for fix temp/berendsen does not exist*
- Self-explanatory.
-
-*Variable name for fix temp/csld does not exist*
- Self-explanatory.
-
-*Variable name for fix temp/csvr does not exist*
- Self-explanatory.
-
-*Variable name for fix temp/rescale does not exist*
- Self-explanatory.
-
-*Variable name for fix vector does not exist*
- Self-explanatory.
-
-*Variable name for fix wall does not exist*
- Self-explanatory.
-
-*Variable name for fix wall/reflect does not exist*
- Self-explanatory.
-
-*Variable name for fix wall/srd does not exist*
- Self-explanatory.
-
-*Variable name for group does not exist*
- Self-explanatory.
-
-*Variable name for group dynamic does not exist*
- Self-explanatory.
-
-*Variable name for region cylinder does not exist*
- Self-explanatory.
-
-*Variable name for region does not exist*
- Self-explanatory.
-
-*Variable name for region sphere does not exist*
- Self-explanatory.
-
-*Variable name for restart does not exist*
- Self-explanatory.
-
-*Variable name for set command does not exist*
- Self-explanatory.
-
-*Variable name for thermo every does not exist*
- Self-explanatory.
-
-*Variable name for velocity set does not exist*
- Self-explanatory.
-
-*Variable name for voronoi radius does not exist*
- Self-explanatory.
-
-*Variable name must be alphanumeric or underscore characters*
- Self-explanatory.
-
-*Variable uses atom property that isn't allocated*
- Self-explanatory.
-
-*Velocity command before simulation box is defined*
- The velocity command cannot be used before a read_data, read_restart,
- or create_box command.
-
-*Velocity command with no atoms existing*
- A velocity command has been used, but no atoms yet exist.
-
-*Velocity ramp in z for a 2d problem*
- Self-explanatory.
-
-*Velocity rigid used with non-rigid fix-ID*
- Self-explanatory.
-
-*Velocity temperature ID does calculate a velocity bias*
- The specified compute must compute a bias for temperature.
-
-*Velocity temperature ID does not compute temperature*
- The compute ID given to the velocity command must compute
- temperature.
-
-*Verlet/split can only currently be used with comm_style brick*
- This is a current restriction in LAMMPS.
-
-*Verlet/split does not yet support TIP4P*
- This is a current limitation.
-
-*Verlet/split requires 2 partitions*
- See the -partition command-line switch.
-
-*Verlet/split requires Rspace partition layout be multiple of Kspace partition layout in each dim*
- This is controlled by the processors command.
-
-*Verlet/split requires Rspace partition size be multiple of Kspace partition size*
- This is so there is an equal number of Rspace processors for every
- Kspace processor.
-
-*Virial was not tallied on needed timestep*
- You are using a thermo keyword that requires potentials to
- have tallied the virial, but they didn't on this timestep. See the
- variable doc page for ideas on how to make this work.
-
-*Voro++ error: narea and neigh have a different size*
- This error is returned by the Voro++ library.
-
-*Wall defined twice in fix wall command*
- Self-explanatory.
-
-*Wall defined twice in fix wall/reflect command*
- Self-explanatory.
-
-*Wall defined twice in fix wall/srd command*
- Self-explanatory.
-
-*Water H epsilon must be 0.0 for pair style lj/cut/tip4p/cut*
- This is because LAMMPS does not compute the Lennard-Jones interactions
- with these particles for efficiency reasons.
-
-*Water H epsilon must be 0.0 for pair style lj/cut/tip4p/long*
- This is because LAMMPS does not compute the Lennard-Jones interactions
- with these particles for efficiency reasons.
-
-*Water H epsilon must be 0.0 for pair style lj/long/tip4p/long*
- This is because LAMMPS does not compute the Lennard-Jones interactions
- with these particles for efficiency reasons.
-
-*World variable count doesn't match # of partitions*
- A world-style variable must specify a number of values equal to the
- number of processor partitions.
-
-*Write_data command before simulation box is defined*
- Self-explanatory.
-
-*Write_restart command before simulation box is defined*
- The write_restart command cannot be used before a read_data,
- read_restart, or create_box command.
-
-*Writing to MPI-IO filename when MPIIO package is not installed*
- Self-explanatory.
-
-*Zero length rotation vector with displace_atoms*
- Self-explanatory.
-
-*Zero length rotation vector with fix move*
- Self-explanatory.
-
-*Zero-length lattice orient vector*
- Self-explanatory.
-
-
-
-.. _warn:
-
-Warnings:
---------------------
-
-
-
-*Adjusting Coulombic cutoff for MSM, new cutoff = %g*
- The adjust/cutoff command is turned on and the Coulombic cutoff has been
- adjusted to match the user-specified accuracy.
-
-*Angle atoms missing at step %ld*
- One or more of 3 atoms needed to compute a particular angle are
- missing on this processor. Typically this is because the pairwise
- cutoff is set too short or the angle has blown apart and an atom is
- too far away.
-
-*Angle style in data file differs from currently defined angle style*
- Self-explanatory.
-
-*Atom style in data file differs from currently defined atom style*
- Self-explanatory.
-
-*Bond atom missing in box size check*
- The 2nd atoms needed to compute a particular bond is missing on this
- processor. Typically this is because the pairwise cutoff is set too
- short or the bond has blown apart and an atom is too far away.
-
-*Bond atom missing in image check*
- The 2nd atom in a particular bond is missing on this processor.
- Typically this is because the pairwise cutoff is set too short or the
- bond has blown apart and an atom is too far away.
-
-*Bond atoms missing at step %ld*
- The 2nd atom needed to compute a particular bond is missing on this
- processor. Typically this is because the pairwise cutoff is set too
- short or the bond has blown apart and an atom is too far away.
-
-*Bond style in data file differs from currently defined bond style*
- Self-explanatory.
-
-*Bond/angle/dihedral extent > half of periodic box length*
- This is a restriction because LAMMPS can be confused about which image
- of an atom in the bonded interaction is the correct one to use.
- "Extent" in this context means the maximum end-to-end length of the
- bond/angle/dihedral. LAMMPS computes this by taking the maximum bond
- length, multiplying by the number of bonds in the interaction (e.g. 3
- for a dihedral) and adding a small amount of stretch.
-
-*Both groups in compute group/group have a net charge; the Kspace boundary correction to energy will be non-zero*
- Self-explantory.
-
-*Calling write_dump before a full system init.*
- The write_dump command is used before the system has been fully
- initialized as part of a 'run' or 'minimize' command. Not all dump
- styles and features are fully supported at this point and thus the
- command may fail or produce incomplete or incorrect output. Insert
- a "run 0" command, if a full system init is required.
-
-*Cannot count rigid body degrees-of-freedom before bodies are fully initialized*
- This means the temperature associated with the rigid bodies may be
- incorrect on this timestep.
-
-*Cannot count rigid body degrees-of-freedom before bodies are initialized*
- This means the temperature associated with the rigid bodies may be
- incorrect on this timestep.
-
-*Cannot include log terms without 1/r terms; setting flagHI to 1*
- Self-explanatory.
-
-*Cannot include log terms without 1/r terms; setting flagHI to 1.*
- Self-explanatory.
-
-*Charges are set, but coulombic solver is not used*
- Self-explanatory.
-
-*Charges did not converge at step %ld: %lg*
- Self-explanatory.
-
-*Communication cutoff is too small for SNAP micro load balancing, increased to %lf*
- Self-explanatory.
-
-*Compute cna/atom cutoff may be too large to find ghost atom neighbors*
- The neighbor cutoff used may not encompass enough ghost atoms
- to perform this operation correctly.
-
-*Computing temperature of portions of rigid bodies*
- The group defined by the temperature compute does not encompass all
- the atoms in one or more rigid bodies, so the change in
- degrees-of-freedom for the atoms in those partial rigid bodies will
- not be accounted for.
-
-*Create_bonds max distance > minimum neighbor cutoff*
- This means atom pairs for some atom types may not be in the neighbor
- list and thus no bond can be created between them.
-
-*Delete_atoms cutoff > minimum neighbor cutoff*
- This means atom pairs for some atom types may not be in the neighbor
- list and thus an atom in that pair cannot be deleted.
-
-*Dihedral atoms missing at step %ld*
- One or more of 4 atoms needed to compute a particular dihedral are
- missing on this processor. Typically this is because the pairwise
- cutoff is set too short or the dihedral has blown apart and an atom is
- too far away.
-
-*Dihedral problem*
- Conformation of the 4 listed dihedral atoms is extreme; you may want
- to check your simulation geometry.
-
-*Dihedral problem: %d %ld %d %d %d %d*
- Conformation of the 4 listed dihedral atoms is extreme; you may want
- to check your simulation geometry.
-
-*Dihedral style in data file differs from currently defined dihedral style*
- Self-explanatory.
-
-*Dump dcd/xtc timestamp may be wrong with fix dt/reset*
- If the fix changes the timestep, the dump dcd file will not
- reflect the change.
-
-*Energy tally does not account for 'zero yes'*
- The energy removed by using the 'zero yes' flag is not accounted
- for in the energy tally and thus energy conservation cannot be
- monitored in this case.
-
-*Estimated error in splitting of dispersion coeffs is %g*
- Error is greater than 0.0001 percent.
-
-*Ewald/disp Newton solver failed, using old method to estimate g_ewald*
- Self-explanatory. Choosing a different cutoff value may help.
-
-*FENE bond too long*
- A FENE bond has stretched dangerously far. It's interaction strength
- will be truncated to attempt to prevent the bond from blowing up.
-
-*FENE bond too long: %ld %d %d %g*
- A FENE bond has stretched dangerously far. It's interaction strength
- will be truncated to attempt to prevent the bond from blowing up.
-
-*FENE bond too long: %ld %g*
- A FENE bond has stretched dangerously far. It's interaction strength
- will be truncated to attempt to prevent the bond from blowing up.
-
-*Fix SRD walls overlap but fix srd overlap not set*
- You likely want to set this in your input script.
-
-*Fix bond/swap will ignore defined angles*
- See the doc page for fix bond/swap for more info on this
- restriction.
-
-*Fix deposit near setting < possible overlap separation %g*
- This test is performed for finite size particles with a diameter, not
- for point particles. The near setting is smaller than the particle
- diameter which can lead to overlaps.
-
-*Fix evaporate may delete atom with non-zero molecule ID*
- This is probably an error, since you should not delete only one atom
- of a molecule.
-
-*Fix gcmc using full_energy option*
- Fix gcmc has automatically turned on the full_energy option since it
- is required for systems like the one specified by the user. User input
- included one or more of the following: kspace, triclinic, a hybrid
- pair style, an eam pair style, or no "single" function for the pair
- style.
-
-*Fix property/atom mol or charge w/out ghost communication*
- A model typically needs these properties defined for ghost atoms.
-
-*Fix qeq CG convergence failed (%g) after %d iterations at %ld step*
- Self-explanatory.
-
-*Fix qeq has non-zero lower Taper radius cutoff*
- Absolute value must be <= 0.01.
-
-*Fix qeq has very low Taper radius cutoff*
- Value should typically be >= 5.0.
-
-*Fix qeq/dynamic tolerance may be too small for damped dynamics*
- Self-explanatory.
-
-*Fix qeq/fire tolerance may be too small for damped fires*
- Self-explanatory.
-
-*Fix rattle should come after all other integration fixes*
- This fix is designed to work after all other integration fixes change
- atom positions. Thus it should be the last integration fix specified.
- If not, it will not satisfy the desired constraints as well as it
- otherwise would.
-
-*Fix recenter should come after all other integration fixes*
- Other fixes may change the position of the center-of-mass, so
- fix recenter should come last.
-
-*Fix srd SRD moves may trigger frequent reneighboring*
- This is because the SRD particles may move long distances.
-
-*Fix srd grid size > 1/4 of big particle diameter*
- This may cause accuracy problems.
-
-*Fix srd particle moved outside valid domain*
- This may indicate a problem with your simulation parameters.
-
-*Fix srd particles may move > big particle diameter*
- This may cause accuracy problems.
-
-*Fix srd viscosity < 0.0 due to low SRD density*
- This may cause accuracy problems.
-
-*Fix thermal/conductivity comes before fix ave/spatial*
- The order of these 2 fixes in your input script is such that fix
- thermal/conductivity comes first. If you are using fix ave/spatial to
- measure the temperature profile induced by fix viscosity, then this
- may cause a glitch in the profile since you are averaging immediately
- after swaps have occurred. Flipping the order of the 2 fixes
- typically helps.
-
-*Fix viscosity comes before fix ave/spatial*
- The order of these 2 fixes in your input script is such that
- fix viscosity comes first. If you are using fix ave/spatial
- to measure the velocity profile induced by fix viscosity, then
- this may cause a glitch in the profile since you are averaging
- immediately after swaps have occurred. Flipping the order
- of the 2 fixes typically helps.
-
-*Fixes cannot send data in Kokkos communication, switching to classic communication*
- This is current restriction with Kokkos.
-
-*For better accuracy use 'pair_modify table 0'*
- The user-specified force accuracy cannot be achieved unless the table
- feature is disabled by using 'pair_modify table 0'.
-
-*Geometric mixing assumed for 1/r^6 coefficients*
- Self-explanatory.
-
-*Group for fix_modify temp != fix group*
- The fix_modify command is specifying a temperature computation that
- computes a temperature on a different group of atoms than the fix
- itself operates on. This is probably not what you want to do.
-
-*H matrix size has been exceeded: m_fill=%d H.m=%d\n*
- This is the size of the matrix.
-
-*Ignoring unknown or incorrect info command flag*
- Self-explanatory. An unknown argument was given to the info command.
- Compare your input with the documentation.
-
-*Improper atoms missing at step %ld*
- One or more of 4 atoms needed to compute a particular improper are
- missing on this processor. Typically this is because the pairwise
- cutoff is set too short or the improper has blown apart and an atom is
- too far away.
-
-*Improper problem: %d %ld %d %d %d %d*
- Conformation of the 4 listed improper atoms is extreme; you may want
- to check your simulation geometry.
-
-*Improper style in data file differs from currently defined improper style*
- Self-explanatory.
-
-*Inconsistent image flags*
- The image flags for a pair on bonded atoms appear to be inconsistent.
- Inconsistent means that when the coordinates of the two atoms are
- unwrapped using the image flags, the two atoms are far apart.
- Specifically they are further apart than half a periodic box length.
- Or they are more than a box length apart in a non-periodic dimension.
- This is usually due to the initial data file not having correct image
- flags for the 2 atoms in a bond that straddles a periodic boundary.
- They should be different by 1 in that case. This is a warning because
- inconsistent image flags will not cause problems for dynamics or most
- LAMMPS simulations. However they can cause problems when such atoms
- are used with the fix rigid or replicate commands. Note that if you
- have an infinite periodic crystal with bonds then it is impossible to
- have fully consistent image flags, since some bonds will cross
- periodic boundaries and connect two atoms with the same image
- flag.
-
-*KIM Model does not provide `energy'; Potential energy will be zero*
- Self-explanatory.
-
-*KIM Model does not provide `forces'; Forces will be zero*
- Self-explanatory.
-
-*KIM Model does not provide `particleEnergy'; energy per atom will be zero*
- Self-explanatory.
-
-*KIM Model does not provide `particleVirial'; virial per atom will be zero*
- Self-explanatory.
-
-*Kspace_modify slab param < 2.0 may cause unphysical behavior*
- The kspace_modify slab parameter should be larger to insure periodic
- grids padded with empty space do not overlap.
-
-*Less insertions than requested*
- The fix pour command was unsuccessful at finding open space
- for as many particles as it tried to insert.
-
-*Library error in lammps_gather_atoms*
- This library function cannot be used if atom IDs are not defined
- or are not consecutively numbered.
-
-*Library error in lammps_scatter_atoms*
- This library function cannot be used if atom IDs are not defined or
- are not consecutively numbered, or if no atom map is defined. See the
- atom_modify command for details about atom maps.
-
-*Lost atoms via change_box: original %ld current %ld*
- The command options you have used caused atoms to be lost.
-
-*Lost atoms via displace_atoms: original %ld current %ld*
- The command options you have used caused atoms to be lost.
-
-*Lost atoms: original %ld current %ld*
- Lost atoms are checked for each time thermo output is done. See the
- thermo_modify lost command for options. Lost atoms usually indicate
- bad dynamics, e.g. atoms have been blown far out of the simulation
- box, or moved futher than one processor's sub-domain away before
- reneighboring.
-
-*MSM mesh too small, increasing to 2 points in each direction*
- Self-explanatory.
-
-*Mismatch between velocity and compute groups*
- The temperature computation used by the velocity command will not be
- on the same group of atoms that velocities are being set for.
-
-*Mixing forced for lj coefficients*
- Self-explanatory.
-
-*Molecule attributes do not match system attributes*
- An attribute is specified (e.g. diameter, charge) that is
- not defined for the specified atom style.
-
-*Molecule has bond topology but no special bond settings*
- This means the bonded atoms will not be excluded in pair-wise
- interactions.
-
-*Molecule template for create_atoms has multiple molecules*
- The create_atoms command will only create molecules of a single type,
- i.e. the first molecule in the template.
-
-*Molecule template for fix gcmc has multiple molecules*
- The fix gcmc command will only create molecules of a single type,
- i.e. the first molecule in the template.
-
-*Molecule template for fix shake has multiple molecules*
- The fix shake command will only recoginze molecules of a single
- type, i.e. the first molecule in the template.
-
-*More than one compute centro/atom*
- It is not efficient to use compute centro/atom more than once.
-
-*More than one compute cluster/atom*
- It is not efficient to use compute cluster/atom more than once.
-
-*More than one compute cna/atom defined*
- It is not efficient to use compute cna/atom more than once.
-
-*More than one compute contact/atom*
- It is not efficient to use compute contact/atom more than once.
-
-*More than one compute coord/atom*
- It is not efficient to use compute coord/atom more than once.
-
-*More than one compute damage/atom*
- It is not efficient to use compute ke/atom more than once.
-
-*More than one compute dilatation/atom*
- Self-explanatory.
-
-*More than one compute erotate/sphere/atom*
- It is not efficient to use compute erorate/sphere/atom more than once.
-
-*More than one compute hexorder/atom*
- It is not efficient to use compute hexorder/atom more than once.
-
-*More than one compute ke/atom*
- It is not efficient to use compute ke/atom more than once.
-
-*More than one compute orientorder/atom*
- It is not efficient to use compute orientorder/atom more than once.
-
-*More than one compute plasticity/atom*
- Self-explanatory.
-
-*More than one compute sna/atom*
- Self-explanatory.
-
-*More than one compute snad/atom*
- Self-explanatory.
-
-*More than one compute snav/atom*
- Self-explanatory.
-
-*More than one fix poems*
- It is not efficient to use fix poems more than once.
-
-*More than one fix rigid*
- It is not efficient to use fix rigid more than once.
-
-*Neighbor exclusions used with KSpace solver may give inconsistent Coulombic energies*
- This is because excluding specific pair interactions also excludes
- them from long-range interactions which may not be the desired effect.
- The special_bonds command handles this consistently by insuring
- excluded (or weighted) 1-2, 1-3, 1-4 interactions are treated
- consistently by both the short-range pair style and the long-range
- solver. This is not done for exclusions of charged atom pairs via the
- neigh_modify exclude command.
-
-*New thermo_style command, previous thermo_modify settings will be lost*
- If a thermo_style command is used after a thermo_modify command, the
- settings changed by the thermo_modify command will be reset to their
- default values. This is because the thermo_modify commmand acts on
- the currently defined thermo style, and a thermo_style command creates
- a new style.
-
-*No Kspace calculation with verlet/split*
- The 2nd partition performs a kspace calculation so the kspace_style
- command must be used.
-
-*No automatic unit conversion to XTC file format conventions possible for units lj*
- This means no scaling will be performed.
-
-*No fixes defined, atoms won't move*
- If you are not using a fix like nve, nvt, npt then atom velocities and
- coordinates will not be updated during timestepping.
-
-*No joints between rigid bodies, use fix rigid instead*
- The bodies defined by fix poems are not connected by joints. POEMS
- will integrate the body motion, but it would be more efficient to use
- fix rigid.
-
-*Not using real units with pair reax*
- This is most likely an error, unless you have created your own ReaxFF
- parameter file in a different set of units.
-
-*Number of MSM mesh points changed to be a multiple of 2*
- MSM requires that the number of grid points in each direction be a multiple
- of two and the number of grid points in one or more directions have been
- adjusted to meet this requirement.
-
-*OMP_NUM_THREADS environment is not set.*
- This environment variable must be set appropriately to use the
- USER-OMP package.
-
-*One or more atoms are time integrated more than once*
- This is probably an error since you typically do not want to
- advance the positions or velocities of an atom more than once
- per timestep.
-
-*One or more chunks do not contain all atoms in molecule*
- This may not be what you intended.
-
-*One or more dynamic groups may not be updated at correct point in timestep*
- If there are other fixes that act immediately after the intitial stage
- of time integration within a timestep (i.e. after atoms move), then
- the command that sets up the dynamic group should appear after those
- fixes. This will insure that dynamic group assignements are made
- after all atoms have moved.
-
-*One or more respa levels compute no forces*
- This is computationally inefficient.
-
-*Pair COMB charge %.10f with force %.10f hit max barrier*
- Something is possibly wrong with your model.
-
-*Pair COMB charge %.10f with force %.10f hit min barrier*
- Something is possibly wrong with your model.
-
-*Pair brownian needs newton pair on for momentum conservation*
- Self-explanatory.
-
-*Pair dpd needs newton pair on for momentum conservation*
- Self-explanatory.
-
-*Pair dsmc: num_of_collisions > number_of_A*
- Collision model in DSMC is breaking down.
-
-*Pair dsmc: num_of_collisions > number_of_B*
- Collision model in DSMC is breaking down.
-
-*Pair style in data file differs from currently defined pair style*
- Self-explanatory.
-
-*Particle deposition was unsuccessful*
- The fix deposit command was not able to insert as many atoms as
- needed. The requested volume fraction may be too high, or other atoms
- may be in the insertion region.
-
-*Proc sub-domain size < neighbor skin, could lead to lost atoms*
- The decomposition of the physical domain (likely due to load
- balancing) has led to a processor's sub-domain being smaller than the
- neighbor skin in one or more dimensions. Since reneighboring is
- triggered by atoms moving the skin distance, this may lead to lost
- atoms, if an atom moves all the way across a neighboring processor's
- sub-domain before reneighboring is triggered.
-
-*Reducing PPPM order b/c stencil extends beyond nearest neighbor processor*
- This may lead to a larger grid than desired. See the kspace_modify overlap
- command to prevent changing of the PPPM order.
-
-*Reducing PPPMDisp Coulomb order b/c stencil extends beyond neighbor processor*
- This may lead to a larger grid than desired. See the kspace_modify overlap
- command to prevent changing of the PPPM order.
-
-*Reducing PPPMDisp dispersion order b/c stencil extends beyond neighbor processor*
- This may lead to a larger grid than desired. See the kspace_modify overlap
- command to prevent changing of the PPPM order.
-
-*Replacing a fix, but new group != old group*
- The ID and style of a fix match for a fix you are changing with a fix
- command, but the new group you are specifying does not match the old
- group.
-
-*Replicating in a non-periodic dimension*
- The parameters for a replicate command will cause a non-periodic
- dimension to be replicated; this may cause unwanted behavior.
-
-*Resetting reneighboring criteria during PRD*
- A PRD simulation requires that neigh_modify settings be delay = 0,
- every = 1, check = yes. Since these settings were not in place,
- LAMMPS changed them and will restore them to their original values
- after the PRD simulation.
-
-*Resetting reneighboring criteria during TAD*
- A TAD simulation requires that neigh_modify settings be delay = 0,
- every = 1, check = yes. Since these settings were not in place,
- LAMMPS changed them and will restore them to their original values
- after the PRD simulation.
-
-*Resetting reneighboring criteria during minimization*
- Minimization requires that neigh_modify settings be delay = 0, every =
- 1, check = yes. Since these settings were not in place, LAMMPS
- changed them and will restore them to their original values after the
- minimization.
-
-*Restart file used different # of processors*
- The restart file was written out by a LAMMPS simulation running on a
- different number of processors. Due to round-off, the trajectories of
- your restarted simulation may diverge a little more quickly than if
- you ran on the same # of processors.
-
-*Restart file used different 3d processor grid*
- The restart file was written out by a LAMMPS simulation running on a
- different 3d grid of processors. Due to round-off, the trajectories
- of your restarted simulation may diverge a little more quickly than if
- you ran on the same # of processors.
-
-*Restart file used different boundary settings, using restart file values*
- Your input script cannot change these restart file settings.
-
-*Restart file used different newton bond setting, using restart file value*
- The restart file value will override the setting in the input script.
-
-*Restart file used different newton pair setting, using input script value*
- The input script value will override the setting in the restart file.
-
-*Restrain problem: %d %ld %d %d %d %d*
- Conformation of the 4 listed dihedral atoms is extreme; you may want
- to check your simulation geometry.
-
-*Running PRD with only one replica*
- This is allowed, but you will get no parallel speed-up.
-
-*SRD bin shifting turned on due to small lamda*
- This is done to try to preserve accuracy.
-
-*SRD bin size for fix srd differs from user request*
- Fix SRD had to adjust the bin size to fit the simulation box. See the
- cubic keyword if you want this message to be an error vs warning.
-
-*SRD bins for fix srd are not cubic enough*
- The bin shape is not within tolerance of cubic. See the cubic
- keyword if you want this message to be an error vs warning.
-
-*SRD particle %d started inside big particle %d on step %ld bounce %d*
- See the inside keyword if you want this message to be an error vs
- warning.
-
-*SRD particle %d started inside wall %d on step %ld bounce %d*
- See the inside keyword if you want this message to be an error vs
- warning.
-
-*Shake determinant < 0.0*
- The determinant of the quadratic equation being solved for a single
- cluster specified by the fix shake command is numerically suspect. LAMMPS
- will set it to 0.0 and continue.
-
-*Shell command '%s' failed with error '%s'*
- Self-explanatory.
-
-*Shell command returned with non-zero status*
- This may indicate the shell command did not operate as expected.
-
-*Should not allow rigid bodies to bounce off relecting walls*
- LAMMPS allows this, but their dynamics are not computed correctly.
-
-*Should not use fix nve/limit with fix shake or fix rattle*
- This will lead to invalid constraint forces in the SHAKE/RATTLE
- computation.
-
-*Simulations might be very slow because of large number of structure factors*
- Self-explanatory.
-
-*Slab correction not needed for MSM*
- Slab correction is intended to be used with Ewald or PPPM and is not needed by MSM.
-
-*System is not charge neutral, net charge = %g*
- The total charge on all atoms on the system is not 0.0.
- For some KSpace solvers this is only a warning.
-
-*Table inner cutoff >= outer cutoff*
- You specified an inner cutoff for a Coulombic table that is longer
- than the global cutoff. Probably not what you wanted.
-
-*Temperature for MSST is not for group all*
- User-assigned temperature to MSST fix does not compute temperature for
- all atoms. Since MSST computes a global pressure, the kinetic energy
- contribution from the temperature is assumed to also be for all atoms.
- Thus the pressure used by MSST could be inaccurate.
-
-*Temperature for NPT is not for group all*
- User-assigned temperature to NPT fix does not compute temperature for
- all atoms. Since NPT computes a global pressure, the kinetic energy
- contribution from the temperature is assumed to also be for all atoms.
- Thus the pressure used by NPT could be inaccurate.
-
-*Temperature for fix modify is not for group all*
- The temperature compute is being used with a pressure calculation
- which does operate on group all, so this may be inconsistent.
-
-*Temperature for thermo pressure is not for group all*
- User-assigned temperature to thermo via the thermo_modify command does
- not compute temperature for all atoms. Since thermo computes a global
- pressure, the kinetic energy contribution from the temperature is
- assumed to also be for all atoms. Thus the pressure printed by thermo
- could be inaccurate.
-
-*The fix ave/spatial command has been replaced by the more flexible fix ave/chunk and compute chunk/atom commands -- fix ave/spatial will be removed in the summer of 2015*
- Self-explanatory.
-
-*The minimizer does not re-orient dipoles when using fix efield*
- This means that only the atom coordinates will be minimized,
- not the orientation of the dipoles.
-
-*Too many common neighbors in CNA %d times*
- More than the maximum # of neighbors was found multiple times. This
- was unexpected.
-
-*Too many inner timesteps in fix ttm*
- Self-explanatory.
-
-*Too many neighbors in CNA for %d atoms*
- More than the maximum # of neighbors was found multiple times. This
- was unexpected.
-
-*Triclinic box skew is large*
- The displacement in a skewed direction is normally required to be less
- than half the box length in that dimension. E.g. the xy tilt must be
- between -half and +half of the x box length. You have relaxed the
- constraint using the box tilt command, but the warning means that a
- LAMMPS simulation may be inefficient as a result.
-
-*Use special bonds = 0,1,1 with bond style fene*
- Most FENE models need this setting for the special_bonds command.
-
-*Use special bonds = 0,1,1 with bond style fene/expand*
- Most FENE models need this setting for the special_bonds command.
-
-*Using a manybody potential with bonds/angles/dihedrals and special_bond exclusions*
- This is likely not what you want to do. The exclusion settings will
- eliminate neighbors in the neighbor list, which the manybody potential
- needs to calculated its terms correctly.
-
-*Using compute temp/deform with inconsistent fix deform remap option*
- Fix nvt/sllod assumes deforming atoms have a velocity profile provided
- by "remap v" or "remap none" as a fix deform option.
-
-*Using compute temp/deform with no fix deform defined*
- This is probably an error, since it makes little sense to use
- compute temp/deform in this case.
-
-*Using fix srd with box deformation but no SRD thermostat*
- The deformation will heat the SRD particles so this can
- be dangerous.
-
-*Using kspace solver on system with no charge*
- Self-explanatory.
-
-*Using largest cut-off for lj/long/dipole/long long long*
- Self-explanatory.
-
-*Using largest cutoff for buck/long/coul/long*
- Self-exlanatory.
-
-*Using largest cutoff for lj/long/coul/long*
- Self-explanatory.
-
-*Using largest cutoff for pair_style lj/long/tip4p/long*
- Self-explanatory.
-
-*Using package gpu without any pair style defined*
- Self-explanatory.
-
-*Using pair potential shift with pair_modify compute no*
- The shift effects will thus not be computed.
-
-*Using pair tail corrections with nonperiodic system*
- This is probably a bogus thing to do, since tail corrections are
- computed by integrating the density of a periodic system out to
- infinity.
-
-*Using pair tail corrections with pair_modify compute no*
- The tail corrections will thus not be computed.
-
-*pair style reax is now deprecated and will soon be retired. Users should switch to pair_style reax/c*
-* :doc:`Thermodynamic output <thermo_style>`, which is a list
- of quantities printed every few timesteps to the screen and logfile.
-* :doc:`Dump files <dump>`, which contain snapshots of atoms and various
- per-atom values and are written at a specified frequency.
-* Certain fixes can output user-specified quantities to files: :doc:`fix ave/time <fix_ave_time>` for time averaging, :doc:`fix ave/chunk <fix_ave_chunk>` for spatial or other averaging, and :doc:`fix print <fix_print>` for single-line output of
- :doc:`variables <variable>`. Fix print can also output to the
- screen.
-* :doc:`Restart files <restart>`.
-A simulation prints one set of thermodynamic output and (optionally)
-restart files. It can generate any number of dump files and fix
-output files, depending on what :doc:`dump <dump>` and :doc:`fix <fix>`
-commands you specify.
-
-As discussed below, LAMMPS gives you a variety of ways to determine
-what quantities are computed and printed when the thermodynamics,
-dump, or fix commands listed above perform output. Throughout this
-discussion, note that users can also :doc:`add their own computes and fixes to LAMMPS <Section_modify>` which can then generate values that can
-then be output with these commands.
-
-The following sub-sections discuss different LAMMPS command related
-to output and the kind of data they operate on and produce:
-
-* :ref:`Global/per-atom/local data <global>`
-* :ref:`Scalar/vector/array data <scalar>`
-* :ref:`Thermodynamic output <thermo>`
-* :ref:`Dump file output <dump>`
-* :ref:`Fixes that write output files <fixoutput>`
-* :ref:`Computes that process output quantities <computeoutput>`
-* :ref:`Fixes that process output quantities <fixprocoutput>`
-* :ref:`Computes that generate values to output <compute>`
-* :ref:`Fixes that generate values to output <fix>`
-* :ref:`Variables that generate values to output <variable>`
-* :ref:`Summary table of output options and data flow between commands <table>`
-
-.. _global:
-
-Global/per-atom/local data
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Various output-related commands work with three different styles of
-data: global, per-atom, or local. A global datum is one or more
-system-wide values, e.g. the temperature of the system. A per-atom
-datum is one or more values per atom, e.g. the kinetic energy of each
-atom. Local datums are calculated by each processor based on the
-atoms it owns, but there may be zero or more per atom, e.g. a list of
-bond distances.
-
-.. _scalar:
-
-Scalar/vector/array data
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Global, per-atom, and local datums can each come in three kinds: a
-single scalar value, a vector of values, or a 2d array of values. The
-doc page for a "compute" or "fix" or "variable" that generates data
-will specify both the style and kind of data it produces, e.g. a
-per-atom vector.
-
-When a quantity is accessed, as in many of the output commands
-discussed below, it can be referenced via the following bracket
-notation, where ID in this case is the ID of a compute. The leading
-"c_" would be replaced by "f_" for a fix, or "v_" for a variable:
-Thermostatting means controlling the temperature of particles in an MD
-simulation. Barostatting means controlling the pressure. Since the
-pressure includes a kinetic component due to particle velocities, both
-these operations require calculation of the temperature. Typically a
-target temperature (T) and/or pressure (P) is specified by the user,
-and the thermostat or barostat attempts to equilibrate the system to
-the requested T and/or P.
-
-Temperature is computed as kinetic energy divided by some number of
-degrees of freedom (and the Boltzmann constant). Since kinetic energy
-is a function of particle velocity, there is often a need to
-distinguish between a particle's advection velocity (due to some
-aggregate motiion of particles) and its thermal velocity. The sum of
-the two is the particle's total velocity, but the latter is often what
-is wanted to compute a temperature.
-
-LAMMPS has several options for computing temperatures, any of which
-can be used in thermostatting and barostatting. These :doc:`compute commands <compute>` calculate temperature, and the :doc:`compute pressure <compute_pressure>` command calculates pressure.
-:doc:`Fix nvt <fix_nh>` only thermostats the translational velocity of
-particles. :doc:`Fix nvt/sllod <fix_nvt_sllod>` also does this, except
-that it subtracts out a velocity bias due to a deforming box and
-integrates the SLLOD equations of motion. See the :ref:`NEMD simulations <howto_13>` section of this page for further details. :doc:`Fix nvt/sphere <fix_nvt_sphere>` and :doc:`fix nvt/asphere <fix_nvt_asphere>` thermostat not only translation
-velocities but also rotational velocities for spherical and aspherical
-particles.
-
-DPD thermostatting alters pairwise interactions in a manner analagous
-to the per-particle thermostatting of :doc:`fix langevin <fix_langevin>`.
-
-Any of the thermostatting fixes can use temperature computes that
-remove bias which has two effects. First, the current calculated
-temperature, which is compared to the requested target temperature, is
-caluclated with the velocity bias removed. Second, the thermostat
-adjusts only the thermal temperature component of the particle's
-velocities, which are the velocities with the bias removed. The
-removed bias is then added back to the adjusted velocities. See the
-doc pages for the individual fixes and for the
-:doc:`fix_modify <fix_modify>` command for instructions on how to assign
-a temperature compute to a thermostatting fix. For example, you can
-apply a thermostat to only the x and z components of velocity by using
-it in conjunction with :doc:`compute temp/partial <compute_temp_partial>`. Of you could thermostat only
-the thermal temperature of a streaming flow of particles without
-affecting the streaming velocity, by using :doc:`compute temp/profile <compute_temp_profile>`.
-
-.. note::
-
- Only the nvt fixes perform time integration, meaning they update
- the velocities and positions of particles due to forces and velocities
- respectively. The other thermostat fixes only adjust velocities; they
- do NOT perform time integration updates. Thus they should be used in
- conjunction with a constant NVE integration fix such as these:
-
-* :doc:`fix nve <fix_nve>`
-* :doc:`fix nve/sphere <fix_nve_sphere>`
-* :doc:`fix nve/asphere <fix_nve_asphere>`
-
-Barostatting in LAMMPS is also performed by :doc:`fixes <fix>`. Two
-barosttating methods are currently available: Nose-Hoover (npt and
-The :doc:`fix npt <fix_nh>` commands include a Nose-Hoover thermostat
-and barostat. :doc:`Fix nph <fix_nh>` is just a Nose/Hoover barostat;
-it does no thermostatting. Both :doc:`fix nph <fix_nh>` and :doc:`fix press/bernendsen <fix_press_berendsen>` can be used in conjunction
-with any of the thermostatting fixes.
-
-As with the thermostats, :doc:`fix npt <fix_nh>` and :doc:`fix nph <fix_nh>` only use translational motion of the particles in
-computing T and P and performing thermo/barostatting. :doc:`Fix npt/sphere <fix_npt_sphere>` and :doc:`fix npt/asphere <fix_npt_asphere>` thermo/barostat using not only
-translation velocities but also rotational velocities for spherical
-and aspherical particles.
-
-All of the barostatting fixes use the :doc:`compute pressure <compute_pressure>` compute to calculate a current
-pressure. By default, this compute is created with a simple :doc:`compute temp <compute_temp>` (see the last argument of the :doc:`compute pressure <compute_pressure>` command), which is used to calculated
-the kinetic componenet of the pressure. The barostatting fixes can
-also use temperature computes that remove bias for the purpose of
-computing the kinetic componenet which contributes to the current
-pressure. See the doc pages for the individual fixes and for the
-:doc:`fix_modify <fix_modify>` command for instructions on how to assign
-a temperature or pressure compute to a barostatting fix.
-
-.. note::
-
- As with the thermostats, the Nose/Hoover methods (:doc:`fix npt <fix_nh>` and :doc:`fix nph <fix_nh>`) perform time integration.
- :doc:`Fix press/berendsen <fix_press_berendsen>` does NOT, so it should
- be used with one of the constant NVE fixes or with one of the NVT
- fixes.
-
-Finally, thermodynamic output, which can be setup via the
-:doc:`thermo_style <thermo_style>` command, often includes temperature
-and pressure values. As explained on the doc page for the
-:doc:`thermo_style <thermo_style>` command, the default T and P are
-setup by the thermo command itself. They are NOT the ones associated
-with any thermostatting or barostatting fix you have defined or with
-any compute that calculates a temperature or pressure. Thus if you
-want to view these values of T and P, you need to specify them
-explicitly via a :doc:`thermo_style custom <thermo_style>` command. Or
-you can use the :doc:`thermo_modify <thermo_modify>` command to
-re-define what temperature or pressure compute is used for default
-thermodynamic output.
-
-
-----------
-
-
-.. _howto_17:
-
-Walls
------
-
-Walls in an MD simulation are typically used to bound particle motion,
-i.e. to serve as a boundary condition.
-
-Walls in LAMMPS can be of rough (made of particles) or idealized
-surfaces. Ideal walls can be smooth, generating forces only in the
-normal direction, or frictional, generating forces also in the
-tangential direction.
-
-Rough walls, built of particles, can be created in various ways. The
-particles themselves can be generated like any other particle, via the
-:doc:`lattice <lattice>` and :doc:`create_atoms <create_atoms>` commands,
-or read in via the :doc:`read_data <read_data>` command.
-
-Their motion can be constrained by many different commands, so that
-they do not move at all, move together as a group at constant velocity
-or in response to a net force acting on them, move in a prescribed
-fashion (e.g. rotate around a point), etc. Note that if a time
-integration fix like :doc:`fix nve <fix_nve>` or :doc:`fix nvt <fix_nh>`
-is not used with the group that contains wall particles, their
-positions and velocities will not be updated.
-
-* :doc:`fix aveforce <fix_aveforce>` - set force on particles to average value, so they move together
-* :doc:`fix setforce <fix_setforce>` - set force on particles to a value, e.g. 0.0
-* :doc:`fix freeze <fix_freeze>` - freeze particles for use as granular walls
-* :doc:`fix nve/noforce <fix_nve_noforce>` - advect particles by their velocity, but without force
-* :doc:`fix move <fix_move>` - prescribe motion of particles by a linear velocity, oscillation, rotation, variable
-
-The :doc:`fix move <fix_move>` command offers the most generality, since
-the motion of individual particles can be specified with
-:doc:`variable <variable>` formula which depends on time and/or the
-particle position.
-
-For rough walls, it may be useful to turn off pairwise interactions
-between wall particles via the :doc:`neigh_modify exclude <neigh_modify>` command.
-
-Rough walls can also be created by specifying frozen particles that do
-not move and do not interact with mobile particles, and then tethering
-other particles to the fixed particles, via a :doc:`bond <bond_style>`.
-The bonded particles do interact with other mobile particles.
-
-Idealized walls can be specified via several fix commands. :doc:`Fix wall/gran <fix_wall_gran>` creates frictional walls for use with
-granular particles; all the other commands create smooth walls.
-These can extract various global or per-atom quantities from LAMMPS as
-well as values calculated by a compute, fix, or variable. The
-"set_variable" function can set an existing string-style variable to a
-new value, so that subsequent LAMMPS commands can access the variable.
-The "get" and "put" operations can retrieve and reset atom
-coordinates. See the library.cpp file and its associated header file
-library.h for details.
-
-The key idea of the library interface is that you can write any
-functions you wish to define how your code talks to LAMMPS and add
-them to src/library.cpp and src/library.h, as well as to the :doc:`Python interface <Section_python>`. The routines you add can access or
-change any LAMMPS data you wish. The examples/COUPLE and python
-directories have example C++ and C and Python codes which show how a
-driver code can link to LAMMPS as a library, run LAMMPS on a subset of
-processors, grab data from LAMMPS, change it, and put it back into
-LAMMPS.
-
-
-----------
-
-
-.. _howto_20:
-
-Calculating thermal conductivity
---------------------------------
-
-The thermal conductivity kappa of a material can be measured in at
-least 4 ways using various options in LAMMPS. See the examples/KAPPA
-directory for scripts that implement the 4 methods discussed here for
-a simple Lennard-Jones fluid model. Also, see :ref:`this section <howto_21>` of the manual for an analogous
-discussion for viscosity.
-
-The thermal conducitivity tensor kappa is a measure of the propensity
-of a material to transmit heat energy in a diffusive manner as given
-by Fourier's law
-
-J = -kappa grad(T)
-
-where J is the heat flux in units of energy per area per time and
-grad(T) is the spatial gradient of temperature. The thermal
-conductivity thus has units of energy per distance per time per degree
-K and is often approximated as an isotropic quantity, i.e. as a
-scalar.
-
-The first method is to setup two thermostatted regions at opposite
-ends of a simulation box, or one in the middle and one at the end of a
-periodic box. By holding the two regions at different temperatures
-with a :ref:`thermostatting fix <howto_13>`, the energy
-added to the hot region should equal the energy subtracted from the
-cold region and be proportional to the heat flux moving between the
-regions. See the papers by :ref:`Ikeshoji and Hafskjold <howto-Ikeshoji>`
-and :ref:`Wirnsberger et al <howto-Wirnsberger>` for details of this idea.
-Note that thermostatting fixes such as :doc:`fix nvt <fix_nh>`, :doc:`fix langevin <fix_langevin>`, and :doc:`fix temp/rescale <fix_temp_rescale>` store the cumulative energy they
-add/subtract.
-
-Alternatively, as a second method, the :doc:`fix heat <fix_heat>` or
-:doc:`fix ehex <fix_ehex>` commands can be used in place of thermostats
-on each of two regions to add/subtract specified amounts of energy to
-both regions. In both cases, the resulting temperatures of the two
-regions can be monitored with the "compute temp/region" command and
-the temperature profile of the intermediate region can be monitored
-with the :doc:`fix ave/spatial <fix_ave_spatial>` and :doc:`compute ke/atom <compute_ke_atom>` commands.
-
-The third method is to perform a reverse non-equilibrium MD simulation
-using the :doc:`fix thermal/conductivity <fix_thermal_conductivity>`
-command which implements the rNEMD algorithm of Muller-Plathe.
-Kinetic energy is swapped between atoms in two different layers of the
-simulation box. This induces a temperature gradient between the two
-layers which can be monitored with the :doc:`fix ave/spatial <fix_ave_spatial>` and :doc:`compute ke/atom <compute_ke_atom>` commands. The fix tallies the
-cumulative energy transfer that it performs. See the :doc:`fix thermal/conductivity <fix_thermal_conductivity>` command for
-details.
-
-The fourth method is based on the Green-Kubo (GK) formula which
-relates the ensemble average of the auto-correlation of the heat flux
-to kappa. The heat flux can be calculated from the fluctuations of
-per-atom potential and kinetic energies and per-atom stress tensor in
-a steady-state equilibrated simulation. This is in contrast to the
-two preceding non-equilibrium methods, where energy flows continuously
-between hot and cold regions of the simulation box.
-
-The :doc:`compute heat/flux <compute_heat_flux>` command can calculate
-the needed heat flux and describes how to implement the Green_Kubo
-formalism using additional LAMMPS commands, such as the :doc:`fix ave/correlate <fix_ave_correlate>` command to calculate the needed
-auto-correlation. See the doc page for the :doc:`compute heat/flux <compute_heat_flux>` command for an example input script
-that calculates the thermal conductivity of solid Ar via the GK
-formalism.
-
-
-----------
-
-
-.. _howto_21:
-
-Calculating viscosity
----------------------
-
-The shear viscosity eta of a fluid can be measured in at least 5 ways
-using various options in LAMMPS. See the examples/VISCOSITY directory
-for scripts that implement the 5 methods discussed here for a simple
-Lennard-Jones fluid model. Also, see :ref:`this section <howto_20>` of the manual for an analogous
-discussion for thermal conductivity.
-
-Eta is a measure of the propensity of a fluid to transmit momentum in
-a direction perpendicular to the direction of velocity or momentum
-flow. Alternatively it is the resistance the fluid has to being
-sheared. It is given by
-
-J = -eta grad(Vstream)
-
-where J is the momentum flux in units of momentum per area per time.
-and grad(Vstream) is the spatial gradient of the velocity of the fluid
-moving in another direction, normal to the area through which the
-momentum flows. Viscosity thus has units of pressure-time.
-
-The first method is to perform a non-equlibrium MD (NEMD) simulation
-by shearing the simulation box via the :doc:`fix deform <fix_deform>`
-command, and using the :doc:`fix nvt/sllod <fix_nvt_sllod>` command to
-thermostat the fluid via the SLLOD equations of motion.
-Alternatively, as a second method, one or more moving walls can be
-used to shear the fluid in between them, again with some kind of
-thermostat that modifies only the thermal (non-shearing) components of
-velocity to prevent the fluid from heating up.
-
-In both cases, the velocity profile setup in the fluid by this
-procedure can be monitored by the :doc:`fix ave/spatial <fix_ave_spatial>` command, which determines
-grad(Vstream) in the equation above. E.g. the derivative in the
-y-direction of the Vx component of fluid motion or grad(Vstream) =
-dVx/dy. The Pxy off-diagonal component of the pressure or stress
-tensor, as calculated by the :doc:`compute pressure <compute_pressure>`
-command, can also be monitored, which is the J term in the equation
-above. See :ref:`this section <howto_13>` of the manual
-for details on NEMD simulations.
-
-The third method is to perform a reverse non-equilibrium MD simulation
-using the :doc:`fix viscosity <fix_viscosity>` command which implements
-the rNEMD algorithm of Muller-Plathe. Momentum in one dimension is
-swapped between atoms in two different layers of the simulation box in
-a different dimension. This induces a velocity gradient which can be
-monitored with the :doc:`fix ave/spatial <fix_ave_spatial>` command.
-The fix tallies the cummulative momentum transfer that it performs.
-See the :doc:`fix viscosity <fix_viscosity>` command for details.
-
-The fourth method is based on the Green-Kubo (GK) formula which
-relates the ensemble average of the auto-correlation of the
-stress/pressure tensor to eta. This can be done in a fully
-equilibrated simulation which is in contrast to the two preceding
-non-equilibrium methods, where momentum flows continuously through the
-simulation box.
-
-Here is an example input script that calculates the viscosity of
-liquid Ar via the GK formalism:
-
-.. parsed-literal::
-
- # Sample LAMMPS input script for viscosity of liquid Ar
-| atoms with same local defect structure | chunk ID = output of :doc:`compute centro/atom <compute_centro_atom>` or :doc:`compute coord/atom <compute_coord_atom>` command |
-When running dynamics with the adiabatic core/shell model, the
-following issues should be considered. Since the relative motion of
-the core and shell particles corresponds to the polarization, typical
-thermostats can alter the polarization behaviour, meaning the shell
-will not react freely to its electrostatic environment. This is
-critical during the equilibration of the system. Therefore
-it's typically desirable to decouple the relative motion of the
-core/shell pair, which is an imaginary degree of freedom, from the
-real physical system. To do that, the :doc:`compute temp/cs <compute_temp_cs>` command can be used, in conjunction with
-any of the thermostat fixes, such as :doc:`fix nvt <fix_nh>` or `fix langevin <fix_langevin>`_. This compute uses the center-of-mass velocity
-of the core/shell pairs to calculate a temperature, and insures that
-velocity is what is rescaled for thermostatting purposes. This
-compute also works for a system with both core/shell pairs and
-non-polarized ions (ions without an attached satellite particle). The
-:doc:`compute temp/cs <compute_temp_cs>` command requires input of two
-groups, one for the core atoms, another for the shell atoms.
-Non-polarized ions which might also be included in the treated system
-should not be included into either of these groups, they are taken
-into account by the *group-ID* (2nd argument) of the compute. The
-groups can be defined using the :doc:`group *type*\ <group>` command.
-Note that to perform thermostatting using this definition of
-temperature, the :doc:`fix modify temp <fix_modify>` command should be
-used to assign the compute to the thermostat fix. Likewise the
-:doc:`thermo_modify temp <thermo_modify>` command can be used to make
-this temperature be output for the overall system.
-
-For the NaCl example, this can be done as follows:
-
-.. parsed-literal::
-
- group cores type 1 2
- group shells type 3 4
- compute CSequ all temp/cs cores shells
- fix thermoberendsen all temp/berendsen 1427 1427 0.4 # thermostat for the true physical system
- fix thermostatequ all nve # integrator as needed for the berendsen thermostat
- fix_modify thermoberendsen temp CSequ
- thermo_modify temp CSequ # output of center-of-mass derived temperature
-
-If :doc:`compute temp/cs <compute_temp_cs>` is used, the decoupled
-relative motion of the core and the shell should in theory be
-stable. However numerical fluctuation can introduce a small
-momentum to the system, which is noticable over long trajectories.
-Therefore it is recomendable to use the :doc:`fix momentum <fix_momentum>` command in combination with :doc:`compute temp/cs <compute_temp_cs>` when equilibrating the system to
-prevent any drift.
-
-When intializing the velocities of a system with core/shell pairs, it
-is also desirable to not introduce energy into the relative motion of
-the core/shell particles, but only assign a center-of-mass velocity to
-the pairs. This can be done by using the *bias* keyword of the
-:doc:`velocity create <velocity>` command and assigning the :doc:`compute temp/cs <compute_temp_cs>` command to the *temp* keyword of the
-:doc:`velocity <velocity>` commmand, e.g.
-
-.. parsed-literal::
-
- velocity all create 1427 134 bias yes temp CSequ
- velocity all scale 1427 temp CSequ
-
-It is important to note that the polarizability of the core/shell
-pairs is based on their relative motion. Therefore the choice of
-spring force and mass ratio need to ensure much faster relative motion
-of the 2 atoms within the core/shell pair than their center-of-mass
-velocity. This allow the shells to effectively react instantaneously
-to the electrostatic environment. This fast movement also limits the
-timestep size that can be used.
-
-The primary literature of the adiabatic core/shell model suggests that
-the fast relative motion of the core/shell pairs only allows negligible
-energy transfer to the environment. Therefore it is not intended to
-decouple the core/shell degree of freedom from the physical system
-during production runs. In other words, the :doc:`compute temp/cs <compute_temp_cs>` command should not be used during
-production runs and is only required during equilibration. This way one
-is consistent with literature (based on the code packages DL_POLY or
-GULP for instance).
-
-The mentioned energy transfer will typically lead to a a small drift
-in total energy over time. This internal energy can be monitored
-using the :doc:`compute chunk/atom <compute_chunk_atom>` and :doc:`compute temp/chunk <compute_temp_chunk>` commands. The internal kinetic
-energies of each core/shell pair can then be summed using the sum()
-special function of the :doc:`variable <variable>` command. Or they can
-be time/averaged and output using the :doc:`fix ave/time <fix_ave_time>`
-command. To use these commands, each core/shell pair must be defined
-as a "chunk". If each core/shell pair is defined as its own molecule,
-the molecule ID can be used to define the chunks. If cores are bonded
-to each other to form larger molecules, the chunks can be identified
-by the :doc:`fix property/atom <fix_property_atom>` via assigning a
-core/shell ID to each atom using a special field in the data file read
-by the :doc:`read_data <read_data>` command. This field can then be
-accessed by the :doc:`compute property/atom <compute_property_atom>`
-command, to use as input to the :doc:`compute chunk/atom <compute_chunk_atom>` command to define the core/shell
-pairs as chunks.
-
-For example,
-
-.. parsed-literal::
-
- fix csinfo all property/atom i_CSID # property/atom command
- read_data NaCl_CS_x0.1_prop.data fix csinfo NULL CS-Info # atom property added in the data-file
- compute prop all property/atom i_CSID
- compute cs_chunk all chunk/atom c_prop
- compute cstherm all temp/chunk cs_chunk temp internal com yes cdof 3.0 # note the chosen degrees of freedom for the core/shell pairs
-| 10.6 :ref:`Fix styles <mod_6>` which include integrators, temperature and pressure control, force constraints, boundary conditions, diagnostic output, etc
- mpirun -np 72 -ppn 36 lmp_machine -sf intel -in in.script -pk intel 0 omp 2 mode double # Don't use any coprocessors that might be available, use 2 OpenMP threads for each task, use double precision
-
-**Or run with the USER-INTEL package by editing an input script:**
-
-As an alternative to adding command-line arguments, the input script
-can be edited to enable the USER-INTEL package. This requires adding
-the :doc:`package intel <package>` command to the top of the input
-script. For the second example above, this would be:
-
-.. parsed-literal::
-
- package intel 0 omp 2 mode double
-
-To enable the USER-INTEL package only for individual styles, you can
-add an "intel" suffix to the individual style, e.g.:
-
-.. parsed-literal::
-
- pair_style lj/cut/intel 2.5
-
-Alternatively, the :doc:`suffix intel <suffix>` command can be added to
-the input script to enable USER-INTEL styles for the commands that
-follow in the input script.
-
-**Tuning for Performance:**
-
-.. note::
-
- The USER-INTEL package will perform better with modifications
- to the input script when :doc:`PPPM <kspace_style>` is used:
- :doc:`kspace_modify diff ad <kspace_modify>` and :doc:`neigh_modify binsize 3 <neigh_modify>` should be added to the input script.
-
-Long-Range Thread (LRT) mode is an option to the :doc:`package intel <package>` command that can improve performance when using
-:doc:`PPPM <kspace_style>` for long-range electrostatics on processors
-with SMT. It generates an extra pthread for each MPI task. The thread
-is dedicated to performing some of the PPPM calculations and MPI
-communications. On Intel Xeon Phi x200 series CPUs, this will likely
-always improve performance, even on a single node. On Intel Xeon
-processors, using this mode might result in better performance when
-using multiple nodes, depending on the machine. To use this mode,
-specify that the number of OpenMP threads is one less than would
-normally be used for the run and add the "lrt yes" option to the "-pk"
-command-line suffix or "package intel" command. For example, if a run
-would normally perform best with "-pk intel 0 omp 4", instead use
-"-pk intel 0 omp 3 lrt yes". When using LRT, you should set the
-environment variable "KMP_AFFINITY=none". LRT mode is not supported
-when using offload.
-
-Not all styles are supported in the USER-INTEL package. You can mix
-the USER-INTEL package with styles from the :doc:`OPT <accelerate_opt>`
-package or the `USER-OMP package <accelerate_omp.html">`_. Of course,
-this requires that these packages were installed at build time. This
-can performed automatically by using "-sf hybrid intel opt" or
-"-sf hybrid intel omp" command-line options. Alternatively, the "opt"
-and "omp" suffixes can be appended manually in the input script. For
-the latter, the :doc:`package omp <package>` command must be in the
-input script or the "-pk omp Nt" :ref:`command-line switch <start_7>` must be used where Nt is the
-number of OpenMP threads. The number of OpenMP threads should not be
-set differently for the different packages. Note that the :doc:`suffix hybrid intel omp <suffix>` command can also be used within the
-input script to automatically append the "omp" suffix to styles when
-USER-INTEL styles are not available.
-
-When running on many nodes, performance might be better when using
-fewer OpenMP threads and more MPI tasks. This will depend on the
-simulation and the machine. Using the :doc:`verlet/split <run_style>`
-run style might also give better performance for simulations with
-:doc:`PPPM <kspace_style>` electrostatics. Note that this is an
-alternative to LRT mode and the two cannot be used together.
-
-Currently, when using Intel MPI with Intel Xeon Phi x200 series
-CPUs, better performance might be obtained by setting the
-environment variable "I_MPI_SHM_LMT=shm" for Linux kernels that do
-not yet have full support for AVX-512. Runs on Intel Xeon Phi x200
-series processors will always perform better using MCDRAM. Please
-consult your system documentation for the best approach to specify
-that MPI runs are performed in MCDRAM.
-
-**Tuning for Offload Performance:**
-
-The default settings for offload should give good performance.
-
-When using LAMMPS with offload to Intel coprocessors, best performance
-will typically be achieved with concurrent calculations performed on
-both the CPU and the coprocessor. This is achieved by offloading only
-a fraction of the neighbor and pair computations to the coprocessor or
-using :doc:`hybrid <pair_hybrid>` pair styles where only one style uses
-the "intel" suffix. For simulations with long-range electrostatics or
-bond, angle, dihedral, improper calculations, computation and data
-transfer to the coprocessor will run concurrently with computations
-and MPI communications for these calculations on the host CPU. This
-is illustrated in the figure below for the rhodopsin protein benchmark
-running on E5-2697v2 processors with a Intel Xeon Phi 7120p
-coprocessor. In this plot, the vertical access is time and routines
-running at the same time are running concurrently on both the host and
-the coprocessor.
-
-.. image:: JPG/offload_knc.png
- :align: center
-
-The fraction of the offloaded work is controlled by the *balance*
-keyword in the :doc:`package intel <package>` command. A balance of 0
-runs all calculations on the CPU. A balance of 1 runs all
-supported calculations on the coprocessor. A balance of 0.5 runs half
-of the calculations on the coprocessor. Setting the balance to -1
-(the default) will enable dynamic load balancing that continously
-adjusts the fraction of offloaded work throughout the simulation.
-Because data transfer cannot be timed, this option typically produces
-results within 5 to 10 percent of the optimal fixed balance.
-
-If running short benchmark runs with dynamic load balancing, adding a
-short warm-up run (10-20 steps) will allow the load-balancer to find a
-near-optimal setting that will carry over to additional runs.
-
-The default for the :doc:`package intel <package>` command is to have
-all the MPI tasks on a given compute node use a single Xeon Phi
-coprocessor. In general, running with a large number of MPI tasks on
-each node will perform best with offload. Each MPI task will
-automatically get affinity to a subset of the hardware threads
-available on the coprocessor. For example, if your card has 61 cores,
-with 60 cores available for offload and 4 hardware threads per core
-(240 total threads), running with 24 MPI tasks per node will cause
-each MPI task to use a subset of 10 threads on the coprocessor. Fine
-tuning of the number of threads to use per MPI task or the number of
-threads to use per core can be accomplished with keyword settings of
-the :doc:`package intel <package>` command.
-
-The USER-INTEL package has two modes for deciding which atoms will be
-handled by the coprocessor. This choice is controlled with the *ghost*
-keyword of the :doc:`package intel <package>` command. When set to 0,
-ghost atoms (atoms at the borders between MPI tasks) are not offloaded
-to the card. This allows for overlap of MPI communication of forces
-with computation on the coprocessor when the :doc:`newton <newton>`
-setting is "on". The default is dependent on the style being used,
-however, better performance may be achieved by setting this option
-explictly.
-
-When using offload with CPU Hyper-Threading disabled, it may help
-performance to use fewer MPI tasks and OpenMP threads than available
-cores. This is due to the fact that additional threads are generated
-internally to handle the asynchronous offload tasks.
-
-If pair computations are being offloaded to an Intel Xeon Phi
-coprocessor, a diagnostic line is printed to the screen (not to the
-log file), during the setup phase of a run, indicating that offload
-mode is being used and indicating the number of coprocessor threads
-per MPI task. Additionally, an offload timing summary is printed at
-the end of each run. When offloading, the frequency for :doc:`atom sorting <atom_modify>` is changed to 1 so that the per-atom data is
-effectively sorted at every rebuild of the neighbor lists. All the
-available coprocessor threads on each Phi will be divided among MPI
-tasks, unless the *tptask* option of the "-pk intel" :ref:`command-line switch <start_7>` is used to limit the coprocessor
-threads per MPI task.
-
-Restrictions
-""""""""""""
-
-
-When offloading to a coprocessor, :doc:`hybrid <pair_hybrid>` styles
-that require skip lists for neighbor builds cannot be offloaded.
-Using :doc:`hybrid/overlay <pair_hybrid>` is allowed. Only one intel
-accelerated style may be used with hybrid styles.
-:doc:`Special_bonds <special_bonds>` exclusion lists are not currently
-supported with offload, however, the same effect can often be
-accomplished by setting cutoffs for excluded atom types to 0. None of
-the pair styles in the USER-INTEL package currently support the
-"inner", "middle", "outer" options for rRESPA integration via the
-:doc:`run_style respa <run_style>` command; only the "pair" option is
-supported.
-
-**References:**
-
-* Brown, W.M., Carrillo, J.-M.Y., Mishra, B., Gavhane, N., Thakker, F.M., De Kraker, A.R., Yamada, M., Ang, J.A., Plimpton, S.J., “Optimizing Classical Molecular Dynamics in LAMMPS,” in Intel Xeon Phi Processor High Performance Programming: Knights Landing Edition, J. Jeffers, J. Reinders, A. Sodani, Eds. Morgan Kaufmann.
-* Brown, W. M., Semin, A., Hebenstreit, M., Khvostov, S., Raman, K., Plimpton, S.J. Increasing Molecular Dynamics Simulation Rates with an 8-Fold Increase in Electrical Power Efficiency. 2016 International Conference for High Performance Computing. In press.
-Your compiler must support the OpenMP interface. You should have one
-or more multi-core CPUs so that multiple threads can be launched by
-each MPI task running on a CPU.
-
-**Building LAMMPS with the USER-OMP package:**
-
-The lines above illustrate how to include/build with the USER-OMP
-package in two steps, using the "make" command. Or how to do it with
-one command via the src/Make.py script, described in :ref:`Section 2.4 <start_4>` of the manual. Type "Make.py -h" for
-help.
-
-Note that the CCFLAGS and LINKFLAGS settings in Makefile.machine must
-include "-fopenmp". Likewise, if you use an Intel compiler, the
-CCFLAGS setting must include "-restrict". The Make.py command will
-add these automatically.
-
-**Run with the USER-OMP package from the command line:**
-
-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.
-
-You need to choose how many OpenMP threads per MPI task will be used
-by the USER-OMP package. Note that the product of MPI tasks *
-threads/task should not exceed the physical number of cores (on a
-node), otherwise performance will suffer.
-
-As in the lines above, use the "-sf omp" :ref:`command-line switch <start_7>`, which will automatically append
-"omp" to styles that support it. The "-sf omp" switch also issues a
-default :doc:`package omp 0 <package>` command, which will set the
-number of threads per MPI task via the OMP_NUM_THREADS environment
-variable.
-
-You can also use the "-pk omp Nt" :ref:`command-line switch <start_7>`, to explicitly set Nt = # of OpenMP
-threads per MPI task to use, as well as additional options. Its
-syntax is the same as the :doc:`package omp <package>` command whose doc
-page gives details, including the default values used if it is not
-specified. It also gives more details on how to set the number of
-threads via the OMP_NUM_THREADS environment variable.
-
-**Or run with the USER-OMP package by editing an input script:**
-
-The discussion above for the mpirun/mpiexec command, MPI tasks/node,
-and threads/MPI task is the same.
-
-Use the :doc:`suffix omp <suffix>` command, or you can explicitly add an
-"omp" suffix to individual styles in your input script, e.g.
-
-.. parsed-literal::
-
- pair_style lj/cut/omp 2.5
-
-You must also use the :doc:`package omp <package>` command to enable the
-USER-OMP package. When you do this you also specify how many threads
-per MPI task to use. The command doc page explains other options and
-how to set the number of threads via the OMP_NUM_THREADS environment
-variable.
-
-**Speed-ups to expect:**
-
-Depending on which styles are accelerated, you should look for a
-reduction in the "Pair time", "Bond time", "KSpace time", and "Loop
-time" values printed at the end of a run.
-
-You may see a small performance advantage (5 to 20%) when running a
-USER-OMP style (in serial or parallel) with a single thread per MPI
-task, versus running standard LAMMPS with its standard un-accelerated
-styles (in serial or all-MPI parallelization with 1 task/core). This
-is because many of the USER-OMP styles contain similar optimizations
-to those used in the OPT package, described in :doc:`Section accelerate 5.3.6 <accelerate_opt>`.
-
-With multiple threads/task, the optimal choice of number of MPI
-tasks/node and OpenMP threads/task can vary a lot and should always be
-tested via benchmark runs for a specific simulation running on a
-specific machine, paying attention to guidelines discussed in the next
-sub-section.
-
-A description of the multi-threading strategy used in the USER-OMP
-package and some performance examples are `presented here <http://sites.google.com/site/akohlmey/software/lammps-icms/lammps-icms-tms2011-talk.pdf?attredirects=0&d=1>`_
-
-**Guidelines for best performance:**
-
-For many problems on current generation CPUs, running the USER-OMP
-package with a single thread/task is faster than running with multiple
-threads/task. This is because the MPI parallelization in LAMMPS is
-often more efficient than multi-threading as implemented in the
-USER-OMP package. The parallel efficiency (in a threaded sense) also
-varies for different USER-OMP styles.
-
-Using multiple threads/task can be more effective under the following
-circumstances:
-
-* Individual compute nodes have a significant number of CPU cores but
- the CPU itself has limited memory bandwidth, e.g. for Intel Xeon 53xx
- (Clovertown) and 54xx (Harpertown) quad-core processors. Running one
- MPI task per CPU core will result in significant performance
- degradation, so that running with 4 or even only 2 MPI tasks per node
- is faster. Running in hybrid MPI+OpenMP mode will reduce the
- inter-node communication bandwidth contention in the same way, but
- offers an additional speedup by utilizing the otherwise idle CPU
- cores.
-* The interconnect used for MPI communication does not provide
- sufficient bandwidth for a large number of MPI tasks per node. For
- example, this applies to running over gigabit ethernet or on Cray XT4
- or XT5 series supercomputers. As in the aforementioned case, this
- effect worsens when using an increasing number of nodes.
-* The system has a spatially inhomogeneous particle density which does
- not map well to the :doc:`domain decomposition scheme <processors>` or
- :doc:`load-balancing <balance>` options that LAMMPS provides. This is
- because multi-threading achives parallelism over the number of
- particles, not via their distribution in space.
-* A machine is being used in "capability mode", i.e. near the point
- where MPI parallelism is maxed out. For example, this can happen when
- using the :doc:`PPPM solver <kspace_style>` for long-range
- electrostatics on large numbers of nodes. The scaling of the KSpace
- calculation (see the :doc:`kspace_style <kspace_style>` command) becomes
- the performance-limiting factor. Using multi-threading allows less
- MPI tasks to be invoked and can speed-up the long-range solver, while
- increasing overall performance by parallelizing the pairwise and
- bonded calculations via OpenMP. Likewise additional speedup can be
- sometimes be achived by increasing the length of the Coulombic cutoff
- and thus reducing the work done by the long-range solver. Using the
- :doc:`run_style verlet/split <run_style>` command, which is compatible
- with the USER-OMP package, is an alternative way to reduce the number
- of MPI tasks assigned to the KSpace calculation.
-Additional performance tips are as follows:
-
-* The best parallel efficiency from *omp* styles is typically achieved
- when there is at least one MPI task per physical CPU chip, i.e. socket
- or die.
-* It is usually most efficient to restrict threading to a single
- socket, i.e. use one or more MPI task per socket.
-* NOTE: By default, several current MPI implementations use a processor
- affinity setting that restricts each MPI task to a single CPU core.
- Using multi-threading in this mode will force all threads to share the
- one core and thus is likely to be counterproductive. Instead, binding
- MPI tasks to a (multi-core) socket, should solve this issue.
-* 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/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 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
-In other words, using one bracket reduces the dimension of the
-quantity once (vector -> scalar, array -> vector). Using two brackets
-reduces the dimension twice (array -> scalar). Thus a command that
-uses scalar compute values as input can also process elements of a
-vector or array.
-
-Note that commands and :doc:`variables <variable>` which use compute
-quantities typically do not allow for all kinds, e.g. a command may
-require a vector of values, not a scalar. This means there is no
-ambiguity about referring to a compute quantity as c_ID even if it
-produces, for example, both a scalar and vector. The doc pages for
-various commands explain the details.
-
-
-----------
-
-
-In LAMMPS, the values generated by a compute can be used in several
-ways:
-
-* The results of computes that calculate a global temperature or
- pressure can be used by fixes that do thermostatting or barostatting
- or when atom velocities are created.
-* Global values can be output via the :doc:`thermo_style custom <thermo_style>` or :doc:`fix ave/time <fix_ave_time>` command.
- Or the values can be referenced in a :doc:`variable equal <variable>` or
- :doc:`variable atom <variable>` command.
-* Per-atom values can be output via the :doc:`dump custom <dump>` command.
- Or they can be time-averaged via the :doc:`fix ave/atom <fix_ave_atom>`
- command or reduced by the :doc:`compute reduce <compute_reduce>`
- command. Or the per-atom values can be referenced in an :doc:`atom-style variable <variable>`.
-* Local values can be reduced by the :doc:`compute reduce <compute_reduce>` command, or histogrammed by the :doc:`fix ave/histo <fix_ave_histo>` command, or output by the :doc:`dump local <dump>` command.
-The results of computes that calculate global quantities can be either
-"intensive" or "extensive" values. Intensive means the value is
-independent of the number of atoms in the simulation,
-e.g. temperature. Extensive means the value scales with the number of
-atoms in the simulation, e.g. total rotational kinetic energy.
-:doc:`Thermodynamic output <thermo_style>` will normalize extensive
-values by the number of atoms in the system, depending on the
-"thermo_modify norm" setting. It will not normalize intensive values.
-If a compute value is accessed in another way, e.g. by a
-:doc:`variable <variable>`, you may want to know whether it is an
-intensive or extensive value. See the doc page for individual
-computes for further info.
-
-
-----------
-
-
-LAMMPS creates its own computes internally for thermodynamic output.
-Three computes are always created, named "thermo_temp",
-"thermo_press", and "thermo_pe", as if these commands had been invoked
-in the input script:
-
-.. parsed-literal::
-
- compute thermo_temp all temp
- compute thermo_press all pressure thermo_temp
- compute thermo_pe all pe
-
-Additional computes for other quantities are created if the thermo
-style requires it. See the documentation for the
-:doc:`thermo_style <thermo_style>` command.
-
-Fixes that calculate temperature or pressure, i.e. for thermostatting
-or barostatting, may also create computes. These are discussed in the
-documentation for specific :doc:`fix <fix>` commands.
-
-In all these cases, the default computes LAMMPS creates can be
-replaced by computes defined by the user in the input script, as
-described by the :doc:`thermo_modify <thermo_modify>` and :doc:`fix modify <fix_modify>` commands.
-
-Properties of either a default or user-defined compute can be modified
-via the :doc:`compute_modify <compute_modify>` command.
-
-Computes can be deleted with the :doc:`uncompute <uncompute>` command.
-
-Code for new computes can be added to LAMMPS (see :doc:`this section <Section_modify>` of the manual) and the results of their
-calculations accessed in the various ways described above.
-
-
-----------
-
-
-Each compute style has its own doc page which describes its arguments
-and what it does. Here is an alphabetic list of compute styles
-available in LAMMPS. They are also given in more compact form in the
-Compute section of :ref:`this page <cmd_5>`.
-
-There are also additional compute styles (not listed here) submitted
-by users which are included in the LAMMPS distribution. The list of
-these with links to the individual styles are given in the compute
-section of :ref:`this page <cmd_5>`.
-
-* :doc:`angle/local <compute_bond_local>` - theta and energy of each angle
-* :doc:`angmom/chunk <compute_angmom_chunk>` - angular momentum for each chunk
-* :doc:`body/local <compute_body_local>` - attributes of body sub-particles
-* :doc:`bond <compute_bond>` - values computed by a bond style
-* :doc:`bond/local <compute_bond_local>` - distance and energy of each bond
-* :doc:`centro/atom <compute_centro_atom>` - centro-symmetry parameter for each atom
-* :doc:`chunk/atom <compute_chunk_atom>` - assign chunk IDs to each atom
-* :doc:`cluster/atom <compute_cluster_atom>` - cluster ID for each atom
-* :doc:`cna/atom <compute_cna_atom>` - common neighbor analysis (CNA) for each atom
-* :doc:`com <compute_com>` - center-of-mass of group of atoms
-* :doc:`com/chunk <compute_com_chunk>` - center-of-mass for each chunk
-* :doc:`contact/atom <compute_contact_atom>` - contact count for each spherical particle
-* :doc:`coord/atom <compute_coord_atom>` - coordination number for each atom
-* :doc:`damage/atom <compute_damage_atom>` - Peridynamic damage for each atom
-* :doc:`dihedral/local <compute_dihedral_local>` - angle of each dihedral
-* :doc:`dilatation/atom <compute_dilatation_atom>` - Peridynamic dilatation for each atom
-* :doc:`displace/atom <compute_displace_atom>` - displacement of each atom
-* :doc:`erotate/asphere <compute_erotate_asphere>` - rotational energy of aspherical particles
-* :doc:`erotate/rigid <compute_erotate_rigid>` - rotational energy of rigid bodies
-* :doc:`erotate/sphere <compute_erotate_sphere>` - rotational energy of spherical particles
-* :doc:`erotate/sphere/atom <compute_erotate_sphere>` - rotational energy for each spherical particle
-* :doc:`event/displace <compute_event_displace>` - detect event on atom displacement
-* :doc:`group/group <compute_group_group>` - energy/force between two groups of atoms
-* :doc:`gyration <compute_gyration>` - radius of gyration of group of atoms
-* :doc:`gyration/chunk <compute_gyration_chunk>` - radius of gyration for each chunk
-* :doc:`heat/flux <compute_heat_flux>` - heat flux through a group of atoms
-* :doc:`hexorder/atom <compute_hexorder_atom>` - bond orientational order parameter q6
-* :doc:`improper/local <compute_improper_local>` - angle of each improper
-* :doc:`inertia/chunk <compute_inertia_chunk>` - inertia tensor for each chunk
-* :doc:`ke <compute_ke>` - translational kinetic energy
-* :doc:`ke/atom <compute_ke_atom>` - kinetic energy for each atom
-* :doc:`ke/rigid <compute_ke_rigid>` - translational kinetic energy of rigid bodies
-* :doc:`msd <compute_msd>` - mean-squared displacement of group of atoms
-* :doc:`msd/chunk <compute_msd_chunk>` - mean-squared displacement for each chunk
-* :doc:`msd/nongauss <compute_msd_nongauss>` - MSD and non-Gaussian parameter of group of atoms
-* :doc:`omega/chunk <compute_omega_chunk>` - angular velocity for each chunk
-* :doc:`orientorder/atom <compute_orientorder_atom>` - Steinhardt bond orientational order parameters Ql
-* :doc:`pair <compute_pair>` - values computed by a pair style
-* :doc:`pair/local <compute_pair_local>` - distance/energy/force of each pairwise interaction
-* :doc:`pe <compute_pe>` - potential energy
-* :doc:`pe/atom <compute_pe_atom>` - potential energy for each atom
-* :doc:`plasticity/atom <compute_plasticity_atom>` - Peridynamic plasticity for each atom
-* :doc:`pressure <compute_pressure>` - total pressure and pressure tensor
-* :doc:`property/atom <compute_property_atom>` - convert atom attributes to per-atom vectors/arrays
-* :doc:`property/local <compute_property_local>` - convert local attributes to localvectors/arrays
-* :doc:`property/chunk <compute_property_chunk>` - extract various per-chunk attributes
-* :doc:`rdf <compute_rdf>` - radial distribution function g(r) histogram of group of atoms
-* :doc:`reduce <compute_reduce>` - combine per-atom quantities into a single global value
-* :doc:`reduce/region <compute_reduce>` - same as compute reduce, within a region
-* :doc:`rigid/local <compute_rigid_local>` - extract rigid body attributes
-* :doc:`slice <compute_slice>` - extract values from global vector or array
-* :doc:`sna/atom <compute_sna_atom>` - calculate bispectrum coefficients for each atom
-* :doc:`snad/atom <compute_sna_atom>` - derivative of bispectrum coefficients for each atom
-* :doc:`snav/atom <compute_sna_atom>` - virial contribution from bispectrum coefficients for each atom
-* :doc:`stress/atom <compute_stress_atom>` - stress tensor for each atom
-* :doc:`temp <compute_temp>` - temperature of group of atoms
-* :doc:`temp/asphere <compute_temp_asphere>` - temperature of aspherical particles
-* :doc:`temp/body <compute_temp_body>` - temperature of body particles
-* :doc:`temp/chunk <compute_temp_chunk>` - temperature of each chunk
-* :doc:`temp/com <compute_temp_com>` - temperature after subtracting center-of-mass velocity
-* :doc:`temp/deform <compute_temp_deform>` - temperature excluding box deformation velocity
-* :doc:`temp/partial <compute_temp_partial>` - temperature excluding one or more dimensions of velocity
-* :doc:`temp/profile <compute_temp_profile>` - temperature excluding a binned velocity profile
-* :doc:`temp/ramp <compute_temp_ramp>` - temperature excluding ramped velocity component
-* :doc:`temp/region <compute_temp_region>` - temperature of a region of atoms
-* :doc:`temp/sphere <compute_temp_sphere>` - temperature of spherical particles
-* :doc:`ti <compute_ti>` - thermodyanmic integration free energy values
-* :doc:`torque/chunk <compute_torque_chunk>` - torque applied on each chunk
-* :doc:`vacf <compute_vacf>` - velocity-autocorrelation function of group of atoms
-* :doc:`vcm/chunk <compute_vcm_chunk>` - velocity of center-of-mass for each chunk
-* :doc:`voronoi/atom <compute_voronoi_atom>` - Voronoi volume and neighbors for each atom
-
-There are also additional compute styles submitted by users which are
-included in the LAMMPS distribution. The list of these with links to
-the individual styles are given in the compute section of :ref:`this page <cmd_5>`.
-
-There are also additional accelerated compute styles included in the
-LAMMPS distribution for faster performance on CPUs and GPUs. The list
-of these with links to the individual styles are given in the pair
-* ID, group-ID are documented in :doc:`compute <compute>` command
-* angmom/chunk = style name of this compute command
-* chunkID = ID of :doc:`compute chunk/atom <compute_chunk_atom>` command
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- compute 1 fluid angmom/chunk molchunk
-
-Description
-"""""""""""
-
-Define a computation that calculates the angular momemtum of multiple
-chunks of atoms.
-
-In LAMMPS, chunks are collections of atoms defined by a :doc:`compute chunk/atom <compute_chunk_atom>` command, which assigns each atom
-to a single chunk (or no chunk). The ID for this command is specified
-as chunkID. For example, a single chunk could be the atoms in a
-molecule or atoms in a spatial bin. See the :doc:`compute chunk/atom <compute_chunk_atom>` doc page and ":ref:`Section_howto 23 <howto_23>` for details of how chunks can be
-defined and examples of how they can be used to measure properties of
-a system.
-
-This compute calculates the 3 components of the angular momentum
-vector for each chunk, due to the velocity/momentum of the individual
-atoms in the chunk around the center-of-mass of the chunk. The
-calculation includes all effects due to atoms passing thru periodic
-boundaries.
-
-Note that only atoms in the specified group contribute to the
-calculation. The :doc:`compute chunk/atom <compute_chunk_atom>` command
-defines its own group; atoms will have a chunk ID = 0 if they are not
-in that group, signifying they are not assigned to a chunk, and will
-thus also not contribute to this calculation. You can specify the
-"all" group for this command if you simply want to include atoms with
-non-zero chunk IDs.
-
-.. note::
-
- The coordinates of an atom contribute to the chunk's angular
- momentum in "unwrapped" form, by using the image flags associated with
- each atom. See the :doc:`dump custom <dump>` command for a discussion
- of "unwrapped" coordinates. See the Atoms section of the
- :doc:`read_data <read_data>` command for a discussion of image flags and
- how they are set for each atom. You can reset the image flags
- (e.g. to 0) before invoking this compute by using the :doc:`set image <set>` command.
-
-The simplest way to output the results of the compute angmom/chunk
-calculation to a file is to use the :doc:`fix ave/time <fix_ave_time>`
- compute 1 all chunk/atom bin/cylinder z lower 2 10 10 2.0 5.0 3 discard yes
-
-Description
-"""""""""""
-
-Define a computation that calculates an integer chunk ID from 1 to
-Nchunk for each atom in the group. Values of chunk IDs are determined
-by the *style* of chunk, which can be based on atom type or molecule
-ID or spatial binning or a per-atom property or value calculated by
-another :doc:`compute <compute>`, :doc:`fix <fix>`, or :doc:`atom-style variable <variable>`. Per-atom chunk IDs can be used by other
-computes with "chunk" in their style name, such as :doc:`compute com/chunk <compute_com_chunk>` or :doc:`compute msd/chunk <compute_msd_chunk>`. Or they can be used by the :doc:`fix ave/chunk <fix_ave_chunk>` command to sum and time average a
-variety of per-atom properties over the atoms in each chunk. Or they
-can simply be accessed by any command that uses per-atom values from a
-compute as input, as discussed in :ref:`Section_howto 15 <howto_15>`.
-
-See :ref:`Section_howto 23 <howto_23>` for an overview of
-how this compute can be used with a variety of other commands to
-tabulate properties of a simulation. The howto section gives several
-examples of input script commands that can be used to calculate
-interesting properties.
-
-Conceptually it is important to realize that this compute does two
-simple things. First, it sets the value of *Nchunk* = the number of
-chunks, which can be a constant value or change over time. Second, it
-assigns each atom to a chunk via a chunk ID. Chunk IDs range from 1
-to *Nchunk* inclusive; some chunks may have no atoms assigned to them.
-Atoms that do not belong to any chunk are assigned a value of 0. Note
-that the two operations are not always performed together. For
-example, spatial bins can be setup once (which sets *Nchunk*\ ), and
-atoms assigned to those bins many times thereafter (setting their
-chunk IDs).
-
-All other commands in LAMMPS that use chunk IDs assume there are
-*Nchunk* number of chunks, and that every atom is assigned to one of
-those chunks, or not assigned to any chunk.
-
-There are many options for specifying for how and when *Nchunk* is
-calculated, and how and when chunk IDs are assigned to atoms. The
-details depend on the chunk *style* and its *args*\ , as well as
-optional keyword settings. They can also depend on whether a :doc:`fix ave/chunk <fix_ave_chunk>` command is using this compute, since
-that command requires *Nchunk* to remain static across windows of
-timesteps it specifies, while it accumulates per-chunk averages.
-
-The details are described below.
-
-
-
-
-
-The different chunk styles operate as follows. For each style, how it
-calculates *Nchunk* and assigns chunk IDs to atoms is explained. Note
-that using the optional keywords can change both of those actions, as
-described further below where the keywords are discussed.
-
-
-----------
-
-
-The *binning* styles perform a spatial binning of atoms, and assign an
-atom the chunk ID corresponding to the bin number it is in. *Nchunk*
-is set to the number of bins, which can change if the simulation box
-size changes.
-
-The *bin/1d*\ , *bin/2d*\ , and *bin/3d* styles define bins as 1d layers
-(slabs), 2d pencils, or 3d boxes. The *dim*\ , *origin*\ , and *delta*
-settings are specified 1, 2, or 3 times. For 2d or 3d bins, there is
-no restriction on specifying dim = x before dim = y or z, or dim = y
-before dim = z. Bins in a particular *dim* have a bin size in that
-dimension given by *delta*\ . In each dimension, bins are defined
-relative to a specified *origin*\ , which may be the lower/upper edge of
-the simulation box (in that dimension), or its center point, or a
-specified coordinate value. Starting at the origin, sufficient bins
-are created in both directions to completely span the simulation box
-or the bounds specified by the optional *bounds* keyword.
-
-For orthogonal simulation boxes, the bins are layers, pencils, or
-boxes aligned with the xyz coordinate axes. For triclinic
-(non-orthogonal) simulation boxes, the bin faces are parallel to the
-tilted faces of the simulation box. See :ref:`this section <howto_12>` of the manual for a discussion of
-the geometry of triclinic boxes in LAMMPS. As described there, a
-tilted simulation box has edge vectors a,b,c. In that nomenclature,
-bins in the x dimension have faces with normals in the "b" cross "c"
-direction. Bins in y have faces normal to the "a" cross "c"
-direction. And bins in z have faces normal to the "a" cross "b"
-direction. Note that in order to define the size and position of
-these bins in an unambiguous fashion, the *units* option must be set
-to *reduced* when using a triclinic simulation box, as noted below.
-
-The meaning of *origin* and *delta* for triclinic boxes is as follows.
-Consider a triclinic box with bins that are 1d layers or slabs in the
-x dimension. No matter how the box is tilted, an *origin* of 0.0
-means start layers at the lower "b" cross "c" plane of the simulation
-box and an *origin* of 1.0 means to start layers at the upper "b"
-cross "c" face of the box. A *delta* value of 0.1 in *reduced* units
-means there will be 10 layers from 0.0 to 1.0, regardless of the
-current size or shape of the simulation box.
-
-The *bin/sphere* style defines a set of spherical shell bins around
-the origin (\ *xorig*\ ,\ *yorig*\ ,\ *zorig*\ ), using *nsbin* bins with radii
-equally spaced between *srmin* and *srmax*\ . This is effectively a 1d
-vector of bins. For example, if *srmin* = 1.0 and *srmax* = 10.0 and
-*nsbin* = 9, then the first bin spans 1.0 < r < 2.0, and the last bin
-spans 9.0 < r 10.0. The geometry of the bins is the same whether the
-simulation box is orthogonal or triclinic; i.e. the spherical shells
-are not tilted or scaled differently in different dimensions to
-transform them into ellipsoidal shells.
-
-The *bin/cylinder* style defines bins for a cylinder oriented along
-the axis *dim* with the axis coordinates in the other two radial
-dimensions at (\ *c1*\ ,\ *c2*\ ). For dim = x, c1/c2 = y/z; for dim = y,
-c1/c2 = x/z; for dim = z, c1/c2 = x/y. This is effectively a 2d array
-of bins. The first dimension is along the cylinder axis, the second
-dimension is radially outward from the cylinder axis. The bin size
-and positions along the cylinder axis are specified by the *origin*
-and *delta* values, the same as for the *bin/1d*\ , *bin/2d*\ , and
-*bin/3d* styles. There are *ncbin* concentric circle bins in the
-radial direction from the cylinder axis with radii equally spaced
-between *crmin* and *crmax*\ . For example, if *crmin* = 1.0 and
-*crmax* = 10.0 and *ncbin* = 9, then the first bin spans 1.0 < r <
-2.0, and the last bin spans 9.0 < r 10.0. The geometry of the bins in
-the radial dimensions is the same whether the simulation box is
-orthogonal or triclinic; i.e. the concetric circles are not tilted or
-scaled differently in the two different dimensions to transform them
-into ellipses.
-
-The created bins (and hence the chunk IDs) are numbered consecutively
-from 1 to the number of bins = *Nchunk*\ . For *bin2d* and *bin3d*\ , the
-numbering varies most rapidly in the first dimension (which could be
-x, y, or z), next rapidly in the 2nd dimension, and most slowly in the
-3rd dimension. For *bin/sphere*\ , the bin with smallest radii is chunk
-1 and the bni with largest radii is chunk Nchunk = *ncbin*\ . For
-*bin/cylinder*\ , the numbering varies most rapidly in the dimension
-along the cylinder axis and most slowly in the radial direction.
-
-Each time this compute is invoked, each atom is mapped to a bin based
-on its current position. Note that between reneighboring timesteps,
-atoms can move outside the current simulation box. If the box is
-periodic (in that dimension) the atom is remapping into the periodic
-box for purposes of binning. If the box in not periodic, the atom may
-have moved outside the bounds of all bins. If an atom is not inside
-any bin, the *discard* keyword is used to determine how a chunk ID is
-assigned to the atom.
-
-
-----------
-
-
-The *type* style uses the atom type as the chunk ID. *Nchunk* is set
-to the number of atom types defined for the simulation, e.g. via the
-:doc:`create_box <create_box>` or :doc:`read_data <read_data>` commands.
-
-
-----------
-
-
-The *molecule* style uses the molecule ID of each atom as its chunk
-ID. *Nchunk* is set to the largest chunk ID. Note that this excludes
-molecule IDs for atoms which are not in the specified group or
-optional region.
-
-There is no requirement that all atoms in a particular molecule are
-assigned the same chunk ID (zero or non-zero), though you probably
-want that to be the case, if you wish to compute a per-molecule
-property. LAMMPS will issue a warning if that is not the case, but
-only the first time that *Nchunk* is calculated.
-
-Note that atoms with a molecule ID = 0, which may be non-molecular
-solvent atoms, have an out-of-range chunk ID. These atoms are
-discarded (not assigned to any chunk) or assigned to *Nchunk*\ ,
-depending on the value of the *discard* keyword.
-
-
-----------
-
-
-The *compute/fix/variable* styles set the chunk ID of each atom based
-on a quantity calculated and stored by a compute, fix, or variable.
-In each case, it must be a per-atom quantity. In each case the
-referenced floating point values are converted to an integer chunk ID
-as follows. The floating point value is truncated (rounded down) to
-an integer value. If the integer value is <= 0, then a chunk ID of 0
-is assigned to the atom. If the integer value is > 0, it becomes the
-chunk ID to the atom. *Nchunk* is set to the largest chunk ID. Note
-that this excludes atoms which are not in the specified group or
-optional region.
-
-If the style begins with "c_", a compute ID must follow which has been
-previously defined in the input script. If no bracketed integer is
-appended, the per-atom vector calculated by the compute is used. If a
-bracketed integer is appended, the Ith column of the per-atom array
-calculated by the compute is used. Users can also write code for
-their own compute styles and :doc:`add them to LAMMPS <Section_modify>`.
-
-If the style begins with "f_", a fix ID must follow which has been
-previously defined in the input script. If no bracketed integer is
-appended, the per-atom vector calculated by the fix is used. If a
-bracketed integer is appended, the Ith column of the per-atom array
-calculated by the fix is used. Note that some fixes only produce
-their values on certain timesteps, which must be compatible with the
-timestep on which this compute accesses the fix, else an error
-results. Users can also write code for their own fix styles and :doc:`add them to LAMMPS <Section_modify>`.
-
-If a value begins with "v_", a variable name for an *atom* or
-*atomfile* style :doc:`variable <variable>` must follow which has been
-previously defined in the input script. Variables of style *atom* can
-reference thermodynamic keywords and various per-atom attributes, or
-invoke other computes, fixes, or variables when they are evaluated, so
-this is a very general means of generating per-atom quantities to
-treat as a chunk ID.
-
-
-
-
-
-Normally, *Nchunk* = the number of chunks, is re-calculated every time
-this fix is invoked, though the value may or may not change. As
-explained below, the *nchunk* keyword can be set to *once* which means
-*Nchunk* will never change.
-
-If a :doc:`fix ave/chunk <fix_ave_chunk>` command uses this compute, it
-can also turn off the re-calculation of *Nchunk* for one or more
-windows of timesteps. The extent of the windows, during which Nchunk
-is held constant, are determined by the *Nevery*\ , *Nrepeat*\ , *Nfreq*
-values and the *ave* keyword setting that are used by the :doc:`fix ave/chunk <fix_ave_chunk>` command.
-
-Specifically, if *ave* = *one*\ , then for each span of *Nfreq*
-timesteps, *Nchunk* is held constant between the first timestep when
-averaging is done (within the Nfreq-length window), and the last
-timestep when averaging is done (multiple of Nfreq). If *ave* =
-*running* or *window*\ , then *Nchunk* is held constant forever,
-starting on the first timestep when the :doc:`fix ave/chunk <fix_ave_chunk>` command invokes this compute.
-
-Note that multiple :doc:`fix ave/chunk <fix_ave_chunk>` commands can use
-the same compute chunk/atom compute. However, the time windows they
-induce for holding *Nchunk* constant must be identical, else an error
-will be generated.
-
-
-
-
-
-The various optional keywords operate as follows. Note that some of
-them function differently or are ignored by different chunk styles.
-Some of them also have different default values, depending on
-the chunk style, as listed below.
-
-The *region* keyword applies to all chunk styles. If used, an atom
-must be in both the specified group and the specified geometric
-:doc:`region <region>` to be assigned to a chunk.
-
-
-----------
-
-
-The *nchunk* keyword applies to all chunk styles. It specifies how
-often *Nchunk* is recalculated, which in turn can affect the chunk IDs
-assigned to individual atoms.
-
-If *nchunk* is set to *once*\ , then *Nchunk* is only calculated once,
-the first time this compute is invoked. If *nchunk* is set to
-*every*\ , then *Nchunk* is re-calculated every time the compute is
-invoked. Note that, as described above, the use of this compute
-by the :doc:`fix ave/chunk <fix_ave_chunk>` command can override
-the *every* setting.
-
-The default values for *nchunk* are listed below and depend on the
-chunk style and other system and keyword settings. They attempt to
-represent typical use cases for the various chunk styles. The
-*nchunk* value can always be set explicitly if desired.
-
-
-----------
-
-
-The *limit* keyword can be used to limit the calculated value of
-*Nchunk* = the number of chunks. The limit is applied each time
-*Nchunk* is calculated, which also limits the chunk IDs assigned to
-any atom. The *limit* keyword is used by all chunk styles except the
-*binning* styles, which ignore it. This is because the number of bins
-can be tailored using the *bound* keyword (described below) which
-effectively limits the size of *Nchunk*\ .
-
-If *limit* is set to *Nc* = 0, then no limit is imposed on *Nchunk*\ ,
-though the *compress* keyword can still be used to reduce *Nchunk*\ , as
-described below.
-
-If *Nc* > 0, then the effect of the *limit* keyword depends on whether
-the *compress* keyword is also used with a setting of *yes*\ , and
-whether the *compress* keyword is specified before the *limit* keyword
-or after.
-
-In all cases, *Nchunk* is first calculated in the usual way for each
-chunk style, as described above.
-
-First, here is what occurs if *compress yes* is not set. If *limit*
-is set to *Nc max*\ , then *Nchunk* is reset to the smaller of *Nchunk*
-and *Nc*\ . If *limit* is set to *Nc exact*\ , then *Nchunk* is reset to
-*Nc*\ , whether the original *Nchunk* was larger or smaller than *Nc*\ .
-If *Nchunk* shrank due to the *limit* setting, then atom chunk IDs >
-*Nchunk* will be reset to 0 or *Nchunk*\ , depending on the setting of
-the *discard* keyword. If *Nchunk* grew, there will simply be some
-chunks with no atoms assigned to them.
-
-If *compress yes* is set, and the *compress* keyword comes before the
-*limit* keyword, the compression operation is performed first, as
-described below, which resets *Nchunk*\ . The *limit* keyword is then
-applied to the new *Nchunk* value, exactly as described in the
-preceeding paragraph. Note that in this case, all atoms will end up
-with chunk IDs <= *Nc*\ , but their original values (e.g. molecule ID or
-compute/fix/variable value) may have been > *Nc*\ , because of the
-compression operation.
-
-If *compress yes* is set, and the *compress* keyword comes after the
-*limit* keyword, then the *limit* value of *Nc* is applied first to
-the uncompressed value of *Nchunk*\ , but only if *Nc* < *Nchunk*
-(whether *Nc max* or *Nc exact* is used). This effectively means all
-atoms with chunk IDs > *Nc* have their chunk IDs reset to 0 or *Nc*\ ,
-depending on the setting of the *discard* keyword. The compression
-operation is then performed, which may shrink *Nchunk* further. If
-the new *Nchunk* < *Nc* and *limit* = *Nc exact* is specified, then
-*Nchunk* is reset to *Nc*\ , which results in extra chunks with no atoms
-assigned to them. Note that in this case, all atoms will end up with
-chunk IDs <= *Nc*\ , and their original values (e.g. molecule ID or
-compute/fix/variable value) will also have been <= *Nc*\ .
-
-
-----------
-
-
-The *ids* keyword applies to all chunk styles. If the setting is
-*once* then the chunk IDs assigned to atoms the first time this
-compute is invoked will be permanent, and never be re-computed.
-
-If the setting is *nfreq* and if a :doc:`fix ave/chunk <fix_ave_chunk>`
-command is using this compute, then in each of the *Nchunk* = constant
-time windows (discussed above), the chunk ID's assigned to atoms on
-the first step of the time window will persist until the end of the
-time window.
-
-If the setting is *every*\ , which is the default, then chunk IDs are
-re-calculated on any timestep this compute is invoked.
-
-.. note::
-
- If you want the persistent chunk-IDs calculated by this compute
- to be continuous when running from a :doc:`restart file <read_restart>`,
- then you should use the same ID for this compute, as in the original
- run. This is so that the fix this compute creates to store per-atom
- quantities will also have the same ID, and thus be initialized
- correctly with chunk IDs from the restart file.
-
-
-----------
-
-
-The *compress* keyword applies to all chunk styles and affects how
-*Nchunk* is calculated, which in turn affects the chunk IDs assigned
-to each atom. It is useful for converting a "sparse" set of chunk IDs
-(with many IDs that have no atoms assigned to them), into a "dense"
-set of IDs, where every chunk has one or more atoms assigned to it.
-
-Two possible use cases are as follows. If a large simulation box is
-mostly empty space, then the *binning* style may produce many bins
-with no atoms. If *compress* is set to *yes*\ , only bins with atoms
-will be contribute to *Nchunk*\ . Likewise, the *molecule* or
-*compute/fix/variable* styles may produce large *Nchunk* values. For
-example, the :doc:`compute cluster/atom <compute_cluster_atom>` command
-assigns every atom an atom ID for one of the atoms it is clustered
-with. For a million-atom system with 5 clusters, there would only be
-5 unique chunk IDs, but the largest chunk ID might be 1 million,
-resulting in *Nchunk* = 1 million. If *compress* is set to *yes*\ ,
-*Nchunk* will be reset to 5.
-
-If *compress* is set to *no*\ , which is the default, no compression is
-done. If it is set to *yes*\ , all chunk IDs with no atoms are removed
-from the list of chunk IDs, and the list is sorted. The remaining
-chunk IDs are renumbered from 1 to *Nchunk* where *Nchunk* is the new
-length of the list. The chunk IDs assigned to each atom reflect
-the new renumbering from 1 to *Nchunk*\ .
-
-The original chunk IDs (before renumbering) can be accessed by the
-:doc:`compute property/chunk <compute_property_chunk>` command and its
-*id* keyword, or by the :doc:`fix ave/chunk <fix_ave_chunk>` command
-which outputs the original IDs as one of the columns in its global
-output array. For example, using the "compute cluster/atom" command
-discussed above, the original 5 unique chunk IDs might be atom IDs
-(27,4982,58374,857838,1000000). After compresion, these will be
-renumbered to (1,2,3,4,5). The original values (27,...,1000000) can
-be output to a file by the :doc:`fix ave/chunk <fix_ave_chunk>` command,
-or by using the :doc:`fix ave/time <fix_ave_time>` command in
-conjunction with the :doc:`compute property/chunk <compute_property_chunk>` command.
-
-.. note::
-
- The compression operation requires global communication across
- all processors to share their chunk ID values. It can require large
- memory on every processor to store them, even after they are
- compressed, if there are are a large number of unique chunk IDs with
- atoms assigned to them. It uses a STL map to find unique chunk IDs
- and store them in sorted order. Each time an atom is assigned a
- compressed chunk ID, it must access the STL map. All of this means
- that compression can be expensive, both in memory and CPU time. The
- use of the *limit* keyword in conjunction with the *compress* keyword
- can affect these costs, depending on which keyword is used first. So
- use this option with care.
-
-
-----------
-
-
-The *discard* keyword applies to all chunk styles. It affects what
-chunk IDs are assigned to atoms that do not match one of the valid
-chunk IDs from 1 to *Nchunk*\ . Note that it does not apply to atoms
-that are not in the specified group or optionally specified region.
-Those atoms are always assigned a chunk ID = 0.
-
-If the calculated chunk ID for an atom is not within the range 1 to
-*Nchunk* then it is a "discard" atom. Note that *Nchunk* may have
-been shrunk by the *limit* keyword. Or the *compress* keyword may
-have eliminated chunk IDs that were valid before the compression took
-place, and are now not in the compressed list. Also note that for the
-*molecule* chunk style, if new molecules are added to the system,
-their chunk IDs may exceed a previously calculated *Nchunk*\ .
-Likewise, evaluation of a compute/fix/variable on a later timestep may
-return chunk IDs that are invalid for the previously calculated
-*Nchunk*\ .
-
-All the chunk styles except the *binning* styles, must use *discard*
-set to either *yes* or *no*\ . If *discard* is set to *yes*\ , which is
-the default, then every "discard" atom has its chunk ID set to 0. If
-*discard* is set to *no*\ , every "discard" atom has its chunk ID set to
-*Nchunk*\ . I.e. it becomes part of the last chunk.
-
-The *binning* styles use the *discard* keyword to decide whether to
-discard atoms outside the spatial domain covered by bins, or to assign
-them to the bin they are nearest to.
-
-For the *bin/1d*\ , *bin/2d*\ , *bin/3d* styles the details are as
-follows. If *discard* is set to *yes*\ , an out-of-domain atom will
-have its chunk ID set to 0. If *discard* is set to *no*\ , the atom
-will have its chunk ID set to the first or last bin in that dimension.
-If *discard* is set to *mixed*\ , which is the default, it will only
-have its chunk ID set to the first or last bin if bins extend to the
-simulation box boundary in that dimension. This is the case if the
-*bound* keyword settings are *lower* and *upper*\ , which is the
-default. If the *bound* keyword settings are numeric values, then the
-atom will have its chunk ID set to 0 if it is outside the bounds of
-any bin. Note that in this case, it is possible that the first or
-last bin extends beyond the numeric *bounds* settings, depending on
-the specified *origin*\ . If this is the case, the chunk ID of the atom
-is only set to 0 if it is outside the first or last bin, not if it is
-simply outside the numeric *bounds* setting.
-
-For the *bin/sphere* style the details are as follows. If *discard*
-is set to *yes*\ , an out-of-domain atom will have its chunk ID set to
-0. If *discard* is set to *no* or *mixed*\ , the atom will have its
-chunk ID set to the first or last bin, i.e. the innermost or outermost
-spherical shell. If the distance of the atom from the origin is less
-than *rmin*\ , it will be assigned to the first bin. If the distance of
-the atom from the origin is greater than *rmax*\ , it will be assigned
-to the last bin.
-
-For the *bin/cylinder* style the details are as follows. If *discard*
-is set to *yes*\ , an out-of-domain atom will have its chunk ID set to
-0. If *discard* is set to *no*\ , the atom will have its chunk ID set
-to the first or last bin in both the radial and axis dimensions. If
-*discard* is set to *mixed*\ , which is the default, the the radial
-dimension is treated the same as for *discard* = no. But for the axis
-dimensinon, it will only have its chunk ID set to the first or last
-bin if bins extend to the simulation box boundary in the axis
-dimension. This is the case if the *bound* keyword settings are
-*lower* and *upper*\ , which is the default. If the *bound* keyword
-settings are numeric values, then the atom will have its chunk ID set
-to 0 if it is outside the bounds of any bin. Note that in this case,
-it is possible that the first or last bin extends beyond the numeric
-*bounds* settings, depending on the specified *origin*\ . If this is
-the case, the chunk ID of the atom is only set to 0 if it is outside
-the first or last bin, not if it is simply outside the numeric
-*bounds* setting.
-
-If *discard* is set to *no* or *mixed*\ , the atom will have its
-chunk ID set to the first or last bin, i.e. the innermost or outermost
-spherical shell. If the distance of the atom from the origin is less
-than *rmin*\ , it will be assigned to the first bin. If the distance of
-the atom from the origin is greater than *rmax*\ , it will be assigned
-to the last bin.
-
-
-----------
-
-
-The *bound* keyword only applies to the *bin/1d*\ , *bin/2d*\ , *bin/3d*
-styles and to the axis dimension of the *bin/cylinder* style;
-otherwise it is ignored. It can be used one or more times to limit
-the extent of bin coverage in a specified dimension, i.e. to only bin
-a portion of the box. If the *lo* setting is *lower* or the *hi*
-setting is *upper*\ , the bin extent in that direction extends to the
-box boundary. If a numeric value is used for *lo* and/or *hi*\ , then
-the bin extent in the *lo* or *hi* direction extends only to that
-value, which is assumed to be inside (or at least near) the simulation
-box boundaries, though LAMMPS does not check for this. Note that
-using the *bound* keyword typically reduces the total number of bins
-and thus the number of chunks *Nchunk*\ .
-
-The *pbc* keyword only applies to the *bin/sphere* and *bin/cylinder*
-styles. If set to *yes*\ , the distance an atom is from the sphere
-origin or cylinder axis is calculated in a minimum image sense with
-respect to periodic dimensions, when determining which bin the atom is
-in. I.e. if x is a periodic dimension and the distance between the
-atom and the sphere center in the x dimension is greater than 0.5 *
-simulation box length in x, then a box length is subtracted to give a
-distance < 0.5 * simulation box length. This allosws the sphere or
-cylinder center to be near a box edge, and atoms on the other side of
-the periodic box will still be close to the center point/axis. Note
-that with a setting of *yes*\ , the outer sphere or cylinder radius must
-also be <= 0.5 * simulation box length in any periodic dimension
-except for the cylinder axis dimension, or an error is generated.
-
-The *units* keyword only applies to the *binning* styles; otherwise it
-is ignored. For the *bin/1d*\ , *bin/2d*\ , *bin/3d* styles, it
-determines the meaning of the distance units used for the bin sizes
-*delta* and for *origin* and *bounds* values if they are coordinate
-values. For the *bin/sphere* style it determines the meaning of the
-distance units used for *xorig*\ ,\ *yorig*\ ,\ *zorig* and the radii *srmin*
-and *srmax*\ . For the *bin/cylinder* style it determines the meaning
-of the distance units used for *delta*\ ,\ *c1*\ ,\ *c2* and the radii *crmin*
-and *crmax*\ .
-
-For orthogonal simulation boxes, any of the 3 options may
-be used. For non-orthogonal (triclinic) simulation boxes, only the
-*reduced* option may be used.
-
-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. A *reduced* value means normalized
-unitless values between 0 and 1, which represent the lower and upper
-faces of the simulation box respectively. Thus an *origin* value of
-0.5 means the center of the box in any dimension. A *delta* value of
-0.1 means 10 bins span the box in that dimension.
-
-Note that for the *bin/sphere* style, the radii *srmin* and *srmax* are
-scaled by the lattice spacing or reduced value of the *x* dimension.
-
-Note that for the *bin/cylinder* style, the radii *crmin* and *crmax*
-are scaled by the lattice spacing or reduced value of the 1st
-dimension perpendicular to the cylinder axis. E.g. y for an x-axis
-cylinder, x for a y-axis cylinder, and x for a z-axis cylinder.
-
-
-----------
-
-
-**Output info:**
-
-This compute calculates a per-atom vector, which can be accessed by
-any command that uses per-atom values from a compute as input. See
-:ref:`Section_howto 15 <howto_15>` for an overview of
-LAMMPS output options.
-
-The per-atom vector values are unitless chunk IDs, ranging from 1 to
-*Nchunk* (inclusive) for atoms assigned to chunks, and 0 for atoms not
-belonging to a chunk.
-
-Restrictions
-""""""""""""
-
-
-Even if the *nchunk* keyword is set to *once*\ , the chunk IDs assigned
-to each atom are not stored in a restart files. This means you cannot
-expect those assignments to persist in a restarted simulation.
-Instead you must re-specify this command and assign atoms to chunks when
-the restarted simulation begins.
-
-Related commands
-""""""""""""""""
-
-:doc:`fix ave/chunk <fix_ave_chunk>`
-
-Default
-"""""""
-
-The option defaults are as follows:
-
-* region = none
-* nchunk = every, if compress is yes, overriding other defaults listed here
-* nchunk = once, for type style
-* nchunk = once, for mol style if region is none
-* nchunk = every, for mol style if region is set
-* nchunk = once, for binning style if the simulation box size is static or units = reduced
-* nchunk = every, for binning style if the simulation box size is dynamic and units is lattice or box
-* ID, group-ID are documented in :doc:`compute <compute>` command
-* com/chunk = style name of this compute command
-* chunkID = ID of :doc:`compute chunk/atom <compute_chunk_atom>` command
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- compute 1 fluid com/chunk molchunk
-
-Description
-"""""""""""
-
-Define a computation that calculates the center-of-mass for multiple
-chunks of atoms.
-
-In LAMMPS, chunks are collections of atoms defined by a :doc:`compute chunk/atom <compute_chunk_atom>` command, which assigns each atom
-to a single chunk (or no chunk). The ID for this command is specified
-as chunkID. For example, a single chunk could be the atoms in a
-molecule or atoms in a spatial bin. See the :doc:`compute chunk/atom <compute_chunk_atom>` doc page and ":ref:`Section_howto 23 <howto_23>` for details of how chunks can be
-defined and examples of how they can be used to measure properties of
-a system.
-
-This compute calculates the x,y,z coordinates of the center-of-mass
-for each chunk, which includes all effects due to atoms passing thru
-periodic boundaries.
-
-Note that only atoms in the specified group contribute to the
-calculation. The :doc:`compute chunk/atom <compute_chunk_atom>` command
-defines its own group; atoms will have a chunk ID = 0 if they are not
-in that group, signifying they are not assigned to a chunk, and will
-thus also not contribute to this calculation. You can specify the
-"all" group for this command if you simply want to include atoms with
-non-zero chunk IDs.
-
-.. note::
-
- The coordinates of an atom contribute to the chunk's
- center-of-mass in "unwrapped" form, by using the image flags
- associated with each atom. See the :doc:`dump custom <dump>` command
- for a discussion of "unwrapped" coordinates. See the Atoms section of
- the :doc:`read_data <read_data>` command for a discussion of image flags
- and how they are set for each atom. You can reset the image flags
- (e.g. to 0) before invoking this compute by using the :doc:`set image <set>` command.
-
-The simplest way to output the results of the compute com/chunk
-calculation to a file is to use the :doc:`fix ave/time <fix_ave_time>`
- compute ID group-ID dipole/chunk chunkID charge-correction
-
-* ID, group-ID are documented in :doc:`compute <compute>` command
-* dipole/chunk = style name of this compute command
-* chunkID = ID of :doc:`compute chunk/atom <compute_chunk_atom>` command
-* charge-correction = *mass* or *geometry*\ , use COM or geometric center for charged chunk correction (optional)
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- compute 1 fluid dipole/chunk molchunk
- compute dw water dipole/chunk 1 geometry
-
-Description
-"""""""""""
-
-Define a computation that calculates the dipole vector and total dipole
-for multiple chunks of atoms.
-
-In LAMMPS, chunks are collections of atoms defined by a :doc:`compute chunk/atom <compute_chunk_atom>` command, which assigns each atom
-to a single chunk (or no chunk). The ID for this command is specified
-as chunkID. For example, a single chunk could be the atoms in a
-molecule or atoms in a spatial bin. See the :doc:`compute chunk/atom <compute_chunk_atom>` doc page and ":ref:`Section_howto 23 <howto_23>` for details of how chunks can be
-defined and examples of how they can be used to measure properties of
-a system.
-
-This compute calculates the x,y,z coordinates of the dipole vector
-and the total dipole moment for each chunk, which includes all effects
-due to atoms passing thru periodic boundaries. For chunks with a net
-charge the resulting dipole is made position independent by subtracting
-the position vector of the center of mass or geometric center times the
-net charge from the computed dipole vector.
-
-Note that only atoms in the specified group contribute to the
-calculation. The :doc:`compute chunk/atom <compute_chunk_atom>` command
-defines its own group; atoms will have a chunk ID = 0 if they are not
-in that group, signifying they are not assigned to a chunk, and will
-thus also not contribute to this calculation. You can specify the
-"all" group for this command if you simply want to include atoms with
-non-zero chunk IDs.
-
-.. note::
-
- The coordinates of an atom contribute to the chunk's
- dipole in "unwrapped" form, by using the image flags
- associated with each atom. See the :doc:`dump custom <dump>` command
- for a discussion of "unwrapped" coordinates. See the Atoms section of
- the :doc:`read_data <read_data>` command for a discussion of image flags
- and how they are set for each atom. You can reset the image flags
- (e.g. to 0) before invoking this compute by using the :doc:`set image <set>` command.
-
-The simplest way to output the results of the compute com/chunk
-calculation to a file is to use the :doc:`fix ave/time <fix_ave_time>`
-Define a computation that calculates the radius of gyration Rg for
-multiple chunks of atoms.
-
-In LAMMPS, chunks are collections of atoms defined by a :doc:`compute chunk/atom <compute_chunk_atom>` command, which assigns each atom
-to a single chunk (or no chunk). The ID for this command is specified
-as chunkID. For example, a single chunk could be the atoms in a
-molecule or atoms in a spatial bin. See the :doc:`compute chunk/atom <compute_chunk_atom>` doc page and ":ref:`Section_howto 23 <howto_23>` for details of how chunks can be
-defined and examples of how they can be used to measure properties of
-a system.
-
-This compute calculates the radius of gyration Rg for each chunk,
-which includes all effects due to atoms passing thru periodic
-boundaries.
-
-Rg is a measure of the size of a chunk, and is computed by this
-formula
-
-.. image:: Eqs/compute_gyration.jpg
- :align: center
-
-where M is the total mass of the chunk, Rcm is the center-of-mass
-position of the chunk, and the sum is over all atoms in the
-chunk.
-
-Note that only atoms in the specified group contribute to the
-calculation. The :doc:`compute chunk/atom <compute_chunk_atom>` command
-defines its own group; atoms will have a chunk ID = 0 if they are not
-in that group, signifying they are not assigned to a chunk, and will
-thus also not contribute to this calculation. You can specify the
-"all" group for this command if you simply want to include atoms with
-non-zero chunk IDs.
-
-If the *tensor* keyword is specified, then the scalar Rg value is not
-calculated, but an Rg tensor is instead calculated for each chunk.
-The formula for the components of the tensor is the same as the above
-formula, except that (Ri - Rcm)^2 is replaced by (Rix - Rcmx) * (Riy -
-Rcmy) for the xy component, etc. The 6 components of the tensor are
-ordered xx, yy, zz, xy, xz, yz.
-
-.. note::
-
- The coordinates of an atom contribute to Rg in "unwrapped" form,
- by using the image flags associated with each atom. See the :doc:`dump custom <dump>` command for a discussion of "unwrapped" coordinates.
- See the Atoms section of the :doc:`read_data <read_data>` command for a
- discussion of image flags and how they are set for each atom. You can
- reset the image flags (e.g. to 0) before invoking this compute by
- using the :doc:`set image <set>` command.
-
-The simplest way to output the results of the compute gyration/chunk
-calculation to a file is to use the :doc:`fix ave/time <fix_ave_time>`
-* ID, group-ID are documented in :doc:`compute <compute>` command
-* inertia/chunk = style name of this compute command
-* chunkID = ID of :doc:`compute chunk/atom <compute_chunk_atom>` command
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- compute 1 fluid inertia/chunk molchunk
-
-Description
-"""""""""""
-
-Define a computation that calculates the inertia tensor for multiple
-chunks of atoms.
-
-In LAMMPS, chunks are collections of atoms defined by a :doc:`compute chunk/atom <compute_chunk_atom>` command, which assigns each atom
-to a single chunk (or no chunk). The ID for this command is specified
-as chunkID. For example, a single chunk could be the atoms in a
-molecule or atoms in a spatial bin. See the :doc:`compute chunk/atom <compute_chunk_atom>` doc page and ":ref:`Section_howto 23 <howto_23>` for details of how chunks can be
-defined and examples of how they can be used to measure properties of
-a system.
-
-This compute calculates the 6 components of the symmetric intertia
-tensor for each chunk, ordered Ixx,Iyy,Izz,Ixy,Iyz,Ixz. The
-calculation includes all effects due to atoms passing thru periodic
-boundaries.
-
-Note that only atoms in the specified group contribute to the
-calculation. The :doc:`compute chunk/atom <compute_chunk_atom>` command
-defines its own group; atoms will have a chunk ID = 0 if they are not
-in that group, signifying they are not assigned to a chunk, and will
-thus also not contribute to this calculation. You can specify the
-"all" group for this command if you simply want to include atoms with
-non-zero chunk IDs.
-
-.. note::
-
- The coordinates of an atom contribute to the chunk's inertia
- tensor in "unwrapped" form, by using the image flags associated with
- each atom. See the :doc:`dump custom <dump>` command for a discussion
- of "unwrapped" coordinates. See the Atoms section of the
- :doc:`read_data <read_data>` command for a discussion of image flags and
- how they are set for each atom. You can reset the image flags
- (e.g. to 0) before invoking this compute by using the :doc:`set image <set>` command.
-
-The simplest way to output the results of the compute inertia/chunk
-calculation to a file is to use the :doc:`fix ave/time <fix_ave_time>`
-* ID, group-ID are documented in :doc:`compute <compute>` command
-* msd/chunk = style name of this compute command
-* chunkID = ID of :doc:`compute chunk/atom <compute_chunk_atom>` command
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- compute 1 all msd/chunk molchunk
-
-Description
-"""""""""""
-
-Define a computation that calculates the mean-squared displacement
-(MSD) for multiple chunks of atoms.
-
-In LAMMPS, chunks are collections of atoms defined by a :doc:`compute chunk/atom <compute_chunk_atom>` command, which assigns each atom
-to a single chunk (or no chunk). The ID for this command is specified
-as chunkID. For example, a single chunk could be the atoms in a
-molecule or atoms in a spatial bin. See the :doc:`compute chunk/atom <compute_chunk_atom>` doc page and ":ref:`Section_howto 23 <howto_23>` for details of how chunks can be
-defined and examples of how they can be used to measure properties of
-a system.
-
-Four quantites are calculated by this compute for each chunk. The
-first 3 quantities are the squared dx,dy,dz displacements of the
-center-of-mass. The 4th component is the total squared displacement,
-i.e. (dx*dx + dy*dy + dz*dz) of the center-of-mass. These
-calculations include all effects due to atoms passing thru periodic
-boundaries.
-
-Note that only atoms in the specified group contribute to the
-calculation. The :doc:`compute chunk/atom <compute_chunk_atom>` command
-defines its own group; atoms will have a chunk ID = 0 if they are not
-in that group, signifying they are not assigned to a chunk, and will
-thus also not contribute to this calculation. You can specify the
-"all" group for this command if you simply want to include atoms with
-non-zero chunk IDs.
-
-The slope of the mean-squared displacement (MSD) versus time is
-proportional to the diffusion coefficient of the diffusing chunks.
-
-The displacement of the center-of-mass of the chunk is from its
-original center-of-mass position, calculated on the timestep this
-compute command was first invoked.
-
-.. note::
-
- The number of chunks *Nchunk* calculated by the :doc:`compute chunk/atom <compute_chunk_atom>` command must remain constant each
- time this compute is invoked, so that the displacement for each chunk
- from its original position can be computed consistently. If *Nchunk*
- does not remain constant, an error will be generated. If needed, you
- can enforce a constant *Nchunk* by using the *nchunk once* or *ids
- once* options when specifying the :doc:`compute chunk/atom <compute_chunk_atom>` command.
-
-.. note::
-
- This compute stores the original position (of the
- center-of-mass) of each chunk. When a displacement is calculated on a
- later timestep, it is assumed that the same atoms are assigned to the
- same chunk ID. However LAMMPS has no simple way to insure this is the
- case, though you can use the *ids once* option when specifying the
- :doc:`compute chunk/atom <compute_chunk_atom>` command. Note that if
- this is not the case, the MSD calculation does not have a sensible
- meaning.
-
-.. note::
-
- The initial coordinates of the atoms in each chunk are stored in
- "unwrapped" form, by using the image flags associated with each atom.
- See the :doc:`dump custom <dump>` command for a discussion of
- "unwrapped" coordinates. See the Atoms section of the
- :doc:`read_data <read_data>` command for a discussion of image flags and
- how they are set for each atom. You can reset the image flags
- (e.g. to 0) before invoking this compute by using the :doc:`set image <set>` command.
-
-.. note::
-
- If you want the quantities calculated by this compute to be
- continuous when running from a :doc:`restart file <read_restart>`, then
- you should use the same ID for this compute, as in the original run.
- This is so that the fix this compute creates to store per-chunk
- quantities will also have the same ID, and thus be initialized
- correctly with chunk reference positions from the restart file.
-
-The simplest way to output the results of the compute com/msd
-calculation to a file is to use the :doc:`fix ave/time <fix_ave_time>`
-* ID, group-ID are documented in :doc:`compute <compute>` command
-* omega/chunk = style name of this compute command
-* chunkID = ID of :doc:`compute chunk/atom <compute_chunk_atom>` command
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- compute 1 fluid omega/chunk molchunk
-
-Description
-"""""""""""
-
-Define a computation that calculates the angular velocity (omega) of
-multiple chunks of atoms.
-
-In LAMMPS, chunks are collections of atoms defined by a :doc:`compute chunk/atom <compute_chunk_atom>` command, which assigns each atom
-to a single chunk (or no chunk). The ID for this command is specified
-as chunkID. For example, a single chunk could be the atoms in a
-molecule or atoms in a spatial bin. See the :doc:`compute chunk/atom <compute_chunk_atom>` doc page and ":ref:`Section_howto 23 <howto_23>` for details of how chunks can be
-defined and examples of how they can be used to measure properties of
-a system.
-
-This compute calculates the 3 components of the angular velocity
-vector for each chunk, via the formula L = Iw where L is the angular
-momentum vector of the chunk, I is its moment of inertia tensor, and w
-is omega = angular velocity of the chunk. The calculation includes
-all effects due to atoms passing thru periodic boundaries.
-
-Note that only atoms in the specified group contribute to the
-calculation. The :doc:`compute chunk/atom <compute_chunk_atom>` command
-defines its own group; atoms will have a chunk ID = 0 if they are not
-in that group, signifying they are not assigned to a chunk, and will
-thus also not contribute to this calculation. You can specify the
-"all" group for this command if you simply want to include atoms with
-non-zero chunk IDs.
-
-.. note::
-
- The coordinates of an atom contribute to the chunk's angular
- velocity in "unwrapped" form, by using the image flags associated with
- each atom. See the :doc:`dump custom <dump>` command for a discussion
- of "unwrapped" coordinates. See the Atoms section of the
- :doc:`read_data <read_data>` command for a discussion of image flags and
- how they are set for each atom. You can reset the image flags
- (e.g. to 0) before invoking this compute by using the :doc:`set image <set>` command.
-
-The simplest way to output the results of the compute omega/chunk
-calculation to a file is to use the :doc:`fix ave/time <fix_ave_time>`
- compute ID group-ID property/chunk chunkID input1 input2 ...
-
-* ID, group-ID are documented in :doc:`compute <compute>` command
-* property/chunk = style name of this compute command
-* input = one or more attributes
-.. parsed-literal::
-
- attributes = count, id, coord1, coord2, coord3
- count = # of atoms in chunk
- id = original chunk IDs before compression by :doc:`compute chunk/atom <compute_chunk_atom>`
- coord123 = coordinates for spatial bins calculated by :doc:`compute chunk/atom <compute_chunk_atom>`
-
-
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- compute 1 all property/chunk count
- compute 1 all property/chunk ID coord1
-
-Description
-"""""""""""
-
-Define a computation that stores the specified attributes of chunks of
-atoms.
-
-In LAMMPS, chunks are collections of atoms defined by a :doc:`compute chunk/atom <compute_chunk_atom>` command, which assigns each atom
-to a single chunk (or no chunk). The ID for this command is specified
-as chunkID. For example, a single chunk could be the atoms in a
-molecule or atoms in a spatial bin. See the :doc:`compute chunk/atom <compute_chunk_atom>` doc page and ":ref:`Section_howto 23 <howto_23>` for details of how chunks can be
-defined and examples of how they can be used to measure properties of
-a system.
-
-This compute calculates and stores the specified attributes of chunks
-as global data so they can be accessed by other :ref:`output commands <howto_15>` and used in conjunction with
-other commands that generate per-chunk data, such as :doc:`compute com/chunk <compute_com_chunk>` or :doc:`compute msd/chunk <compute_msd_chunk>`.
-
-Note that only atoms in the specified group contribute to the
-calculation of the *count* attribute. The :doc:`compute chunk/atom <compute_chunk_atom>` command defines its own group;
-atoms will have a chunk ID = 0 if they are not in that group,
-signifying they are not assigned to a chunk, and will thus also not
-contribute to this calculation. You can specify the "all" group for
-this command if you simply want to include atoms with non-zero chunk
-IDs.
-
-The *count* attribute is the number of atoms in the chunk.
-
-The *id* attribute stores the original chunk ID for each chunk. It
-can only be used if the *compress* keyword was set to *yes* for the
-:doc:`compute chunk/atom <compute_chunk_atom>` command referenced by
-chunkID. This means that the original chunk IDs (e.g. molecule IDs)
-will have been compressed to remove chunk IDs with no atoms assigned
-to them. Thus a compresed chunk ID of 3 may correspond to an original
-chunk ID (molecule ID in this case) of 415. The *id* attribute will
-then be 415 for the 3rd chunk.
-
-The *coordN* attributes can only be used if a *binning* style was used
-in the :doc:`compute chunk/atom <compute_chunk_atom>` command referenced
-by chunkID. For *bin/1d*\ , *bin/2d*\ , and *bin/3d* styles the attribute
-is the center point of the bin in the corresponding dimension. Style
-*bin/1d* only defines a *coord1* attribute. Style *bin/2d* adds a
-*coord2* attribute. Style *bin/3d* adds a *coord3* attribute.
-
-Note that if the value of the *units* keyword used in the :doc:`compute chunk/atom command <compute_chunk_atom>` is *box* or *lattice*\ , the
-*coordN* attributes will be in distance :doc:`units <units>`. If the
-value of the *units* keyword is *reduced*\ , the *coordN* attributes
-will be in unitless reduced units (0-1).
-
-The simplest way to output the results of the compute property/chunk
-calculation to a file is to use the :doc:`fix ave/time <fix_ave_time>`
-The first two input values in the compute reduce command are vectors
-with the IDs of the 2 atoms in each bond, using the :doc:`compute property/local <compute_property_local>` command. The last input
-value is bond distance, using the :doc:`compute bond/local <compute_bond_local>` command. Instead of taking the
-max of the two atom ID vectors, which does not yield useful
-information in this context, the *replace* keywords will extract the
-atom IDs for the two atoms in the bond of maximum stretch. These atom
-IDs and the bond stretch will be printed with thermodynamic output.
-
-
-----------
-
-
-If a single input is specified this compute produces a global scalar
-value. If multiple inputs are specified, this compute produces a
-global vector of values, the length of which is equal to the number of
-inputs specified.
-
-As discussed below, for the *sum* and *sumsq* modes, the value(s)
-produced by this compute are all "extensive", meaning their value
-scales linearly with the number of atoms involved. If normalized
-values are desired, this compute can be accessed by the :doc:`thermo_style custom <thermo_style>` command with :doc:`thermo_modify norm yes <thermo_modify>` set as an option. Or it can be accessed by a
-:doc:`variable <variable>` that divides by the appropriate atom count.
-
-
-----------
-
-
-**Output info:**
-
-This compute calculates a global scalar if a single input value is
-specified or a global vector of length N where N is the number of
-inputs, and which can be accessed by indices 1 to N. These values can
-be used by any command that uses global scalar or vector values from a
-compute as input. See :ref:`Section_howto 15 <howto_15>`
-for an overview of LAMMPS output options.
-
-All the scalar or vector values calculated by this compute are
-"intensive", except when the *sum* or *sumsq* modes are used on
-per-atom or local vectors, in which case the calculated values are
-"extensive".
-
-The scalar or vector values will be in whatever :doc:`units <units>` the
-Define a computation that calculates the temperature of a group of
-atoms that are also in chunks, after optionally subtracting out the
-center-of-mass velocity of each chunk. By specifying optional values,
-it can also calulate the per-chunk temperature or energies of the
-multiple chunks of atoms.
-
-In LAMMPS, chunks are collections of atoms defined by a :doc:`compute chunk/atom <compute_chunk_atom>` command, which assigns each atom
-to a single chunk (or no chunk). The ID for this command is specified
-as chunkID. For example, a single chunk could be the atoms in a
-molecule or atoms in a spatial bin. See the :doc:`compute chunk/atom <compute_chunk_atom>` doc page and ":ref:`Section_howto 23 <howto_23>` for details of how chunks can be
-defined and examples of how they can be used to measure properties of
-a system.
-
-The temperature is calculated by the formula KE = DOF/2 k T, where KE =
-total kinetic energy of all atoms assigned to chunks (sum of 1/2 m
-v^2), DOF = the total number of degrees of freedom for those atoms, k
-= Boltzmann constant, and T = temperature.
-
-The DOF is calculated as N*adof + Nchunk*cdof, where N = number of
-atoms contributing to the KE, adof = degrees of freedom per atom, and
-cdof = degrees of freedom per chunk. By default adof = 2 or 3 =
-dimensionality of system, as set via the :doc:`dimension <dimension>`
-command, and cdof = 0.0. This gives the usual formula for
-temperature.
-
-A kinetic energy tensor, stored as a 6-element vector, is also
-calculated by this compute for use in the computation of a pressure
-tensor. The formula for the components of the tensor is the same as
-the above formula, except that v^2 is replaced by vx*vy for the xy
-component, etc. The 6 components of the vector are ordered xx, yy,
-zz, xy, xz, yz.
-
-Note that the number of atoms contributing to the temperature is
-calculated each time the temperature is evaluated since it is assumed
-the atoms may be dynamically assigned to chunks. Thus there is no
-need to use the *dynamic* option of the
-:doc:`compute_modify <compute_modify>` command for this compute style.
-
-If any optional values are specified, then per-chunk quantities are
-also calculated and stored in a global array, as described below.
-
-The *temp* value calculates the temperature for each chunk by the
-formula KE = DOF/2 k T, where KE = total kinetic energy of the chunk
-of atoms (sum of 1/2 m v^2), DOF = the total number of degrees of
-freedom for all atoms in the chunk, k = Boltzmann constant, and T =
-temperature.
-
-The DOF in this case is calculated as N*adof + cdof, where N = number
-of atoms in the chunk, adof = degrees of freedom per atom, and cdof =
-degrees of freedom per chunk. By default adof = 2 or 3 =
-dimensionality of system, as set via the :doc:`dimension <dimension>`
-command, and cdof = 0.0. This gives the usual formula for
-temperature.
-
-The *kecom* value calculates the kinetic energy of each chunk as if
-all its atoms were moving with the velocity of the center-of-mass of
-the chunk.
-
-The *internal* value calculates the internal kinetic energy of each
-chunk. The interal KE is summed over the atoms in the chunk using an
-internal "thermal" velocity for each atom, which is its velocity minus
-the center-of-mass velocity of the chunk.
-
-
-----------
-
-
-Note that currently the global and per-chunk temperatures calculated
-by this compute only include translational degrees of freedom for each
-atom. No rotational degrees of freedom are included for finite-size
-particles. Also no degrees of freedom are subtracted for any velocity
-bias or constraints that are applied, such as :doc:`compute temp/partial <compute_temp_partial>`, or :doc:`fix shake <fix_shake>`
-or :doc:`fix rigid <fix_rigid>`. This is because those degrees of
-freedom (e.g. a constrained bond) could apply to sets of atoms that
-are both included and excluded from a specific chunk, and hence the
-concept is somewhat ill-defined. In some cases, you can use the
-*adof* and *cdof* keywords to adjust the calculated degress of freedom
-appropriately, as explained below.
-
-Note that the per-chunk temperature calulated by this compute and the
-:doc:`fix ave/chunk temp <fix_ave_chunk>` command can be different.
-This compute calculates the temperature for each chunk for a single
-snapshot. Fix ave/chunk can do that but can also time average those
-values over many snapshots, or it can compute a temperature as if the
-atoms in the chunk on different timesteps were collected together as
-one set of atoms to calculate their temperature. This compute allows
-the center-of-mass velocity of each chunk to be subtracted before
-calculating the temperature; fix ave/chunk does not.
-
-.. note::
-
- Only atoms in the specified group contribute to the calculations
- performed by this compute. The :doc:`compute chunk/atom <compute_chunk_atom>` command defines its own group;
- atoms will have a chunk ID = 0 if they are not in that group,
- signifying they are not assigned to a chunk, and will thus also not
- contribute to this calculation. You can specify the "all" group for
- this command if you simply want to include atoms with non-zero chunk
- IDs.
-
-The simplest way to output the per-chunk results of the compute
-temp/chunk calculation to a file is to use the :doc:`fix ave/time <fix_ave_time>` command, for example:
-* ID, group-ID are documented in :doc:`compute <compute>` command
-* temp/com = style name of this compute command
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- compute 1 all temp/com
- compute myTemp mobile temp/com
-
-Description
-"""""""""""
-
-Define a computation that calculates the temperature of a group of
-atoms, after subtracting out the center-of-mass velocity of the group.
-This is useful if the group is expected to have a non-zero net
-velocity for some reason. 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.
-
-After the center-of-mass velocity has been subtracted from each atom,
-the temperature is calculated by the formula KE = dim/2 N k T, where
-KE = total kinetic energy of the group of atoms (sum of 1/2 m v^2),
-dim = 2 or 3 = dimensionality of the simulation, N = number of atoms
-in the group, k = Boltzmann constant, and T = temperature.
-
-A kinetic energy tensor, stored as a 6-element vector, is also
-calculated by this compute for use in the computation of a pressure
-tensor. The formula for the components of the tensor is the same as
-the above formula, except that v^2 is replaced by vx*vy for the xy
-component, etc. The 6 components of the vector are ordered xx, yy,
-zz, xy, xz, yz.
-
-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 the center-of-mass velocity 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.
-
-**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>`.
-* ID, group-ID are documented in :doc:`compute <compute>` command
-* temp/cs = style name of this compute command
-* group1 = group-ID of either cores or shells
-* group2 = group-ID of either shells or cores
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- compute oxygen_c-s all temp/cs O_core O_shell
- compute core_shells all temp/cs cores shells
-
-Description
-"""""""""""
-
-Define a computation that calculates the temperature of a system based
-on the center-of-mass velocity of atom pairs that are bonded to each
-other. This compute is designed to be used with the adiabatic
-core/shell model of :ref:`(Mitchell and Finchham) <MitchellFinchham>`. See
-:ref:`Section_howto 25 <howto_25>` of the manual for an
-overview of the model as implemented in LAMMPS. Specifically, this
-compute enables correct temperature calculation and thermostatting of
-core/shell pairs where it is desirable for the internal degrees of
-freedom of the core/shell pairs to not be influenced by a thermostat.
-A compute of this style can be used by any command that computes a
-temperature via :doc:`fix_modify <fix_modify>` e.g. :doc:`fix temp/rescale <fix_temp_rescale>`, :doc:`fix npt <fix_nh>`, etc.
-
-Note that this compute does not require all ions to be polarized,
-hence defined as core/shell pairs. One can mix core/shell pairs and
-ions without a satellite particle if desired. The compute will
-consider the non-polarized ions according to the physical system.
-
-For this compute, core and shell particles are specified by two
-respective group IDs, which can be defined using the
-:doc:`group <group>` command. The number of atoms in the two groups
-must be the same and there should be one bond defined between a pair
-of atoms in the two groups. Non-polarized ions which might also be
-included in the treated system should not be included into either of
-these groups, they are taken into account by the *group-ID* (2nd
-argument) of the compute.
-
-The temperature is calculated by the formula KE = dim/2 N k T, where
-KE = total kinetic energy of the group of atoms (sum of 1/2 m v^2),
-dim = 2 or 3 = dimensionality of the simulation, N = number of atoms
-in the group, k = Boltzmann constant, and T = temperature. Note that
-the velocity of each core or shell atom used in the KE calculation is
-the velocity of the center-of-mass (COM) of the core/shell pair the
-atom is part of.
-
-A kinetic energy tensor, stored as a 6-element vector, is also
-calculated by this compute for use in the computation of a pressure
-tensor. The formula for the components of the tensor is the same as
-the above formula, except that v^2 is replaced by vx*vy for the xy
-component, etc. The 6 components of the vector are ordered xx, yy,
-zz, xy, xz, yz. In contrast to the temperature, the velocity of
-each core or shell atom is taken individually.
-
-The change this fix makes to core/shell atom velocities is essentially
-computing the temperature after a "bias" has been removed from the
-velocity of the atoms. This "bias" is the velocity of the atom
-relative to the COM velocity of the core/shell pair. If this compute
-is used with a fix command that performs thermostatting then this bias
-will be subtracted from each atom, thermostatting of the remaining COM
-velocity will be performed, and the bias will be added back in. This
-means the thermostating will effectively be performed on the
-core/shell pairs, instead of on the individual core and shell atoms.
-Thermostatting fixes that work in this way include :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>`.
-
-The internal energy of core/shell pairs can be calculated by the
-:doc:`compute temp/chunk <compute_temp_chunk>` command, if chunks are
-defined as core/shell pairs. See :ref:`Section_howto 25 <howto_25>` for more discussion on how to do this.
-
-**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.
-
-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>`.
-
-Restrictions
-""""""""""""
-
-
-The number of core/shell pairs contributing to the temperature is
-assumed to be constant for the duration of the run. No fixes should
-be used which generate new molecules or atoms during a simulation.
-* ID, group-ID are documented in :doc:`compute <compute>` command
-* temp/deform = style name of this compute command
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- compute myTemp all temp/deform
-
-Description
-"""""""""""
-
-Define a computation that calculates the temperature of a group of
-atoms, after subtracting out a streaming velocity induced by the
-simulation box changing size and/or shape, for example in a
-non-equilibrium MD (NEMD) simulation. The size/shape change is
-induced by use of the :doc:`fix deform <fix_deform>` command. A compute
-of this style is created by the :doc:`fix nvt/sllod <fix_nvt_sllod>`
-command to compute the thermal temperature of atoms for thermostatting
-purposes. A compute of this style can also 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 deformation fix changes the box size and/or shape over time, so
-each atom in the simulation box can be thought of as having a
-"streaming" velocity. For example, if the box is being sheared in x,
-relative to y, then atoms at the bottom of the box (low y) have a
-small x velocity, while atoms at the top of the box (hi y) have a
-large x velocity. This position-dependent streaming velocity is
-subtracted from each atom's actual velocity to yield a thermal
-velocity which is used to compute the temperature.
-
-.. note::
-
- :doc:`Fix deform <fix_deform>` has an option for remapping either
- atom coordinates or velocities to the changing simulation box. When
- using this compute in conjunction with a deforming box, fix deform
- should NOT remap atom positions, but rather should let atoms respond
- to the changing box by adjusting their own velocities (or let :doc:`fix deform <fix_deform>` remap the atom velocities, see it's remap
- option). If fix deform does remap atom positions, then they appear to
- move with the box but their velocity is not changed, and thus they do
- NOT have the streaming velocity assumed by this compute. LAMMPS will
- warn you if fix deform is defined and its remap setting is not
- consistent with this compute.
-
-After the streaming velocity has been subtracted from each atom, the
-temperature is calculated by the formula KE = dim/2 N k T, where KE =
-total kinetic energy of the group of atoms (sum of 1/2 m v^2), dim = 2
-or 3 = dimensionality of the simulation, N = number of atoms in the
-group, k = Boltzmann constant, and T = temperature. Note that v in
-the kinetic energy formula is the atom's thermal velocity.
-
-A kinetic energy tensor, stored as a 6-element vector, is also
-calculated by this compute for use in the computation of a pressure
-tensor. The formula for the components of the tensor is the same as
-the above formula, except that v^2 is replaced by vx*vy for the xy
-component, etc. The 6 components of the vector are ordered xx, yy,
-zz, xy, xz, yz.
-
-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 the box deformation velocity component 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>`.
-
-.. note::
-
- The temperature calculated by this compute is only accurate if
- the atoms are indeed moving with a stream velocity profile that
- matches the box deformation. If not, then the compute will subtract
- off an incorrect stream velocity, yielding a bogus thermal
- temperature. You should NOT assume that your atoms are streaming at
- the same rate the box is deforming. Rather, you should monitor their
- velocity profile, e.g. via the :doc:`fix ave/chunk <fix_ave_chunk>`
- command. And you can compare the results of this compute to :doc:`compute temp/profile <compute_temp_profile>`, which actually calculates the
- stream profile before subtracting it. If the two computes do not give
- roughly the same temperature, then your atoms are not streaming
- consistent with the box deformation. See the :doc:`fix deform <fix_deform>` command for more details on ways to get atoms
- to stream consistently with the box deformation.
-
-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.
-
-**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>`.
- 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 *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 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>`.
-Define a computation that calculates the temperature of a group of
-atoms, after subtracting out a spatially-averaged center-of-mass
-velocity field, before computing the kinetic energy. This can be
-useful for thermostatting a collection of atoms undergoing a complex
-flow, e.g. via a profile-unbiased thermostat (PUT) as described in
-:ref:`(Evans) <Evans>`. 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 *xflag*\ , *yflag*\ , *zflag* settings determine which components of
-average velocity are subtracted out.
-
-The *binstyle* setting and its *Nx*\ , *Ny*\ , *Nz* arguments determine
-how bins are setup to perform spatial averaging. "Bins" can be 1d
-slabs, 2d pencils, or 3d bricks depending on which *binstyle* is used.
-The simulation box is partitioned conceptually into *Nx* by *Ny* by
-*Nz* bins. Depending on the *binstyle*\ , you may only specify one or
-two of these values; the others are effectively set to 1 (no binning
-in that dimension). For non-orthogonal (triclinic) simulation boxes,
-the bins are "tilted" slabs or pencils or bricks that are parallel to
-the tilted faces of the box. See the :doc:`region prism <region>`
-command for a discussion of the geometry of tilted boxes in LAMMPS.
-
-When a temperature is computed, the center-of-mass velocity for the
-set of atoms that are both in the compute group and in the same
-spatial bin is calculated. This bias velocity is then subtracted from
-the velocities of individual atoms in the bin to yield a thermal
-velocity for each atom. Note that if there is only one atom in the
-bin, its thermal velocity will thus be 0.0.
-
-After the spatially-averaged velocity field has been subtracted from
-each atom, the temperature is calculated by the formula KE = (dim/2 N
-- dim*Nx*Ny*Nz) k T, where KE = total kinetic energy of the group of
-atoms (sum of 1/2 m v^2), dim = 2 or 3 = dimensionality of the
-simulation, N = number of atoms in the group, k = Boltzmann constant,
-and T = temperature. The dim*Nx*Ny*Nz term are degrees of freedom
-subtracted to adjust for the removal of the center-of-mass velocity in
-each of Nx*Ny*Nz bins, as discussed in the :ref:`(Evans) <Evans>` paper.
-
-If the *out* keyword is used with a *tensor* value, which is the
-default, a kinetic energy tensor, stored as a 6-element vector, is
-also calculated by this compute for use in the computation of a
-pressure tensor. The formula for the components of the tensor is the
-same as the above formula, except that v^2 is replaced by vx*vy for
-the xy component, etc. The 6 components of the vector are ordered xx,
-yy, zz, xy, xz, yz.
-
-If the *out* keyword is used with a *bin* value, the count of atoms
-and computed temperature for each bin are stored for output, as an
-array of values, as described below. The temperature of each bin is
-calculated as described above, where the bias velocity is subtracted
-and only the remaining thermal velocity of atoms in the bin
-contributes to the temperature. See the note below for how the
-temperature is normalized by the degrees-of-freedom of atoms in the
-bin.
-
-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 the spatially-averaged velocity field 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.
-
-.. note::
-
- When using the *out* keyword with a value of *bin*\ , the
- calculated temperature for each bin does not include the
- degrees-of-freedom adjustment described in the preceeding paragraph,
- for fixes that constrain molecular motion. It does include the
- adjustment due to the *extra* option, which is applied to each bin.
-
-See :ref:`this howto section <howto_16>` of the manual for
-a discussion of different ways to compute temperature and perform
-thermostatting. Using this compute in conjunction with a
-thermostatting fix, as explained there, will effectively implement a
-profile-unbiased thermostat (PUT), as described in :ref:`(Evans) <Evans>`.
-
-**Output info:**
-
-This compute calculates a global scalar (the temperature). Depending
-on the setting of the *out* keyword, it also calculates a global
-vector or array. For *out* = *tensor*\ , it calculates a vector of
-length 6 (KE tensor), which can be accessed by indices 1-6. For *out*
-= *bin* it calculates a global array which has 2 columns and N rows,
-where N is the number of bins. The first column contains the number
-of atoms in that bin. The second contains the temperature of that
-bin, calculated as described above. The ordering of rows in the array
-is as follows. Bins in x vary fastest, then y, then z. Thus for a
-10x10x10 3d array of bins, there will be 1000 rows. The bin with
-indices ix,iy,iz = 2,3,4 would map to row M = (iz-1)*10*10 + (iy-1)*10
-+ ix = 322, where the rows are numbered from 1 to 1000 and the bin
-indices are numbered from 1 to 10 in each dimension.
-
-These values can be used by any command that uses global scalar or
-vector or array 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 array values are "intensive".
-
-The scalar value will be in temperature :doc:`units <units>`. The
-vector values will be in energy :doc:`units <units>`. The first column
-of array values are counts; the values in the second column will be in
-temperature :doc:`units <units>`.
-
-Restrictions
-""""""""""""
-
-
-You should not use too large a velocity-binning grid, especially in
-3d. In the current implementation, the binned velocity averages are
-summed across all processors, so this will be inefficient if the grid
-is too large, and the operation is performed every timestep, as it
- compute ID group-ID temp/ramp vdim vlo vhi dim clo chi keyword value ...
-
-* ID, group-ID are documented in :doc:`compute <compute>` command
-* temp/ramp = style name of this compute command
-* vdim = *vx* or *vy* or *vz*
-* vlo,vhi = subtract velocities between vlo and vhi (velocity units)
-* dim = *x* or *y* or *z*
-* clo,chi = lower and upper bound of domain to subtract from (distance units)
-* zero or more keyword/value pairs may be appended
-* keyword = *units*
-
-.. parsed-literal::
-
- *units* value = *lattice* or *box*
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- compute 2nd middle temp/ramp vx 0 8 y 2 12 units lattice
-
-Description
-"""""""""""
-
-Define a computation that calculates the temperature of a group of
-atoms, after subtracting out an ramped velocity profile before
-computing the kinetic energy. 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 meaning of the arguments for this command which define the
-velocity ramp are the same as for the :doc:`velocity ramp <velocity>`
-command which was presumably used to impose the velocity.
-
-After the ramp velocity has been subtracted from the specified
-dimension for each atom, the temperature is calculated by the formula
-KE = dim/2 N k T, where KE = total kinetic energy of the group of
-atoms (sum of 1/2 m v^2), dim = 2 or 3 = dimensionality of the
-simulation, N = number of atoms in the group, k = Boltzmann constant,
-and T = temperature.
-
-The *units* keyword determines the meaning of the distance units used
-for coordinates (c1,c2) and velocities (vlo,vhi). 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; e.g. velocity =
-lattice spacings / tau. The :doc:`lattice <lattice>` command must have
-been previously used to define the lattice spacing.
-
-A kinetic energy tensor, stored as a 6-element vector, is also
-calculated by this compute for use in the computation of a pressure
-tensor. The formula for the components of the tensor is the same as
-the above formula, except that v^2 is replaced by vx*vy for the xy
-component, etc. The 6 components of the vector are ordered xx, yy,
-zz, xy, xz, yz.
-
-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 the ramped velocity component 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.
-
-**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>`.
-* ID, group-ID are documented in :doc:`compute <compute>` command
-* temp/region = style name of this compute command
-* region-ID = ID of region to use for choosing atoms
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- compute mine flow temp/region boundary
-
-Description
-"""""""""""
-
-Define a computation that calculates the temperature of a group of
-atoms in a geometric region. This can be useful for thermostatting
-one portion of the simulation box. E.g. a McDLT simulation where one
-side is cooled, and the other side is heated. 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>`, etc.
-
-Note that a *region*\ -style temperature can be used to thermostat with
-:doc:`fix temp/rescale <fix_temp_rescale>` or :doc:`fix langevin <fix_langevin>`, but should probably not be used with
-Nose/Hoover style fixes (:doc:`fix nvt <fix_nh>`, :doc:`fix npt <fix_nh>`, or :doc:`fix nph <fix_nh>`), if the
-degrees-of-freedom included in the computed T varies with time.
-
-The temperature is calculated by the formula KE = dim/2 N k T, where
-KE = total kinetic energy of the group of atoms (sum of 1/2 m v^2),
-dim = 2 or 3 = dimensionality of the simulation, N = number of atoms
-in both the group and region, k = Boltzmann constant, and T =
-temperature.
-
-A kinetic energy tensor, stored as a 6-element vector, is also
-calculated by this compute for use in the computation of a pressure
-tensor. The formula for the components of the tensor is the same as
-the above formula, except that v^2 is replaced by vx*vy for the xy
-component, etc. The 6 components of the vector are ordered xx, yy,
-zz, xy, xz, yz.
-
-The number of atoms contributing to the temperature is calculated each
-time the temperature is evaluated since it is assumed atoms can
-enter/leave the region. Thus there is no need to use the *dynamic*
-option of the :doc:`compute_modify <compute_modify>` command for this
-compute style.
-
-The removal of atoms outside the region by this fix is essentially
-computing the temperature after a "bias" has been removed, which in
-this case is the velocity of any atoms outside the region. 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 means that when this compute
-is used to calculate the temperature for any of the thermostatting
-fixes via the :doc:`fix modify temp <fix_modify>` command, the thermostat
-will operate only on atoms that are currently in the geometric
-region.
-
-Unlike other compute styles that calculate temperature, this compute
-does not subtract out degrees-of-freedom due to fixes that constrain
-motion, such as :doc:`fix shake <fix_shake>` and :doc:`fix rigid <fix_rigid>`. This is because those degrees of freedom
-(e.g. a constrained bond) could apply to sets of atoms that straddle
-the region boundary, and hence the concept is somewhat ill-defined.
-If needed the number of subtracted degrees-of-freedom can be set
-explicitly 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.
-
-**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>`.
-* ID, group-ID are documented in :doc:`compute <compute>` command
-* temp/rotate = style name of this compute command
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- compute Tbead bead temp/rotate
-
-Description
-"""""""""""
-
-Define a computation that calculates the temperature of a group of
-atoms, after subtracting out the center-of-mass velocity and angular velocity of the group.
-This is useful if the group is expected to have a non-zero net
-velocity and/or global rotation motion for some reason. 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.
-
-After the center-of-mass velocity and angular velocity has been subtracted from each atom,
-the temperature is calculated by the formula KE = dim/2 N k T, where
-KE = total kinetic energy of the group of atoms (sum of 1/2 m v^2),
-dim = 2 or 3 = dimensionality of the simulation, N = number of atoms
-in the group, k = Boltzmann constant, and T = temperature.
-
-A kinetic energy tensor, stored as a 6-element vector, is also
-calculated by this compute for use in the computation of a pressure
-tensor. The formula for the components of the tensor is the same as
-the above formula, except that v^2 is replaced by vx*vy for the xy
-component, etc. The 6 components of the vector are ordered xx, yy,
-zz, xy, xz, yz.
-
-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 the center-of-mass velocity and angular velocity 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.
-
-**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>`.
-
-Restrictions
-""""""""""""
-
-
-This compute is part of the USER-MISC package. It is only enabled if
-LAMMPS was built with that package. See the :ref:`Making LAMMPS <start_3>` section for more info.
-* ID, group-ID are documented in :doc:`compute <compute>` command
-* torque/chunk = style name of this compute command
-* chunkID = ID of :doc:`compute chunk/atom <compute_chunk_atom>` command
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- compute 1 fluid torque/chunk molchunk
-
-Description
-"""""""""""
-
-Define a computation that calculates the torque on multiple chunks of
-atoms.
-
-In LAMMPS, chunks are collections of atoms defined by a :doc:`compute chunk/atom <compute_chunk_atom>` command, which assigns each atom
-to a single chunk (or no chunk). The ID for this command is specified
-as chunkID. For example, a single chunk could be the atoms in a
-molecule or atoms in a spatial bin. See the :doc:`compute chunk/atom <compute_chunk_atom>` doc page and ":ref:`Section_howto 23 <howto_23>` for details of how chunks can be
-defined and examples of how they can be used to measure properties of
-a system.
-
-This compute calculates the 3 components of the torque vector for eqch
-chunk, due to the forces on the individual atoms in the chunk around
-the center-of-mass of the chunk. The calculation includes all effects
-due to atoms passing thru periodic boundaries.
-
-Note that only atoms in the specified group contribute to the
-calculation. The :doc:`compute chunk/atom <compute_chunk_atom>` command
-defines its own group; atoms will have a chunk ID = 0 if they are not
-in that group, signifying they are not assigned to a chunk, and will
-thus also not contribute to this calculation. You can specify the
-"all" group for this command if you simply want to include atoms with
-non-zero chunk IDs.
-
-.. note::
-
- The coordinates of an atom contribute to the chunk's torque in
- "unwrapped" form, by using the image flags associated with each atom.
- See the :doc:`dump custom <dump>` command for a discussion of
- "unwrapped" coordinates. See the Atoms section of the
- :doc:`read_data <read_data>` command for a discussion of image flags and
- how they are set for each atom. You can reset the image flags
- (e.g. to 0) before invoking this compute by using the :doc:`set image <set>` command.
-
-The simplest way to output the results of the compute torque/chunk
-calculation to a file is to use the :doc:`fix ave/time <fix_ave_time>`
-* ID, group-ID are documented in :doc:`compute <compute>` command
-* vcm/chunk = style name of this compute command
-* chunkID = ID of :doc:`compute chunk/atom <compute_chunk_atom>` command
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- compute 1 fluid vcm/chunk molchunk
-
-Description
-"""""""""""
-
-Define a computation that calculates the center-of-mass velocity for
-multiple chunks of atoms.
-
-In LAMMPS, chunks are collections of atoms defined by a :doc:`compute chunk/atom <compute_chunk_atom>` command, which assigns each atom
-to a single chunk (or no chunk). The ID for this command is specified
-as chunkID. For example, a single chunk could be the atoms in a
-molecule or atoms in a spatial bin. See the :doc:`compute chunk/atom <compute_chunk_atom>` doc page and ":ref:`Section_howto 23 <howto_23>` for details of how chunks can be
-defined and examples of how they can be used to measure properties of
-a system.
-
-This compute calculates the x,y,z components of the center-of-mass
-velocity for each chunk. This is done by summing mass*velocity for
-each atom in the chunk and dividing the sum by the total mass of the
-chunk.
-
-Note that only atoms in the specified group contribute to the
-calculation. The :doc:`compute chunk/atom <compute_chunk_atom>` command
-defines its own group; atoms will have a chunk ID = 0 if they are not
-in that group, signifying they are not assigned to a chunk, and will
-thus also not contribute to this calculation. You can specify the
-"all" group for this command if you simply want to include atoms with
-non-zero chunk IDs.
-
-The simplest way to output the results of the compute vcm/chunk
-calculation to a file is to use the :doc:`fix ave/time <fix_ave_time>`
-* region-ID = ID of region to use as simulation domain
-* zero or more keyword/value pairs may be appended
-* keyword = *bond/types* or *angle/types* or *dihedral/types* or *improper/types* or *extra/bond/per/atom* or *extra/angle/per/atom* or *extra/dihedral/per/atom* or *extra/improper/per/atom*
-.. parsed-literal::
-
- *bond/types* value = # of bond types
- *angle/types* value = # of angle types
- *dihedral/types* value = # of dihedral types
- *improper/types* value = # of improper types
- *extra/bond/per/atom* value = # of bonds per atom
- *extra/angle/per/atom* value = # of angles per atom
- *extra/dihedral/per/atom* value = # of dihedrals per atom
- *extra/improper/per/atom* value = # of impropers per atom
- *extra/special/per/atom* value = # of special neighbors per atom
-* group-ID = ID of the group of atoms to be dumped
-* style = *atom* or *atom/gz* or *atom/mpiio* or *cfg* or *cfg/gz* or *cfg/mpiio* or *dcd* or *xtc* or *xyz* or *xyz/gz* or *xyz/mpiio* or *h5md* or *image* or *movie* or *molfile* or *local* or *custom* or *custom/gz* or *custom/mpiio*
-* N = dump every this many timesteps
-* file = name of file to write dump info to
-* args = list of arguments for a particular style
-.. parsed-literal::
-
- *atom* args = none
- *atom/gz* args = none
- *atom/mpiio* args = none
- *cfg* args = same as *custom* args, see below
- *cfg/gz* args = same as *custom* args, see below
- *cfg/mpiio* args = same as *custom* args, see below
- *dcd* args = none
- *xtc* args = none
- *xyz* args = none
-
-.. parsed-literal::
-
- *xyz/gz* args = none
-
-.. parsed-literal::
-
- *xyz/mpiio* args = none
-
-.. parsed-literal::
-
- *custom/vtk* args = similar to custom args below, discussed on :doc:`dump custom/vtk <dump_custom_vtk>` doc page
-* group-ID = ID of the group of atoms to be imaged
-* h5md = style of dump command (other styles *atom* or *cfg* or *dcd* or *xtc* or *xyz* or *local* or *custom* are discussed on the :doc:`dump <dump>` doc page)
-* N = dump every this many timesteps
-* file.h5 = name of file to write to
-* args = list of data elements to dump, with their dump "subintervals".
- At least one element must be given and image may only be present if
- position is specified first.
-.. parsed-literal::
-
- position options
- image
- velocity options
- force options
- species options
- file_from ID: do not open a new file, re-use the already opened file from dump ID
- box value = *yes* or *no*
- create_group value = *yes* or *no*
- author value = quoted string
-
-For the elements *position*\ , *velocity*\ , *force* and *species*\ , one
-may specify a sub-interval to write the data only every N_element
-iterations of the dump (i.e. every N*N_element time steps). This is
-specified by the option
-
-.. parsed-literal::
-
- every N_element
-
-that follows directly the element declaration.
-
-
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- dump h5md1 all h5md 100 dump_h5md.h5 position image
- dump h5md1 all h5md 100 dump_h5md.h5 position velocity every 10
- dump ID group-ID style N file color diameter keyword value ...
-
-* ID = user-assigned name for the dump
-* group-ID = ID of the group of atoms to be imaged
-* style = *image* or *movie* = style of dump command (other styles *atom* or *cfg* or *dcd* or *xtc* or *xyz* or *local* or *custom* are discussed on the :doc:`dump <dump>` doc page)
-* N = dump every this many timesteps
-* file = name of file to write image to
-* color = atom attribute that determines color of each atom
-* diameter = atom attribute that determines size of each atom
-* zero or more keyword/value pairs may be appended
-* keyword = *atom* or *adiam* or *bond* or *line* or *tri* or *body* or *fix* or *size* or *view* or *center* or *up* or *zoom* or *persp* or *box* or *axes* or *subbox* or *shiny* or *ssao*
-.. parsed-literal::
-
- *atom* = yes/no = do or do not draw atoms
- *adiam* size = numeric value for atom diameter (distance units)
- *bond* values = color width = color and width of bonds
- color = *atom* or *type* or *none*
- width = number or *atom* or *type* or *none*
- number = numeric value for bond width (distance units)
- *line* = color width
- color = *type*
- width = numeric value for line width (distance units)
- *tri* = color tflag width
- color = *type*
- tflag = 1 for just triangle, 2 for just tri edges, 3 for both
- width = numeric value for tringle edge width (distance units)
- *body* = color bflag1 bflag2
- color = *type*
- bflag1,bflag2 = 2 numeric flags to affect how bodies are drawn
- *fix* = fixID color fflag1 fflag2
- fixID = ID of fix that generates objects to dray
- color = *type*
- fflag1,fflag2 = 2 numeric flags to affect how fix objects are drawn
-* one or more keyword/value pairs may be appended
-* these keywords apply to various dump styles
-* keyword = *append* or *buffer* or *element* or *every* or *fileper* or *first* or *flush* or *format* or *image* or *label* or *nfile* or *pad* or *precision* or *region* or *scale* or *sort* or *thresh* or *unwrap*
-.. parsed-literal::
-
- *append* arg = *yes* or *no*
- *buffer* arg = *yes* or *no*
- *element* args = E1 E2 ... EN, where N = # of atom types
- E1,...,EN = element name, e.g. C or Fe or Ga
- *every* arg = N
- N = dump every this many timesteps
- N can be a variable (see below)
- *fileper* arg = Np
- Np = write one file for every this many processors
- *first* arg = *yes* or *no*
- *format* args = *line* string, *int* string, *float* string, M string, or *none*
- string = C-style format string
- M = integer from 1 to N, where N = # of per-atom quantities being output
- *flush* arg = *yes* or *no*
- *image* arg = *yes* or *no*
- *label* arg = string
- string = character string (e.g. BONDS) to use in header of dump local file
- *nfile* arg = Nf
- Nf = write this many files, one from each of Nf processors
- *pad* arg = Nchar = # of characters to convert timestep to
- *pbc* arg = *yes* or *no* = remap atoms via periodic boundary conditions
- *precision* arg = power-of-10 value from 10 to 1000000
-* group-ID = ID of the group of atoms to be imaged
-* molfile = style of dump command (other styles *atom* or *cfg* or *dcd* or *xtc* or *xyz* or *local* or *custom* are discussed on the :doc:`dump <dump>` doc page)
-* N = dump every this many timesteps
-* file = name of file to write to
-* format = file format to be used
-* path = file path with plugins (optional)
-
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- dump mf1 all molfile 10 melt1.xml hoomd
- dump mf2 all molfile 10 melt2-*.pdb pdb .
- dump mf3 all molfile 50 melt3.xyz xyz .:/home/akohlmey/vmd/plugins/LINUX/molfile
-
-Description
-"""""""""""
-
-Dump a snapshot of atom coordinates and selected additional quantities
-to one or more files every N timesteps in one of several formats.
-Only information for atoms in the specified group is dumped. This
-specific dump style uses molfile plugins that are bundled with the
-`VMD <http://www.ks.uiuc.edu/Research/vmd>`_ molecular visualization and
-analysis program. See :ref:`Section tools <vmd>` of the
-manual and the tools/lmp2vmd/README.txt file for more information
-about support in VMD for reading and visualizing native LAMMPS dump
-files.
-
-Unless the filename contains a * character, the output will be written
-to one single file with the specified format. Otherwise there will be
-one file per snapshot and the * will be replaced by the time step number
-when the snapshot is written.
-
-.. note::
-
- Because periodic boundary conditions are enforced only on
- timesteps when neighbor lists are rebuilt, the coordinates of an atom
- written to a dump file may be slightly outside the simulation box.
-
-The molfile plugin API has a few restrictions that have to be honored
-by this dump style: the number of atoms must not change, the atoms
-must be sorted, outside of the coordinates no change in atom properties
-(like type, mass, charge) will be recorded.
-
-
-----------
-
-
-The *format* keyword determines what format is used to write out the
-dump. For this to work, LAMMPS must be able to find and load a
-compatible molfile plugin that supports this format. Settings made via
-the :doc:`dump_modify <dump_modify>` command can alter per atom properties
-like element names.
-
-The *path* keyword determines which in directories. This is a "path"
-like other search paths, i.e. it can contain multiple directories
-separated by a colon (or semi-colon on windows). This keyword is
-optional and default to ".", the current directory.
-
-The *unwrap* option of the :doc:`dump_modify <dump_modify>` command allows
-coordinates to be written "unwrapped" by the image flags for each atom.
-Unwrapped means that if the atom has passed through a periodic boundary
-one or more times, the value is printed for what the coordinate would be
-if it had not been wrapped back into the periodic box. Note that these
-coordinates may thus be far outside the box size stored with the
-snapshot.
-
-
-----------
-
-
-Dumps are performed on timesteps that are a multiple of N (including
-timestep 0) and on the last timestep of a minimization if the
-minimization converges. Note that this means a dump will not be
-performed on the initial timestep after the dump command is invoked,
-if the current timestep is not a multiple of N. This behavior can be
-changed via the :doc:`dump_modify first <dump_modify>` command, which can
-be useful if the dump command is invoked after a minimization ended on
-an arbitrary timestep. N can be changed between runs by using the
-:doc:`dump_modify every <dump_modify>` command. The :doc:`dump_modify every <dump_modify>` command also allows a variable to be used to
-determine the sequence of timesteps on which dump files are written.
-
-
-----------
-
-
-Restrictions
-""""""""""""
-
-
-The *molfile* dump style is part of the USER-MOLFILE package. It is
-only enabled if LAMMPS was built with that package. See the :ref:`Making LAMMPS <start_3>` section for more info.
-
-Molfile plugins provide a consistent programming interface to read and
-write file formats commonly used in molecular simulations. The
-USER-MOLFILE package only provides the interface code, not the plugins.
-These can be obtained from a VMD installation which has to match the
-platform that you are using to compile LAMMPS for. By adding plugins
-to VMD, support for new file formats can be added to LAMMPS (or VMD
-or other programs that use them) without having to recompile the
-application itself. The plugins are installed in the directory:
-<VMDHOME>/plugins/<VMDARCH>/molfile
-
-.. note::
-
- while the programming interface (API) to the plugins is backward
- compatible, the binary interface (ABI) has been changing over time, so
- it is necessary to compile this package with the plugin header files
- from VMD that match the binary plugins. These header files in the
- directory: <VMDHOME>/plugins/include For convenience, the package ships
- with a set of header files that are compatible with VMD 1.9 and 1.9.1
-In other words, using one bracket reduces the dimension of the
-quantity once (vector -> scalar, array -> vector). Using two brackets
-reduces the dimension twice (array -> scalar). Thus a command that
-uses scalar fix values as input can also process elements of a vector
-or array.
-
-Note that commands and :doc:`variables <variable>` which use fix
-quantities typically do not allow for all kinds, e.g. a command may
-require a vector of values, not a scalar. This means there is no
-ambiguity about referring to a fix quantity as f_ID even if it
-produces, for example, both a scalar and vector. The doc pages for
-various commands explain the details.
-
-
-----------
-
-
-In LAMMPS, the values generated by a fix can be used in several ways:
-
-* Global values can be output via the :doc:`thermo_style custom <thermo_style>` or :doc:`fix ave/time <fix_ave_time>` command.
- Or the values can be referenced in a :doc:`variable equal <variable>` or
- :doc:`variable atom <variable>` command.
-* Per-atom values can be output via the :doc:`dump custom <dump>` command.
- Or they can be time-averaged via the :doc:`fix ave/atom <fix_ave_atom>`
- command or reduced by the :doc:`compute reduce <compute_reduce>`
- command. Or the per-atom values can be referenced in an :doc:`atom-style variable <variable>`.
-* Local values can be reduced by the :doc:`compute reduce <compute_reduce>` command, or histogrammed by the :doc:`fix ave/histo <fix_ave_histo>` command.
-See this :ref:`howto section <howto_15>` for a summary of
-various LAMMPS output options, many of which involve fixes.
-
-The results of fixes that calculate global quantities can be either
-"intensive" or "extensive" values. Intensive means the value is
-independent of the number of atoms in the simulation,
-e.g. temperature. Extensive means the value scales with the number of
-atoms in the simulation, e.g. total rotational kinetic energy.
-:doc:`Thermodynamic output <thermo_style>` will normalize extensive
-values by the number of atoms in the system, depending on the
-"thermo_modify norm" setting. It will not normalize intensive values.
-If a fix value is accessed in another way, e.g. by a
-:doc:`variable <variable>`, you may want to know whether it is an
-intensive or extensive value. See the doc page for individual fixes
-for further info.
-
-
-----------
-
-
-Each fix style has its own documentation page which describes its
-arguments and what it does, as listed below. Here is an alphabetic
-list of fix styles available in LAMMPS. They are also given in more
-compact form in the Fix section of :ref:`this page <cmd_5>`.
-
-There are also additional fix styles (not listed here) submitted by
-users which are included in the LAMMPS distribution. The list of
-these with links to the individual styles are given in the fix section
-of :ref:`this page <cmd_5>`.
-
-* :doc:`adapt <fix_adapt>` - change a simulation parameter over time
-* :doc:`addforce <fix_addforce>` - add a force to each atom
-* :doc:`append/atoms <fix_append_atoms>` - append atoms to a running simulation
-* :doc:`atom/swap <fix_atom_swap>` - Monte Carlo atom type swapping
-* :doc:`aveforce <fix_aveforce>` - add an averaged force to each atom
-* :doc:`qeq/comb <fix_qeq_comb>` - charge equilibration for COMB potential :doc:`qeq/dynamic <fix_qeq>` - charge equilibration via dynamic method :doc:`qeq/fire <fix_qeq>` - charge equilibration via FIRE minimizer :doc:`qeq/point <fix_qeq>` - charge equilibration via point method :doc:`qeq/shielded <fix_qeq>` - charge equilibration via shielded method :doc:`qeq/slater <fix_qeq>` - charge equilibration via Slater method :doc:`rattle <fix_shake>` - RATTLE constraints on bonds and/or angles
-* :doc:`reax/bonds <fix_reax_bonds>` - write out ReaxFF bond information :doc:`recenter <fix_recenter>` - constrain the center-of-mass position of a group of atoms
-* :doc:`restrain <fix_restrain>` - constrain a bond, angle, dihedral
-* :doc:`rigid <fix_rigid>` - constrain one or more clusters of atoms to move as a rigid body with NVE integration
-* :doc:`rigid/nph <fix_rigid>` - constrain one or more clusters of atoms to move as a rigid body with NPH integration
-* :doc:`rigid/npt <fix_rigid>` - constrain one or more clusters of atoms to move as a rigid body with NPT integration
-* :doc:`rigid/nve <fix_rigid>` - constrain one or more clusters of atoms to move as a rigid body with alternate NVE integration
-* :doc:`rigid/nvt <fix_rigid>` - constrain one or more clusters of atoms to move as a rigid body with NVT integration
-* :doc:`rigid/small <fix_rigid>` - constrain many small clusters of atoms to move as a rigid body with NVE integration
-* :doc:`rigid/small/nph <fix_rigid>` - constrain many small clusters of atoms to move as a rigid body with NPH integration
-* :doc:`rigid/small/npt <fix_rigid>` - constrain many small clusters of atoms to move as a rigid body with NPT integration
-* :doc:`rigid/small/nve <fix_rigid>` - constrain many small clusters of atoms to move as a rigid body with alternate NVE integration
-* :doc:`rigid/small/nvt <fix_rigid>` - constrain many small clusters of atoms to move as a rigid body with NVT integration
-* :doc:`setforce <fix_setforce>` - set the force on each atom
-* :doc:`shake <fix_shake>` - SHAKE constraints on bonds and/or angles
-* :doc:`spring <fix_spring>` - apply harmonic spring force to group of atoms
-* :doc:`spring/chunk <fix_spring_chunk>` - apply harmonic spring force to each chunk of atoms
-* :doc:`spring/rg <fix_spring_rg>` - spring on radius of gyration of group of atoms
-* :doc:`spring/self <fix_spring_self>` - spring from each atom to its origin
-* type = *thermal* or *two_temperature* or *hardy* or *field*
-.. parsed-literal::
-
- *thermal* = thermal coupling with fields: temperature
- *two_temperature* = electron-phonon coupling with field: temperature and electron_temperature
- *hardy* = on-the-fly post-processing using kernel localization functions (see "related" section for possible fields)
- *field* = on-the-fly post-processing using mesh-based localization functions (see "related" section for possible fields)
-
-* parameter_file = name of the file with material parameters. Note: Neither hardy nor field requires a parameter file
-Examples
-""""""""
-
-.. parsed-literal::
-
- fix AtC internal atc thermal Ar_thermal.dat
- fix AtC internal atc two_temperature Ar_ttm.mat
- fix AtC internal atc hardy
- fix AtC internal atc field
-
-Description
-"""""""""""
-
-This fix is the beginning to creating a coupled FE/MD simulation and/or an on-the-fly estimation of continuum fields. The coupled versions of this fix do Verlet integration and the post-processing does not. After instantiating this fix, several other fix_modify commands will be needed to set up the problem, e.g. define the finite element mesh and prescribe initial and boundary conditions.
-
-.. image:: JPG/atc_nanotube.jpg
- :align: center
-
-.. parsed-literal::
-
- The following coupling example is typical, but non-exhaustive:
- # ... commands to create and initialize the MD system
-
-.. parsed-literal::
-
- # initial fix to designate coupling type and group to apply it to
- # tag group physics material_file
- fix AtC internal atc thermal Ar_thermal.mat
-
-.. parsed-literal::
-
- # create a uniform 12 x 2 x 2 mesh that covers region contain the group
- # nx ny nz region periodicity
- fix_modify AtC mesh create 12 2 2 mdRegion f p p
-
-.. parsed-literal::
-
- # specify the control method for the type of coupling
- # physics control_type
- fix_modify AtC thermal control flux
-
-.. parsed-literal::
-
- # specify the initial values for the empirical field "temperature"
- # field node_group value
- fix_modify AtC initial temperature all 30
-
-.. parsed-literal::
-
- # create an output stream for nodal fields
- # filename output_frequency
- fix_modify AtC output atc_fe_output 100
-
-.. parsed-literal::
-
- run 1000
-
-likewise for this post-processing example:
-
-.. parsed-literal::
-
- # ... commands to create and initialize the MD system
-
-.. parsed-literal::
-
- # initial fix to designate post-processing and the group to apply it to
- # no material file is allowed nor required
- fix AtC internal atc hardy
-
-.. parsed-literal::
-
- # for hardy fix, specific kernel function (function type and range) to # be used as a localization function
- fix AtC kernel quartic_sphere 10.0
-
-.. parsed-literal::
-
- # create a uniform 1 x 1 x 1 mesh that covers region contain the group
- # with periodicity this effectively creats a system average
- fix_modify AtC mesh create 1 1 1 box p p p
-
-.. parsed-literal::
-
- # change from default lagrangian map to eulerian
- # refreshed every 100 steps
- fix_modify AtC atom_element_map eulerian 100
-
-.. parsed-literal::
-
- # start with no field defined
- # add mass density, potential energy density, stress and temperature
- fix_modify AtC fields add density energy stress temperature
-
-.. parsed-literal::
-
- # create an output stream for nodal fields
- # filename output_frequency
- fix_modify AtC output nvtFE 100 text
-
-.. parsed-literal::
-
- run 1000
-
-the mesh's linear interpolation functions can be used as the localization function
- by using the field option:
-
-fix AtC internal atc field
-
-fix_modify AtC mesh create 1 1 1 box p p p
-
-...
-
-Note coupling and post-processing can be combined in the same simulations using separate fixes.
-
-
-----------
-
-
-Restart, fix_modify, output, run start/stop, minimize info
-No information about this fix is written to :doc:`binary restart files <restart>`. The :doc:`fix_modify <fix_modify>` options relevant to this fix are listed below. No global scalar or vector or per-atom quantities are stored by this fix for access by various :ref:`output commands <howto_15>`. No parameter of this fix can be used with the *start/stop* keywords of the :doc:`run <run>` command. This fix is not invoked during :doc:`energy minimization <minimize>`.
-
-Restrictions
-""""""""""""
-
-
-Thermal and two_temperature (coupling) types use a Verlet time-integration algorithm. The hardy type does not contain its own time-integrator and must be used with a separate fix that does contain one, e.g. nve, nvt, etc.
-
-* Currently,
-* - the coupling is restricted to thermal physics
-* - the FE computations are done in serial on each processor.
-
-Related commands
-""""""""""""""""
-
-After specifying this fix in your input script, several other :doc:`fix_modify <fix_modify>` commands are used to setup the problem, e.g. define the finite element mesh and prescribe initial and boundary conditions.
-Note: a set of example input files with the attendant material files are included with this package
-
-Default
-"""""""
-None
-
-
-----------
-
-
-For detailed exposition of the theory and algorithms please see:
-
-.. _Wagner:
-
-
-
-**(Wagner)** Wagner, GJ; Jones, RE; Templeton, JA; Parks, MA, "An atomistic-to-continuum coupling method for heat transfer in solids." Special Issue of Computer Methods and Applied Mechanics (2008) 197:3351.
-
-.. _Zimmeman2004:
-
-
-
-**(Zimmerman2004)** Zimmerman, JA; Webb, EB; Hoyt, JJ;. Jones, RE; Klein, PA; Bammann, DJ, "Calculation of stress in atomistic simulation." Special Issue of Modelling and Simulation in Materials Science and Engineering (2004), 12:S319.
-
-.. _Zimmerman2010:
-
-
-
-**(Zimmerman2010)** Zimmerman, JA; Jones, RE; Templeton, JA, "A material frame approach for evaluating continuum variables in atomistic simulations." Journal of Computational Physics (2010), 229:2364.
-
-.. _Templeton2010:
-
-
-
-**(Templeton2010)** Templeton, JA; Jones, RE; Wagner, GJ, "Application of a field-based method to spatially varying thermal transport problems in molecular dynamics." Modelling and Simulation in Materials Science and Engineering (2010), 18:085007.
-
-.. _Jones:
-
-
-
-**(Jones)** Jones, RE; Templeton, JA; Wagner, GJ; Olmsted, D; Modine, JA, "Electron transport enhanced molecular dynamics for metals and semi-metals." International Journal for Numerical Methods in Engineering (2010), 83:940.
-
-.. _Templeton2011:
-
-
-
-**(Templeton2011)** Templeton, JA; Jones, RE; Lee, JW; Zimmerman, JA; Wong, BM, "A long-range electric field solver for molecular dynamics based on atomistic-to-continuum modeling." Journal of Chemical Theory and Computation (2011), 7:1736.
-
-.. _Mandadapu:
-
-
-
-**(Mandadapu)** Mandadapu, KK; Templeton, JA; Lee, JW, "Polarization as a field variable from molecular dynamics simulations." Journal of Chemical Physics (2013), 139:054115.
-
-Please refer to the standard finite element (FE) texts, e.g. T.J.R Hughes " The finite element method ", Dover 2003, for the basics of FE simulation.
-* ID, group-ID are documented in :doc:`fix <fix>` command
-* ave/atom = style name of this fix command
-* Nevery = use input values every this many timesteps
-* Nrepeat = # of times to use input values for calculating averages
-* Nfreq = calculate averages every this many timesteps
- one or more input values can be listed
-* value = x, y, z, vx, vy, vz, fx, fy, fz, c_ID, c_ID[i], f_ID, f_ID[i], v_name
-.. parsed-literal::
-
- x,y,z,vx,vy,vz,fx,fy,fz = atom attribute (position, velocity, force component)
- c_ID = per-atom vector calculated by a compute with ID
- c_ID[I] = Ith column of per-atom array calculated by a compute with ID, I can include wildcard (see below)
- f_ID = per-atom vector calculated by a fix with ID
- f_ID[I] = Ith column of per-atom array calculated by a fix with ID, I can include wildcard (see below)
- v_name = per-atom vector calculated by an atom-style variable with name
-
-
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- fix 1 all ave/atom 1 100 100 vx vy vz
- fix 1 all ave/atom 10 20 1000 c_my_stress[1]
- fix 1 all ave/atom 10 20 1000 c_my_stress[*]
-
-Description
-"""""""""""
-
-Use one or more per-atom vectors as inputs every few timesteps, and
-average them atom by atom over longer timescales. The resulting
-per-atom averages can be used by other :ref:`output commands <howto_15>` such as the :doc:`fix ave/chunk <fix_ave_chunk>` or :doc:`dump custom <dump>` commands.
-
-The group specified with the command means only atoms within the group
-have their averages computed. Results are set to 0.0 for atoms not in
-the group.
-
-Each input value can be an atom attribute (position, velocity, force
-component) or can be the result of a :doc:`compute <compute>` or
-:doc:`fix <fix>` or the evaluation of an atom-style
-:doc:`variable <variable>`. In the latter cases, the compute, fix, or
-variable must produce a per-atom vector, not a global quantity or
-local quantity. If you wish to time-average global quantities from a
-compute, fix, or variable, then see the :doc:`fix ave/time <fix_ave_time>` command.
-
-Each per-atom value of each input vector is averaged independently.
-
-:doc:`Computes <compute>` that produce per-atom vectors or arrays are
-those which have the word *atom* in their style name. See the doc
-pages for individual :doc:`fixes <fix>` to determine which ones produce
-per-atom vectors or arrays. :doc:`Variables <variable>` of style *atom*
-are the only ones that can be used with this fix since they produce
-per-atom vectors.
-
-Note that for values from a compute or fix, the bracketed index I can
-be specified using a wildcard asterisk with the index to effectively
-specify multiple values. This takes the form "*" or "*n" or "n*" or
-"m*n". If N = the size of the vector (for *mode* = scalar) or the
-number of columns in the array (for *mode* = vector), then an asterisk
-with no numeric values means all indices from 1 to N. A leading
-asterisk means all indices from 1 to n (inclusive). A trailing
-asterisk means all indices from n to N (inclusive). A middle asterisk
-means all indices from m to n (inclusive).
-
-Using a wildcard is the same as if the individual columns of the array
-had been listed one by one. E.g. these 2 fix ave/atom commands are
-equivalent, since the :doc:`compute stress/atom <compute_stress_atom>`
-Use one or more per-atom vectors as inputs every few timesteps, sum
-the values over the atoms in each chunk at each timestep, then average
-the per-chunk values over longer timescales. The resulting chunk
-averages can be used by other :ref:`output commands <howto_15>` such as :doc:`thermo_style custom <thermo_style>`, and can also be written to a file.
-
-In LAMMPS, chunks are collections of atoms defined by a :doc:`compute chunk/atom <compute_chunk_atom>` command, which assigns each atom
-to a single chunk (or no chunk). The ID for this command is specified
-as chunkID. For example, a single chunk could be the atoms in a
-molecule or atoms in a spatial bin. See the :doc:`compute chunk/atom <compute_chunk_atom>` doc page and ":ref:`Section_howto 23 <howto_23>` for details of how chunks can be
-defined and examples of how they can be used to measure properties of
-a system.
-
-Note that only atoms in the specified group contribute to the summing
-and averaging calculations. The :doc:`compute chunk/atom <compute_chunk_atom>` command defines its own group as
-well as an optional region. Atoms will have a chunk ID = 0, meaning
-they belong to no chunk, if they are not in that group or region.
-Thus you can specify the "all" group for this command if you simply
-want to use the chunk definitions provided by chunkID.
-
-Each specified per-atom value can be an atom attribute (position,
-velocity, force component), a mass or number density, or the result of
-a :doc:`compute <compute>` or :doc:`fix <fix>` or the evaluation of an
-atom-style :doc:`variable <variable>`. In the latter cases, the
-compute, fix, or variable must produce a per-atom quantity, not a
-global quantity. Note that the :doc:`compute property/atom <compute_property_atom>` command provides access to
-any attribute defined and stored by atoms. If you wish to
-time-average global quantities from a compute, fix, or variable, then
-see the :doc:`fix ave/time <fix_ave_time>` command.
-
-The per-atom values of each input vector are summed and averaged
-independently of the per-atom values in other input vectors.
-
-:doc:`Computes <compute>` that produce per-atom quantities are those
-which have the word *atom* in their style name. See the doc pages for
-individual :doc:`fixes <fix>` to determine which ones produce per-atom
-quantities. :doc:`Variables <variable>` of style *atom* are the only
-ones that can be used with this fix since all other styles of variable
-produce global quantities.
-
-Note that for values from a compute or fix, the bracketed index I can
-be specified using a wildcard asterisk with the index to effectively
-specify multiple values. This takes the form "*" or "*n" or "n*" or
-"m*n". If N = the size of the vector (for *mode* = scalar) or the
-number of columns in the array (for *mode* = vector), then an asterisk
-with no numeric values means all indices from 1 to N. A leading
-asterisk means all indices from 1 to n (inclusive). A trailing
-asterisk means all indices from n to N (inclusive). A middle asterisk
-means all indices from m to n (inclusive).
-
-Using a wildcard is the same as if the individual columns of the array
-had been listed one by one. E.g. these 2 fix ave/chunk commands are
-equivalent, since the :doc:`compute property/atom <compute_property/atom>` command creates, in this
-case, a per-atom array with 3 columns:
-
-.. parsed-literal::
-
- compute myAng all property/atom angmomx angmomy angmomz
- type upper ave running title1 "My correlation data"
-
-fix 1 all ave/correlate 1 50 10000 c_thermo_press[*]
-
-Description
-"""""""""""
-
-Use one or more global scalar values as inputs every few timesteps,
-calculate time correlations bewteen them at varying time intervals,
-and average the correlation data over longer timescales. The
-resulting correlation values can be time integrated by
-:doc:`variables <variable>` or used by other :ref:`output commands <howto_15>` such as :doc:`thermo_style custom <thermo_style>`, and can also be written to a file. See the
-:doc:`fix ave/correlate/long <fix_ave_correlate_long>` command for an
-alternate method for computing correlation functions efficiently over
-very long time windows.
-
-The group specified with this command is ignored. However, note that
-specified values may represent calculations performed by computes and
-fixes which store their own "group" definitions.
-
-Each listed value can be the result of a :doc:`compute <compute>` or
-:doc:`fix <fix>` or the evaluation of an equal-style or vector-style
-:doc:`variable <variable>`. In each case, the compute, fix, or variable
-must produce a global quantity, not a per-atom or local quantity. If
-you wish to spatial- or time-average or histogram per-atom quantities
-from a compute, fix, or variable, then see the :doc:`fix ave/chunk <fix_ave_chunk>`, :doc:`fix ave/atom <fix_ave_atom>`, or
-:doc:`fix ave/histo <fix_ave_histo>` commands. If you wish to convert a
-per-atom quantity into a single global value, see the :doc:`compute reduce <compute_reduce>` command.
-
-The input values must either be all scalars. What kinds of
-correlations between input values are calculated is determined by the
-*type* keyword as discussed below.
-
-:doc:`Computes <compute>` that produce global quantities are those which
-do not have the word *atom* in their style name. Only a few
-:doc:`fixes <fix>` produce global quantities. See the doc pages for
-individual fixes for info on which ones produce such values.
-:doc:`Variables <variable>` of style *equal* and *vector* are the only
-ones that can be used with this fix. Variables of style *atom* cannot
-be used, since they produce per-atom values.
-
-Note that for values from a compute or fix, the bracketed index I can
-be specified using a wildcard asterisk with the index to effectively
-specify multiple values. This takes the form "*" or "*n" or "n*" or
-"m*n". If N = the size of the vector (for *mode* = scalar) or the
-number of columns in the array (for *mode* = vector), then an asterisk
-with no numeric values means all indices from 1 to N. A leading
-asterisk means all indices from 1 to n (inclusive). A trailing
-asterisk means all indices from n to N (inclusive). A middle asterisk
-means all indices from m to n (inclusive).
-
-Using a wildcard is the same as if the individual elements of the
-vector had been listed one by one. E.g. these 2 fix ave/correlate
-commands are equivalent, since the :doc:`compute pressure <compute_pressure>` command creates a global vector with 6
-values.
-
-.. parsed-literal::
-
- compute myPress all pressure NULL
- fix 1 all ave/correlate 1 50 10000 c_myPress[*]
- fix 1 all ave/correlate 1 50 10000 &
- c_myPress[1] c_myPress[2] c_myPress[3] &
- c_myPress[4] c_myPress[5] c_myPress[6]
-
-
-----------
-
-
-The *Nevery*\ , *Nrepeat*\ , and *Nfreq* arguments specify on what
-timesteps the input values will be used to calculate correlation data.
-The input values are sampled every *Nevery* timesteps. The
-correlation data for the preceding samples is computed on timesteps
-that are a multiple of *Nfreq*\ . Consider a set of samples from some
-initial time up to an output timestep. The initial time could be the
-beginning of the simulation or the last output time; see the *ave*
-keyword for options. For the set of samples, the correlation value
-Cij is calculated as:
-
-.. parsed-literal::
-
- Cij(delta) = ave(Vi(t)*Vj(t+delta))
-
-which is the correlation value between input values Vi and Vj,
-separated by time delta. Note that the second value Vj in the pair is
-always the one sampled at the later time. The ave() represents an
-average over every pair of samples in the set that are separated by
-time delta. The maximum delta used is of size (\ *Nrepeat*\ -1)*\ *Nevery*\ .
-Thus the correlation between a pair of input values yields *Nrepeat*
-If the fix ave/histo/weight command is used, exactly two values must
-be specified. If the values are vectors, they must be the same
-length. The first value (a scalar or vector) is what is histogrammed
-into bins, in the same manner the fix ave/histo command operates. The
-second value (a scalar or vector) is used as a "weight". This means
-that instead of each value tallying a "1" to its bin, the
-corresponding weight is tallied. E.g. The Nth entry (weight) in the
-second vector is tallied to the bin corresponding to the Nth entry in
-the first vector.
-
-
-----------
-
-
-The *Nevery*\ , *Nrepeat*\ , and *Nfreq* arguments specify on what
-timesteps the input values will be used in order to contribute to the
-histogram. The final histogram is generated on timesteps that are
-multiple of *Nfreq*\ . It is averaged over *Nrepeat* histograms,
-computed in the preceding portion of the simulation every *Nevery*
-timesteps. *Nfreq* must be a multiple of *Nevery* and *Nevery* must
-be non-zero even if *Nrepeat* is 1. Also, the timesteps
-contributing to the histogram value cannot overlap,
-i.e. Nrepeat*Nevery can not exceed Nfreq.
-
-For example, if Nevery=2, Nrepeat=6, and Nfreq=100, then input values
-on timesteps 90,92,94,96,98,100 will be used to compute the final
-histogram on timestep 100. Similarly for timesteps
-190,192,194,196,198,200 on timestep 200, etc. If Nrepeat=1 and Nfreq
-= 100, then no time averaging of the histogram is done; a histogram is
-simply generated on timesteps 100,200,etc.
-
-
-----------
-
-
-The atom attribute values (x,y,z,vx,vy,vz,fx,fy,fz) are
-self-explanatory. Note that other atom attributes can be used as
-inputs to this fix by using the :doc:`compute property/atom <compute_property_atom>` command and then specifying
-an input value from that compute.
-
-If a value begins with "c_", a compute ID must follow which has been
-previously defined in the input script. If *mode* = scalar, then if
-no bracketed term is appended, the global scalar calculated by the
-compute is used. If a bracketed term is appended, the Ith element of
-the global vector calculated by the compute is used. If *mode* =
-vector, then if no bracketed term is appended, the global or per-atom
-or local vector calculated by the compute is used. If a bracketed
-term is appended, the Ith column of the global or per-atom or local
-array calculated by the compute is used. See the discussion above for
-how I can be specified with a wildcard asterisk to effectively specify
-multiple values.
-
-Note that there is a :doc:`compute reduce <compute_reduce>` command
-which can sum per-atom quantities into a global scalar or vector which
-can thus be accessed by fix ave/histo. Or it can be a compute defined
-not in your input script, but by :doc:`thermodynamic output <thermo_style>` or other fixes such as :doc:`fix nvt <fix_nh>` or :doc:`fix temp/rescale <fix_temp_rescale>`. See
-the doc pages for these commands which give the IDs of these computes.
-Users can also write code for their own compute styles and :doc:`add them to LAMMPS <Section_modify>`.
-
-If a value begins with "f_", a fix ID must follow which has been
-previously defined in the input script. If *mode* = scalar, then if
-no bracketed term is appended, the global scalar calculated by the fix
-is used. If a bracketed term is appended, the Ith element of the
-global vector calculated by the fix is used. If *mode* = vector, then
-if no bracketed term is appended, the global or per-atom or local
-vector calculated by the fix is used. If a bracketed term is
-appended, the Ith column of the global or per-atom or local array
-calculated by the fix is used. See the discussion above for how I can
-be specified with a wildcard asterisk to effectively specify multiple
-values.
-
-Note that some fixes only produce their values on certain timesteps,
-which must be compatible with *Nevery*\ , else an error will result.
-Users can also write code for their own fix styles and :doc:`add them to LAMMPS <Section_modify>`.
-
-If a value begins with "v_", a variable name must follow which has
-been previously defined in the input script. If *mode* = scalar, then
-only equal-style or vector-style variables can be used, which both
-produce global values. In this mode, a vector-style variable requires
-a bracketed term to specify the Ith element of the vector calculated
-by the variable. If *mode* = vector, then only vector-style or
-atom-style variables can be used, which produce a global or per-atom
-vector respectively. The vector-style variable must be used without a
-bracketed term. See the :doc:`variable <variable>` command for details.
-
-Note that variables of style *equal*\ , *vector*\ , and *atom* define a
-formula which can reference individual atom properties or
-thermodynamic keywords, or they can invoke other computes, fixes, or
-variables when they are evaluated, so this is a very general means of
-specifying quantities to histogram.
-
-
-----------
-
-
-Additional optional keywords also affect the operation of this fix.
-
-If the *mode* keyword is set to *scalar*\ , then all input values must
-be global scalars, or elements of global vectors. If the *mode*
-keyword is set to *vector*\ , then all input values must be global or
-per-atom or local vectors, or columns of global or per-atom or local
-arrays.
-
-The *beyond* keyword determines how input values that fall outside the
-*lo* to *hi* bounds are treated. Values such that *lo* <= value <=
-*hi* are assigned to one bin. Values on a bin boundary are assigned
-to the lower of the 2 bins. If *beyond* is set to *ignore* then
-values < *lo* and values > *hi* are ignored, i.e. they are not binned.
-If *beyond* is set to *end* then values < *lo* are counted in the
-first bin and values > *hi* are counted in the last bin. If *beyond*
-is set to *extend* then two extra bins are created, so that there are
-Nbins+2 total bins. Values < *lo* are counted in the first bin and
-values > *hi* are counted in the last bin (Nbins+1). Values between
-*lo* and *hi* (inclusive) are counted in bins 2 thru Nbins+1. The
-"coordinate" stored and printed for these two extra bins is *lo* and
-*hi*\ .
-
-The *ave* keyword determines how the histogram produced every *Nfreq*
-steps are averaged with histograms produced on previous steps that
-were multiples of *Nfreq*\ , before they are accessed by another output
-command or written to a file.
-
-If the *ave* setting is *one*\ , then the histograms produced on
-timesteps that are multiples of *Nfreq* are independent of each other;
-they are output as-is without further averaging.
-
-If the *ave* setting is *running*\ , then the histograms produced on
-timesteps that are multiples of *Nfreq* are summed and averaged in a
-cumulative sense before being output. Each bin value in the histogram
-is thus the average of the bin value produced on that timestep with
-all preceding values for the same bin. This running average begins
-when the fix is defined; it can only be restarted by deleting the fix
-via the :doc:`unfix <unfix>` command, or by re-defining the fix by
-re-specifying it.
-
-If the *ave* setting is *window*\ , then the histograms produced on
-timesteps that are multiples of *Nfreq* are summed within a moving
-"window" of time, so that the last M histograms are used to produce
-the output. E.g. if M = 3 and Nfreq = 1000, then the output on step
-10000 will be the combined histogram of the individual histograms on
-steps 8000,9000,10000. Outputs on early steps will be sums over less
-than M histograms if they are not available.
-
-The *start* keyword specifies what timestep histogramming will begin
-on. The default is step 0. Often input values can be 0.0 at time 0,
-so setting *start* to a larger value can avoid including a 0.0 in
-a running or windowed histogram.
-
-The *file* keyword allows a filename to be specified. Every *Nfreq*
-steps, one histogram is written to the file. This includes a leading
-line that contains the timestep, number of bins, the total count of
-values contributing to the histogram, the count of values that were
-not histogrammed (see the *beyond* keyword), the minimum value
-encountered, and the maximum value encountered. The min/max values
-include values that were not histogrammed. Following the leading
-line, one line per bin is written into the file. Each line contains
-the bin #, the coordinate for the center of the bin (between *lo* and
-*hi*\ ), the count of values in the bin, and the normalized count. The
-normalized count is the bin count divided by the total count (not
-including values not histogrammed), so that the normalized values sum
-to 1.0 across all bins.
-
-The *overwrite* keyword will continuously overwrite the output file
-with the latest output, so that it only contains one timestep worth of
-output. This option can only be used with the *ave running* setting.
-
-The *title1* and *title2* and *title3* keywords allow specification of
-the strings that will be printed as the first 3 lines of the output
-file, assuming the *file* keyword was used. LAMMPS uses default
-values for each of these, so they do not need to be specified.
-The *Nevery*\ , *Nrepeat*\ , and *Nfreq* arguments specify on what
-timesteps the input values will be used in order to contribute to the
-average. The final averaged quantities are generated on timesteps
-that are a mlutiple of *Nfreq*\ . The average is over *Nrepeat*
-quantities, computed in the preceding portion of the simulation every
-*Nevery* timesteps. *Nfreq* must be a multiple of *Nevery* and
-*Nevery* must be non-zero even if *Nrepeat* is 1. Also, the timesteps
-contributing to the average value cannot overlap,
-i.e. Nrepeat*Nevery can not exceed Nfreq.
-
-For example, if Nevery=2, Nrepeat=6, and Nfreq=100, then values on
-timesteps 90,92,94,96,98,100 will be used to compute the final average
-on timestep 100. Similarly for timesteps 190,192,194,196,198,200 on
-timestep 200, etc. If Nrepeat=1 and Nfreq = 100, then no time
-averaging is done; values are simply generated on timesteps
-100,200,etc.
-
-
-----------
-
-
-If a value begins with "c_", a compute ID must follow which has been
-previously defined in the input script. If *mode* = scalar, then if
-no bracketed term is appended, the global scalar calculated by the
-compute is used. If a bracketed term is appended, the Ith element of
-the global vector calculated by the compute is used. If *mode* =
-vector, then if no bracketed term is appended, the global vector
-calculated by the compute is used. If a bracketed term is appended,
-the Ith column of the global array calculated by the compute is used.
-See the discussion above for how I can be specified with a wildcard
-asterisk to effectively specify multiple values.
-
-Note that there is a :doc:`compute reduce <compute_reduce>` command
-which can sum per-atom quantities into a global scalar or vector which
-can thus be accessed by fix ave/time. Or it can be a compute defined
-not in your input script, but by :doc:`thermodynamic output <thermo_style>` or other fixes such as :doc:`fix nvt <fix_nh>` or :doc:`fix temp/rescale <fix_temp_rescale>`. See
-the doc pages for these commands which give the IDs of these computes.
-Users can also write code for their own compute styles and :doc:`add them to LAMMPS <Section_modify>`.
-
-If a value begins with "f_", a fix ID must follow which has been
-previously defined in the input script. If *mode* = scalar, then if
-no bracketed term is appended, the global scalar calculated by the fix
-is used. If a bracketed term is appended, the Ith element of the
-global vector calculated by the fix is used. If *mode* = vector, then
-if no bracketed term is appended, the global vector calculated by the
-fix is used. If a bracketed term is appended, the Ith column of the
-global array calculated by the fix is used. See the discussion above
-for how I can be specified with a wildcard asterisk to effectively
-specify multiple values.
-
-Note that some fixes only produce their values on certain timesteps,
-which must be compatible with *Nevery*\ , else an error will result.
-Users can also write code for their own fix styles and :doc:`add them to LAMMPS <Section_modify>`.
-
-If a value begins with "v_", a variable name must follow which has
-been previously defined in the input script. If *mode* = scalar, then
-only equal-style or vector-style variables can be used, which both
-produce global values. In this mode, a vector-style variable requires
-a bracketed term to specify the Ith element of the vector calculated
-by the variable. If *mode* = vector, then only a vector-style
-variable can be used, without a bracketed term. See the
-:doc:`variable <variable>` command for details.
-
-Note that variables of style *equal* and *vector* define a formula
-which can reference individual atom properties or thermodynamic
-keywords, or they can invoke other computes, fixes, or variables when
-they are evaluated, so this is a very general means of specifying
-quantities to time average.
-
-
-----------
-
-
-Additional optional keywords also affect the operation of this fix.
-
-If the *mode* keyword is set to *scalar*\ , then all input values must
-be global scalars, or elements of global vectors. If the *mode*
-keyword is set to *vector*\ , then all input values must be global
-vectors, or columns of global arrays. They can also be global arrays,
-which are converted into a series of global vectors (one per column),
-as explained above.
-
-The *ave* keyword determines how the values produced every *Nfreq*
-steps are averaged with values produced on previous steps that were
-multiples of *Nfreq*\ , before they are accessed by another output
-command or written to a file.
-
-If the *ave* setting is *one*\ , then the values produced on timesteps
-that are multiples of *Nfreq* are independent of each other; they are
-output as-is without further averaging.
-
-If the *ave* setting is *running*\ , then the values produced on
-timesteps that are multiples of *Nfreq* are summed and averaged in a
-cummulative sense before being output. Each output value is thus the
-average of the value produced on that timestep with all preceding
-values. This running average begins when the fix is defined; it can
-only be restarted by deleting the fix via the :doc:`unfix <unfix>`
-command, or by re-defining the fix by re-specifying it.
-
-If the *ave* setting is *window*\ , then the values produced on
-timesteps that are multiples of *Nfreq* are summed and averaged within
-a moving "window" of time, so that the last M values are used to
-produce the output. E.g. if M = 3 and Nfreq = 1000, then the output
-on step 10000 will be the average of the individual values on steps
-8000,9000,10000. Outputs on early steps will average over less than M
-values if they are not available.
-
-The *start* keyword specifies what timestep averaging will begin on.
-The default is step 0. Often input values can be 0.0 at time 0, so
-setting *start* to a larger value can avoid including a 0.0 in a
-running or windowed average.
-
-The *off* keyword can be used to flag any of the input values. If a
-value is flagged, it will not be time averaged. Instead the most
-recent input value will always be stored and output. This is useful
-if one of more of the inputs produced by a compute or fix or variable
-are effectively constant or are simply current values. E.g. they are
-being written to a file with other time-averaged values for purposes
-of creating well-formatted output.
-
-The *file* keyword allows a filename to be specified. Every *Nfreq*
-steps, one quantity or vector of quantities is written to the file for
-each input value specified in the fix ave/time command. For *mode* =
-scalar, this means a single line is written each time output is
-performed. Thus the file ends up to be a series of lines, i.e. one
-column of numbers for each input value. For *mode* = vector, an array
-of numbers is written each time output is performed. The number of
-rows is the length of the input vectors, and the number of columns is
-the number of values. Thus the file ends up to be a series of these
-array sections.
-
-The *overwrite* keyword will continuously overwrite the output file
-with the latest output, so that it only contains one timestep worth of
-output. This option can only be used with the *ave running* setting.
-
-The *format* keyword sets the numeric format of each value when it is
-printed to a file via the *file* keyword. Note that all values are
-floating point quantities. The default format is %g. You can specify
-a higher precision if desired, e.g. %20.16g.
-
-The *title1* and *title2* and *title3* keywords allow specification of
-the strings that will be printed as the first 2 or 3 lines of the
-output file, assuming the *file* keyword was used. LAMMPS uses
-default values for each of these, so they do not need to be specified.
-
-By default, these header lines are as follows for *mode* = scalar:
-
-.. parsed-literal::
-
- # Time-averaged data for fix ID
- # TimeStep value1 value2 ...
-
-In the first line, ID is replaced with the fix-ID. In the second line
-the values are replaced with the appropriate fields from the fix
-ave/time command. There is no third line in the header of the file,
-so the *title3* setting is ignored when *mode* = scalar.
-
-By default, these header lines are as follows for *mode* = vector:
-
-.. parsed-literal::
-
- # Time-averaged data for fix ID
- # TimeStep Number-of-rows
- # Row value1 value2 ...
-
-In the first line, ID is replaced with the fix-ID. The second line
-describes the two values that are printed at the first of each section
-of output. In the third line the values are replaced with the
-appropriate fields from the fix ave/time command.
-
-
-----------
-
-
-Restart, fix_modify, output, run start/stop, minimize info
-* ID, group-ID are documented in :doc:`fix <fix>` command
-* box/relax = style name of this fix command
-.. parsed-literal::
-
- one or more keyword value pairs may be appended
- keyword = *iso* or *aniso* or *tri* or *x* or *y* or *z* or *xy* or *yz* or *xz* or *couple* or *nreset* or *vmax* or *dilate* or *scaleyz* or *scalexz* or *scalexy* or *fixedpoint*
- *iso* or *aniso* or *tri* value = Ptarget = desired pressure (pressure units)
- *x* or *y* or *z* or *xy* or *yz* or *xz* value = Ptarget = desired pressure (pressure units)
- *couple* = *none* or *xyz* or *xy* or *yz* or *xz*
- *nreset* value = reset reference cell every this many minimizer iterations
- *vmax* value = fraction = max allowed volume change in one iteration
- *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
- *fixedpoint* values = x y z
- x,y,z = perform relaxation dilation/contraction around this point (distance 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 *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 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
- fix ID group-ID deposit N type M seed keyword values ...
-
-* ID, group-ID are documented in :doc:`fix <fix>` command
-* deposit = style name of this fix command
-* N = # of atoms or molecules to insert
-* type = atom type to assign to inserted atoms (offset for moleclue insertion)
-* M = insert a single atom or molecule every M steps
-* seed = random # seed (positive integer)
-* one or more keyword/value pairs may be appended to args
-* keyword = *region* or *id* or *global* or *local* or *near* or *gaussian* or *attempt* or *rate* or *vx* or *vy* or *vz* or *mol* or *rigid* or *shake* or *units*
-.. parsed-literal::
-
- *region* value = region-ID
- region-ID = ID of region to use as insertion volume
- *id* value = *max* or *next*
- max = atom ID for new atom(s) is max ID of all current atoms plus one
- next = atom ID for new atom(s) increments by one for every deposition
- *global* values = lo hi
- lo,hi = put new atom/molecule a distance lo-hi above all other atoms (distance units)
- *local* values = lo hi delta
- lo,hi = put new atom/molecule a distance lo-hi above any nearby atom beneath it (distance units)
- delta = lateral distance within which a neighbor is considered "nearby" (distance units)
- *near* value = R
- R = only insert atom/molecule if further than R from existing particles (distance units)
- *gaussian* values = xmid ymid zmid sigma
- xmid,ymid,zmid = center of the gaussian distribution (distance units)
- sigma = width of gaussian distribution (distance units)
- *attempt* value = Q
- Q = attempt a single insertion up to Q times
- *rate* value = V
- V = z velocity (y in 2d) at which insertion volume moves (velocity units)
- *vx* values = vxlo vxhi
- vxlo,vxhi = range of x velocities for inserted atom/molecule (velocity units)
- *vy* values = vylo vyhi
- vylo,vyhi = range of y velocities for inserted atom/molecule (velocity units)
- *vz* values = vzlo vzhi
- vzlo,vzhi = range of z velocities for inserted atom/molecule (velocity units)
- *target* values = tx ty tz
- tx,ty,tz = location of target point (distance units)
- *mol* value = template-ID
- template-ID = ID of molecule template specified in a separate :doc:`molecule <molecule>` command
- *molfrac* values = f1 f2 ... fN
- f1 to fN = relative probability of creating each of N molecules in template-ID
- *rigid* value = fix-ID
- fix-ID = ID of :doc:`fix rigid/small <fix_rigid>` command
- *shake* value = fix-ID
- fix-ID = ID of :doc:`fix shake <fix_shake>` command
- *units* value = *lattice* or *box*
- lattice = the geometry is defined in lattice units
- box = the geometry is defined in simulation box units
-
-
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- fix 3 all deposit 1000 2 100 29494 region myblock local 1.0 1.0 1.0 units box
- fix 2 newatoms deposit 10000 1 500 12345 region disk near 2.0 vz -1.0 -0.8
- fix 4 sputter deposit 1000 2 500 12235 region sphere vz -1.0 -1.0 target 5.0 5.0 0.0 units lattice
- fix 5 insert deposit 200 2 100 777 region disk gaussian 5.0 5.0 9.0 1.0 units box
-
-Description
-"""""""""""
-
-Insert a single atom or molecule into the simulation domain every M
-timesteps until N atoms or molecules have been inserted. This is
-useful for simulating deposition onto a surface. For the remainder of
-this doc page, a single inserted atom or molecule is referred to as a
-"particle".
-
-If inserted particles are individual atoms, they are assigned the
-specified atom type. If they are molecules, the type of each atom in
-the inserted molecule is specified in the file read by the
-:doc:`molecule <molecule>` command, and those values are added to the
-specified atom type. E.g. if the file specifies atom types 1,2,3, and
-those are the atom types you want for inserted molecules, then specify
-*type* = 0. If you specify *type* = 2, the in the inserted molecule
-will have atom types 3,4,5.
-
-All atoms in the inserted particle are assigned to two groups: the
-default group "all" and the group specified in the fix deposit command
-(which can also be "all").
-
-If you are computing temperature values which include inserted
-particles, you will want to use the
-:doc:`compute_modify <compute_modify>` dynamic option, which insures the
-current number of atoms is used as a normalizing factor each time the
-temperature is computed.
-
-Care must be taken that inserted particles are not too near existing
-atoms, using the options described below. When inserting particles
-above a surface in a non-periodic box (see the
-:doc:`boundary <boundary>` command), the possibility of a particle
-escaping the surface and flying upward should be considered, since the
-particle may be lost or the box size may grow infinitely large. A
-:doc:`fix wall/reflect <fix_wall_reflect>` command can be used to
-prevent this behavior. Note that if a shrink-wrap boundary is used,
-it is OK to insert the new particle outside the box, however the box
-will immediately be expanded to include the new particle. When
-simulating a sputtering experiment it is probably more realistic to
-ignore those atoms using the :doc:`thermo_modify <thermo_modify>`
-command with the *lost ignore* option and a fixed
-:doc:`boundary <boundary>`.
-
-The fix deposit command must use the *region* keyword to define an
-insertion volume. The specified region must have been previously
-defined with a :doc:`region <region>` command. It must be defined with
-side = *in*\ .
-
-.. note::
-
- LAMMPS checks that the specified region is wholly inside the
- simulation box. It can do this correctly for orthonormal simulation
- boxes. However for :ref:`triclinic boxes <howto_12>`, it
- only tests against the larger orthonormal box that bounds the tilted
- simulation box. If the specified region includes volume outside the
- tilted box, then an insertion will likely fail, leading to a "lost
- atoms" error. Thus for triclinic boxes you should insure the
- specified region is wholly inside the simulation box.
-
-The locations of inserted particles are taken from uniform distributed
-random numbers, unless the *gaussian* keyword is used. Then the
-individual coordinates are taken from a gaussian distribution of
-width *sigma* centered on *xmid,ymid,zmid*\ .
-
-Individual atoms are inserted, unless the *mol* keyword is used. It
-specifies a *template-ID* previously defined using the
-:doc:`molecule <molecule>` command, which reads files that define one or
-more molecules. The coordinates, atom types, charges, etc, as well as
-any bond/angle/etc and special neighbor information for the molecule
-can be specified in the molecule file. See the
-:doc:`molecule <molecule>` command for details. The only settings
-required to be in each file are the coordinates and types of atoms in
-the molecule.
-
-If the molecule template contains more than one molecule, the relative
-probability of depositing each molecule can be specified by the
-*molfrac* keyword. N relative probablities, each from 0.0 to 1.0, are
-specified, where N is the number of molecules in the template. Each
-time a molecule is deposited, a random number is used to sample from
-the list of relative probabilities. The N values must sum to 1.0.
-
-If you wish to insert molecules via the *mol* keyword, that will be
-treated as rigid bodies, use the *rigid* keyword, specifying as its
-value the ID of a separate :doc:`fix rigid/small <fix_rigid_small>`
-command which also appears in your input script.
-
-If you wish to insert molecules via the *mol* keyword, that will have
-their bonds or angles constrained via SHAKE, use the *shake* keyword,
-specifying as its value the ID of a separate :doc:`fix shake <fix_shake>` command which also appears in your input script.
-
-Each timestep a particle is inserted, the coordinates for its atoms
-are chosen as follows. For insertion of individual atoms, the
-"position" referred to in the following description is the coordinate
-of the atom. For insertion of molecule, the "position" is the
-geometric center of the molecule; see the :doc:`molecule <molecule>` doc
-page for details. A random rotation of the molecule around its center
-point is performed, which determines the coordinates all the
-individual atoms.
-
-A random position within the region insertion volume is generated. If
-neither the *global* or *local* keyword is used, the random position
-is the trial position. If the *global* keyword is used, the random
-x,y values are used, but the z position of the new particle is set
-above the highest current atom in the simulation by a distance
-randomly chosen between lo/hi. (For a 2d simulation, this is done for
-the y position.) If the *local* keyword is used, the z position is
-set a distance between lo/hi above the highest current atom in the
-simulation that is "nearby" the chosen x,y position. In this context,
-"nearby" means the lateral distance (in x,y) between the new and old
-particles is less than the *delta* setting.
-
-Once a trial x,y,z position has been selected, the insertion is only
-performed if no current atom in the simulation is within a distance R
-of any atom in the new particle, including the effect of periodic
-boundary conditions if applicable. R is defined by the *near*
-keyword. Note that the default value for R is 0.0, which will allow
-atoms to strongly overlap if you are inserting where other atoms are
-present. This distance test is performed independently for each atom
-in an inserted molecule, based on the randomly rotated configuration
-of the molecule. If this test fails, a new random position within the
-insertion volume is chosen and another trial is made. Up to Q
-attempts are made. If the particle is not successfully inserted,
-LAMMPS prints a warning message.
-
-.. note::
-
- If you are inserting finite size particles or a molecule or
- rigid body consisting of finite-size particles, then you should
- typically set R larger than the distance at which any inserted
- particle may overlap with either a previouly inserted particle or an
- existing particle. LAMMPS will issue a warning if R is smaller than
- this value, based on the radii of existing and inserted particles.
-
-The *rate* option moves the insertion volume in the z direction (3d)
-or y direction (2d). This enables particles to be inserted from a
-successively higher height over time. Note that this parameter is
-ignored if the *global* or *local* keywords are used, since those
-options choose a z-coordinate for insertion independently.
-
-The vx, vy, and vz components of velocity for the inserted particle
-are set using the values specified for the *vx*\ , *vy*\ , and *vz*
-keywords. Note that normally, new particles should be a assigned a
-negative vertical velocity so that they move towards the surface. For
-molecules, the same velocity is given to every particle (no rotation
-or bond vibration).
-
-If the *target* option is used, the velocity vector of the inserted
-particle is changed so that it points from the insertion position
-towards the specified target point. The magnitude of the velocity is
-unchanged. This can be useful, for example, for simulating a
-sputtering process. E.g. the target point can be far away, so that
-all incident particles strike the surface as if they are in an
-incident beam of particles at a prescribed angle.
-
-The *id* keyword determines how atom IDs and molecule IDs are assigned
-to newly deposited particles. Molecule IDs are only assigned if
-molecules are being inserted. For the *max* setting, the atom and
-molecule IDs of all current atoms are checked. Atoms in the new
-particle are assigned IDs starting with the current maximum plus one.
-If a molecule is inserted it is assigned an ID = current maximum plus
-one. This means that if particles leave the system, the new IDs may
-replace the lost ones. For the *next* setting, the maximum ID of any
-atom and molecule is stored at the time the fix is defined. Each time
-a new particle is added, this value is incremented to assign IDs to
-the new atom(s) or molecule. Thus atom and molecule IDs for deposited
-particles will be consecutive even if particles leave the system over
-time.
-
-The *units* keyword determines the meaning of the distance units used
-for the other deposition parameters. 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 affects all the keyword values that have
-units of distance or velocity.
-
-.. note::
-
- If you are monitoring the temperature of a system where the atom
- count is changing due to adding particles, you typically should use
- the :doc:`compute_modify dynamic yes <compute_modify>` command for the
- temperature compute you are using.
-
-Restart, fix_modify, output, run start/stop, minimize info
- fix ID group-ID lb/fluid nevery LBtype viscosity density keyword values ...
-
-* ID, group-ID are documented in :doc:`fix <fix>` command
-* lb/fluid = style name of this fix command
-* nevery = update the lattice-Boltzmann fluid every this many timesteps
-* LBtype = 1 to use the standard finite difference LB integrator,
- 2 to use the LB integrator of :ref:`Ollila et al. <Ollila>`
-* viscosity = the fluid viscosity (units of mass/(time*length)).
-* density = the fluid density.
-* zero or more keyword/value pairs may be appended
-* keyword = *setArea* or *setGamma* or *scaleGamma* or *dx* or *dm* or *a0* or *noise* or *calcforce* or *trilinear* or *D3Q19* or *read_restart* or *write_restart* or *zwall_velocity* or *bodyforce* or *printfluid*
-.. parsed-literal::
-
- *setArea* values = type node_area
- type = atom type (1-N)
- node_area = portion of the surface area of the composite object associated with the particular atom type (used when the force coupling constant is set by default).
- *setGamma* values = gamma
- gamma = user set value for the force coupling constant.
- *scaleGamma* values = type gammaFactor
- type = atom type (1-N)
- gammaFactor = factor to scale the *setGamma* gamma value by, for the specified atom type.
- *dx* values = dx_LB = the lattice spacing.
- *dm* values = dm_LB = the lattice-Boltzmann mass unit.
- *a0* values = a_0_real = the square of the speed of sound in the fluid.
- *noise* values = Temperature seed
- Temperature = fluid temperature.
- seed = random number generator seed (positive integer)
- *calcforce* values = N forcegroup-ID
- N = output the force and torque every N timesteps
- forcegroup-ID = ID of the particle group to calculate the force and torque of
- *trilinear* values = none (used to switch from the default Peskin interpolation stencil to the trilinear stencil).
- *D3Q19* values = none (used to switch from the default D3Q15, 15 velocity lattice, to the D3Q19, 19 velocity lattice).
- *read_restart* values = restart file = name of the restart file to use to restart a fluid run.
- *write_restart* values = N = write a restart file every N MD timesteps.
- *zwall_velocity* values = velocity_bottom velocity_top = velocities along the y-direction of the bottom and top walls (located at z=zmin and z=zmax).
- *bodyforce* values = bodyforcex bodyforcey bodyforcez = the x,y and z components of a constant body force added to the fluid.
- *printfluid* values = N = print the fluid density and velocity at each grid point every N timesteps.
-Implement a lattice-Boltzmann fluid on a uniform mesh covering the LAMMPS
-simulation domain. The MD particles described by *group-ID* apply a velocity
-dependent force to the fluid.
-
-The lattice-Boltzmann algorithm solves for the fluid motion governed by
-the Navier Stokes equations,
-
-.. image:: Eqs/fix_lb_fluid_navierstokes.jpg
- :align: center
-
-with,
-
-.. image:: Eqs/fix_lb_fluid_viscosity.jpg
- :align: center
-
-where rho is the fluid density, u is the local fluid velocity, sigma
-is the stress tensor, F is a local external force, and eta and Lambda
-are the shear and bulk viscosities respectively. Here, we have
-implemented
-
-.. image:: Eqs/fix_lb_fluid_stress.jpg
- :align: center
-
-with a_0 set to 1/3 (dx/dt)^2 by default.
-
-The algorithm involves tracking the time evolution of a set of partial
-distribution functions which evolve according to a velocity
-discretized version of the Boltzmann equation,
-
-.. image:: Eqs/fix_lb_fluid_boltzmann.jpg
- :align: center
-
-where the first term on the right hand side represents a single time
-relaxation towards the equilibrium distribution function, and tau is a
-parameter physically related to the viscosity. On a technical note,
-we have implemented a 15 velocity model (D3Q15) as default; however,
-the user can switch to a 19 velocity model (D3Q19) through the use of
-the *D3Q19* keyword. This fix provides the user with the choice of
-two algorithms to solve this equation, through the specification of
-the keyword *LBtype*\ . If *LBtype* is set equal to 1, the standard
-finite difference LB integrator is used. If *LBtype* is set equal to
-2, the algorithm of :ref:`Ollila et al. <Ollila>` is used.
-
-Physical variables are then defined in terms of moments of the distribution
-functions,
-
-.. image:: Eqs/fix_lb_fluid_properties.jpg
- :align: center
-
-Full details of the lattice-Boltzmann algorithm used can be found in
-:ref:`Mackay et al. <fluid-Mackay>`.
-
-The fluid is coupled to the MD particles described by *group-ID*
-through a velocity dependent force. The contribution to the fluid
-force on a given lattice mesh site j due to MD particle alpha is
-calculated as:
-
-.. image:: Eqs/fix_lb_fluid_fluidforce.jpg
- :align: center
-
-where v_n is the velocity of the MD particle, u_f is the fluid
-velocity interpolated to the particle location, and gamma is the force
-coupling constant. Zeta is a weight assigned to the grid point,
-obtained by distributing the particle to the nearest lattice sites.
-For this, the user has the choice between a trilinear stencil, which
-provides a support of 8 lattice sites, or the immersed boundary method
-Peskin stencil, which provides a support of 64 lattice sites. While
-the Peskin stencil is seen to provide more stable results, the
-trilinear stencil may be better suited for simulation of objects close
-to walls, due to its smaller support. Therefore, by default, the
-Peskin stencil is used; however the user may switch to the trilinear
-stencil by specifying the keyword, *trilinear*\ .
-
-By default, the force coupling constant, gamma, is calculated according to
-
-.. image:: Eqs/fix_lb_fluid_gammadefault.jpg
- :align: center
-
-Here, m_v is the mass of the MD particle, m_u is a representative
-fluid mass at the particle location, and dt_collision is a collision
-time, chosen such that tau/dt_collision = 1 (see :ref:`Mackay and Denniston <Mackay2>` for full details). In order to calculate m_u, the
-fluid density is interpolated to the MD particle location, and
-multiplied by a volume, node_area*dx_lb, where node_area represents
-the portion of the surface area of the composite object associated
-with a given MD particle. By default, node_area is set equal to
-dx_lb*dx_lb; however specific values for given atom types can be set
-using the *setArea* keyword.
-
-The user also has the option of specifying their own value for the
-force coupling constant, for all the MD particles associated with the
-fix, through the use of the *setGamma* keyword. This may be useful
-when modelling porous particles. See :ref:`Mackay et al. <fluid-Mackay>` for a
-detailed description of the method by which the user can choose an
-appropriate gamma value.
-
-.. note::
-
- while this fix applies the force of the particles on the fluid,
- it does not apply the force of the fluid to the particles. When the
- force coupling constant is set using the default method, there is only
- one option to include this hydrodynamic force on the particles, and
- that is through the use of the :doc:`lb/viscous <fix_lb_viscous>` fix.
- This fix adds the hydrodynamic force to the total force acting on the
- particles, after which any of the built-in LAMMPS integrators can be
- used to integrate the particle motion. However, if the user specifies
- their own value for the force coupling constant, as mentioned in
- :ref:`Mackay et al. <fluid-Mackay>`, the built-in LAMMPS integrators may prove to
- be unstable. Therefore, we have included our own integrators :doc:`fix lb/rigid/pc/sphere <fix_lb_rigid_pc_sphere>`, and :doc:`fix lb/pc <fix_lb_pc>`, to solve for the particle motion in these
- cases. These integrators should not be used with the
- :doc:`lb/viscous <fix_lb_viscous>` fix, as they add hydrodynamic forces
- to the particles directly. In addition, they can not be used if the
- force coupling constant has been set the default way.
-
-.. note::
-
- if the force coupling constant is set using the default method,
- and the :doc:`lb/viscous <fix_lb_viscous>` fix is NOT used to add the
- hydrodynamic force to the total force acting on the particles, this
- physically corresponds to a situation in which an infinitely massive
- particle is moving through the fluid (since collisions between the
- particle and the fluid do not act to change the particle's velocity).
- Therefore, the user should set the mass of the particle to be
- significantly larger than the mass of the fluid at the particle
- location, in order to approximate an infinitely massive particle (see
- the dragforce test run for an example).
-
-
-----------
-
-
-Inside the fix, parameters are scaled by the lattice-Boltzmann
-timestep, dt, grid spacing, dx, and mass unit, dm. dt is set equal to
-(nevery*dt_MD), where dt_MD is the MD timestep. By default, dm is set
-equal to 1.0, and dx is chosen so that tau/(dt) =
-(3*eta*dt)/(rho*dx^2) is approximately equal to 1. However, the user
-has the option of specifying their own values for dm, and dx, by using
-the optional keywords *dm*\ , and *dx* respectively.
-
-.. note::
-
- Care must be taken when choosing both a value for dx, and a
- simulation domain size. This fix uses the same subdivision of the
- simulation domain among processors as the main LAMMPS program. In
- order to uniformly cover the simulation domain with lattice sites, the
- lengths of the individual LAMMPS subdomains must all be evenly
- divisible by dx. If the simulation domain size is cubic, with equal
- lengths in all dimensions, and the default value for dx is used, this
- will automatically be satisfied.
-
-Physical parameters describing the fluid are specified through
-*viscosity*\ , *density*\ , and *a0*\ . If the force coupling constant is
-set the default way, the surface area associated with the MD particles
-is specified using the *setArea* keyword. If the user chooses to
-specify a value for the force coupling constant, this is set using the
-*setGamma* keyword. These parameters should all be given in terms of
-the mass, distance, and time units chosen for the main LAMMPS run, as
-they are scaled by the LB timestep, lattice spacing, and mass unit,
-inside the fix.
-
-
-----------
-
-
-The *setArea* keyword allows the user to associate a surface area with
-a given atom type. For example if a spherical composite object of
-radius R is represented as a spherical shell of N evenly distributed
-MD particles, all of the same type, the surface area per particle
-associated with that atom type should be set equal to 4*pi*R^2/N.
-This keyword should only be used if the force coupling constant,
-gamma, is set the default way.
-
-The *setGamma* keyword allows the user to specify their own value for
-the force coupling constant, gamma, instead of using the default
-value.
-
-The *scaleGamma* keyword should be used in conjunction with the
-*setGamma* keyword, when the user wishes to specify different gamma
-values for different atom types. This keyword allows the user to
-scale the *setGamma* gamma value by a factor, gammaFactor, for a given
-atom type.
-
-The *dx* keyword allows the user to specify a value for the LB grid
-spacing.
-
-The *dm* keyword allows the user to specify the LB mass unit.
-
-If the *a0* keyword is used, the value specified is used for the
-square of the speed of sound in the fluid. If this keyword is not
-present, the speed of sound squared is set equal to (1/3)*(dx/dt)^2.
-Setting a0 > (dx/dt)^2 is not allowed, as this may lead to
-instabilities.
-
-If the *noise* keyword is used, followed by a a positive temperature
-value, and a positive integer random number seed, a thermal
-lattice-Boltzmann algorithm is used. If *LBtype* is set equal to 1
-(i.e. the standard LB integrator is chosen), the thermal LB algorithm
-of :ref:`Adhikari et al. <Adhikari>` is used; however if *LBtype* is set
-equal to 2 both the LB integrator, and thermal LB algorithm described
-in :ref:`Ollila et al. <Ollila>` are used.
-
-If the *calcforce* keyword is used, both the fluid force and torque
-acting on the specified particle group are printed to the screen every
-N timesteps.
-
-If the keyword *trilinear* is used, the trilinear stencil is used to
-interpolate the particle nodes onto the fluid mesh. By default, the
-immersed boundary method, Peskin stencil is used. Both of these
-interpolation methods are described in :ref:`Mackay et al. <fluid-Mackay>`.
-
-If the keyword *D3Q19* is used, the 19 velocity (D3Q19) lattice is
-used by the lattice-Boltzmann algorithm. By default, the 15 velocity
-(D3Q15) lattice is used.
-
-If the keyword *write_restart* is used, followed by a positive
-integer, N, a binary restart file is printed every N LB timesteps.
-This restart file only contains information about the fluid.
-Therefore, a LAMMPS restart file should also be written in order to
-print out full details of the simulation.
-
-.. note::
-
- When a large number of lattice grid points are used, the restart
- files may become quite large.
-
-In order to restart the fluid portion of the simulation, the keyword
-*read_restart* is specified, followed by the name of the binary
-lb_fluid restart file to be used.
-
-If the *zwall_velocity* keyword is used y-velocities are assigned to
-the lower and upper walls. This keyword requires the presence of
-walls in the z-direction. This is set by assigning fixed boundary
-conditions in the z-direction. If fixed boundary conditions are
-present in the z-direction, and this keyword is not used, the walls
-are assumed to be stationary.
-
-If the *bodyforce* keyword is used, a constant body force is added to
-the fluid, defined by it's x, y and z components.
-
-If the *printfluid* keyword is used, followed by a positive integer, N,
-the fluid densities and velocities at each lattice site are printed to the
-screen every N timesteps.
-
-
-----------
-
-
-For further details, as well as descriptions and results of several
-test runs, see :ref:`Mackay et al. <fluid-Mackay>`. Please include a citation to
-this paper if the lb_fluid fix is used in work contributing to
-published research.
-
-
-----------
-
-
-Restart, fix_modify, output, run start/stop, minimize info
-Due to the large size of the fluid data, this fix writes it's own
-binary restart files, if requested, independent of the main LAMMPS
-:doc:`binary restart files <restart>`; no information about *lb_fluid*
-is written to the main LAMMPS :doc:`binary restart files <restart>`.
-
-None of the :doc:`fix_modify <fix_modify>` options are relevant to this
-fix. No global or per-atom quantities are stored by this fix for
-access by various :ref:`output commands <howto_15>`. No
-parameter of this fix can be used with the *start/stop* keywords of
-the :doc:`run <run>` command. This fix is not invoked during :doc:`energy minimization <minimize>`.
-
-Restrictions
-""""""""""""
-
-
-This fix is part of the USER-LB package. It is only enabled if LAMMPS
-was built with that package. See the :ref:`Making LAMMPS <start_3>` section for more info.
-
-This fix can only be used with an orthogonal simulation domain.
-
-Walls have only been implemented in the z-direction. Therefore, the
-boundary conditions, as specified via the main LAMMPS boundary command
-must be periodic for x and y, and either fixed or periodic for z.
-Shrink-wrapped boundary conditions are not permitted with this fix.
-
-This fix must be used before any of :doc:`fix lb/viscous <fix_lb_viscous>`, :doc:`fix lb/momentum <fix_lb_momentum>`, :doc:`fix lb/rigid/pc/sphere <fix_lb_rigid_pc_sphere>`, and/ or :doc:`fix lb/pc <fix_lb_pc>` , as the fluid needs to be initialized before
-any of these routines try to access its properties. In addition, in
-order for the hydrodynamic forces to be added to the particles, this
-fix must be used in conjunction with the
-:doc:`lb/viscous <fix_lb_viscous>` fix if the force coupling constant is
-set by default, or either the :doc:`lb/viscous <fix_lb_viscous>` fix or
-one of the :doc:`lb/rigid/pc/sphere <fix_lb_rigid_pc_sphere>` or
-:doc:`lb/pc <fix_lb_pc>` integrators, if the user chooses to specifiy
-By default, the force coupling constant is set according to
-
-.. image:: Eqs/fix_lb_fluid_gammadefault.jpg
- :align: center
-
-and an area of dx_lb^2 per node, used to calculate the fluid mass at
-the particle node location, is assumed.
-
-dx is chosen such that tau/(delta t_LB) =
-(3 eta dt_LB)/(rho dx_lb^2) is approximately equal to 1.
-dm is set equal to 1.0.
-a0 is set equal to (1/3)*(dx_lb/dt_lb)^2.
-The Peskin stencil is used as the default interpolation method.
-The D3Q15 lattice is used for the lattice-Boltzmann algorithm.
-If walls are present, they are assumed to be stationary.
-
-
-----------
-
-
-.. _Ollila:
-
-
-
-**(Ollila et al.)** Ollila, S.T.T., Denniston, C., Karttunen, M., and Ala-Nissila, T., Fluctuating lattice-Boltzmann model for complex fluids, J. Chem. Phys. 134 (2011) 064902.
-
-.. _fluid-Mackay:
-
-
-
-**(Mackay et al.)** Mackay, F. E., Ollila, S.T.T., and Denniston, C., Hydrodynamic Forces Implemented into LAMMPS through a lattice-Boltzmann fluid, Computer Physics Communications 184 (2013) 2021-2031.
-
-.. _Mackay2:
-
-
-
-**(Mackay and Denniston)** Mackay, F. E., and Denniston, C., Coupling MD particles to a lattice-Boltzmann fluid through the use of conservative forces, J. Comput. Phys. 237 (2013) 289-298.
-
-.. _Adhikari:
-
-
-
-**(Adhikari et al.)** Adhikari, R., Stratford, K., Cates, M. E., and Wagner, A. J., Fluctuating lattice Boltzmann, Europhys. Lett. 71 (2005) 473-479.
-**(Mackay et al.)** Mackay, F. E., Ollila, S.T.T., and Denniston, C., Hydrodynamic Forces Implemented into LAMMPS through a lattice-Boltzmann fluid, Computer Physics Communications 184 (2013) 2021-2031.
-The defaults are force * on on on, and torque * on on on.
-
-
-----------
-
-
-.. _Mackay:
-
-
-
-**(Mackay et al.)** Mackay, F. E., Ollila, S.T.T., and Denniston, C., Hydrodynamic Forces Implemented into LAMMPS through a lattice-Boltzmann fluid, Computer Physics Communications 184 (2013) 2021-2031.
-* ID, group-ID are documented in :doc:`fix <fix>` command
-* lb/viscous = style name of this fix command
-
-Examples
-""""""""
-
-fix 1 flow lb/viscous
-
-Description
-"""""""""""
-
-This fix is similar to the :doc:`fix viscous <fix_viscous>` command, and
-is to be used in place of that command when a lattice-Boltzmann fluid
-is present, and the user wishes to integrate the particle motion using
-one of the built in LAMMPS integrators.
-
-This fix adds a force, F = - Gamma*(velocity-fluid_velocity), to each
-atom, where Gamma is the force coupling constant described in the :doc:`fix lb/fluid <fix_lb_fluid>` command (which applies an equal and
-opposite force to the fluid).
-
-.. note::
-
- This fix should only be used in conjunction with one of the
- built in LAMMPS integrators; it should not be used with the :doc:`fix lb/pc <fix_lb_pc>` or :doc:`fix lb/rigid/pc/sphere <fix_lb_rigid_pc_sphere>` integrators, which
- already include the hydrodynamic forces. These latter fixes should
- only be used if the force coupling constant has been set by the user
- (instead of using the default value); if the default force coupling
- value is used, then this fix provides the only method for adding the
- hydrodynamic forces to the particles.
-
-
-----------
-
-
-For further details, as well as descriptions and results of several
-test runs, see :ref:`Mackay et al. <Mackay>`. Please include a citation to
-this paper if this fix is used in work contributing to published
-research.
-
-
-----------
-
-
-Restart, fix_modify, output, run start/stop, minimize info
-**(Mackay et al.)** Mackay, F. E., Ollila, S.T.T., and Denniston, C., Hydrodynamic Forces Implemented into LAMMPS through a lattice-Boltzmann fluid, Computer Physics Communications 184 (2013) 2021-2031.
-1. *dhugoniot* is the departure from the Hugoniot (temperature units).
-2. *drayleigh* is the departure from the Rayleigh line (pressure units).
-3. *lagrangian_speed* is the laboratory-frame Lagrangian speed (particle velocity) of the computational cell (velocity units).
-4. *lagrangian_position* is the computational cell position in the reference frame moving at the shock speed. This is usually a good estimate of distance of the computational cell behind the shock front.
-
-To print these quantities to the log file with descriptive column
-headers, the following LAMMPS commands are suggested:
-
-.. parsed-literal::
-
- fix msst all msst z
- fix_modify msst energy yes
- variable dhug equal f_msst[1]
- variable dray equal f_msst[2]
- variable lgr_vel equal f_msst[3]
- variable lgr_pos equal f_msst[4]
- thermo_style custom step temp ke pe lz pzz etotal v_dhug v_dray v_lgr_vel v_lgr_pos f_msst
-
-These fixes compute a global scalar and a global vector of 4
-quantities, which can be accessed by various :ref:`output commands <howto_15>`. The scalar values calculated
-by this fix are "extensive"; the vector values are "intensive".
-
-Restrictions
-""""""""""""
-
-
-This fix style is part of the SHOCK package. It is only enabled if
-LAMMPS was built with that package. See the :ref:`Making LAMMPS <start_3>` section for more info.
-
-All cell dimensions must be periodic. This fix can not be used with a
-triclinic cell. The MSST fix has been tested only for the group-ID
-* 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* or *dipole/dlm*
- dipole = update dipole orientation (only for sphere variants)
- dipole/dlm = use DLM integrator to 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
-* style_name = *nvt/eff* or *npt/eff* or *nph/eff*
-.. 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 *xy* or *yz* or *xz* or *couple* or *tchain* or *pchain* or *mtk* or *tloop* or *ploop* or *nreset* or *drag* or *dilate*
- *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 = 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*
-
-
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- fix 1 all nvt/eff temp 300.0 300.0 0.1
- fix 1 part npt/eff temp 300.0 300.0 0.1 iso 0.0 0.0 1.0
- fix 2 part npt/eff temp 300.0 300.0 0.1 tri 5.0 5.0 1.0
- fix 2 ice nph/eff x 1.0 1.0 0.5 y 2.0 2.0 0.5 z 3.0 3.0 0.5 yz 0.1 0.1 0.5 xz 0.2 0.2 0.5 xy 0.3 0.3 0.5 nreset 1000
-
-Description
-"""""""""""
-
-These commands perform time integration on Nose-Hoover style
-non-Hamiltonian equations of motion for nuclei and electrons in the
-group for the :doc:`electron force field <pair_eff>` model. The fixes
-are designed to generate positions and velocities sampled from the
-canonical (nvt), isothermal-isobaric (npt), and isenthalpic (nph)
-ensembles. This is achieved by adding some dynamic variables which
-are coupled to the particle velocities (thermostatting) and simulation
-domain dimensions (barostatting). In addition to basic thermostatting
-and barostatting, these fixes can also create a chain of thermostats
-coupled to the particle thermostat, and another chain of thermostats
-coupled to the barostat variables. The barostat can be coupled to the
-overall box volume, or to individual dimensions, including the *xy*\ ,
-*xz* and *yz* tilt dimensions. The external pressure of the barostat
-can be specified as either a scalar pressure (isobaric ensemble) or as
-components of a symmetric stress tensor (constant stress ensemble).
-When used correctly, the time-averaged temperature and stress tensor
-of the particles will match the target values specified by
-Tstart/Tstop and Pstart/Pstop.
-
-The operation of these fixes is exactly like that described by the
-:doc:`fix nvt, npt, and nph <fix_nh>` commands, except that the radius
-and radial velocity of electrons are also updated. Likewise the
-temperature and pressure calculated by the fix, using the computes it
-creates (as discussed in the :doc:`fix nvt, npt, and nph <fix_nh>`
-doc page), are performed with computes that include the eFF contribution
-to the temperature or kinetic energy from the electron radial velocity.
-
-.. note::
-
- there are two different pressures that can be reported for eFF
- when defining the pair_style (see :doc:`pair eff/cut <pair_eff_cut>` to
- understand these settings), one (default) that considers electrons do
- not contribute radial virial components (i.e. electrons treated as
- incompressible 'rigid' spheres) and one that does. The radial
- electronic contributions to the virials are only tallied if the
- flexible pressure option is set, and this will affect both global and
- per-atom quantities. In principle, the true pressure of a system is
- somewhere in between the rigid and the flexible eFF pressures, but,
- for most cases, the difference between these two pressures will not be
- significant over long-term averaged runs (i.e. even though the energy
- partitioning changes, the total energy remains similar).
-
-.. note::
-
- currently, there is no available option for the user to set or
- create temperature distributions that include the radial electronic
- degrees of freedom with the :doc:`velocity <velocity>` command, so the
- the user must allow for these degrees of freedom to equilibrate
- (i.e. equi-partitioning of energy) through time integration.
-
-Restart, fix_modify, output, run start/stop, minimize info
-* 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:
-This fix combines the RATTLE-based :ref:`(Andersen) <Andersen>` time integrator of :doc:`fix nve/manifold/rattle <fix_nve_manifold_rattle>` :ref:`(Paquay) <Paquay>` with a Nose-Hoover-chain thermostat to sample the
-canonical ensemble of particles constrained to a curved surface (manifold). This sampling does suffer from discretization bias of O(dt).
-For a list of currently supported manifolds and their parameters, see :doc:`manifolds <manifolds>`
-
-
-----------
-
-
-Restart, fix_modify, output, run start/stop, minimize info
- fix ID group-ID property/atom vec1 vec2 ... keyword value ...
-
-* ID, group-ID are documented in :doc:`fix <fix>` command
-* property/atom = style name of this fix command
-* vec1,vec2,... = *mol* or *q* or *rmass* or *i_name* or *d_name*
-.. parsed-literal::
-
- *mol* = molecule IDs
- *q* = charge
- *rmass* = per-atom mass
- *i_name* = new integer vector referenced by name
- *d_name* = new floating-point vector referenced by name
-
-* zero of more keyword/value pairs may be appended
-* keyword = *ghost*
-.. parsed-literal::
-
- *ghost* value = *no* or *yes* for whether ghost atom info in communicated
-
-
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- fix 1 all property/atom mol
- fix 1 all property/atom i_myflag1 i_myflag2
- fix 1 all property/atom d_sx d_sy d_sz
-
-Description
-"""""""""""
-
-Create one or more additional per-atom vectors to store information
-about atoms and to use during a simulation. The specified *group-ID*
-is ignored by this fix.
-
-The atom style used for a simulation defines a set of per-atom
-properties, as explained on the :doc:`atom_style <atom_style>` and
-:doc:`read_data <read_data>` doc pages. The latter command allows these
-properties to be defined for each atom in the system when a data file
-is read. This fix will augment the set of properties with new custom
-ones. This can be useful in several scenarios.
-
-If the atom style does not define molecule IDs, per-atom charge,
-or per-atom mass, they can be added using the *mol*\ , *q* or *rmass*
-keywords. This can be useful, e.g, to define "molecules" to use as
-rigid bodies with the :doc:`fix rigid <fix_rigid>` command, or just to
-carry around an extra flag with the atoms (stored as a molecule ID)
-that can be used to group atoms without having to use the group
-command (which is limited to a total of 32 groups including *all*\ ).
-
-Another application would be to use the *rmass* flag in order to have
-per-atom masses instead of per-type masses, for example this can be
-useful to study isotope effects with partial isotope substitution.
-Please :ref:`see below <isotopes>` for an example of simulating a mixture
-of light and heavy water with the TIP4P water potential.
-
-An alternative to using fix *property/atom* in these ways is to
-use an atom style that does define molecule IDs or charge or per-atom
-mass (indirectly via diameter and density) or to use a hybrid atom
-style that combines two or more atom styles
-to provide the union of all atom properties. However, this has two
-practical drawbacks: first, it typically necessitates changing the
-format of the data file, which can be tedious for large systems;
-and second, it may define additional properties that are not needed
-such as bond lists, which has some overhead when there are no bonds.
-
-In the future, we may add additional per-atom properties similar to
-*mol*\ , *q* or *rmass*\ , which "turn-on" specific properties defined
-by some atom styles, so they can be used by atom styles that do not
-define them.
-
-More generally, the *i_name* and *d_name* vectors allow one or more
-new custom per-atom properties to be defined. Each name must be
-unique and can use alphanumeric or underscore characters. These
-vectors can store whatever values you decide are useful in your
-simulation. As explained below there are several ways to initialize
-and access and output these values, both via input script commands and
-in new code that you add to LAMMPS.
-
-This is effectively a simple way to add per-atom properties to a model
-without needing to write code for a new :doc:`atom style <atom_style>`
-that defines the properties. Note however that implementing a new
-atom style allows new atom properties to be more tightly and
-seamlessly integrated with the rest of the code.
-
-The new atom properties encode values that migrate with atoms to new
-processors and are written to restart files. If you want the new
-properties to also be defined for ghost atoms, then use the *ghost*
-keyword with a value of *yes*\ . This will invoke extra communication
-when ghost atoms are created (at every re-neighboring) to insure the
-new properties are also defined for the ghost atoms.
-
-.. note::
-
- If you use this command with the *mol*\ , *q* or *rmass* vectors,
- then you most likely want to set *ghost* yes, since these properties
- are stored with ghost atoms if you use an :doc:`atom_style <atom_style>`
- that defines them, and many LAMMPS operations that use molecule IDs or
- charge, such as neighbor lists and pair styles, will expect ghost
- atoms to have these valuse. LAMMPS will issue a warning it you define
- those vectors but do not set *ghost* yes.
-
-.. note::
-
- The properties for ghost atoms are not updated every timestep,
- but only once every few steps when neighbor lists are re-built. Thus
- the *ghost* keyword is suitable for static properties, like molecule
- IDs, but not for dynamic properties that change every step. For the
- latter, the code you add to LAMMPS to change the properties will also
- need to communicate their new values to/from ghost atoms, an operation
- that can be invoked from within a :doc:`pair style <pair_style>` or
- :doc:`fix <fix>` or :doc:`compute <compute>` that you write.
-
-
-----------
-
-
-This fix is one of a small number that can be defined in an input
-script before the simulation box is created or atoms are defined.
-This is so it can be used with the :doc:`read_data <read_data>` command
-as described below.
-
-Per-atom properties that are defined by the :doc:`atom style <atom_style>` are initialized when atoms are created, e.g. by
-the :doc:`read_data <read_data>` or :doc:`create_atoms <create_atoms>`
-commands. The per-atom properaties defined by this fix are not. So
-you need to initialize them explicitly. This can be done by the
-:doc:`read_data <read_data>` command, using its *fix* keyword and
-passing it the fix-ID of this fix.
-
-Thus these commands:
-
-.. parsed-literal::
-
- fix prop all property/atom mol d_flag
- read_data data.txt fix prop NULL Molecules
-
-would allow a data file to have a section like this:
-
-.. parsed-literal::
-
- Molecules
-
-.. parsed-literal::
-
- 1 4 1.5
- 2 4 3.0
- 3 10 1.0
- 4 10 1.0
- 5 10 1.0
- ...
- N 763 4.5
-
-where N is the number of atoms, and the first field on each line is
-the atom-ID, followed by a molecule-ID and a floating point value that
-will be stored in a new property called "flag". Note that the list of
-per-atom properties can be in any order.
-
-Another way of initializing the new properties is via the
-:doc:`set <set>` command. For example, if you wanted molecules
-defined for every set of 10 atoms, based on their atom-IDs,
-these commands could be used:
-
-.. parsed-literal::
-
- fix prop all property/atom mol
- variable cluster atom ((id-1)/10)+1
- set id * mol v_cluster
-
-The :doc:`atom-style variable <variable>` will create values for atoms
-with IDs 31,32,33,...40 that are 4.0,4.1,4.2,...,4.9. When the
-:doc:`set <set>` commands assigns them to the molecule ID for each atom,
-they will be truncated to an integer value, so atoms 31-40 will all be
-assigned a molecule ID of 4.
-
-Note that :doc:`atomfile-style variables <variable>` can also be used in
-place of atom-style variables, which means in this case that the
-molecule IDs could be read-in from a separate file and assinged by the
-:doc:`set <set>` command. This allows you to initialize new per-atom
-properties in a completely general fashion.
-
-
-----------
-
-
-For new atom properties specified as *i_name* or *d_name*\ , the
-:doc:`compute property/atom <compute_property_atom>` command can access
-their values. This means that the values can be output via the :doc:`dump custom <dump>` command, accessed by fixes like :doc:`fix ave/atom <fix_ave_atom>`, accessed by other computes like :doc:`compute reduce <compute_reduce>`, or used in `atom-style variables <variables>`_.
-
-For example, these commands will output two new properties to a custom
-dump file:
-
-.. parsed-literal::
-
- fix prop all property/atom i_flag1 d_flag2
- compute 1 all property/atom i_flag1 d_flag2
- dump 1 all custom 100 tmp.dump id x y z c_1[1] c_1[2]
-
-
-----------
-
-
-If you wish to add new :doc:`pair styles <pair_style>`,
-:doc:`fixes <fix>`, or :doc:`computes <compute>` that use the per-atom
-properties defined by this fix, see :ref:`Section modify <mod_1>` of the manual which has some details
-on how the properties can be accessed from added classes.
-
-
-----------
-
-
-.. _isotopes:
-
-
-
-Example for using per-atom masses with TIP4P water to study isotope
-effects. When setting up simulations with the :ref:`TIP4P pair styles <howto_8>` for water, you have to provide
-exactly one atom type each to identify the water oxygen and hydrogen
-atoms. Since the atom mass is normally tied to the atom type, this
-makes it impossible to study multiple isotopes in the same simulation.
-With *fix property/atom rmass* however, the per-type masses are
-replaced by per-atom masses. Asumming you have a working input deck
-for regular TIP4P water, where water oxygen is atom type 1 and
-water hydrogen is atom type 2, the following lines of input script
-convert this to using per-atom masses:
-
-.. parsed-literal::
-
- fix Isotopes all property/atom rmass ghost yes
- set type 1 mass 15.9994
- set type 2 mass 1.008
-
-When writing out the system data with the :doc:`write_data <write_data>`
-command, there will be a new section named with the fix-ID
-(i.e. *Isotopes* in this case). Alternatively, you can take an
-existing data file and just add this *Isotopes* section with
-one line per atom containing atom-ID and mass. Either way, the
-* zero or more keyword/value pairs may be appended
-* keyword = *q* or *mu* or *p0* or *v0* or *e0* or *tscale* or *damp* or *seed*\ or *f_max* or *N_f* or *eta* or *beta* or *T_init*
-.. parsed-literal::
-
- *q* value = cell mass-like parameter (mass^2/distance^4 units)
- *mu* value = artificial viscosity (mass/distance/time units)
- *p0* value = initial pressure in the shock equations (pressure units)
- *v0* value = initial simulation cell volume in the shock equations (distance^3 units)
- *e0* value = initial total energy (energy units)
- *tscale* value = reduction in initial temperature (unitless fraction between 0.0 and 1.0)
- *damp* value = damping parameter (time units) inverse of friction <i>γ</i>
- *seed* value = random number seed (positive integer)
- *f_max* value = upper cutoff frequency of the vibration spectrum (1/time units)
- *N_f* value = number of frequency bins (positive integer)
- *eta* value = coupling constant between the shock system and the quantum thermal bath (positive unitless)
- *beta* value = the quantum temperature is updated every beta time steps (positive integer)
- *T_init* value = quantum temperature for the initial state (temperature units)
-
-
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- fix 1 all qbmsst z 0.122 q 25 mu 0.9 tscale 0.01 damp 200 seed 35082 f_max 0.3 N_f 100 eta 1 beta 400 T_init 110 (liquid methane modeled with the REAX force field, real units)
- fix 2 all qbmsst z 72 q 40 tscale 0.05 damp 1 seed 47508 f_max 120.0 N_f 100 eta 1.0 beta 500 T_init 300 (quartz modeled with the BKS force field, metal units)
-
-Two example input scripts are given, including shocked alpha quartz
-and shocked liquid methane. The input script first equilibrate an
-initial state with the quantum thermal bath at the target temperature
-and then apply the qbmsst to simulate shock compression with quantum
-nuclear correction. The following two figures plot related quantities
-for shocked alpha quartz.
-
-.. image:: JPG/qbmsst_init.jpg
- :align: center
-
-Figure 1. Classical temperature <i>T</i><sup>cl</sup> = ∑
-<i>m<sub>i</sub>v<sub>i</sub><sup>2</sup>/3Nk</i><sub>B</sub> vs. time
-for coupling the alpha quartz initial state with the quantum thermal
-bath at target quantum temperature <i>T</i><sup>qm</sup> = 300 K. The
-NpH ensemble is used for time integration while QTB provides the
-colored random force. <i>T</i><sup>cl</sup> converges at the timescale
-of *damp* which is set to be 1 ps.
-
-.. image:: JPG/qbmsst_shock.jpg
- :align: center
-
-Figure 2. Quantum temperature and pressure vs. time for simulating
-shocked alpha quartz with the QBMSST. The shock propagates along the z
-direction. Restart of the QBMSST command is demonstrated in the
-example input script. Thermodynamic quantities stay continuous before
-and after the restart.
-
-Description
-"""""""""""
-
-This command performs the Quantum-Bath coupled Multi-Scale Shock
-Technique (QBMSST) integration. See :ref:`(Qi) <Qi>` for a detailed
-description of this method. The QBMSST provides description of the
-thermodynamics and kinetics of shock processes while incorporating
-quantum nuclear effects. The *shockvel* setting determines the steady
-shock velocity that will be simulated along direction *dir*\ .
-
-Quantum nuclear effects :doc:`(fix qtb) <fix_qtb>` can be crucial
-especially when the temperature of the initial state is below the
-classical limit or there is a great change in the zero point energies
-between the initial and final states. Theoretical post processing
-quantum corrections of shock compressed water and methane have been
-reported as much as 30% of the temperatures :ref:`(Goldman) <Goldman>`. A
-self-consistent method that couples the shock to a quantum thermal
-bath described by a colored noise Langevin thermostat has been
-developed by Qi et al :ref:`(Qi) <Qi>` and applied to shocked methane. The
-onset of chemistry is reported to be at a pressure on the shock
-Hugoniot that is 40% lower than observed with classical molecular
-dynamics.
-
-It is highly recommended that the system be already in an equilibrium
-state with a quantum thermal bath at temperature of *T_init*\ . The fix
-command :doc:`fix qtb <fix_qtb>` at constant temperature *T_init* could
-be used before applying this command to introduce self-consistent
-quantum nuclear effects into the initial state.
-
-The parameters *q*\ , *mu*\ , *e0*\ , *p0*\ , *v0* and *tscale* are described
-in the command :doc:`fix msst <fix_msst>`. The values of *e0*\ , *p0*\ , or
-*v0* will be calculated on the first step if not specified. The
-parameter of *damp*\ , *f_max*\ , and *N_f* are described in the command
-:doc:`fix qtb <fix_qtb>`.
-
-The fix qbmsst command couples the shock system to a quantum thermal
-bath with a rate that is proportional to the change of the total
-energy of the shock system, <i>etot</i> - <i>etot</i><sub>0</sub>.
-Here <i>etot</i> consists of both the system energy and a thermal
-term, see :ref:`(Qi) <Qi>`, and <i>etot</i><sub>0</sub> = *e0* is the
-initial total energy.
-
-The *eta* (<i>η</i>) parameter is a unitless coupling constant
-between the shock system and the quantum thermal bath. A small *eta*
-value cannot adjust the quantum temperature fast enough during the
-temperature ramping period of shock compression while large *eta*
-leads to big temperature oscillation. A value of *eta* between 0.3 and
-1 is usually appropriate for simulating most systems under shock
-compression. We observe that different values of *eta* lead to almost
-the same final thermodynamic state behind the shock, as expected.
-
-The quantum temperature is updated every *beta* (<i>β</i>) steps
-with an integration time interval *beta* times longer than the
-simulation time step. In that case, <i>etot</i> is taken as its
-average over the past *beta* steps. The temperature of the quantum
-thermal bath <i>T</i><sup>qm</sup> changes dynamically according to
-the following equation where Δ<i>t</i> is the MD time step and
-<i>γ</i> is the friction constant which is equal to the inverse
-1. *dhugoniot* is the departure from the Hugoniot (temperature units).
-2. *drayleigh* is the departure from the Rayleigh line (pressure units).
-3. *lagrangian_speed* is the laboratory-frame Lagrangian speed (particle velocity) of the computational cell (velocity units).
-4. *lagrangian_position* is the computational cell position in the reference frame moving at the shock speed. This is the distance of the computational cell behind the shock front.
-5. *quantum_temperature* is the temperature of the quantum thermal bath <i>T</i><sup>qm</sup>.
-
-To print these quantities to the log file with descriptive column
-headers, the following LAMMPS commands are suggested. Here the
-:doc:`fix_modify <fix_modify>` energy command is also enabled to allow
-the thermo keyword *etotal* to print the quantity <i>etot</i>. See
-also the :doc:`thermo_style <thermo_style>` command.
-
-.. parsed-literal::
-
- fix fix_id all msst z
- fix_modify fix_id energy yes
- variable dhug equal f_fix_id[1]
- variable dray equal f_fix_id[2]
- variable lgr_vel equal f_fix_id[3]
- variable lgr_pos equal f_fix_id[4]
- variable T_qm equal f_fix_id[5]
- thermo_style custom step temp ke pe lz pzz etotal v_dhug v_dray v_lgr_vel v_lgr_pos v_T_qm f_fix_id
-
-The global scalar under the entry f_fix_id is the quantity of thermo
-energy as an extra part of <i>etot</i>. This global scalar and the
-vector of 5 quantities can be accessed by various :ref:`output commands <howto_15>`. It is worth noting that the
-temp keyword under the :doc:`thermo_style <thermo_style>` command print
-the instantaneous classical temperature <i>T</i><sup>cl</sup> as
-described in the command :doc:`fix qtb <fix_qtb>`.
-
-
-----------
-
-
-Restrictions
-""""""""""""
-
-
-This fix style is part of the USER-QTB package. It is only enabled if
-LAMMPS was built with that package. See the :ref:`Making LAMMPS <start_3>` section for more info.
-
-All cell dimensions must be periodic. This fix can not be used with a
-triclinic cell. The QBMSST fix has been tested only for the group-ID
-Perform the charge equilibration (QEq) method as described in :ref:`(Rappe and Goddard) <Rappe>` and formulated in :ref:`(Nakano) <Nakano>` (also known
-as the matrix inversion method) and in :ref:`(Rick and Stuart) <Rick>` (also
-known as the extended Lagrangian method) based on the
-electronegativity equilization principle.
-
-These fixes can be used with any :doc:`pair style <pair_style>` in
-LAMMPS, so long as per-atom charges are defined. The most typical
-use-case is in conjunction with a :doc:`pair style <pair_style>` that
-performs charge equilibration periodically (e.g. every timestep), such
-as the ReaxFF or Streitz-Mintmire potential.
-But these fixes can also be used with
-potentials that normally assume per-atom charges are fixed, e.g. a
-:doc:`Buckingham <pair_buck>` or :doc:`LJ/Coulombic <pair_lj>` potential.
-
-Because the charge equilibration calculation is effectively
-independent of the pair style, these fixes can also be used to perform
-a one-time assignment of charges to atoms. For example, you could
-define the QEq fix, perform a zero-timestep run via the :doc:`run <run>`
-command without any pair style defined which would set per-atom
-charges (based on the current atom configuration), then remove the fix
-via the :doc:`unfix <unfix>` command before performing further dynamics.
-
-.. note::
-
- Computing and using charge values different from published
- values defined for a fixed-charge potential like Buckingham or CHARMM
- or AMBER, can have a strong effect on energies and forces, and
- produces a different model than the published versions.
-
-.. note::
-
- The :doc:`fix qeq/comb <fix_qeq_comb>` command must still be used
- to perform charge equliibration with the :doc:`COMB potential <pair_comb>`. The :doc:`fix qeq/reax <fix_qeq_reax>`
- command can be used to perform charge equilibration with the :doc:`ReaxFF force field <pair_reax_c>`, although fix qeq/shielded yields the
- same results as fix qeq/reax if *Nevery*\ , *cutoff*\ , and *tolerance*
- are the same. Eventually the fix qeq/reax command will be deprecated.
-
-The QEq method minimizes the electrostatic energy of the system (or
-equalizes the derivative of energy with respect to charge of all the
-atoms) by adjusting the partial charge on individual atoms based on
-interactions with their neighbors within *cutoff*\ . It reqires a few
-parameters, in *metal* units, for each atom type which provided in a
-file specified by *qfile*\ . The file has the following format
-
-.. parsed-literal::
-
- 1 chi eta gamma zeta qcore
- 2 chi eta gamma zeta qcore
- ...
- Ntype chi eta gamma zeta qcore
-
-There is one line per atom type with the following parameters.
-Only a subset of the parameters is used by each QEq style as descibed
-below, thus the others can be set to 0.0 if desired.
-
-* *chi* = electronegativity in energy units
-* *eta* = self-Coulomb potential in energy units
-* *gamma* = shielded Coulomb constant defined by :ref:`ReaxFF force field <vanDuin>` in distance units
-* *zeta* = Slater type orbital exponent defined by the :ref:`Streitz-Mintmire <Streitz>` potential in reverse distance units
-* *qcore* = charge of the nucleus defined by the :ref:`Streitz-Mintmire potential <Streitz>` potential in charge units
-
-The *qeq/point* style describes partial charges on atoms as point
-charges. Interaction between a pair of charged particles is 1/r,
-which is the simplest description of the interaction between charges.
-Only the *chi* and *eta* parameters from the *qfile* file are used.
-Note that Coulomb catastrophe can occur if repulsion between the pair
-of charged particles is too weak. This style solves partial charges
-on atoms via the matrix inversion method. A tolerance of 1.0e-6 is
-usually a good number.
-
-The *qeq/shielded* style describes partial charges on atoms also as
-point charges, but uses a shielded Coulomb potential to describe the
-interaction between a pair of charged particles. Interaction through
-the shielded Coulomb is given by equation (13) of the :ref:`ReaxFF force field <vanDuin>` paper. The shielding accounts for charge overlap
-between charged particles at small separation. This style is the same
-as :doc:`fix qeq/reax <fix_qeq_reax>`, and can be used with :doc:`pair_style reax/c <pair_reax_c>`. Only the *chi*\ , *eta*\ , and *gamma*
-parameters from the *qfile* file are used. This style solves partial
-charges on atoms via the matrix inversion method. A tolerance of
-1.0e-6 is usually a good number.
-
-The *qeq/slater* style describes partial charges on atoms as spherical
-charge densities centered around atoms via the Slater 1\ *s* orbital, so
-that the interaction between a pair of charged particles is the
-product of two Slater 1\ *s* orbitals. The expression for the Slater
-1\ *s* orbital is given under equation (6) of the
-:ref:`Streitz-Mintmire <Streitz>` paper. Only the *chi*\ , *eta*\ , *zeta*\ , and
-*qcore* parameters from the *qfile* file are used. This style solves
-partial charges on atoms via the matrix inversion method. A tolerance
-of 1.0e-6 is usually a good number. Keyword *alpha* can be used to
-change the Slater type orbital exponent.
-
-The *qeq/dynamic* style describes partial charges on atoms as point
-charges that interact through 1/r, but the extended Lagrangian method
-is used to solve partial charges on atoms. Only the *chi* and *eta*
-parameters from the *qfile* file are used. Note that Coulomb
-catastrophe can occur if repulsion between the pair of charged
-particles is too weak. A tolerance of 1.0e-3 is usually a good
-number. Keyword *qdamp* can be used to change the damping factor, while
-keyword *qstep* can be used to change the time step size.
-
-The :ref:`\ *qeq/fire*\ <Shan>` style describes the same charge model and charge
-solver as the *qeq/dynamic* style, but employs a FIRE minimization
-algorithm to solve for equilibrium charges.
-Keyword *qdamp* can be used to change the damping factor, while
-keyword *qstep* can be used to change the time step size.
-
-Note that *qeq/point*\ , *qeq/shielded*\ , and *qeq/slater* describe
-different charge models, whereas the matrix inversion method and the
-extended Lagrangian method (\ *qeq/dynamic* and *qeq/fire*\ ) are
-different solvers.
-
-Note that *qeq/point*\ , *qeq/dynamic* and *qeq/fire* styles all describe
-charges as point charges that interact through 1/r relationship, but
-solve partial charges on atoms using different solvers. These three
-styles should yield comparable results if
-the QEq parameters and *Nevery*\ , *cutoff*\ , and *tolerance* are the
-same. Style *qeq/point* is typically faster, *qeq/dynamic* scales
-better on larger sizes, and *qeq/fire* is faster than *qeq/dynamic*\ .
-
-.. note::
-
- To avoid the evaluation of the derivative of charge with respect
- to position, which is typically ill-defined, the system should have a
- zero net charge.
-
-.. note::
-
- Developing QEq parameters (chi, eta, gamma, zeta, and qcore) is
- non-trivial. Charges on atoms are not guaranteed to equilibrate with
- arbitrary choices of these parameters. We do not develop these QEq
- paramters. See the examples/qeq directory for some examples.
-
-Restart, fix_modify, output, run start/stop, minimize info
- 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
-The rigid body IDs are all positive integers. For the *single*
-bodystyle, only an ID of 1 can be used. For the *group* bodystyle,
-IDs from 1 to Ng can be used where Ng is the number of specified
-groups. For the *molecule* bodystyle, use the molecule ID for the
-atoms in a specific rigid body as the rigid body ID.
-
-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.
-
-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.
-
-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.
-
-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.
-
-.. note::
-
- If you use the *infile* or *mol* 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 *infile* 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.
-
-
-----------
-
-
-If you use a :doc:`temperature compute <compute>` 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.
-
-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).
-
-.. note::
-
- You may wish to explicitly subtract additional
- degrees-of-freedom if you use the *force* and *torque* keywords to
- eliminate certain motions of one or more rigid bodies. LAMMPS does
- not do this automatically.
-
-The rigid body contribution to the pressure of the system (virial) is
-also accounted for by this fix.
-
-
-----------
-
-
-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 :doc:`fix nve <fix_nve>`, :doc:`fix nvt <fix_nh>`, :doc:`fix npt <fix_nh>`, and :doc:`fix nph <fix_nh>`.
-
-If you wish to perform NVE dynamics (no thermostatting or
-barostatting), use one of 4 NVE rigid styles to integrate the rigid
-bodies, and :doc:`fix nve <fix_nve>` to integrate the non-rigid
-particles.
-
-If you wish to perform NVT dynamics (thermostatting, but no
-barostatting), you can use one of the 2 NVT rigid styles for the rigid
-bodies, and any thermostatting fix for the non-rigid particles (:doc:`fix nvt <fix_nh>`, :doc:`fix langevin <fix_langevin>`, :doc:`fix temp/berendsen <fix_temp_berendsen>`). You can also use one of the
-4 NVE rigid styles for the rigid bodies and thermostat them using :doc:`fix langevin <fix_langevin>` on the group that contains all the
-particles in the rigid bodies. The net force added by :doc:`fix langevin <fix_langevin>` to each rigid body effectively thermostats
-its translational center-of-mass motion. Not sure how well it does at
-thermostatting its rotational motion.
-
-If you with to perform NPT or NPH dynamics (barostatting), you cannot
-use both :doc:`fix npt <fix_nh>` and the NPT or NPH rigid styles. This
-is because there can only be one fix which monitors the global
-pressure and changes the simulation box dimensions. So you have 3
-choices:
-
-* Use one of the 4 NPT or NPH styles for the rigid bodies. Use the
- *dilate* all option so that it will dilate the positions of the
- non-rigid particles as well. Use :doc:`fix nvt <fix_nh>` (or any other
- thermostat) for the non-rigid particles.
-* Use :doc:`fix npt <fix_nh>` for the group of non-rigid particles. Use
- the *dilate* all option so that it will dilate the center-of-mass
- positions of the rigid bodies as well. Use one of the 4 NVE or 2 NVT
- rigid styles for the rigid bodies.
-* Use :doc:`fix press/berendsen <fix_press_berendsen>` to compute the
- pressure and change the box dimensions. Use one of the 4 NVE or 2 NVT
- rigid styles for the rigid bodies. Use `fix nvt <fix_nh.thml>`_ (or any
- other thermostat) for the non-rigid particles.
-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.
-
-You could even use the 2nd and 3rd options for a non-hybrid simulation
-consisting of only rigid bodies, assuming you give :doc:`fix npt <fix_nh>` an empty group, though it's an odd thing to do. The
-barostatting fixes (:doc:`fix npt <fix_nh>` and :doc:`fix press/berensen <fix_press_berendsen>`) 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.
-
-
-----------
-
-
-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 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
-* shardlow = style name of this fix command
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- fix 1 all shardlow
-
-Description
-"""""""""""
-
-Specifies that the Shardlow splitting algorithm (SSA) is to be used to
-integrate the DPD equations of motion. The SSA splits the integration
-into a stochastic and deterministic integration step. The fix
-*shardlow* performs the stochastic integration step and must be used
-in conjunction with a deterministic integrator (e.g. :doc:`fix nve <fix_nve>` or :doc:`fix nph <fix_nph>`). The stochastic
-integration of the dissipative and random forces is performed prior to
-the deterministic integration of the conservative force. Further
-details regarding the method are provided in :ref:`(Lisal) <Lisal>` and
-:ref:`(Larentzos) <Larentzos>`.
-
-The fix *shardlow* must be used with the :doc:`pair_style dpd/fdt <pair_style>` or :doc:`pair_style dpd/fdt/energy <pair_style>` command to properly initialize the
-fluctuation-dissipation theorem parameter(s) sigma (and kappa, if
-necessary).
-
-Note that numerous variants of DPD can be specified by choosing an
-appropriate combination of the integrator and :doc:`pair_style dpd/fdt <pair_style>` command. DPD under isothermal conditions can
-be specified by using fix *shardlow*\ , fix *nve* and pair_style
-*dpd/fdt*\ . DPD under isoenergetic conditions can be specified by
- adjust_radius_factor = factor which scale the smooth/kernel radius
- min_nn = minimum number of neighbors
- max_nn = maximum number of neighbors
-limit_velocity values = max_velocity
- max_velocity = maximum allowed velocity.
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- fix 1 all smd/integrate_ulsph adjust_radius 1.02 25 50
-
-.. parsed-literal::
-
- fix 1 all smd/integrate_ulsph limit_velocity 1000
-
-Description
-"""""""""""
-
-The fix performs explicit time integration for particles which interact with the updated Lagrangian SPH pair style.
-See `this PDF guide <USER/smd/SMD_LAMMPS_userguide.pdf>`_ to using Smooth Mach Dynamics in LAMMPS.
-
-The *adjust_radius* keyword activates dynamic adjustment of the per-particle SPH smoothing kernel radius such that the number of neighbors per particles remains
-within the interval *min_nn* to *max_nn*\ . The parameter *adjust_radius_factor* determines the amount of adjustment per timestep. Typical values are
-*adjust_radius_factor*\ =1.02, *min_nn*\ =15, and *max_nn*\ =20.
-
-The *limit_velocity* keyword will control the velocity, scaling the norm of
-the velocity vector to max_vel in case it exceeds this velocity limit.
-
-Restart, fix_modify, output, run start/stop, minimize info
-Currently, no part of USER-SMD supports restarting nor minimization. This fix has no outputs.
-
-Restrictions
-""""""""""""
-
-
-This fix is part of the USER-SMD package. It is only enabled if
-LAMMPS was built with that package. See the :ref:`Making LAMMPS <start_3>`
-section for more info. The molecule ID given to the particles created by this fix have to be equal to or larger than 65535.
-
-Within each .STL file, only a single triangulated object must be present, even though the STL format allows for the possibility of multiple objects in one file.
- fix ID group-ID srd N groupbig-ID Tsrd hgrid seed keyword value ...
-
-* ID, group-ID are documented in :doc:`fix <fix>` command
-* srd = style name of this fix command
-* N = reset SRD particle velocities every this many timesteps
-* groupbig-ID = ID of group of large particles that SRDs interact with
-* Tsrd = temperature of SRD particles (temperature units)
-* hgrid = grid spacing for SRD grouping (distance units)
-* seed = random # seed (positive integer)
-
-* zero or more keyword/value pairs may be appended
-* keyword = *lamda* or *collision* or *overlap* or *inside* or *exact* or *radius* or *bounce* or *search* or *cubic* or *shift* or *tstat* or *rescale*
-.. parsed-literal::
-
- *lamda* value = mean free path of SRD particles (distance units)
- *collision* value = *noslip* or *slip* = collision model
- *overlap* value = *yes* or *no* = whether big particles may overlap
- *inside* value = *error* or *warn* or *ignore* = how SRD particles which end up inside a big particle are treated
- *exact* value = *yes* or *no*
- *radius* value = rfactor = scale collision radius by this factor
- *bounce* value = Nbounce = max # of collisions an SRD particle can undergo in one timestep
- *search* value = sgrid = grid spacing for collision partner searching (distance units)
- xflag,yflag,zflag = 0/1 to exclude/include each dimension
- *rot* args = none
-
-
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- fix 1 all tfmc 0.1 1000.0 159345
- fix 1 all tfmc 0.05 600.0 658943 com 1 1 0
- fix 1 all tfmc 0.1 750.0 387068 com 1 1 1 rot
-
-Description
-"""""""""""
-
-Perform uniform-acceptance force-bias Monte Carlo (fbMC) simulations,
-using the time-stamped force-bias Monte Carlo (tfMC) algorithm
-described in :ref:`(Mees) <Mees>` and :ref:`(Bal) <Bal>`.
-
-One successful use case of force-bias Monte Carlo methods is that they
-can be used to extend the time scale of atomistic simulations, in
-particular when long time scale relaxation effects must be considered;
-some interesting examples are given in the review by :ref:`(Neyts) <Neyts>`.
-An example of a typical use case would be the modelling of chemical
-vapour deposition (CVD) processes on a surface, in which impacts by
-gas-phase species can be performed using MD, but subsequent relaxation
-of the surface is too slow to be done using MD only. Using tfMC can
-allow for a much faster relaxation of the surface, so that higher
-fluxes can be used, effectively extending the time scale of the
-simulation. (Such an alternating simulation approach could be set up
-using a :doc:`loop <jump>`.)
-
-The initial version of tfMC algorithm in :ref:`(Mees) <Mees>` contained an
-estimation of the effective time scale of such a simulation, but it
-was later shown that the speed-up one can gain from a tfMC simulation
-is system- and process-dependent, ranging from none to several orders
-of magnitude. In general, solid-state processes such as
-(re)crystallisation or growth can be accelerated by up to two or three
-orders of magnitude, whereas diffusion in the liquid phase is not
-accelerated at all. The observed pseudodynamics when using the tfMC
-method is not the actual dynamics one would obtain using MD, but the
-relative importance of processes can match the actual relative
-dynamics of the system quite well, provided *Delta* is chosen with
-care. Thus, the system's equilibrium is reached faster than in MD,
-along a path that is generally roughly similar to a typical MD
-simulation (but not necessarily so). See :ref:`(Bal) <Bal>` for details.
-
-Each step, all atoms in the selected group are displaced using the
-stochastic tfMC algorithm, which is designed to sample the canonical
-(NVT) ensemble at the temperature *Temp*\ . Although tfMC is a Monte
-Carlo algorithm and thus strictly speaking does not perform time
-integration, it is similar in the sense that it uses the forces on all
-atoms in order to update their positions. Therefore, it is implemented
-as a time integration fix, and no other fixes of this type (such as
-:doc:`fix nve <fix_nve>`) should be used at the same time. Because
-velocities do not play a role in this kind of Monte Carlo simulations,
-instantaneous temperatures as calculated by :doc:`temperature computes <compute_temp>` or :doc:`thermodynamic output <thermo_style>` have no meaning: the only relevant
-temperature is the sampling temperature *Temp*\ . Similarly, performing
-tfMC simulations does not require setting a :doc:`timestep <timestep>`
-and the :doc:`simulated time <thermo_style>` as calculated by LAMMPS is
-meaningless.
-
-The critical parameter determining the success of a tfMC simulation is
-*Delta*\ , the maximal displacement length of the lightest element in
-the system: the larger it is, the longer the effective time scale of
-the simulation will be (there is an approximately quadratic
-dependence). However, *Delta* must also be chosen sufficiently small
-in order to comply with detailed balance; in general values between 5
-and 10 % of the nearest neighbor distance are found to be a good
-choice. For a more extensive discussion with specific examples, please
-refer to :ref:`(Bal) <Bal>`, which also describes how the code calculates
-element-specific maximal displacements from *Delta*\ , based on the
-fourth root of their mass.
-
-Because of the uncorrelated movements of the atoms, the center-of-mass
-of the fix group will not necessarily be stationary, just like its
-orientation. When the *com* keyword is used, all atom positions will
-be shifted (after every tfMC iteration) in order to fix the position
-of the center-of-mass along the included directions, by setting the
-corresponding flag to 1. The *rot* keyword does the same for the
-rotational component of the tfMC displacements after every iteration.
-
-.. note::
-
- the *com* and *rot* keywords should not be used if an external
- force is acting on the specified fix group, along the included
- directions. This can be either a true external force (e.g. through
- :doc:`fix wall <fix_wall>`) or forces due to the interaction with atoms
- not included in the fix group. This is because in such cases,
- translations or rotations of the fix group could be induced by these
- external forces, and removing them will lead to a violation of
- detailed balance.
-
-
-----------
-
-
-Restart, fix_modify, output, run start/stop, minimize info
-* style = *delete* or *region* or *type* or *id* or *molecule* or *variable* or *include* or *subtract* or *union* or *intersect* or *dynamic* or *static*
-.. parsed-literal::
-
- *delete* = no args
- *clear* = no args
- *region* args = region-ID
- *type* or *id* or *molecule*
- args = list of one or more atom types, atom IDs, or molecule IDs
- any entry in list can be a sequence formatted as A:B or A:B:C where
- A = starting index, B = ending index,
- C = increment between indices, 1 if not specified
- args = logical value
- logical = "<" or "<=" or ">" or ">=" or "==" or "!="
- value = an atom type or atom ID or molecule ID (depending on *style*\ )
- args = logical value1 value2
- logical = "<>"
- value1,value2 = atom types or atom IDs or molecule IDs (depending on *style*\ )
- *variable* args = variable-name
- *include* args = molecule
- molecule = add atoms to group with same molecule ID as atoms already in group
- *subtract* args = two or more group IDs
- *union* args = one or more group IDs
- *intersect* args = two or more group IDs
- *dynamic* args = parent-ID keyword value ...
- one or more keyword/value pairs may be appended
- keyword = *region* or *var* or *every*
- *region* value = region-ID
- *var* value = name of variable
- *every* value = N = update group every this many timesteps
- *static* = no args
-
-
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- group edge region regstrip
- group water type 3 4
- group sub id 10 25 50
- group sub id 10 25 50 500:1000
- group sub id 100:10000:10
- group sub id <= 150
- group polyA molecule <> 50 250
- group hienergy variable eng
- group hienergy include molecule
- group boundary subtract all a2 a3
- group boundary union lower upper
- group boundary intersect upper flow
- group boundary delete
- group mine dynamic all region myRegion every 100
-
-Description
-"""""""""""
-
-Identify a collection of atoms as belonging to a group. The group ID
-can then be used in other commands such as :doc:`fix <fix>`,
-:doc:`compute <compute>`, :doc:`dump <dump>`, or :doc:`velocity <velocity>`
-to act on those atoms together.
-
-If the group ID already exists, the group command adds the specified
-atoms to the group.
-
-.. note::
-
- By default groups are static, meaning the atoms are permanently
- assigned to the group. For example, if the *region* style is used to
- assign atoms to a group, the atoms will remain in the group even if
- they later move out of the region. As explained below, the *dynamic*
- style can be used to make a group dynamic so that a periodic
- determination is made as to which atoms are in the group. Since many
- LAMMPS commands operate on groups of atoms, you should think carefully
- about whether making a group dynamic makes sense for your model.
-
-A group with the ID *all* is predefined. All atoms belong to this
-group. This group cannot be deleted, or made dynamic.
-
-The *delete* style removes the named group and un-assigns all atoms
-that were assigned to that group. Since there is a restriction (see
-below) that no more than 32 groups can be defined at any time, the
-*delete* style allows you to remove groups that are no longer needed,
-so that more can be specified. You cannot delete a group if it has
-been used to define a current :doc:`fix <fix>` or :doc:`compute <compute>`
-or :doc:`dump <dump>`.
-
-The *clear* style un-assigns all atoms that were assigned to that
-group. This may be dangerous to do during a simulation run,
-e.g. using the :doc:`run every <run>` command if a fix or compute or
-other operation expects the atoms in the group to remain constant, but
-LAMMPS does not check for this.
-
-The *region* style puts all atoms in the region volume into the group.
-Note that this is a static one-time assignment. The atoms remain
-assigned (or not assigned) to the group even in they later move out of
-the region volume.
-
-The *type*\ , *id*\ , and *molecule* styles put all atoms with the
-specified atom types, atom IDs, or molecule IDs into the group. These
-3 styles can use arguments specified in one of two formats.
-
-The first format is a list of values (types or IDs). For example, the
-2nd command in the examples above puts all atoms of type 3 or 4 into
-the group named *water*\ . Each entry in the list can be a
-colon-separated sequence A:B or A:B:C, as in two of the examples
-above. A "sequence" generates a sequence of values (types or IDs),
-with an optional increment. The first example with 500:1000 has the
-default increment of 1 and would add all atom IDs from 500 to 1000
-(inclusive) to the group sub, along with 10,25,50 since they also
-appear in the list of values. The second example with 100:10000:10
-uses an increment of 10 and would thus would add atoms IDs
-100,110,120, ... 9990,10000 to the group sub.
-
-The second format is a *logical* followed by one or two values (type
-or ID). The 7 valid logicals are listed above. All the logicals
-except <> take a single argument. The 3rd example above adds all
-atoms with IDs from 1 to 150 to the group named *sub*\ . The logical <>
-means "between" and takes 2 arguments. The 4th example above adds all
-atoms belonging to molecules with IDs from 50 to 250 (inclusive) to
-the group named polyA.
-
-The *variable* style evaluates a variable to determine which atoms to
-add to the group. It must be an :doc:`atom-style variable <variable>`
-previously defined in the input script. If the variable evaluates
-to a non-zero value for a particular atom, then that atom is added
-to the specified group.
-
-Atom-style variables can specify formulas that include thermodynamic
-quantities, per-atom values such as atom coordinates, or per-atom
-quantities calculated by computes, fixes, or other variables. They
-can also include Boolean logic where 2 numeric values are compared to
-yield a 1 or 0 (effectively a true or false). Thus using the
-*variable* style, is a general way to flag specific atoms to include
-or exclude from a group.
-
-For example, these lines define a variable "eatom" that calculates the
-potential energy of each atom and includes it in the group if its
-potential energy is above the threshhold value -3.0.
-
-.. parsed-literal::
-
- compute 1 all pe/atom
- compute 2 all reduce sum c_1
- thermo_style custom step temp pe c_2
- run 0
-
-.. parsed-literal::
-
- variable eatom atom "c_1 > -3.0"
- group hienergy variable eatom
-
-Note that these lines
-
-.. parsed-literal::
-
- compute 2 all reduce sum c_1
- thermo_style custom step temp pe c_2
- run 0
-
-are necessary to insure that the "eatom" variable is current when the
-group command invokes it. Because the eatom variable computes the
-per-atom energy via the pe/atom compute, it will only be current if a
-run has been performed which evaluated pairwise energies, and the
-pe/atom compute was actually invoked during the run. Printing the
-thermodyanmic info for compute 2 insures that this is the case, since
-it sums the pe/atom compute values (in the reduce compute) to output
-them to the screen. See the "Variable Accuracy" section of the
-:doc:`variable <variable>` doc page for more details on insuring that
-variables are current when they are evaluated between runs.
-
-The *include* style with its arg *molecule* adds atoms to a group that
-have the same molecule ID as atoms already in the group. The molecule
-ID = 0 is ignored in this operation, since it is assumed to flag
-isolated atoms that are not part of molecules. An example of where
-this operation is useful is if the *region* style has been used
-previously to add atoms to a group that are within a geometric region.
-If molecules straddle the region boundary, then atoms outside the
-region that are part of molecules with atoms inside the region will
-not be in the group. Using the group command a 2nd time with *include
-molecule* will add those atoms that are outside the region to the
-group.
-
-.. note::
-
- The *include molecule* operation is relatively expensive in a
- parallel sense. This is because it requires communication of relevant
- molecule IDs between all the processors and each processor to loop
- over its atoms once per processor, to compare its atoms to the list of
- molecule IDs from every other processor. Hence it scales as N, rather
- than N/P as most of the group operations do, where N is the number of
- atoms, and P is the number of processors.
-
-The *subtract* style takes a list of two or more existing group names
-as arguments. All atoms that belong to the 1st group, but not to any
-of the other groups are added to the specified group.
-
-The *union* style takes a list of one or more existing group names as
-arguments. All atoms that belong to any of the listed groups are
-added to the specified group.
-
-The *intersect* style takes a list of two or more existing group names
-as arguments. Atoms that belong to every one of the listed groups are
-added to the specified group.
-
-
-----------
-
-
-The *dynamic* style flags an existing or new group as dynamic. This
-means atoms will be (re)assigned to the group periodically as a
-simulation runs. This is in contrast to static groups where atoms are
-permanently assigned to the group. The way the assignment occurs is
-as follows. Only atoms in the group specified as the parent group via
-the parent-ID are assigned to the dynamic group before the following
-conditions are applied. If the *region* keyword is used, atoms not in
-the specified region are removed from the dynamic group. If the *var*
-keyword is used, the variable name must be an atom-style or
-atomfile-style variable. The variable is evaluated and atoms whose
-per-atom values are 0.0, are removed from the dynamic group.
-
-The assignment of atoms to a dynamic group is done at the beginning of
-each run and on every timestep that is a multiple of *N*\ , which is the
-argument for the *every* keyword (N = 1 is the default). For an
-energy minimization, via the :doc:`minimize <minimize>` command, an
-assignement is made at the beginning of the minimization, but not
-during the iterations of the minimizer.
-
-The point in the timestep at which atoms are assigned to a dynamic
-group is after the initial stage of velocity Verlet time integration
-has been performed, and before neighbor lists or forces are computed.
-This is the point in the timestep where atom positions have just
-changed due to the time integration, so the region criterion should be
-accurate, if applied.
-
-.. note::
-
- If the *region* keyword is used to determine what atoms are in
- the dynamic group, atoms can move outside of the simulation box
- between reneighboring events. Thus if you want to include all atoms
- on the left side of the simulation box, you probably want to set the
- left boundary of the region to be outside the simulation box by some
- reasonable amount (e.g. up to the cutoff of the potential), else they
- may be excluded from the dynamic region.
-
-Here is an example of using a dynamic group to shrink the set of atoms
-being integrated by using a spherical region with a variable radius
-(shrinking from 18 to 5 over the course of the run). This could be
-used to model a quench of the system, freezing atoms outside the
-shrinking sphere, then converting the remaining atoms to a static
-group and running further.
-
-.. parsed-literal::
-
- variable nsteps equal 5000
- variable rad equal 18-(step/v_nsteps)*(18-5)
- region ss sphere 20 20 0 v_rad
- group mobile dynamic all region ss
- fix 1 mobile nve
- run ${nsteps}
- group mobile static
- run ${nsteps}
-
-.. note::
-
- All fixes and computes take a group ID as an argument, but they
- do not all allow for use of a dynamic group. If you get an error
- message that this is not allowed, but feel that it should be for the
- fix or compute in question, then please post your reasoning to the
- LAMMPS mail list and we can change it.
-
-The *static* style removes the setting for a dynamic group, converting
-it to a static group (the default). The atoms in the static group are
-those currently in the dynamic group.
-
-
-----------
-
-
-Restrictions
-""""""""""""
-
-
-There can be no more than 32 groups defined at one time, including
-"all".
-
-The parent group of a dynamic group cannot itself be a dynamic group.
-args = one or more of the following keywords: *out*\ , *all*\ , *system*\ , *communication*\ , *computes*\ , *dumps*\ , *fixes*\ , *groups*\ , *regions*\ , *variables*\ , *time*\ , or *configuration*
- keyword = *mesh* or *order* or *order/disp* or *mix/disp* or *overlap* or *minorder* or *force* or *gewald* or *gewald/disp* or *slab* or (nozforce* or *compute* or *cutoff/adjust* or *fftbench* or *collective* or *diff* or *kmax/ewald* or *force/disp/real* or *force/disp/kspace* or *splittol* or *disp/auto*\ :l
- *mesh* value = x y z
- x,y,z = grid size in each dimension for long-range Coulombics
- *mesh/disp* value = x y z
- x,y,z = grid size in each dimension for 1/r^6 dispersion
- *order* value = N
- N = extent of Gaussian for PPPM or MSM mapping of charge to grid
- *order/disp* value = N
- N = extent of Gaussian for PPPM mapping of dispersion term to grid
- *mix/disp* value = *pair* or *geom* or *none*
- *overlap* = *yes* or *no* = whether the grid stencil for PPPM is allowed to overlap into more than the nearest-neighbor processor
- *minorder* value = M
- M = min allowed extent of Gaussian when auto-adjusting to minimize grid communication
- *force* value = accuracy (force units)
- *gewald* value = rinv (1/distance units)
- rinv = G-ewald parameter for Coulombics
- *gewald/disp* value = rinv (1/distance units)
- rinv = G-ewald parameter for dispersion
- *slab* value = volfactor or *nozforce*
- volfactor = ratio of the total extended volume used in the
- 2d approximation compared with the volume of the simulation domain
- *nozforce* turns off kspace forces in the z direction
- *compute* value = *yes* or *no*
- *cutoff/adjust* value = *yes* or *no*
- *pressure/scalar* value = *yes* or *no*
- *fftbench* value = *yes* or *no*
- *collective* value = *yes* or *no*
- *diff* value = *ad* or *ik* = 2 or 4 FFTs for PPPM in smoothed or non-smoothed mode
- *kmax/ewald* value = kx ky kz
- kx,ky,kz = number of Ewald sum kspace vectors in each dimension
- *force/disp/real* value = accuracy (force units)
- *force/disp/kspace* value = accuracy (force units)
- *splittol* value = tol
- tol = relative size of two eigenvalues (see discussion below)
- *disp/auto* value = yes or no
-
-
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- kspace_modify mesh 24 24 30 order 6
- kspace_modify slab 3.0
-
-Description
-"""""""""""
-
-Set parameters used by the kspace solvers defined by the
-:doc:`kspace_style <kspace_style>` command. Not all parameters are
-relevant to all kspace styles.
-
-The *mesh* keyword sets the grid size for kspace style *pppm* or
-*msm*\ . In the case of PPPM, this is the FFT mesh, and each dimension
-must be factorizable into powers of 2, 3, and 5. In the case of MSM,
-this is the finest scale real-space mesh, and each dimension must be
-factorizable into powers of 2. When this option is not set, the PPPM
-or MSM solver chooses its own grid size, consistent with the
-user-specified accuracy and pairwise cutoff. Values for x,y,z of
-0,0,0 unset the option.
-
-The *mesh/disp* keyword sets the grid size for kspace style
-*pppm/disp*\ . This is the FFT mesh for long-range dispersion and ach
-dimension must be factorizable into powers of 2, 3, and 5. When this
-option is not set, the PPPM solver chooses its own grid size,
-consistent with the user-specified accuracy and pairwise cutoff.
-Values for x,y,z of 0,0,0 unset the option.
-
-The *order* keyword determines how many grid spacings an atom's charge
-extends when it is mapped to the grid in kspace style *pppm* or *msm*\ .
-The default for this parameter is 5 for PPPM and 8 for MSM, which
-means each charge spans 5 or 8 grid cells in each dimension,
-respectively. For the LAMMPS implementation of MSM, the order can
-range from 4 to 10 and must be even. For PPPM, the minimum allowed
-setting is 2 and the maximum allowed setting is 7. The larger the
-value of this parameter, the smaller that LAMMPS will set the grid
-size, to achieve the requested accuracy. Conversely, the smaller the
-order value, the larger the grid size will be. Note that there is an
-inherent trade-off involved: a small grid will lower the cost of FFTs
-or MSM direct sum, but a larger order parameter will increase the cost
-of interpolating charge/fields to/from the grid.
-
-The *order/disp* keyword determines how many grid spacings an atom's
-dispersion term extends when it is mapped to the grid in kspace style
-*pppm/disp*\ . It has the same meaning as the *order* setting for
-Coulombics.
-
-The *overlap* keyword can be used in conjunction with the *minorder*
-keyword with the PPPM styles to adjust the amount of communication
-that occurs when values on the FFT grid are exchangeed between
-processors. This communication is distinct from the communication
-inherent in the parallel FFTs themselves, and is required because
-processors interpolate charge and field values using grid point values
-owned by neighboring processors (i.e. ghost point communication). If
-the *overlap* keyword is set to *yes* then this communication is
-allowed to extend beyond nearest-neighbor processors, e.g. when using
-lots of processors on a small problem. If it is set to *no* then the
-communication will be limited to nearest-neighbor processors and the
-*order* setting will be reduced if necessary, as explained by the
-*minorder* keyword discussion. The *overlap* keyword is always set to
-*yes* in MSM.
-
-The *minorder* keyword allows LAMMPS to reduce the *order* setting if
-necessary to keep the communication of ghost grid point limited to
-exchanges between nearest-neighbor processors. See the discussion of
-the *overlap* keyword for details. If the *overlap* keyword is set to
-*yes*\ , which is the default, this is never needed. If it set to *no*
-and overlap occurs, then LAMMPS will reduce the order setting, one
-step at a time, until the ghost grid overlap only extends to nearest
-neighbor processors. The *minorder* keyword limits how small the
-*order* setting can become. The minimum allowed value for PPPM is 2,
-which is the default. If *minorder* is set to the same value as
-*order* then no reduction is allowed, and LAMMPS will generate an
-error if the grid communcation is non-nearest-neighbor and *overlap*
-is set to *no*\ . The *minorder* keyword is not currently supported in
-MSM.
-
-The PPPM order parameter may be reset by LAMMPS when it sets up the
-FFT grid if the implied grid stencil extends beyond the grid cells
-owned by neighboring processors. Typically this will only occur when
-small problems are run on large numbers of processors. A warning will
-be generated indicating the order parameter is being reduced to allow
-LAMMPS to run the problem. Automatic adjustment of the order parameter
-is not supported in MSM.
-
-The *force* keyword overrides the relative accuracy parameter set by
-the :doc:`kspace_style <kspace_style>` command with an absolute
-accuracy. The accuracy determines the RMS error in per-atom forces
-calculated by the long-range solver and is thus specified in force
-units. A negative value for the accuracy setting means to use the
-relative accuracy parameter. The accuracy setting is used in
-conjunction with the pairwise cutoff to determine the number of
-K-space vectors for style *ewald*\ , the FFT grid size for style
-*pppm*\ , or the real space grid size for style *msm*\ .
-
-The *gewald* keyword sets the value of the Ewald or PPPM G-ewald
-parameter for charge as *rinv* in reciprocal distance units. Without
-this setting, LAMMPS chooses the parameter automatically as a function
-of cutoff, precision, grid spacing, etc. This means it can vary from
-one simulation to the next which may not be desirable for matching a
-KSpace solver to a pre-tabulated pairwise potential. This setting can
-also be useful if Ewald or PPPM fails to choose a good grid spacing
-and G-ewald parameter automatically. If the value is set to 0.0,
-LAMMPS will choose the G-ewald parameter automatically. MSM does not
-use the *gewald* parameter.
-
-The *gewald/disp* keyword sets the value of the Ewald or PPPM G-ewald
-parameter for dispersion as *rinv* in reciprocal distance units. It
-has the same meaning as the *gewald* setting for Coulombics.
-
-The *slab* keyword allows an Ewald or PPPM solver to be used for a
-systems that are periodic in x,y but non-periodic in z - a
-:doc:`boundary <boundary>` setting of "boundary p p f". This is done by
-treating the system as if it were periodic in z, but inserting empty
-volume between atom slabs and removing dipole inter-slab interactions
-so that slab-slab interactions are effectively turned off. The
-volfactor value sets the ratio of the extended dimension in z divided
-by the actual dimension in z. The recommended value is 3.0. A larger
-value is inefficient; a smaller value introduces unwanted slab-slab
-interactions. The use of fixed boundaries in z means that the user
-must prevent particle migration beyond the initial z-bounds, typically
-by providing a wall-style fix. The methodology behind the *slab*
-option is explained in the paper by :ref:`(Yeh) <Yeh>`. The *slab* option
-is also extended to non-neutral systems :ref:`(Ballenegger) <Ballenegger>`.
-
-An alternative slab option can be invoked with the *nozforce* keyword
-in lieu of the volfactor. This turns off all kspace forces in the z
-direction. The *nozforce* option is not supported by MSM. For MSM,
-any combination of periodic, non-periodic, or shrink-wrapped
-boundaries can be set using :doc:`boundary <boundary>` (the slab
-approximation in not needed). The *slab* keyword is not currently
-supported by Ewald or PPPM when using a triclinic simulation cell. The
-slab correction has also been extended to point dipole interactions
-:ref:`(Klapp) <Klapp>` in :doc:`kspace_style <kspace_style>` *ewald/disp*\ .
-
-.. note::
-
- If you wish to apply an electric field in the Z-direction, in
- conjunction with the *slab* keyword, you should do it by adding
- explicit charged particles to the +/- Z surfaces. If you do it via
- the :doc:`fix efield <fix_efield>` command, it will not give the correct
- dielectric constant due to the Yeh/Berkowitz :ref:`(Yeh) <Yeh>` correction
- not being compatible with how :doc:`fix efield <fix_efield>` works.
-
-The *compute* keyword allows Kspace computations to be turned off,
-even though a :doc:`kspace_style <kspace_style>` is defined. This is
-not useful for running a real simulation, but can be useful for
-debugging purposes or for computing only partial forces that do not
-include the Kspace contribution. You can also do this by simply not
-defining a :doc:`kspace_style <kspace_style>`, but a Kspace-compatible
-:doc:`pair_style <pair_style>` requires a kspace style to be defined.
-This keyword gives you that option.
-
-The *cutoff/adjust* keyword applies only to MSM. If this option is
-turned on, the Coulombic cutoff will be automatically adjusted at the
-beginning of the run to give the desired estimated error. Other
-cutoffs such as LJ will not be affected. If the grid is not set using
-the *mesh* command, this command will also attempt to use the optimal
-grid that minimizes cost using an estimate given by
-:ref:`(Hardy) <Hardy>`. Note that this cost estimate is not exact, somewhat
-experimental, and still may not yield the optimal parameters.
-
-The *pressure/scalar* keyword applies only to MSM. If this option is
-turned on, only the scalar pressure (i.e. (Pxx + Pyy + Pzz)/3.0) will
-be computed, which can be used, for example, to run an isotropic barostat.
-Computing the full pressure tensor with MSM is expensive, and this option
-provides a faster alternative. The scalar pressure is computed using a
-relationship between the Coulombic energy and pressure :ref:`(Hummer) <Hummer>`
-instead of using the virial equation. This option cannot be used to access
-individual components of the pressure tensor, to compute per-atom virial,
-or with suffix kspace/pair styles of MSM, like OMP or GPU.
-
-The *fftbench* keyword applies only to PPPM. It is on by default. If
-this option is turned off, LAMMPS will not take the time at the end
-of a run to give FFT benchmark timings, and will finish a few seconds
-faster than it would if this option were on.
-
-The *collective* keyword applies only to PPPM. It is set to *no* by
-default, except on IBM BlueGene machines. If this option is set to
-*yes*\ , LAMMPS will use MPI collective operations to remap data for
-3d-FFT operations instead of the default point-to-point communication.
-This is faster on IBM BlueGene machines, and may also be faster on
-other machines if they have an efficient implementation of MPI
-collective operations and adequate hardware.
-
-The *diff* keyword specifies the differentiation scheme used by the
-PPPM method to compute forces on particles given electrostatic
-potentials on the PPPM mesh. The *ik* approach is the default for
-PPPM and is the original formulation used in :ref:`(Hockney) <Hockney>`. It
-performs differentiation in Kspace, and uses 3 FFTs to transfer each
-component of the computed fields back to real space for total of 4
-FFTs per timestep.
-
-The analytic differentiation *ad* approach uses only 1 FFT to transfer
-information back to real space for a total of 2 FFTs per timestep. It
-then performs analytic differentiation on the single quantity to
-generate the 3 components of the electric field at each grid point.
-This is sometimes referred to as "smoothed" PPPM. This approach
-requires a somewhat larger PPPM mesh to achieve the same accuracy as
-the *ik* method. Currently, only the *ik* method (default) can be
-used for a triclinic simulation cell with PPPM. The *ad* method is
-always used for MSM.
-
-.. note::
-
- Currently, not all PPPM styles support the *ad* option. Support
- for those PPPM variants will be added later.
-
-The *kmax/ewald* keyword sets the number of kspace vectors in each
-dimension for kspace style *ewald*\ . The three values must be positive
-integers, or else (0,0,0), which unsets the option. When this option
-is not set, the Ewald sum scheme chooses its own kspace vectors,
-consistent with the user-specified accuracy and pairwise cutoff. In
-any case, if kspace style *ewald* is invoked, the values used are
-printed to the screen and the log file at the start of the run.
-
-With the *mix/disp* keyword one can select the mixing rule for the
-dispersion coefficients. With *pair*\ , the dispersion coefficients of
-unlike types are computed as indicated with
-:doc:`pair_modify <pair_modify>`. With *geom*\ , geometric mixing is
-enforced on the dispersion coefficients in the kspace
-coefficients. When using the arithmetic mixing rule, this will
-speed-up the simulations but introduces some error in the force
-computations, as shown in :ref:`(Wennberg) <Wennberg>`. With *none*\ , it is
-assumed that no mixing rule is applicable. Splitting of the dispersion
-coefficients will be performed as described in
-:ref:`(Isele-Holder) <Isele-Holder>`. This splitting can be influenced with
-the *splittol* keywords. Only the eigenvalues that are larger than tol
-compared to the largest eigenvalues are included. Using this keywords
-the original matrix of dispersion coefficients is approximated. This
-leads to faster computations, but the accuracy in the reciprocal space
-computations of the dispersion part is decreased.
-
-The *force/disp/real* and *force/disp/kspace* keywords set the force
-accuracy for the real and space computations for the dispersion part
-of pppm/disp. As shown in :ref:`(Isele-Holder) <Isele-Holder>`, optimal
-performance and accuracy in the results is obtained when these values
-are different.
-
-The *disp/auto* option controlls whether the pppm/disp is allowed to
-generate PPPM parameters automatically. If set to *no*\ , parameters have
-to be specified using the *gewald/disp*\ , *mesh/disp*\ ,
-*force/disp/real* or *force/disp/kspace* keywords, or
-the code will stop with an error message. When this option is set to
-*yes*\ , the error message will not appear and the simulation will start.
-For a typical application, using the automatic parameter generation will provide
-simulations that are either inaccurate or slow. Using this option is thus not
-recommended. For guidelines on how to obtain good parameters, see the :ref:`How-To <howto_23>` discussion.
-* 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 *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 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.
-
-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
-| cylinder_dent | R l a | x^2 + y^2 - r(z)^2 = 0, r(x) = R if |z| > l, r(z) = R - a*(1 + cos(z/l))/2 otherwise | A cylinder with a dent around z = 0 | |
-| spine | a, A, B, B2, c | -(x^2 + y^2)*(a^2 - z^2/f(z)^2)*(1 + (A*sin(g(z)*z^2))^4), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise | An approximation to a dendtritic spine | |
-| spine_two | a, A, B, B2, c | -(x^2 + y^2)*(a^2 - z^2/f(z)^2)*(1 + (A*sin(g(z)*z^2))^2), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise | Another approximation to a dendtritic spine | |
-| thylakoid | wB LB lB | Various, see :ref:`(Paquay) <Paquay>` | A model grana thylakoid consisting of two block-like compartments connected by a bridge of width wB, length LB and taper length lB | |
-* etol = stopping tolerance for energy (unitless)
-* ftol = stopping tolerance for force (force units)
-* maxiter = max iterations of minimizer
-* maxeval = max number of force/energy evaluations
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- minimize 1.0e-4 1.0e-6 100 1000
- minimize 0.0 1.0e-8 1000 100000
-
-Description
-"""""""""""
-
-Perform an energy minimization of the system, by iteratively adjusting
-atom coordinates. Iterations are terminated when one of the stopping
-criteria is satisfied. At that point the configuration will hopefully
-be in local potential energy minimum. More precisely, the
-configuration should approximate a critical point for the objective
-function (see below), which may or may not be a local minimum.
-
-The minimization algorithm used is set by the
-:doc:`min_style <min_style>` command. Other options are set by the
-:doc:`min_modify <min_modify>` command. Minimize commands can be
-interspersed with :doc:`run <run>` commands to alternate between
-relaxation and dynamics. The minimizers bound the distance atoms move
-in one iteration, so that you can relax systems with highly overlapped
-atoms (large energies and forces) by pushing the atoms off of each
-other.
-
-Alternate means of relaxing a system are to run dynamics with a small
-or :doc:`limited timestep <fix_nve_limit>`. Or dynamics can be run
-using :doc:`fix viscous <fix_viscous>` to impose a damping force that
-slowly drains all kinetic energy from the system. The :doc:`pair_style soft <pair_soft>` potential can be used to un-overlap atoms while
-running dynamics.
-
-Note that you can minimize some atoms in the system while holding the
-coordiates of other atoms fixed by applying :doc:`fix setforce <fix_setforce>` to the other atoms. See a fuller
-discussion of using fixes while minimizing below.
-
-The :doc:`minimization styles <min_style>` *cg*\ , *sd*\ , and *hftn*
-involves an outer iteration loop which sets the search direction along
-which atom coordinates are changed. An inner iteration is then
-performed using a line search algorithm. The line search typically
-evaluates forces and energies several times to set new coordinates.
-Currently, a backtracking algorithm is used which may not be optimal
-in terms of the number of force evaulations performed, but appears to
-be more robust than previous line searches we've tried. The
-backtracking method is described in Nocedal and Wright's Numerical
-Optimization (Procedure 3.1 on p 41).
-
-The :doc:`minimization styles <min_style>` *quickmin* and *fire* perform
-damped dynamics using an Euler integration step. Thus they require a
-:doc:`timestep <timestep>` be defined.
-
-.. note::
-
- The damped dynamic minimizers use whatever timestep you have
- defined via the :doc:`timestep <timestep>` command. Often they will
- converge more quickly if you use a timestep about 10x larger than you
- would normally use for dynamics simulations.
-
-
-----------
-
-
-In all cases, the objective function being minimized is the total
-potential energy of the system as a function of the N atom
-coordinates:
-
-.. image:: Eqs/min_energy.jpg
- :align: center
-
-where the first term is the sum of all non-bonded :doc:`pairwise interactions <pair_style>` including :doc:`long-range Coulombic interactions <kspace_style>`, the 2nd thru 5th terms are
-as do the GROMACS potentials (e.g. :doc:`pair_style lj/gromacs <pair_gromacs>`).
-
-If a soft potential (:doc:`pair_style soft <pair_soft>`) is used the
-Astop value is used for the prefactor (no time dependence).
-
-The :doc:`fix box/relax <fix_box_relax>` command can be used to apply an
-external pressure to the simulation box and allow it to shrink/expand
-during the minimization.
-
-Only a few other fixes (typically those that apply force constraints)
-are invoked during minimization. See the doc pages for individual
-:doc:`fix <fix>` commands to see which ones are relevant. Current
-examples of fixes that can be used include:
-
-* :doc:`fix addforce <fix_addforce>`
-* :doc:`fix addtorque <fix_addtorque>`
-* :doc:`fix efield <fix_efield>`
-* :doc:`fix enforce2d <fix_enforce2d>`
-* :doc:`fix indent <fix_indent>`
-* :doc:`fix lineforce <fix_lineforce>`
-* :doc:`fix planeforce <fix_planeforce>`
-* :doc:`fix setforce <fix_setforce>`
-* :doc:`fix spring <fix_spring>`
-* :doc:`fix spring/self <fix_spring_self>`
-* :doc:`fix viscous <fix_viscous>`
-* :doc:`fix wall <fix_wall>`
-* :doc:`fix wall/region <fix_wall_region>`
-
-.. note::
-
- Some fixes which are invoked during minimization have an
- associated potential energy. For that energy to be included in the
- total potential energy of the system (the quantity being minimized),
- you MUST enable the :doc:`fix_modify <fix_modify>` *energy* option for
- that fix. The doc pages for individual :doc:`fix <fix>` commands
- specify if this should be done.
-
-
-----------
-
-
-Restrictions
-""""""""""""
-
-
-Features that are not yet implemented are listed here, in case someone
-knows how they could be coded:
-
-It is an error to use :doc:`fix shake <fix_shake>` with minimization
-because it turns off bonds that should be included in the potential
-energy of the system. The effect of a fix shake can be approximated
-during a minimization by using stiff spring constants for the bonds
-and/or angles that would normally be constrained by the SHAKE
-algorithm.
-
-:doc:`Fix rigid <fix_rigid>` is also not supported by minimization. It
-is not an error to have it defined, but the energy minimization will
-not keep the defined body(s) rigid during the minimization. Note that
-if bonds, angles, etc internal to a rigid body have been turned off
-(e.g. via :doc:`neigh_modify exclude <neigh_modify>`), they will not
-contribute to the potential energy which is probably not what is
-desired.
-
-Pair potentials that produce torque on a particle (e.g. :doc:`granular potentials <pair_gran>` or the :doc:`GayBerne potential <pair_gayberne>` for ellipsoidal particles) are not
-relaxed by a minimization. More specifically, radial relaxations are
-induced, but no rotations are induced by a minimization, so such a
-* etol = stopping tolerance for energy (energy units)
-* ftol = stopping tolerance for force (force units)
-* N1 = max # of iterations (timesteps) to run initial NEB
-* N2 = max # of iterations (timesteps) to run barrier-climbing NEB
-* Nevery = print replica energies and reaction coordinates every this many timesteps
-* file-style= *final* or *each* or *none*
-.. parsed-literal::
-
- *final* arg = filename
- filename = file with initial coords for final replica
- coords for intermediate replicas are linearly interpolated between first and last replica
- *each* arg = filename
- filename = unique filename for each replica (except first) with its initial coords
- *none* arg = no argument
- all replicas assumed to already have their initial coords
-
-
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- neb 0.1 0.0 1000 500 50 final coords.final
- neb 0.0 0.001 1000 500 50 each coords.initial.$i
- neb 0.0 0.001 1000 500 50 none
-
-Description
-"""""""""""
-
-Perform a nudged elastic band (NEB) calculation using multiple
-replicas of a system. Two or more replicas must be used; the first
-and last are the end points of the transition path.
-
-NEB is a method for finding both the atomic configurations and height
-of the energy barrier associated with a transition state, e.g. for an
-atom to perform a diffusive hop from one energy basin to another in a
-coordinated fashion with its neighbors. The implementation in LAMMPS
-follows the discussion in these 3 papers: :ref:`(Henkelman1) <Henkelman1>`,
-:ref:`(Henkelman2) <Henkelman2>`, and :ref:`(Nakano) <Nakano>`.
-
-Each replica runs on a partition of one or more processors. Processor
-partitions are defined at run-time using the -partition command-line
-switch; see :ref:`Section_start 7 <start_7>` of the
-manual. Note that if you have MPI installed, you can run a
-multi-replica simulation with more replicas (partitions) than you have
-physical processors, e.g you can run a 10-replica simulation on just
-one or two processors. You will simply not get the performance
-speed-up you would see with one or more physical processors per
-replica. See :ref:`this section <howto_5>` of the manual
-for further discussion.
-
-.. note::
-
- The current NEB implementation in LAMMPS only allows there to be
- one processor per replica.
-
-.. note::
-
- As explained below, a NEB calculation perfoms a damped dynamics
- minimization across all the replicas. The mimimizer uses whatever
- timestep you have defined in your input script, via the
- :doc:`timestep <timestep>` command. Often NEB will converge more
- quickly if you use a timestep about 10x larger than you would normally
- use for dynamics simulations.
-
-When a NEB calculation is performed, it is assumed that each replica
-is running the same system, though LAMMPS does not check for this.
-I.e. the simulation domain, the number of atoms, the interaction
-potentials, and the starting configuration when the neb command is
-issued should be the same for every replica.
-
-In a NEB calculation each atom in a replica is connected to the same
-atom in adjacent replicas by springs, which induce inter-replica
-forces. These forces are imposed by the :doc:`fix neb <fix_neb>`
-command, which must be used in conjunction with the neb command. The
-group used to define the fix neb command defines the NEB atoms which
-are the only ones that inter-replica springs are applied to. If the
-group does not include all atoms, then non-NEB atoms have no
-inter-replica springs and the forces they feel and their motion is
-computed in the usual way due only to other atoms within their
-replica. Conceptually, the non-NEB atoms provide a background force
-field for the NEB atoms. They can be allowed to move during the NEB
-minimiation procedure (which will typically induce different
-coordinates for non-NEB atoms in different replicas), or held fixed
-using other LAMMPS commands such as `fix setforce <fix_setforce>`_. Note
-that the :doc:`partition <partition>` command can be used to invoke a
-command on a subset of the replicas, e.g. if you wish to hold NEB or
-non-NEB atoms fixed in only the end-point replicas.
-
-The initial atomic configuration for each of the replicas can be
-specified in different manners via the *file-style* setting, as
-discussed below. Only atoms whose initial coordinates should differ
-from the current configuration need be specified.
-
-Conceptually, the initial configuration for the first replica should
-be a state with all the atoms (NEB and non-NEB) having coordinates on
-one side of the energy barrier. A perfect energy minimum is not
-required, since atoms in the first replica experience no spring forces
-from the 2nd replica. Thus the damped dynamics minimizaiton will
-drive the first replica to an energy minimum if it is not already
-there. However, you will typically get better convergence if the
-initial state is already at a minimum. For example, for a system with
-a free surface, the surface should be fully relaxed before attempting
-a NEB calculation.
-
-Likewise, the initial configuration of the final replica should be a
-state with all the atoms (NEB and non-NEB) on the other side of the
-energy barrier. Again, a perfect energy minimum is not required,
-since the atoms in the last replica also experience no spring forces
-from the next-to-last replica, and thus the damped dynamics
-minimization will drive it to an energy minimum.
-
-As explained below, the initial configurations of intermediate
-replicas can be atomic coordinates interpolated in a linear fashion
-between the first and last replicas. This is often adequate state for
-simple transitions. For more complex transitions, it may lead to slow
-convergence or even bad results if the minimum energy path (MEP, see
-below) of states over the barrier cannot be correctly converged to
-from such an initial configuration. In this case, you will want to
-generate initial states for the intermediate replicas that are
-geometrically closer to the MEP and read them in.
-
-
-----------
-
-
-For a *file-style* setting of *final*\ , a filename is specified which
-contains atomic coordinates for zero or more atoms, in the format
-described below. For each atom that appears in the file, the new
-coordinates are assigned to that atom in the final replica. Each
-intermediate replica also assigns a new position to that atom in an
-interpolated manner. This is done by using the current position of
-the atom as the starting point and the read-in position as the final
-point. The distance between them is calculated, and the new position
-is assigned to be a fraction of the distance. E.g. if there are 10
-replicas, the 2nd replica will assign a position that is 10% of the
-distance along a line between the starting and final point, and the
-9th replica will assign a position that is 90% of the distance along
-the line. Note that this procedure to produce consistent coordinates
-across all the replicas, the current coordinates need to be the same
-in all replicas. LAMMPS does not check for this, but invalid initial
-configurations will likely result if it is not the case.
-
-.. note::
-
- The "distance" between the starting and final point is
- calculated in a minimum-image sense for a periodic simulation box.
- This means that if the two positions are on opposite sides of a box
- (periodic in that dimension), the distance between them will be small,
- because the periodic image of one of the atoms is close to the other.
- Similarly, even if the assigned position resulting from the
- interpolation is outside the periodic box, the atom will be wrapped
- back into the box when the NEB calculation begins.
-
-For a *file-style* setting of *each*\ , a filename is specified which is
-assumed to be unique to each replica. This can be done by
-using a variable in the filename, e.g.
-
-.. parsed-literal::
-
- variable i equal part
- neb 0.0 0.001 1000 500 50 each coords.initial.$i
-
-which in this case will substitute the partition ID (0 to N-1) for the
-variable I, which is also effectively the replica ID. See the
-:doc:`variable <variable>` command for other options, such as using
-world-, universe-, or uloop-style variables.
-
-Each replica (except the first replica) will read its file, formatted
-as described below, and for any atom that appears in the file, assign
-the specified coordinates to its atom. The various files do not need
-to contain the same set of atoms.
-
-For a *file-style* setting of *none*\ , no filename is specified. Each
-replica is assumed to already be in its initial configuration at the
-time the neb command is issued. This allows each replica to define
-its own configuration by reading a replica-specific data or restart or
-dump file, via the :doc:`read_data <read_data>`,
-:doc:`read_restart <read_restart>`, or :doc:`read_dump <read_dump>`
-commands. The replica-specific names of these files can be specified
-as in the discussion above for the *each* file-style. Also see the
-section below for how a NEB calculation can produce restart files, so
-that a long calculation can be restarted if needed.
-
-.. note::
-
- None of the *file-style* settings change the initial
- configuration of any atom in the first replica. The first replica
- must thus be in the correct initial configuration at the time the neb
- command is issued.
-
-
-----------
-
-
-A NEB calculation proceeds in two stages, each of which is a
-minimization procedure, performed via damped dynamics. To enable
-this, you must first define a damped dynamics
-:doc:`min_style <min_style>`, such as *quickmin* or *fire*\ . The *cg*\ ,
-*sd*\ , and *hftn* styles cannot be used, since they perform iterative
-line searches in their inner loop, which cannot be easily synchronized
-across multiple replicas.
-
-The minimizer tolerances for energy and force are set by *etol* and
-*ftol*\ , the same as for the :doc:`minimize <minimize>` command.
-
-A non-zero *etol* means that the NEB calculation will terminate if the
-energy criterion is met by every replica. The energies being compared
-to *etol* do not include any contribution from the inter-replica
-forces, since these are non-conservative. A non-zero *ftol* means
-that the NEB calculation will terminate if the force criterion is met
-by every replica. The forces being compared to *ftol* include the
-inter-replica forces between an atom and its images in adjacent
-replicas.
-
-The maximum number of iterations in each stage is set by *N1* and
-*N2*\ . These are effectively timestep counts since each iteration of
-damped dynamics is like a single timestep in a dynamics
-:doc:`run <run>`. During both stages, the potential energy of each
-replica and its normalized distance along the reaction path (reaction
-coordinate RD) will be printed to the screen and log file every
-*Nevery* timesteps. The RD is 0 and 1 for the first and last replica.
-For intermediate replicas, it is the cumulative distance (normalized
-by the total cumulative distance) between adjacent replicas, where
-"distance" is defined as the length of the 3N-vector of differences in
-atomic coordinates, where N is the number of NEB atoms involved in the
-transition. These outputs allow you to monitor NEB's progress in
-finding a good energy barrier. *N1* and *N2* must both be multiples
-of *Nevery*\ .
-
-In the first stage of NEB, the set of replicas should converge toward
-the minimum energy path (MEP) of conformational states that transition
-over the barrier. The MEP for a barrier is defined as a sequence of
-3N-dimensional states that cross the barrier at its saddle point, each
-of which has a potential energy gradient parallel to the MEP itself.
-The replica states will also be roughly equally spaced along the MEP
-due to the inter-replica spring force added by the :doc:`fix neb <fix_neb>` command.
-
-In the second stage of NEB, the replica with the highest energy
-is selected and the inter-replica forces on it are converted to a
-force that drives its atom coordinates to the top or saddle point of
-the barrier, via the barrier-climbing calculation described in
-:ref:`(Henkelman2) <Henkelman2>`. As before, the other replicas rearrange
-themselves along the MEP so as to be roughly equally spaced.
-
-When both stages are complete, if the NEB calculation was successful,
-one of the replicas should be an atomic configuration at the top or
-saddle point of the barrier, the potential energies for the set of
-replicas should represent the energy profile of the barrier along the
-MEP, and the configurations of the replicas should be a sequence of
-configurations along the MEP.
-
-
-----------
-
-
-A few other settings in your input script are required or advised to
-perform a NEB calculation. See the NOTE about the choice of timestep
-at the beginning of this doc page.
-
-An atom map must be defined which it is not by default for :doc:`atom_style atomic <atom_style>` problems. The :doc:`atom_modify map <atom_modify>` command can be used to do this.
-
-The "atom_modify sort 0 0.0" command should be used to turn off atom
-sorting.
-
-.. note::
-
- This sorting restriction will be removed in a future version of
- NEB in LAMMPS.
-
-The minimizers in LAMMPS operate on all atoms in your system, even
-non-NEB atoms, as defined above. To prevent non-NEB atoms from moving
-during the minimization, you should use the :doc:`fix setforce <fix_setforce>` command to set the force on each of those
-atoms to 0.0. This is not required, and may not even be desired in
-some cases, but if those atoms move too far (e.g. because the initial
-state of your system was not well-minimized), it can cause problems
-for the NEB procedure.
-
-The damped dynamics :doc:`minimizers <min_style>`, such as *quickmin*
-and *fire*\ ), adjust the position and velocity of the atoms via an
-Euler integration step. Thus you must define an appropriate
-:doc:`timestep <timestep>` to use with NEB. As mentioned above, NEB
-will often converge more quickly if you use a timestep about 10x
-larger than you would normally use for dynamics simulations.
-
-
-----------
-
-
-Each file read by the neb command containing atomic coordinates used
-to initialize one or more replicas must be formatted as follows.
-
-The file can be ASCII text or a gzipped text file (detected by a .gz
-suffix). The file can contain initial blank lines or comment lines
-starting with "#" which are ignored. The first non-blank, non-comment
-line should list N = the number of lines to follow. The N successive
-lines contain the following information:
-
-.. parsed-literal::
-
- ID1 x1 y1 z1
- ID2 x2 y2 z2
- ...
- IDN xN yN zN
-
-The fields are the the atom ID, followed by the x,y,z coordinates.
-The lines can be listed in any order. Additional trailing information
-on the line is OK, such as a comment.
-
-Note that for a typical NEB calculation you do not need to specify
-initial coordinates for very many atoms to produce differing starting
-and final replicas whose intermediate replicas will converge to the
-energy barrier. Typically only new coordinates for atoms
-geometrically near the barrier need be specified.
-
-Also note there is no requirement that the atoms in the file
-correspond to the NEB atoms in the group defined by the :doc:`fix neb <fix_neb>` command. Not every NEB atom need be in the file,
-and non-NEB atoms can be listed in the file.
-
-
-----------
-
-
-Four kinds of output can be generated during a NEB calculation: energy
-barrier statistics, thermodynamic output by each replica, dump files,
-and restart files.
-
-When running with multiple partitions (each of which is a replica in
-this case), the print-out to the screen and master log.lammps file
-contains a line of output, printed once every *Nevery* timesteps. It
-contains the timestep, the maximum force per replica, the maximum
-force per atom (in any replica), potential gradients in the initial,
- final, and climbing replicas,
-the forward and backward energy barriers,
-the total reaction coordinate (RDT), and
-the normalized reaction coordinate and potential energy of each replica.
-
-The "maximum force per replica" is
-the two-norm of the 3N-length force vector for the atoms in each
-replica, maximized across replicas, which is what the *ftol* setting
-is checking against. In this case, N is all the atoms in each
-replica. The "maximum force per atom" is the maximum force component
-of any atom in any replica. The potential gradients are the two-norm
-of the 3N-length force vector solely due to the interaction potential i.e.
-without adding in inter-replica forces. Note that inter-replica forces
-are zero in the initial and final replicas, and only affect
-the direction in the climbing replica. For this reason, the "maximum
-force per replica" is often equal to the potential gradient in the
-climbing replica. In the first stage of NEB, there is no climbing
-replica, and so the potential gradient in the highest energy replica
-is reported, since this replica will become the climbing replica
-in the second stage of NEB.
-
-The "reaction coordinate" (RD) for each
-replica is the two-norm of the 3N-length vector of distances between
-its atoms and the preceding replica's atoms, added to the RD of the
-preceding replica. The RD of the first replica RD1 = 0.0;
-the RD of the final replica RDN = RDT, the total reaction coordinate.
-The normalized RDs are divided by RDT,
-so that they form a monotonically increasing sequence
-from zero to one. When computing RD, N only includes the atoms
-being operated on by the fix neb command.
-
-The forward (reverse) energy barrier is the potential energy of the highest
-replica minus the energy of the first (last) replica.
-
-When running on multiple partitions, LAMMPS produces additional log
-files for each partition, e.g. log.lammps.0, log.lammps.1, etc. For a
-NEB calculation, these contain the thermodynamic output for each
-replica.
-
-If :doc:`dump <dump>` commands in the input script define a filename
-that includes a *universe* or *uloop* style :doc:`variable <variable>`,
-then one dump file (per dump command) will be created for each
-replica. At the end of the NEB calculation, the final snapshot in
-each file will contain the sequence of snapshots that transition the
-system over the energy barrier. Earlier snapshots will show the
-convergence of the replicas to the MEP.
-
-Likewise, :doc:`restart <restart>` filenames can be specified with a
-*universe* or *uloop* style :doc:`variable <variable>`, to generate
-restart files for each replica. These may be useful if the NEB
-calculation fails to converge properly to the MEP, and you wish to
-restart the calculation from an intermediate point with altered
-parameters.
-
-There are 2 Python scripts provided in the tools/python directory,
-neb_combine.py and neb_final.py, which are useful in analyzing output
-from a NEB calculation. Assume a NEB simulation with M replicas, and
-the NEB atoms labelled with a specific atom type.
-
-The neb_combine.py script extracts atom coords for the NEB atoms from
-all M dump files and creates a single dump file where each snapshot
-contains the NEB atoms from all the replicas and one copy of non-NEB
-atoms from the first replica (presumed to be identical in other
-replicas). This can be visualized/animated to see how the NEB atoms
-relax as the NEB calculation proceeds.
-
-The neb_final.py script extracts the final snapshot from each of the M
-dump files to create a single dump file with M snapshots. This can be
-visualized to watch the system make its transition over the energy
-barrier.
-
-To illustrate, here are images from the final snapshot produced by the
-neb_combine.py script run on the dump files produced by the two
-example input scripts in examples/neb. Click on them to see a larger
-image.
-
-.. thumbnail:: JPG/hop1.jpg
-
-.. thumbnail:: JPG/hop2.jpg
-
-
-----------
-
-
-Restrictions
-""""""""""""
-
-
-This command can only be used if LAMMPS was built with the REPLICA
-package. See the :ref:`Making LAMMPS <start_3>` section
-Styles *brownian* and *brownian/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 *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 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 = *born/coul/long/cs* or *buck/coul/long/cs*
-* args = list of arguments for a particular style
-
-.. parsed-literal::
-
- *born/coul/long/cs* args = cutoff (cutoff2)
- cutoff = global cutoff for non-Coulombic (and Coulombic if only 1 arg) (distance units)
- cutoff2 = global cutoff for Coulombic (optional) (distance units)
- *buck/coul/long/cs* args = cutoff (cutoff2)
- cutoff = global cutoff for Buckingham (and Coulombic if only 1 arg) (distance units)
- cutoff2 = global cutoff for Coulombic (optional) (distance units)
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- pair_style born/coul/long/cs 10.0 8.0
- pair_coeff 1 1 6.08 0.317 2.340 24.18 11.51
-
-.. parsed-literal::
-
- pair_style buck/coul/long/cs 10.0
- pair_style buck/coul/long/cs 10.0 8.0
- pair_coeff * * 100.0 1.5 200.0
- pair_coeff 1 1 100.0 1.5 200.0 9.0
-
-Description
-"""""""""""
-
-These pair styles are designed to be used with the adiabatic
-core/shell model of :ref:`(Mitchell and Finchham) <MitchellFinchham>`. See
-:ref:`Section_howto 25 <howto_25>` of the manual for an
-overview of the model as implemented in LAMMPS.
-
-These pair styles are identical to the :doc:`pair_style born/coul/long <pair_born>` and :doc:`pair_style buck/coul/long <pair_buck>` styles, except they correctly treat the
-special case where the distance between two charged core and shell
-atoms in the same core/shell pair approach r = 0.0. This needs
-special treatment when a long-range solver for Coulombic interactions
-is also used, i.e. via the :doc:`kspace_style <kspace_style>` command.
-
-More specifically, the short-range Coulomb interaction between a core
-and its shell should be turned off using the
-:doc:`special_bonds <special_bonds>` command by setting the 1-2 weight
-to 0.0, which works because the core and shell atoms are bonded to
-each other. This induces a long-range correction approximation which
-fails at small distances (~< 10e-8). Therefore, the Coulomb term which
-is used to calculate the correction factor is extended by a minimal
-distance (r_min = 1.0-6) when the interaction between a core/shell
-pair is treated, as follows
-
-.. image:: Eqs/pair_cs.jpg
- :align: center
-
-where C is an energy-conversion constant, Qi and Qj are the charges on
-the core and shell, epsilon is the dielectric constant and r_min is the
-minimal distance.
-
-Restrictions
-""""""""""""
-
-
-These pair styles are part of the CORESHELL package. They are only
-enabled if LAMMPS was built with that package. See the :ref:`Making LAMMPS <start_3>` section for more info.
-
-Related commands
-""""""""""""""""
-
-:doc:`pair_coeff <pair_coeff>`, :doc:`pair_style born <pair_born>`,
-:doc:`pair_style buck <pair_buck>`
-
-**Default:** none
-
-
-----------
-
-
-.. _MitchellFinchham:
-
-
-
-**(Mitchell and Finchham)** Mitchell, Finchham, J Phys Condensed Matter,
-* 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)
-* 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)
- pair_style style mu flaglog cutinner cutoff gdot flagHI flagVF
-
-* style = *lubricateU* or *lubricateU/poly*
-* mu = dynamic viscosity (dynamic viscosity units)
-* flaglog = 0/1 to exclude/include log terms in the lubrication approximation
-* cutinner = inner cut off distance (distance units)
-* cutoff = outer cutoff for interactions (distance units)
-* gdot = shear rate (1/time units)
-* flagHI (optional) = 0/1 to exclude/include 1/r hydrodynamic interactions
-* flagVF (optional) = 0/1 to exclude/include volume fraction corrections in the long-range isotropic terms
-
-**Examples:** (all assume radius = 1)
-
-.. parsed-literal::
-
- pair_style lubricateU 1.5 1 2.01 2.5 0.01 1 1
- pair_coeff 1 1 2.05 2.8
- pair_coeff * *
-
-Description
-"""""""""""
-
-Styles *lubricateU* and *lubricateU/poly* compute velocities and
-angular velocities for finite-size spherical particles such that the
-hydrodynamic interaction balances the force and torque due to all
-other types of interactions.
-
-The interactions have 2 components. The first is
-Ball-Melrose lubrication terms via the formulas in :ref:`(Ball and Melrose) <Ball>`
-
-.. image:: Eqs/pair_lubricate.jpg
- :align: center
-
-which represents the dissipation W between two nearby particles due to
-their relative velocities in the presence of a background solvent with
-viscosity *mu*\ . Note that this is dynamic viscosity which has units of
-mass/distance/time, not kinematic viscosity.
-
-The Asq (squeeze) term is the strongest and is included as long as
-*flagHI* is set to 1 (default). It scales as 1/gap where gap is the
-separation between the surfaces of the 2 particles. The Ash (shear)
-and Apu (pump) terms are only included if *flaglog* is set to 1. They
-are the next strongest interactions, and the only other singular
-interaction, and scale as log(gap). Note that *flaglog* = 1 and
-*flagHI* = 0 is invalid, and will result in a warning message, after
-which *flagHI* will be set to 1. The Atw (twist) term is currently not
-included. It is typically a very small contribution to the lubrication
-forces.
-
-The *flagHI* and *flagVF* settings are optional. Neither should be
-used, or both must be defined.
-
-*Cutinner* sets the minimum center-to-center separation that will be
-used in calculations irrespective of the actual separation. *Cutoff*
-is the maximum center-to-center separation at which an interaction is
-computed. Using a *cutoff* less than 3 radii is recommended if
-*flaglog* is set to 1.
-
-The other component is due to the Fast Lubrication Dynamics (FLD)
-approximation, described in :ref:`(Kumar) <Kumar>`. The equation being
-solved to balance the forces and torques is
-
-.. image:: Eqs/fld2.jpg
- :align: center
-
-where U represents the velocities and angular velocities of the
-particles, U^\ *infty* represents the velocities and the angular
-velocities of the undisturbed fluid, and E^\ *infty* represents the rate
-of strain tensor of the undisturbed fluid flow with viscosity
-*mu*\ . Again, note that this is dynamic viscosity which has units of
-mass/distance/time, not kinematic viscosity. Volume fraction
-corrections to R_FU are included if *flagVF* is set to 1 (default).
-
-F\ *rest* represents the forces and torques due to all other types of
-interactions, e.g. Brownian, electrostatic etc. Note that this
-algorithm neglects the inertial terms, thereby removing the
-restriction of resolving the small interial time scale, which may not
-be of interest for colloidal particles. This pair style solves for
-the velocity such that the hydrodynamic force balances all other types
-of forces, thereby resulting in a net zero force (zero inertia limit).
-When defining this pair style, it must be defined last so that when
-this style is invoked all other types of forces have already been
-computed. For the same reason, it won't work if additional non-pair
-styles are defined (such as bond or Kspace forces) as they are
-calculated in LAMMPS after the pairwise interactions have been
-computed.
-
-.. note::
-
- When using these styles, the these pair styles are designed to
- be used with implicit time integration and a correspondingly larger
- timestep. Thus either :doc:`fix nve/noforce <fix_nve_noforce>` should
- be used for spherical particles defined via :doc:`atom_style sphere <atom_style>` or :doc:`fix nve/asphere/noforce <fix_nve_asphere_noforce>` should be used for
- spherical particles defined via :doc:`atom_style ellipsoid <atom_style>`. This is because the velocity and angular
- momentum of each particle is set by the pair style, and should not be
-The *smd/tlsph* style computes particle interactions according to continuum mechanics constitutive laws and a Total-Lagrangian Smooth-Particle Hydrodynamics algorithm.
-
-This pair style is invoked with the following command:
-
-.. parsed-literal::
-
- pair_style smd/tlsph
- pair_coeff i j *COMMON rho0 E nu Q1 Q2 hg Cp &
- *END
-
-Here, *i* and *j* denote the *LAMMPS* particle types for which this pair style is
-defined. Note that *i* and *j* must be equal, i.e., no *tlsph* cross interactions
-between different particle types are allowed.
-In contrast to the usual *LAMMPS* *pair coeff* definitions, which are given solely a
-number of floats and integers, the *tlsph* *pair coeff* definition is organised using
-keywords. These keywords mark the beginning of different sets of parameters for particle properties,
-material constitutive models, and damage models. The *pair coeff* line must be terminated with
-the **END* keyword. The use the line continuation operator *&* is recommended. A typical
-invocation of the *tlsph* for a solid body would consist of an equation of state for computing
-the pressure (the diagonal components of the stress tensor), and a material model to compute shear
-stresses (the off-diagonal components of the stress tensor). Damage and failure models can also be added.
-
-Please see the `SMD user guide <USER/smd/SMD_LAMMPS_userguide.pdf>`_ for a complete listing of the possible keywords and material models.
-keyword = **DENSITY_SUMMATION* or **DENSITY_CONTINUITY* and **VELOCITY_GRADIENT* or **NO_VELOCITY_GRADIENT* and **GRADIENT_CORRECTION* or **NO_GRADIENT_CORRECTION*
-The *smd/ulsph* style computes particle interactions according to continuum mechanics constitutive laws and an updated Lagrangian Smooth-Particle Hydrodynamics algorithm.
-
-This pair style is invoked similar to the following command:
-Here, *i* and *j* denote the *LAMMPS* particle types for which this pair style is
-defined. Note that *i* and *j* can be different, i.e., *ulsph* cross interactions
-between different particle types are allowed. However, *i*\ --\ *i* respectively *j*\ --\ *j* pair_coeff lines have to preceed a cross interaction.
-In contrast to the usual *LAMMPS* *pair coeff* definitions, which are given solely a
-number of floats and integers, the *ulsph* *pair coeff* definition is organised using
-keywords. These keywords mark the beginning of different sets of parameters for particle properties,
-material constitutive models, and damage models. The *pair coeff* line must be terminated with
-the **END* keyword. The use the line continuation operator *&* is recommended. A typical
-invocation of the *ulsph* for a solid body would consist of an equation of state for computing
-the pressure (the diagonal components of the stress tensor), and a material model to compute shear
-stresses (the off-diagonal components of the stress tensor).
-
-Note that the use of *GRADIENT_CORRECTION can lead to severe numerical instabilities. For a general fluid simulation, *NO_GRADIENT_CORRECTION is recommended.
-
-Please see the `SMD user guide <USER/smd/SMD_LAMMPS_userguide.pdf>`_ for a complete listing of the possible keywords and material models.
-This pair stylecomputes a variable charge SMTB-Q (Second-Moment
-tight-Binding QEq) potential as described in :ref:`SMTB-Q_1 <SMTB-Q_1>` and
-:ref:`SMTB-Q_2 <SMTB-Q_2>`. Briefly, the energy of metallic-oxygen systems
-is given by three contributions:
-
-.. image:: Eqs/pair_smtbq1.jpg
- :align: center
-
-where *E<sub>tot</sub>* is the total potential energy of the system,
-*E<sub>ES</sub>* is the electrostatic part of the total energy,
-*E<sub>OO</sub>* is the interaction between oxygens and
-*E<sub>MO</sub>* is a short-range interaction between metal and oxygen
-atoms. This interactions depend on interatomic distance
-*r<sub>ij</sub>* and/or the charge *Q<sub>i</sub>* of atoms
-*i*\ . Cut-off function enables smooth convergence to zero interaction.
-
-The parameters appearing in the upper expressions are set in the
-ffield.SMTBQ.Syst file where Syst corresponds to the selected system
-(e.g. field.SMTBQ.Al2O3). Exemples for TiO<sub>2</sub>,
-Al<sub>2</sub>O<sub>3</sub> are provided. A single pair_coeff command
-is used with the SMTBQ styles which provides the path to the potential
-file with parameters for needed elements. These are mapped to LAMMPS
-atom types by specifying additional arguments after the potential
-filename in the pair_coeff command. Note that atom type 1 must always
-correspond to oxygen atoms. As an example, to simulate a TiO2 system,
-atom type 1 has to be oxygen and atom type 2 Ti. The following
-pair_coeff command should then be used:
-
-.. parsed-literal::
-
- pair_coeff * * PathToLammps/potentials/ffield.smtbq.TiO2 O Ti
-
-The electrostatic part of the energy consists of two components
-
-self-energy of atom *i* in the form of a second order charge dependent
-polynomial and a long-range Coulombic electrostatic interaction. The
-latter uses the wolf summation method described in :ref:`Wolf <Wolf>`,
-spherically truncated at a longer cutoff, *R<sub>coul</sub>*\ . The
-charge of each ion is modeled by an orbital Slater which depends on
-the principal quantum number (\ *n*\ ) of the outer orbital shared by the
-ion.
-
-Interaction between oxygen, *E<sub>OO</sub>*\ , consists of two parts,
-an attractive and a repulsive part. The attractive part is effective
-only at short range (< r<sub>2</sub><sup>OO</sup>). The attractive
-contribution was optimized to study surfaces reconstruction
-(e.g. :ref:`SMTB-Q_2 <SMTB-Q_2>` in TiO<sub>2</sub>) and is not necessary
-for oxide bulk modeling. The repulsive part is the Pauli interaction
-between the electron clouds of oxygen. The Pauli repulsion and the
-coulombic electrostatic interaction have same cut off value. In the
-ffield.SMTBQ.Syst, the keyword *'buck'* allows to consider only the
-repulsive O-O interactions. The keyword *'buckPlusAttr'* allows to
-consider the repulsive and the attractive O-O interactions.
-
-The short-range interaction between metal-oxygen, *E<sub>MO</sub>* is
-based on the second moment approximation of the density of states with
-a N-body potential for the band energy term,
-*E<sup>i</sup><sub>cov</sub>*\ , and a Born-Mayer type repulsive terms
-as indicated by the keyword *'second_moment'* in the
-ffield.SMTBQ.Syst. The energy band term is given by:
-
-.. image:: Eqs/pair_smtbq2.jpg
- :align: center
-
-where *η<sub>i</sub>* is the stoichiometry of atom *i*\ ,
-*δQ<sub>i</sub>* is the charge delocalization of atom *i*\ ,
-compared to its formal charge
-*Q<sup>F</sup><sub>i</sub>*\ . n<sub>0</sub>, the number of hybridized
-orbitals, is calculated with to the atomic orbitals shared
-*d<sub>i</sub>* and the stoichiometry
-*η<sub>i</sub>*\ . *r<sub>c1</sub>* and *r<sub>c2</sub>* are the two
-cutoff radius around the fourth neighbors in the cutoff function.
-
-In the formalism used here, *ξ<sup>0</sup>* is the energy
-parameter. *ξ<sup>0</sup>* is in tight-binding approximation the
-hopping integral between the hybridized orbitals of the cation and the
-anion. In the literature we find many ways to write the hopping
-integral depending on whether one takes the point of view of the anion
-or cation. These are equivalent vision. The correspondence between the
-two visions is explained in appendix A of the article in the
-SrTiO<sub>3</sub> :ref:`SMTB-Q_3 <SMTB-Q_3>` (parameter *β* shown in
-this article is in fact the *β<sub>O</sub>*\ ). To summarize the
-relationship between the hopping integral *ξ<sup>0</sup>* and the
-others, we have in an oxide C<sub>n</sub>O<sub>m</sub> the following
-relationship:
-
-.. image:: Eqs/pair_smtbq3.jpg
- :align: center
-
-Thus parameter μ, indicated above, is given by : μ = (√n
-+ √m) ⁄ 2
-
-The potential offers the possibility to consider the polarizability of
-the electron clouds of oxygen by changing the slater radius of the
-charge density around the oxygens through the parameters *rBB, rB and
-rS* in the ffield.SMTBQ.Syst. This change in radius is performed
-according to the method developed by E. Maras
-:ref:`SMTB-Q_2 <SMTB-Q_2>`. This method needs to determine the number of
-nearest neighbors around the oxygen. This calculation is based on
-first (\ *r<sub>1n</sub>*\ ) and second (\ *r<sub>2n</sub>*\ ) distances
-neighbors.
-
-The SMTB-Q potential is a variable charge potential. The equilibrium
-charge on each atom is calculated by the electronegativity
-equalization (QEq) method. See :ref:`Rick <Rick>` for further detail. One
-can adjust the frequency, the maximum number of iterative loop and the
-convergence of the equilibrium charge calculation. To obtain the
-energy conservation in NVE thermodynamic ensemble, we recommend to use
-a convergence parameter in the interval 10<sup>-5</sup> -
-10<sup>-6</sup> eV.
-
-The ffield.SMTBQ.Syst files are provided for few systems. They consist
-of nine parts and the lines beginning with '#' are comments (note that
-the number of comment lines matter). The first sections are on the
-potential parameters and others are on the simulation options and
-might be modified. Keywords are character type and must be enclosed in
-quotation marks ('').
-
-1) Number of different element in the oxide:
-
-* N<sub>elem</sub>= 2 or 3
-* Divided line
-
-2) Atomic parameters
-
-For the anion (oxygen)
-
-* Name of element (char) and stoichiometry in oxide
-* Formal charge and mass of element
-* Principal quantic number of outer orbital (\ *n*\ ), electronegativity (\ *χ<sup>0</sup><sub>i</simulationub>*\ ) and hardness (\ *J<sup>0</sup><sub>i</sub>*\ )
-* Ionic radius parameters : max coordination number (\ *coordBB* = 6 by default), bulk coordination number *(coordB)*\ , surface coordination number *(coordS)* and *rBB, rB and rS* the slater radius for each coordination number. (<b>note : If you don't want to change the slater radius, use three identical radius values</b>)
-* Number of orbital shared by the element in the oxide (\ *d<sub>i</sub>*\ )
-* Divided line
-
-For each cations (metal):
-
-* Name of element (char) and stoichiometry in oxide
-* Formal charge and mass of element
-* Number of electron in outer orbital *(ne)*\ , electronegativity (\ *χ<sup>0</sup><sub>i</simulationub>*\ ), hardness (\ *J<sup>0</sup><sub>i</sub>*\ ) and *r<sub>Salter</sub>* the slater radius for the cation.
-* Number of orbitals shared by the elements in the oxide (\ *d<sub>i</sub>*\ )
-* Divided line
-
-3) Potential parameters:
-
-* Keyword for element1, element2 and interaction potential ('second_moment' or 'buck' or 'buckPlusAttr') between element 1 and 2. If the potential is 'second_moment', specify 'oxide' or 'metal' for metal-oxygen or metal-metal interactions respectively.
-* Potential parameter: <pre><br/> If type of potential is 'second_moment' : *A (eV)*\ , *p*\ , *ξ<sup>0</sup>* (eV) and *q* <br/> *r<sub>c1</sub>* (Å), *r<sub>c2</sub>* (Å) and *r<sub>0</sub>* (Å) <br/> If type of potential is 'buck' : *C* (eV) and *ρ* (Å) <br/> If type of potential is 'buckPlusAttr' : *C* (eV) and *ρ* (Å) <br/> *D* (eV), *B* (Å<sup>-1</sup>), *r<sub>1</sub><sup>OO</sup>* (Å) and *r<sub>2</sub><sup>OO</sup>* (Å) </pre>
-* Divided line
-
-4) Tables parameters:
-
-* Cutoff radius for the Coulomb interaction (\ *R<sub>coul</sub>*\ )
-* Starting radius (\ *r<sub>min</sub>* = 1,18845 Å) and increments (\ *dr* = 0,001 Å) for creating the potential table.
-* Divided line
-
-5) Rick model parameter:
-
-* *Nevery* : parameter to set the frequency (\ *1/Nevery*\ ) of the charge resolution. The charges are evaluated each *Nevery* time steps.
-* Max number of iterative loop (\ *loopmax*\ ) and precision criterion (\ *prec*\ ) in eV of the charge resolution
-* Divided line
-
-6) Coordination parameter:
-
-* First (\ *r<sub>1n</sub>*\ ) and second (\ *r<sub>2n</sub>*\ ) neighbor distances in Å
-* Divided line
-
-7) Charge initialization mode:
-
-* Keyword (\ *QInitMode*\ ) and initial oxygen charge (\ *Q<sub>init</sub>*\ ). If keyword = 'true', all oxygen charges are initially set equal to *Q<sub>init</sub>*\ . The charges on the cations are initially set in order to respect the neutrality of the box. If keyword = 'false', all atom charges are initially set equal to 0 if you use "create_atom"#create_atom command or the charge specified in the file structure using :doc:`read_data <read_data>` command.
-* Divided line
-
-8) Mode for the electronegativity equalization (Qeq)
-
-* Keyword mode: <pre> <br/> QEqAll (one QEq group) | no parameters <br/> QEqAllParallel (several QEq groups) | no parameters <br/> Surface | zlim (QEq only for z>zlim) </pre>
-* Parameter if necessary
-* Divided line
-
-9) Verbose
-
-* If you want the code to work in verbose mode or not : 'true' or 'false'
-* If you want to print or not in file 'Energy_component.txt' the three main contributions to the energy of the system according to the description presented above : 'true' or 'false' and *N<sub>Energy</sub>*\ . This option writes in file every *N<sub>Energy</sub>* time step. If the value is 'false' then *N<sub>Energy</sub>* = 0. The file take into account the possibility to have several QEq group *g* then it writes: time step, number of atoms in group *g*\ , electrostatic part of energy, *E<sub>ES</sub>*\ , the interaction between oxygen, *E<sub>OO</sub>*\ , and short range metal-oxygen interaction, *E<sub>MO</sub>*\ .
-* If you want to print in file 'Electroneg_component.txt' the electronegativity component (\ *∂E<sub>tot</sub> ⁄∂Q<sub>i</sub>*\ ) or not: 'true' or 'false' and *N<sub>Electroneg</sub>*\ .This option writes in file every *N<sub>Electroneg</sub>* time step. If the value is 'false' then *N<sub>Electroneg</sub>* = 0. The file consist in atom number *i*\ , atom type (1 for oxygen and # higher than 1 for metal), atom position: *x*\ , *y* and *z*\ , atomic charge of atom *i*\ , electrostatic part of atom *i* electronegativity, covalent part of atom *i* electronegativity, the hopping integral of atom *i* *(Zβ<sup>2</sup>)<sub>i<sub>* and box electronegativity.
-
-.. note::
-
- This last option slows down the calculation dramatically. Use
-This pair style does not support the :doc:`pair_modify <pair_modify>`
-shift option for the energy of the pair interaction. Note that as
-discussed above, the energy term is already shifted to be 0.0 at the
-cutoff distance *rc*\ .
-
-The :doc:`pair_modify <pair_modify>` table option is not relevant for
-this pair style.
-
-This pair style does not support the :doc:`pair_modify <pair_modify>`
-tail option for adding long-range tail corrections to energy and
-pressure.
-
-This pair style writes global and per-atom information to :doc:`binary restart files <restart>`. Pair srp should be used with :doc:`pair_style hybrid <pair_hybrid>`, thus the pair_coeff commands need to be
-specified in the input script when reading a restart file.
-
-This pair style can only be used via the *pair* keyword of the
-:doc:`run_style respa <run_style>` command. It does not support the
-*inner*\ , *middle*\ , *outer* keywords.
-
-
-----------
-
-
-Restrictions
-""""""""""""
-
-
-This pair style is part of the USER-MISC package. It is only enabled
-if LAMMPS was built with that package. See the Making LAMMPS section
-for more info.
-
-This pair style must be used with :doc:`pair_style hybrid <pair_hybrid>`.
-
-This pair style requires the :doc:`newton <newton>` command to be *on*
-* keyword = *add* or *offset* or *shift* or *extra/atom/types* or *extra/bond/types* or *extra/angle/types* or *extra/dihedral/types* or *extra/improper/types* or *group* or *nocoeff* or *fix*
-.. parsed-literal::
-
- *add* arg = *append* or *Nstart* or *merge*
- append = add new atoms with IDs appended to current IDs
- Nstart = add new atoms with IDs starting with Nstart
- merge = add new atoms with their IDs unchanged
- *offset* args = toff boff aoff doff ioff
- toff = offset to add to atom types
- boff = offset to add to bond types
- aoff = offset to add to angle types
- doff = offset to add to dihedral types
- ioff = offset to add to improper types
- *shift* args = Sx Sy Sz
- Sx,Sy,Sz = distance to shift atoms when adding to system (distance units)
- *extra/atom/types* arg = # of extra atom types
- *extra/bond/types* arg = # of extra bond types
- *extra/angle/types* arg = # of extra angle types
- *extra/dihedral/types* arg = # of extra dihedral types
- *extra/improper/types* arg = # of extra improper types
-* style = *atom* or *type* or *mol* or *group* or *region*
-* ID = atom ID range or type range or mol ID range or group ID or region ID
-* one or more keyword/value pairs may be appended
-* keyword = *type* or *type/fraction* or *mol* or *x* or *y* or *z* or *charge* or *dipole* or *dipole/random* or *quat* or *quat/random* or *diameter* or *shape* or *length* or *tri* or *theta* or *theta/random* or *angmom* or *omega* or *mass* or *density* or *volume* or *image* or *bond* or *angle* or *dihedral* or *improper* or *meso/e* or *meso/cv* or *meso/rho* or *smd/contact/radius* or *smd/mass/density* or *dpd/theta* or *i_name* or *d_name*
-.. parsed-literal::
-
- *type* value = atom type
- value can be an atom-style variable (see below)
- *type/fraction* values = type fraction seed
- type = new atom type
- fraction = fraction of selected atoms to set to new atom type
- seed = random # seed (positive integer)
- *mol* value = molecule ID
- value can be an atom-style variable (see below)
- *x*\ ,\ *y*\ ,\ *z* value = atom coordinate (distance units)
- value can be an atom-style variable (see below)
- *charge* value = atomic charge (charge units)
- value can be an atom-style variable (see below)
- *dipole* values = x y z
- x,y,z = orientation of dipole moment vector
- any of x,y,z can be an atom-style variable (see below)
- *dipole/random* value = seed Dlen
- seed = random # seed (positive integer) for dipole moment orientations
- Dlen = magnitude of dipole moment (dipole units)
- *quat* values = a b c theta
- a,b,c = unit vector to rotate particle around via right-hand rule
- theta = rotation angle (degrees)
- any of a,b,c,theta can be an atom-style variable (see below)
- *quat/random* value = seed
- seed = random # seed (positive integer) for quaternion orientations
- *diameter* value = diameter of spherical particle (distance units)
- value can be an atom-style variable (see below)
- *shape* value = Sx Sy Sz
- Sx,Sy,Sz = 3 diameters of ellipsoid (distance units)
- *length* value = len
- len = length of line segment (distance units)
- len can be an atom-style variable (see below)
- *tri* value = side
- side = side length of equilateral triangle (distance units)
- side can be an atom-style variable (see below)
- *theta* value = angle (degrees)
- angle = orientation of line segment with respect to x-axis
- angle can be an atom-style variable (see below)
- *theta/random* value = seed
- seed = random # seed (positive integer) for line segment orienations
- *angmom* values = Lx Ly Lz
- Lx,Ly,Lz = components of angular momentum vector (distance-mass-velocity units)
- any of Lx,Ly,Lz can be an atom-style variable (see below)
- *omega* values = Wx Wy Wz
- Wx,Wy,Wz = components of angular velocity vector (radians/time units)
- any of wx,wy,wz can be an atom-style variable (see below)
- *mass* value = per-atom mass (mass units)
- value can be an atom-style variable (see below)
- *density* value = particle density for sphere or ellipsoid (mass/distance^3 or mass/distance^2 or mass/distance units, depending on dimensionality of particle)
- value can be an atom-style variable (see below)
- *volume* value = particle volume for Peridynamic particle (distance^3 units)
- value can be an atom-style variable (see below)
- *image* nx ny nz
- nx,ny,nz = which periodic image of the simulation box the atom is in
- *bond* value = bond type for all bonds between selected atoms
- *angle* value = angle type for all angles between selected atoms
- *dihedral* value = dihedral type for all dihedrals between selected atoms
- *improper* value = improper type for all impropers between selected atoms
- *meso/e* value = energy of SPH particles (need units)
- value can be an atom-style variable (see below)
- *meso/cv* value = heat capacity of SPH particles (need units)
- value can be an atom-style variable (see below)
- *meso/rho* value = density of SPH particles (need units)
- value can be an atom-style variable (see below)
- *smd/contact/radius* = radius for short range interactions, i.e. contact and friction
- value can be an atom-style variable (see below)
- *smd/mass/density* = set particle mass based on volume by providing a mass density
- value can be an atom-style variable (see below)
- *dpd/theta* value = internal temperature of DPD particles (temperature units)
- value can be an atom-style variable (see below)
- value can be NULL which sets internal temp of each particle to KE temp
- *i_name* value = value for custom integer vector with name
- *d_name* value = value for custom floating-point vector with name
-
-
-
-Examples
-""""""""
-
-.. parsed-literal::
-
- set group solvent type 2
- set group solvent type/fraction 2 0.5 12393
- set group edge bond 4
- set region half charge 0.5
- set type 3 charge 0.5
- set type 1*3 charge 0.5
- set atom * charge v_atomfile
- set atom 100*200 x 0.5 y 1.0
- set atom 1492 type 3
-
-Description
-"""""""""""
-
-Set one or more properties of one or more atoms. Since atom
-properties are initially assigned by the :doc:`read_data <read_data>`,
-:doc:`read_restart <read_restart>` or :doc:`create_atoms <create_atoms>`
-commands, this command changes those assignments. This can be useful
-for overriding the default values assigned by the
-:doc:`create_atoms <create_atoms>` command (e.g. charge = 0.0). It can
-be useful for altering pairwise and molecular force interactions,
-since force-field coefficients are defined in terms of types. It can
-be used to change the labeling of atoms by atom type or molecule ID
-when they are output in :doc:`dump <dump>` files. It can also be useful
-for debugging purposes; i.e. positioning an atom at a precise location
-to compute subsequent forces or energy.
-
-Note that the *style* and *ID* arguments determine which atoms have
-their properties reset. The remaining keywords specify which
-properties to reset and what the new values are. Some strings like
-*type* or *mol* can be used as a style and/or a keyword.
-
-
-----------
-
-
-This section describes how to select which atoms to change
-the properties of, via the *style* and *ID* arguments.
-
-The style *atom* selects all the atoms in a range of atom IDs. The
-style *type* selects all the atoms in a range of types. The style
-*mol* selects all the atoms in a range of molecule IDs.
-
-In each of the range cases, the range can be specified as a single
-numeric value, or a wildcard asterisk can be used to specify a range
-of values. This takes the form "*" or "*n" or "n*" or "m*n". For
-example, for the style *type*\ , if N = the number of atom types, then
-an asterisk with no numeric values means all types from 1 to N. A
-leading asterisk means all types from 1 to n (inclusive). A trailing
-asterisk means all types from n to N (inclusive). A middle asterisk
-means all types from m to n (inclusive). For all the styles except
-*mol*\ , the lowest value for the wildcard is 1; for *mol* it is 0.
-
-The style *group* selects all the atoms in the specified group. The
-style *region* selects all the atoms in the specified geometric
-region. See the :doc:`group <group>` and :doc:`region <region>` commands
-for details of how to specify a group or region.
-
-
-----------
-
-
-This section describes the keyword options for which properties to
-change, for the selected atoms.
-
-Note that except where explicitly prohibited below, all of the
-keywords allow an :doc:`atom-style or atomfile-style variable <variable>` to be used as the specified value(s). If the
-value is a variable, it should be specified as v_name, where name is
-the variable name. In this case, the variable will be evaluated, and
-its resulting per-atom value used to determine the value assigned to
-each selected atom. Note that the per-atom value from the variable
-will be ignored for atoms that are not selected via the *style* and
-*ID* settings explained above. A simple way to use per-atom values
-from the variable to reset a property for all atoms is to use style
-*atom* with *ID* = "*"; this selects all atom IDs.
-
-Atom-style variables can specify formulas with various mathematical
-functions, and include :doc:`thermo_style <thermo_style>` command
-keywords for the simulation box parameters and timestep and elapsed
-time. They can also include per-atom values, such as atom
-coordinates. Thus it is easy to specify a time-dependent or
-spatially-dependent set of per-atom values. As explained on the
-:doc:`variable <variable>` doc page, atomfile-style variables can be
-used in place of atom-style variables, and thus as arguments to the
-set command. Atomfile-style variables read their per-atoms values
-from a file.
-
-.. note::
-
- Atom-style and atomfile-style variables return floating point
- per-atom values. If the values are assigned to an integer variable,
- such as the molecule ID, then the floating point value is truncated to
- its integer portion, e.g. a value of 2.6 would become 2.
-
-Keyword *type* sets the atom type for all selected atoms. The
-specified value must be from 1 to ntypes, where ntypes was set by the
-:doc:`create_box <create_box>` command or the *atom types* field in the
-header of the data file read by the :doc:`read_data <read_data>`
-command.
-
-Keyword *type/fraction* sets the atom type for a fraction of the
-selected atoms. The actual number of atoms changed is not guaranteed
-to be exactly the requested fraction, but should be statistically
-close. Random numbers are used in such a way that a particular atom
-is changed or not changed, regardless of how many processors are being
-used. This keyword does not allow use of an atom-style variable.
-
-Keyword *mol* sets the molecule ID for all selected atoms. The :doc:`atom style <atom_style>` being used must support the use of molecule
-IDs.
-
-Keywords *x*\ , *y*\ , *z*\ , and *charge* set the coordinates or charge of
-all selected atoms. For *charge*\ , the :doc:`atom style <atom_style>`
-being used must support the use of atomic charge.
-
-Keyword *dipole* uses the specified x,y,z values as components of a
-vector to set as the orientation of the dipole moment vectors of the
-selected atoms. The magnitude of the dipole moment is set
-by the length of this orientation vector.
-
-Keyword *dipole/random* randomizes the orientation of the dipole
-moment vectors for the selected atoms and sets the magnitude of each
-to the specified *Dlen* value. For 2d systems, the z component of the
-orientation is set to 0.0. Random numbers are used in such a way that
-the orientation of a particular atom is the same, regardless of how
-many processors are being used. This keyword does not allow use of an
-atom-style variable.
-
-Keyword *quat* uses the specified values to create a quaternion
-(4-vector) that represents the orientation of the selected atoms. The
-particles must define a quaternion for their orientation
-(e.g. ellipsoids, triangles, body particles) as defined by the
-:doc:`atom_style <atom_style>` command. Note that particles defined by
-:doc:`atom_style ellipsoid <atom_style>` have 3 shape parameters. The 3
-values must be non-zero for each particle set by this command. They
-are used to specify the aspect ratios of an ellipsoidal particle,
-which is oriented by default with its x-axis along the simulation
-box's x-axis, and similarly for y and z. If this body is rotated (via
-the right-hand rule) by an angle theta around a unit rotation vector
-(a,b,c), then the quaternion that represents its new orientation is
-given by (cos(theta/2), a*sin(theta/2), b*sin(theta/2),
-c*sin(theta/2)). The theta and a,b,c values are the arguments to the
-*quat* keyword. LAMMPS normalizes the quaternion in case (a,b,c) was
-not specified as a unit vector. For 2d systems, the a,b,c values are
-ignored, since a rotation vector of (0,0,1) is the only valid choice.
-
-Keyword *quat/random* randomizes the orientation of the quaternion for
-the selected atoms. The particles must define a quaternion for their
-orientation (e.g. ellipsoids, triangles, body particles) as defined by
-the :doc:`atom_style <atom_style>` command. Random numbers are used in
-such a way that the orientation of a particular atom is the same,
-regardless of how many processors are being used. For 2d systems,
-only orientations in the xy plane are generated. As with keyword
-*quat*\ , for ellipsoidal particles, the 3 shape values must be non-zero
-for each particle set by this command. This keyword does not allow
-use of an atom-style variable.
-
-Keyword *diameter* sets the size of the selected atoms. The particles
-must be finite-size spheres as defined by the :doc:`atom_style sphere <atom_style>` command. The diameter of a particle can be
-set to 0.0, which means they will be treated as point particles. Note
-that this command does not adjust the particle mass, even if it was
-defined with a density, e.g. via the :doc:`read_data <read_data>`
-command.
-
-Keyword *shape* sets the size and shape of the selected atoms. The
-particles must be ellipsoids as defined by the :doc:`atom_style ellipsoid <atom_style>` command. The *Sx*\ , *Sy*\ , *Sz* settings are
-the 3 diameters of the ellipsoid in each direction. All 3 can be set
-to the same value, which means the ellipsoid is effectively a sphere.
-They can also all be set to 0.0 which means the particle will be
-treated as a point particle. Note that this command does not adjust
-the particle mass, even if it was defined with a density, e.g. via the
-:doc:`read_data <read_data>` command.
-
-Keyword *length* sets the length of selected atoms. The particles
-must be line segments as defined by the :doc:`atom_style line <atom_style>` command. If the specified value is non-zero the
-line segment is (re)set to a length = the specified value, centered
-around the particle position, with an orientation along the x-axis.
-If the specified value is 0.0, the particle will become a point
-particle. Note that this command does not adjust the particle mass,
-even if it was defined with a density, e.g. via the
-:doc:`read_data <read_data>` command.
-
-Keyword *tri* sets the size of selected atoms. The particles must be
-triangles as defined by the :doc:`atom_style tri <atom_style>` command.
-If the specified value is non-zero the triangle is (re)set to be an
-equilateral triangle in the xy plane with side length = the specified
-value, with a centroid at the particle position, with its base
-parallel to the x axis, and the y-axis running from the center of the
-base to the top point of the triangle. If the specified value is 0.0,
-the particle will become a point particle. Note that this command
-does not adjust the particle mass, even if it was defined with a
-density, e.g. via the :doc:`read_data <read_data>` command.
-
-Keyword *theta* sets the orientation of selected atoms. The particles
-must be line segments as defined by the :doc:`atom_style line <atom_style>` command. The specified value is used to set the
-orientation angle of the line segments with respect to the x axis.
-
-Keyword *theta/random* randomizes the orientation of theta for the
-selected atoms. The particles must be line segments as defined by the
-:doc:`atom_style line <atom_style>` command. Random numbers are used in
-such a way that the orientation of a particular atom is the same,
-regardless of how many processors are being used. This keyword does
-not allow use of an atom-style variable.
-
-Keyword *angmom* sets the angular momentum of selected atoms. The
-particles must be ellipsoids as defined by the :doc:`atom_style ellipsoid <atom_style>` command or triangles as defined by the
-:doc:`atom_style tri <atom_style>` command. The angular momentum vector
-of the particles is set to the 3 specified components.
-
-Keyword *omega* sets the angular velocity of selected atoms. The
-particles must be spheres as defined by the "atom_style sphere"_
-atom_style.html command. The angular velocity vector of the particles
-is set to the 3 specified components.
-
-Keyword *mass* sets the mass of all selected particles. The particles
-must have a per-atom mass attribute, as defined by the
-:doc:`atom_style <atom_style>` command. See the "mass" command for how
-to set mass values on a per-type basis.
-
-Keyword *density* also sets the mass of all selected particles, but in
-a different way. The particles must have a per-atom mass attribute,
-as defined by the :doc:`atom_style <atom_style>` command. If the atom
-has a radius attribute (see :doc:`atom_style sphere <atom_style>`) and
-its radius is non-zero, its mass is set from the density and particle
-volume. If the atom has a shape attribute (see :doc:`atom_style ellipsoid <atom_style>`) and its 3 shape parameters are non-zero,
-then its mass is set from the density and particle volume. If the
-atom has a length attribute (see :doc:`atom_style line <atom_style>`)
-and its length is non-zero, then its mass is set from the density and
-line segment length (the input density is assumed to be in
-mass/distance units). If the atom has an area attribute (see
-:doc:`atom_style tri <atom_style>`) and its area is non-zero, then its
-mass is set from the density and triangle area (the input density is
-assumed to be in mass/distance^2 units). If none of these cases are
-valid, then the mass is set to the density value directly (the input
-density is assumed to be in mass units).
-
-Keyword *volume* sets the volume of all selected particles.
-Currently, only the :doc:`atom_style peri <atom_style>` command defines
-particles with a volume attribute. Note that this command does not
-adjust the particle mass.
-
-Keyword *image* sets which image of the simulation box the atom is
-considered to be in. An image of 0 means it is inside the box as
-defined. A value of 2 means add 2 box lengths to get the true value.
-A value of -1 means subtract 1 box length to get the true value.
-LAMMPS updates these flags as atoms cross periodic boundaries during
-the simulation. The flags can be output with atom snapshots via the
-:doc:`dump <dump>` command. If a value of NULL is specified for any of
-nx,ny,nz, then the current image value for that dimension is
-unchanged. For non-periodic dimensions only a value of 0 can be
-specified. This keyword does not allow use of atom-style variables.
-This command can be useful after a system has been equilibrated and
-atoms have diffused one or more box lengths in various directions.
-This command can then reset the image values for atoms so that they
-are effectively inside the simulation box, e.g if a diffusion
-coefficient is about to be measured via the :doc:`compute msd <compute_msd>` command. Care should be taken not to reset the
-image flags of two atoms in a bond to the same value if the bond
-straddles a periodic boundary (rather they should be different by +/-
-1). This will not affect the dynamics of a simulation, but may mess
-up analysis of the trajectories if a LAMMPS diagnostic or your own
-analysis relies on the image flags to unwrap a molecule which
-straddles the periodic box.
-
-Keywords *bond*\ , *angle*\ , *dihedral*\ , and *improper*\ , set the bond
-type (angle type, etc) of all bonds (angles, etc) of selected atoms to
-the specified value from 1 to nbondtypes (nangletypes, etc). All
-atoms in a particular bond (angle, etc) must be selected atoms in
-order for the change to be made. The value of nbondtype (nangletypes,
-etc) was set by the *bond types* (\ *angle types*\ , etc) field in the
-header of the data file read by the :doc:`read_data <read_data>`
-command. These keywords do not allow use of an atom-style variable.
-
-Keywords *meso/e*\ , *meso/cv*\ , and *meso/rho* set the energy, heat
-capacity, and density of smmothed particle hydrodynamics (SPH)
-particles. See `this PDF guide <USER/sph/SPH_LAMMPS_userguide.pdf>`_ to
-using SPH in LAMMPS.
-
-Keyword *smd/mass/density* sets the mass of all selected particles,
-but it is only applicable to the Smooth Mach Dynamics package
-USER-SMD. It assumes that the particle volume has already been
-correctly set and calculates particle mass from the provided mass
-density value.
-
-Keyword *smd/contact/radius* only applies to simulations with the
-Smooth Mach Dynamics package USER-SMD. Itsets an interaction radius
-for computing short-range interactions, e.g. repulsive forces to
-prevent different individual physical bodies from penetrating each
-other. Note that the SPH smoothing kernel diameter used for computing
-long range, nonlocal interactions, is set using the *diameter*
-keyword.
-
-Keyword *dpd/theta* sets the internal temperature of a DPD particle as
-defined by the USER-DPD package. If the specified value is a number
-it must be >= 0.0. If the specified value is NULL, then the kinetic
-temperature Tkin of each particle is computed as 3/2 k Tkin = KE = 1/2
-m v^2 = 1/2 m (vx*vx+vy*vy+vz*vz). Each particle's internal
-temperature is set to Tkin. If the specified value is an atom-style
-variable, then the variable is evaluated for each particle. If a
-value >= 0.0, the internal temperature is set to that value. If it is
-< 0.0, the computation of Tkin is performed and the internal
-temperature is set to that value.
-
-Keywords *i_name* and *d_name* refer to custom integer and
-floating-point properties that have been added to each atom via the
-:doc:`fix property/atom <fix_property_atom>` command. When that command
-is used specific names are given to each attribute which are what is
-specified as the "name" portion of *i_name* or *d_name*\ .
-
-Restrictions
-""""""""""""
-
-
-You cannot set an atom attribute (e.g. *mol* or *q* or *volume*\ ) if
-the :doc:`atom_style <atom_style>` does not have that attribute.
-
-This command requires inter-processor communication to coordinate the
-setting of bond types (angle types, etc). This means that your system
-must be ready to perform a simulation before using one of these
-keywords (force fields set, atom mass set, etc). This is not
-necessary for other keywords.
-
-Using the *region* style with the bond (angle, etc) keywords can give
-unpredictable results if there are bonds (angles, etc) that straddle
-periodic boundaries. This is because the region may only extend up to
-the boundary and partner atoms in the bond (angle, etc) may have
-coordinates outside the simulation box if they are ghost atoms.
-Ideally, the mass of the Drude particle should be small, and the
-stiffness of the harmonic bond should be large, so that the Drude
-particle remains close ot the core. The values of Drude mass, Drude
-charge, and force constant can be chosen following different
-strategies, as in the following examples of polarizable force
-fields:
-
-* :ref:`Lamoureux and Roux <Lamoureux>` suggest adopting a global half-stiffness, :math:`K_D` = 500 kcal/(mol Ang :math:`{}^2`) - which corresponds to a force constant :math:`k_D` = 4184 kJ/(mol Ang :math:`{}^2`) - for all types of core-Drude bond, a global mass :math:`m_D` = 0.4 g/mol (or u) for all types of Drude particles, and to calculate the Drude charges for individual atom types from the atom polarizabilities using equation (1). This choice is followed in the polarizable CHARMM force field.
-* Alternately :ref:`Schroeder and Steinhauser <Schroeder>` suggest adopting a global charge :math:`q_D` = -1.0e and a global mass :math:`m_D` = 0.1 g/mol (or u) for all Drude particles, and to calculate the force constant for each type of core-Drude bond from equation (1). The timesteps used by these authors are between 0.5 and 2 fs, with the degrees of freedom of the Drude oscillators kept cold at 1 K.
-* In both these force fields hydrogen atoms are treated as non-polarizable.
-
-The motion of of the Drude particles can be calculated by minimizing
-the energy of the induced dipoles at each timestep, by an interative,
-self-consistent procedure. The Drude particles can be massless and
-therefore do not contribute to the kinetic energy. However, the
-relaxed method is computationall slow. An extended-lagrangian method
-can be used to calculate the positions of the Drude particles, but
-this requires them to have mass. It is important in this case to
-decouple the degrees of freedom associated with the Drude oscillators
-from those of the normal atoms. Thermalizing the Drude dipoles at
-temperatures comparable to the rest of the simulation leads to several
-problems (kinetic energy transfer, very short timestep, etc.), which
-can be remediated by the "cold Drude" technique (:ref:`Lamoureux and Roux <Lamoureux>`).
-
-Two closely related models are used to represent polarization through
-"charges on a spring": the core-shell model and the Drude
-model. Although the basic idea is the same, the core-shell model is
-normally used for ionic/crystalline materials, whereas the Drude model
-is normally used for molecular systems and fluid states. In ionic
-crystals the symmetry around each ion and the distance between them
-are such that the core-shell model is sufficiently stable. But to be
-applicable to molecular/covalent systems the Drude model includes two
-important features:
-
-#. The possibility to thermostat the additional degrees of freedom associated with the induced dipoles at very low temperature, in terms of the reduced coordinates of the Drude particles with respect to their cores. This makes the trajectory close to that of relaxed induced dipoles.
-#. The Drude dipoles on covalently bonded atoms interact too strongly due to the short distances, so an atom may capture the Drude particle (shell) of a neighbor, or the induced dipoles within the same molecule may align too much. To avoid this, damping at short of the interactions between the point charges composing the induced dipole can be done by :ref:`Thole <Thole>` functions.
-
-
-----------
-
-
-**Preparation of the data file**
-
-The data file is similar to a standard LAMMPS data file for
-*atom_style full*\ . The DPs and the *harmonic bonds* connecting them
-to their DC should appear in the data file as normal atoms and bonds.
-
-You can use the *polarizer* tool (Python script distributed with the
-USER-DRUDE package) to convert a non-polarizable data file (here
-*data.102494.lmp*\ ) to a polarizable data file (\ *data-p.lmp*\ )
-* style = *delete* or *index* or *loop* or *world* or *universe* or *uloop* or *string* or *format* or *getenv* or *file* or *atomfile* or *python* or *internal* or *equal* or *vector* or *atom*
-.. parsed-literal::
-
- *delete* = no args
- *index* args = one or more strings
- *loop* args = N
- N = integer size of loop, loop from 1 to N inclusive
- *loop* args = N pad
- N = integer size of loop, loop from 1 to N inclusive
- pad = all values will be same length, e.g. 001, 002, ..., 100
- *loop* args = N1 N2
- N1,N2 = loop from N1 to N2 inclusive
- *loop* args = N1 N2 pad
- N1,N2 = loop from N1 to N2 inclusive
- pad = all values will be same length, e.g. 050, 051, ..., 100
- *world* args = one string for each partition of processors
- *universe* args = one or more strings
- *uloop* args = N
- N = integer size of loop
- *uloop* args = N pad
- N = integer size of loop
- pad = all values will be same length, e.g. 001, 002, ..., 100
- *string* arg = one string
- *format* args = vname fstr
- vname = name of equal-style variable to evaluate
- fstr = C-style format string
- *getenv* arg = one string
- *file* arg = filename
- *atomfile* arg = filename
- *python* arg = function
- *internal* arg = numeric value
- *equal* or *vector* or *atom* args = one formula containing numbers, thermo keywords, math operations, group functions, atom values and vectors, compute/fix/variable references
- numbers = 0.0, 100, -5.4, 2.8e-4, etc
- constants = PI, version, on, off, true, false, yes, no
-The slope() function uses linear regression to fit a line to the set
-of points, equally spaced by 1 in their x coordinate: (1,V1), (2,V2),
-..., (N,VN), where the Vi are the values in the global vector of
-length N. The returned value is the slope of the line. If the line
-has a single point or is vertical, it returns 1.0e20.
-
-The gmask(x) function takes 1 argument which is a group ID. It
-can only be used in atom-style variables. It returns a 1 for
-atoms that are in the group, and a 0 for atoms that are not.
-
-The rmask(x) function takes 1 argument which is a region ID. It can
-only be used in atom-style variables. It returns a 1 for atoms that
-are in the geometric region, and a 0 for atoms that are not.
-
-The grmask(x,y) function takes 2 arguments. The first is a group ID,
-and the second is a region ID. It can only be used in atom-style
-variables. It returns a 1 for atoms that are in both the group and
-region, and a 0 for atoms that are not in both.
-
-The next(x) function takes 1 argument which is a variable ID (not
-"v_foo", just "foo"). It must be for a file-style or atomfile-style
-variable. Each time the next() function is invoked (i.e. each time
-the equal-style or atom-style variable is evaluated), the following
-steps occur.
-
-For file-style variables, the current string value stored by the
-file-style variable is converted to a numeric value and returned by
-the function. And the next string value in the file is read and
-stored. Note that if the line previously read from the file was not a
-numeric string, then it will typically evaluate to 0.0, which is
-likely not what you want.
-
-For atomfile-style variables, the current per-atom values stored by
-the atomfile-style variable are returned by the function. And the
-next set of per-atom values in the file is read and stored.
-
-Since file-style and atomfile-style variables read and store the first
-line of the file or first set of per-atoms values when they are
-defined in the input script, these are the value(s) that will be
-returned the first time the next() function is invoked. If next() is
-invoked more times than there are lines or sets of lines in the file,
-the variable is deleted, similar to how the :doc:`next <next>` command
-operates.
-
-
-----------
-
-
-Feature Functions
------------------
-
-Feature functions allow to probe the running LAMMPS executable for
-whether specific features are either active, defined, or available.
-The functions take two arguments, a *category* and a corresponding
-*argument*\ . The arguments are strings thus cannot be formulas
-themselves (only $-style immediate variable expansion is possible).
-Return value is either 1.0 or 0.0 depending on whether the function
-evaluates to true or false, respectively.
-
-The *is_active()* function allows to query for active settings which
-are grouped by categories. Currently supported categories and
-arguments are:
-
-* *package* (argument = *cuda* or *gpu* or *intel* or *kokkos* or *omp*\ )
-* *newton* (argument = *pair* or *bond* or *any*\ )
-* *pair* (argument = *single* or *respa* or *manybody* or *tail* or *shift*\ )
-* *comm_style* (argument = *brick* or *tiled*\ )
-* *min_style* (argument = any of the compiled in minimizer styles)
-* *run_style* (argument = any of the compiled in run styles)
-* *atom_style* (argument = any of the compiled in atom styles)
-* *pair_style* (argument = any of the compiled in pair styles)
-* *bond_style* (argument = any of the compiled in bond styles)
-* *angle_style* (argument = any of the compiled in angle styles)
-* *dihedral_style* (argument = any of the compiled in dihedral styles)
-* *improper_style* (argument = any of the compiled in improper styles)
-* *kspace_style* (argument = any of the compiled in kspace styles)
-
-Most of the settings are self-explanatory, the *single* argument in the
-*pair* category allows to check whether a pair style supports a
-Pair::single() function as needed by compute group/group and others
-features or LAMMPS, *respa* allows to check whether the inner/middle/outer
-mode of r-RESPA is supported. In the various style categories,
-the checking is also done using suffix flags, if available and enabled.
-
-Example 1: disable use of suffix for pppm when using GPU package (i.e. run it on the CPU concurrently to running the pair style on the GPU), but do use the suffix otherwise (e.g. with USER-OMP).
-
-.. parsed-literal::
-
- pair_style lj/cut/coul/long 14.0
- if $(is_active(package,gpu)) then "suffix off"
- kspace_style pppm
-
-Example 2: use r-RESPA with inner/outer cutoff, if supported by pair style, otherwise fall back to using pair and reducing the outer time step
<p>The position of a neighbor atom <em>i’</em> relative to a central atom <em>i</em> is
a point within the 3D ball of radius <em>R_ii’ = rcutfac*(R_i + R_i’)</em></p>
<p>Bartok et al. <a class="reference internal" href="pair_snap.html#bartok2010"><span class="std std-ref">(Bartok)</span></a>, proposed mapping this 3D ball
onto the 3-sphere, the surface of the unit ball in a four-dimensional
space. The radial distance <em>r</em> within <em>R_ii’</em> is mapped on to a third
<p>Compute <em>snad/atom</em> evaluates a per-atom array. The columns are
arranged into <em>ntypes</em> blocks, listed in order of atom type <em>I</em>. Each
block contains three sub-blocks corresponding to the <em>x</em>, <em>y</em>, and <em>z</em>
components of the atom position. Each of these sub-blocks contains
one column for each bispectrum component, the same as for compute
<em>sna/atom</em></p>
<p>Compute <em>snav/atom</em> evaluates a per-atom array. The columns are
arranged into <em>ntypes</em> blocks, listed in order of atom type <em>I</em>. Each
block contains six sub-blocks corresponding to the <em>xx</em>, <em>yy</em>, <em>zz</em>,
<em>yz</em>, <em>xz</em>, and <em>xy</em> components of the virial tensor in Voigt
notation. Each of these sub-blocks contains one column for each
bispectrum component, the same as for compute <em>sna/atom</em></p>
<p>These values can be accessed by any command that uses per-atom values
from a compute as input. See <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">Section_howto 15</span></a> for an overview of LAMMPS output
options.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>These computes are part of the SNAP package. They are only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
+<p>This fix implements the Gaussian dynamics (GD) method to simulate a
+system at constant mass flux <a class="reference internal" href="#strong"><span class="std std-ref">(Strong)</span></a>. GD is a
+nonequilibrium molecular dynamics simulation method that can be used
+to study fluid flows through pores, pipes, and channels. In its
+original implementation GD was used to compute the pressure required
+to achieve a fixed mass flux through an opening. The flux can be
+conserved in any combination of the directions, x, y, or z, using
+xflag,yflag,zflag. This fix does not initialize a net flux through a
+system, it only conserves the center-of-mass momentum that is present
+when the fix is declared in the input script. Use the
+<a class="reference internal" href="velocity.html"><span class="doc">velocity</span></a> command to generate an initial center-of-mass
+momentum.</p>
+<p>GD applies an external fluctuating gravitational field that acts as a
+driving force to keep the system away from equilibrium. To maintain
+steady state, a profile-unbiased thermostat must be implemented to
+dissipate the heat that is added by the driving force. <a class="reference internal" href="compute_temp_profile.html"><span class="doc">Compute temp/profile</span></a> can be used to implement a
+profile-unbiased thermostat.</p>
+<p>A common use of this fix is to compute a pressure drop across a pipe,
+pore, or membrane. The pressure profile can be computed in LAMMPS with
+<a class="reference internal" href="compute_stress_atom.html"><span class="doc">compute stress/atom</span></a> and <a class="reference internal" href="fix_ave_chunk.html"><span class="doc">fix ave/chunk</span></a>, or with the hardy method in <a class="reference internal" href="fix_atc.html"><span class="doc">fix atc</span></a>. Note that the simple <a class="reference internal" href="compute_stress_atom.html"><span class="doc">compute stress/atom</span></a> method is only accurate away
+from inhomogeneities in the fluid, such as fixed wall atoms. Further,
+the computed pressure profile must be corrected for the acceleration
+applied by GD before computing a pressure drop or comparing it to
+other methods, such as the pump method <a class="reference internal" href="#zhu"><span class="std std-ref">(Zhu)</span></a>. The pressure
+correction is discussed and described in <a class="reference internal" href="#strong"><span class="std std-ref">(Strong)</span></a>.</p>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">For a complete example including the considerations discussed
+above, see the examples/USER/flow_gauss directory.</p>
+</div>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">Only the flux of the atoms in group-ID will be conserved. If the
+velocities of the group-ID atoms are coupled to the velocities of
+other atoms in the simulation, the flux will not be conserved. For
+example, in a simulation with fluid atoms and harmonically constrained
+wall atoms, if a single thermostat is applied to group <em>all</em>, the
+fluid atom velocities will be coupled to the wall atom velocities, and
+the flux will not be conserved. This issue can be avoided by
+thermostatting the fluid and wall groups separately.</p>
+</div>
+<p>Adding an acceleration to atoms does work on the system. This added
+energy can be optionally subtracted from the potential energy for the
+thermodynamic output (see below) to check that the timestep is small
+enough to conserve energy. Since the applied acceleration is
+fluctuating in time, the work cannot be computed from a potential. As
+a result, computing the work is slightly more computationally
+expensive than usual, so it is not performed by default. To invoke the
+work calculation, use the <em>energy</em> keyword. The
+<a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option also invokes the work
+calculation, and overrides an <em>energy no</em> setting here. If neither
+<em>energy yes</em> or <em>fix_modify energy yes</em> are set, the global scalar
+computed by the fix will return zero.</p>
+<div class="admonition note">
+<p class="first admonition-title">Note</p>
+<p class="last">In order to check energy conservation, any other fixes that do
+work on the system must have <em>fix_modify energy yes</em> set as well. This
+includes thermostat fixes and any constraints that hold the positions
+of wall atoms fixed, such as <a class="reference internal" href="fix_spring_self.html"><span class="doc">fix spring/self</span></a>.</p>
+<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
+<p>This fix is part of the USER-MISC package. It is only enabled if
+LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
+<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>.</p>
+<p>The <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> <em>energy</em> option is supported by this
+fix to subtract the work done from the
+system’s potential energy as part of <a class="reference internal" href="thermo_style.html"><span class="doc">thermodynamic output</span></a>.</p>
+<p>This fix computes a global scalar and a global 3-vector of forces,
+which can be accessed by various <a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar is the negative of the
+work done on the system, see above discussion. The vector is the total force
+that this fix applied to the group of atoms on the current timestep.
+The scalar and vector values calculated by this fix are “extensive”.</p>
+<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
+ Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
* -# The \link cudpp_kernel Kernel-Level API\endlink comprises functions
* that run entirely on the GPU across an entire grid of thread blocks.
* These functions may call into the \link cudpp_cta CTA-Level API\endlink
* below them.
* -# The \link cudpp_cta CTA-Level API\endlink comprises functions that run
* entirely on the GPU within a single Cooperative Thread Array (CTA,
* aka thread block). These are low-level functions that implement core
* data-parallel algorithms, typically by processing data within shared
* (CUDA \c __shared__) memory.
*
* Programmers may use any of the lower three CUDPP layers in their own
* programs by building the source directly into their application. However,
* the typical usage of CUDPP is to link to the library and invoke functions in
* the CUDPP \link publicInterface Public Interface\endlink, as in the
* \ref example_simpleCUDPP "simpleCUDPP", satGL, and cudpp_testrig application
* examples included in the CUDPP distribution.
*
* In the future, if and when CUDA supports building device-level libraries, we
* hope to enhance CUDPP to ease the use of CUDPP internal algorithms at all
* levels.
*
* \subsection uses Use Cases
* We expect the normal use of CUDPP will be in one of two ways:
* -# Linking the CUDPP library against another application.
* -# Running our "test" application, cudpp_testrig, that exercises
* CUDPP functionality.
*
* \section references References
* The following publications describe work incorporated in CUDPP.
*
* - Mark Harris, Shubhabrata Sengupta, and John D. Owens. "Parallel Prefix Sum (Scan) with CUDA". In Hubert Nguyen, editor, <i>GPU Gems 3</i>, chapter 39, pages 851–876. Addison Wesley, August 2007. http://graphics.idav.ucdavis.edu/publications/print_pub?pub_id=916
* - Shubhabrata Sengupta, Mark Harris, Yao Zhang, and John D. Owens. "Scan Primitives for GPU Computing". In <i>Graphics Hardware 2007</i>, pages 97–106, August 2007. http://graphics.idav.ucdavis.edu/publications/print_pub?pub_id=915
* - Shubhabrata Sengupta, Mark Harris, and Michael Garland. "Efficient parallel scan algorithms for GPUs". NVIDIA Technical Report NVR-2008-003, December 2008. http://mgarland.org/papers.html#segscan-tr
* - Nadathur Satish, Mark Harris, and Michael Garland. "Designing Efficient Sorting Algorithms for Manycore GPUs". In <i>Proceedings of the 23rd IEEE International Parallel & Distributed Processing Symposium</i>, May 2009. http://mgarland.org/papers.html#gpusort
* - Stanley Tzeng, Li-Yi Wei. "Parallel White Noise Generation on a GPU via Cryptographic Hash". In <i>Proceedings of the 2008 Symposium on Interactive 3D Graphics and Games</i>, pages 79–87, February 2008. http://research.microsoft.com/apps/pubs/default.aspx?id=70502
*
* Many researchers are using CUDPP in their work, and there are many publications
* that have used it \ref cudpp_refs "(references)". If your work uses CUDPP, please
* let us know by sending us a reference (preferably in BibTeX format) to your work.
*
* \section citing Citing CUDPP
*
* If you make use of CUDPP primitives in your work and want to cite
* CUDPP (thanks!), we would prefer for you to cite the appropriate
* papers above, since they form the core of CUDPP. To be more specific,
* the GPU Gems paper describes (unsegmented) scan, multi-scan for
* summed-area tables, and stream compaction. The NVIDIA technical report
* describes the current scan and segmented scan algorithms used in the
* library, and the Graphics Hardware paper describes an earlier
* implementation of segmented scan, quicksort, and sparse matrix-vector
* multiply. The IPDPS paper describes the radix sort used in CUDPP, and
* the I3D paper describes the random number generation algorithm.