<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>
<p>LAMMPS-ICMS is an experimental variant of LAMMPS with additional
features made available for testing before they will be submitted
for inclusion into the official LAMMPS tree. The source code is
based on the official LAMMPS svn repository mirror at the Institute
for Computational Molecular Science at Temple University and generally
kept up-to-date as much as possible. Sometimes, e.g. when additional
development work is needed to adapt the upstream changes into
LAMMPS-ICMS it can take longer until synchronization; and occasionally,
e.g. in case of the rewrite of the multi-threading support, the
development will be halted except for important bugfixes until
all features of LAMMPS-ICMS fully compatible with the upstream
version or replaced by alternate implementations.</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 upstream LAMMPS, but may be
missing some new features in LAMMPS-ICMS.</li>
<li>If you browse the HTML doc pages included in your tarball, they
describe the version you have, however, not all new features in
LAMMPS-ICMS are documented immediately.</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: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
<p>These are additional compute styles in USER packages, which can be
used if <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">LAMMPS is built with the appropriate package</span></a>.</p>
<p>See the <a class="reference internal" href="pair_style.html"><span class="doc">pair_style</span></a> command for an overview of pair
potentials. Click on the style itself for a full description. Many
of the styles have accelerated versions, which can be used if LAMMPS
is built with the <a class="reference internal" href="Section_accelerate.html"><span class="doc">appropriate accelerated package</span></a>. This is indicated by additional
letters in parenthesis: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
<p>These are additional pair styles in USER packages, which can be used
if <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">LAMMPS is built with the appropriate package</span></a>.</p>
<p>See the <a class="reference internal" href="bond_style.html"><span class="doc">bond_style</span></a> command for an overview of bond
potentials. Click on the style itself for a full description. Some
of the styles have accelerated versions, which can be used if LAMMPS
is built with the <a class="reference internal" href="Section_accelerate.html"><span class="doc">appropriate accelerated package</span></a>. This is indicated by additional
letters in parenthesis: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
<p>These are additional bond styles in USER packages, which can be used
if <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">LAMMPS is built with the appropriate package</span></a>.</p>
<p>See the <a class="reference internal" href="angle_style.html"><span class="doc">angle_style</span></a> command for an overview of
angle potentials. Click on the style itself for a full description.
Some of the styles have accelerated versions, which can be used if
LAMMPS is built with the <a class="reference internal" href="Section_accelerate.html"><span class="doc">appropriate accelerated package</span></a>. This is indicated by additional
letters in parenthesis: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
<p>These are additional angle styles in USER packages, which can be used
if <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">LAMMPS is built with the appropriate package</span></a>.</p>
<p>See the <a class="reference internal" href="dihedral_style.html"><span class="doc">dihedral_style</span></a> command for an overview
of dihedral potentials. Click on the style itself for a full
description. Some of the styles have accelerated versions, which can
be used if LAMMPS is built with the <a class="reference internal" href="Section_accelerate.html"><span class="doc">appropriate accelerated package</span></a>. This is indicated by additional
letters in parenthesis: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
<p>These are additional dihedral styles in USER packages, which can be
used if <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">LAMMPS is built with the appropriate package</span></a>.</p>
<p>See the <a class="reference internal" href="improper_style.html"><span class="doc">improper_style</span></a> command for an overview
of improper potentials. Click on the style itself for a full
description. Some of the styles have accelerated versions, which can
be used if LAMMPS is built with the <a class="reference internal" href="Section_accelerate.html"><span class="doc">appropriate accelerated package</span></a>. This is indicated by additional
letters in parenthesis: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
<p>These are additional improper styles in USER packages, which can be
used if <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">LAMMPS is built with the appropriate package</span></a>.</p>
<p>See the <a class="reference internal" href="kspace_style.html"><span class="doc">kspace_style</span></a> command for an overview of
Kspace solvers. Click on the style itself for a full description.
Some of the styles have accelerated versions, which can be used if
LAMMPS is built with the <a class="reference internal" href="Section_accelerate.html"><span class="doc">appropriate accelerated package</span></a>. This is indicated by additional
letters in parenthesis: c = USER-CUDA, g = GPU, i = USER-INTEL, k =
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
<p>Contents: Compute and pair styles that implement the adiabatic
core/shell model for polarizability. The compute temp/cs command
measures the temperature of a system with core/shell particles. The
pair styles augment Born, Buckingham, and Lennard-Jones styles with
core/shell capabilities. See <a class="reference internal" href="Section_howto.html#howto-26"><span class="std std-ref">Section howto 6.26</span></a> for an overview of how to use the
<p>Contents: Dozens of atom, pair, bond, angle, dihedral, improper styles
which run with the Kokkos library to provide optimization for
multicore CPUs (via OpenMP), NVIDIA GPUs, or the Intel Xeon Phi (in
native mode). All of them have a “kk” in their style name. <a class="reference internal" href="accelerate_kokkos.html"><span class="doc">Section accelerate kokkos</span></a> gives details of what
hardware and software is required on your system, and how to build and
use this package. See the GPU, OPT, USER-CUDA, USER-INTEL, USER-OMP
packages, which also provide optimizations for the same range of
hardware.</p>
<p>Building with the KOKKOS package requires choosing which of 3 hardware
options you are optimizing for: CPU acceleration via OpenMP, GPU
acceleration, or Intel Xeon Phi. (You can build multiple times to
create LAMMPS executables for different hardware.) It also requires a
C++11 compatible compiler. For GPUs, the NVIDIA “nvcc” compiler is
used, and an appopriate KOKKOS_ARCH setting should be made in your
Makefile.machine for your GPU hardware and NVIDIA software.</p>
<p>The simplest way to do this is to use Makefile.kokkos_cuda or
Makefile.kokkos_omp or Makefile.kokkos_phi in src/MAKE/OPTIONS, via
“make kokkos_cuda” or “make kokkos_omp” or “make kokkos_phi”. (Check
the KOKKOS_ARCH setting in Makefile.kokkos_cuda), Or, as illustrated
below, you can use the Make.py script with its “-kokkos” option to
choose which hardware to build for. Type “python src/Make.py -h
-kokkos” to see the details. If these methods do not work on your
system, you will need to read the <a class="reference internal" href="accelerate_kokkos.html"><span class="doc">Section accelerate kokkos</span></a> doc page for details of what
Makefile.machine settings are needed.</p>
<p>To install via make or Make.py for each of 3 hardware options:</p>
<span class="n">make</span> <span class="n">kokkos_omp</span> <span class="c1"># for CPUs with OpenMP</span>
<span class="n">make</span> <span class="n">kokkos_cuda</span> <span class="c1"># for GPUs, check the KOKKOS_ARCH setting in Makefile.kokkos_cuda</span>
<span class="n">make</span> <span class="n">kokkos_phi</span> <span class="c1"># for Xeon Phis</span>
</pre></div>
</div>
<p>Make.py -p kokkos -kokkos omp -a machine # for CPUs with OpenMP
Make.py -p kokkos -kokkos cuda arch=35 -a machine # for GPUs of style arch
Make.py -p kokkos -kokkos phi -a machine # for Xeon Phis</p>
<p>Contents: A variety of long-range Coulombic solvers, and pair styles
which compute the corresponding short-range portion of the pairwise
Coulombic interactions. These include Ewald, particle-particle
particle-mesh (PPPM), and multilevel summation method (MSM) solvers.</p>
<p>Building with the KSPACE package requires a 1d FFT library be present
on your system for use by the PPPM solvers. This can be the KISS FFT
library provided with LAMMPS, or 3rd party libraries like FFTW or a
vendor-supplied FFT library. See step 6 of <a class="reference internal" href="Section_start.html#start-2-2"><span class="std std-ref">Section start 2.2.2</span></a> of the manual for details of how
to select different FFT options in your machine Makefile. The Make.py
tool has an “-fft” option which can insert these settings into your
machine Makefile automatically. Type “python src/Make.py -h -fft” to
<p>Contents: A handful of pair styles with an “opt” in their style name
which are optimized for improved CPU performance on single or multiple
cores. These include EAM, LJ, CHARMM, and Morse potentials. <a class="reference internal" href="accelerate_opt.html"><span class="doc">Section accelerate opt</span></a> gives details of how to build and
use this package. See the KOKKOS, USER-INTEL, and USER-OMP packages,
which also have styles optimized for CPU performance.</p>
<p>Some C++ compilers, like the Intel compiler, require the compile flag
“-restrict” to build LAMMPS with the OPT package. It should be added
to the CCFLAGS line of your Makefile.machine. Or use Makefile.opt in
src/MAKE/OPTIONS, via “make opt”. For compilers that use the flag,
the Make.py command adds it automatically to the Makefile.auto file it
<p>Contents: A collection of multi-replica methods that are used by
invoking multiple instances (replicas) of LAMMPS
simulations. Communication between individual replicas is performed in
different ways by the different methods. See <a class="reference internal" href="Section_howto.html#howto-5"><span class="std std-ref">Section howto 6.5</span></a> for an overview of how to run
multi-replica simulations in LAMMPS. Multi-replica methods included
in the package are nudged elastic band (NEB), parallel replica
dynamics (PRD), temperature accelerated dynamics (TAD), parallel
tempering, and a verlet/split algorithm for performing long-range
Coulombics on one set of processors, and the remainded of the force
Sampling and Restraints. This package implements a <a class="reference internal" href="fix_colvars.html"><span class="doc">fix colvars</span></a> command which wraps a COLVARS library which
can perform those kinds of simulations. See src/USER-COLVARS/README
<p>Contents: This package contains methods for simulating polarizable
systems using thermalized Drude oscillators. It has computes, fixes,
and pair styles for this purpose. See <a class="reference internal" href="Section_howto.html#howto-27"><span class="std std-ref">Section howto 6.27</span></a> for an overview of how to use the
package. See src/USER-DRUDE/README for additional details. There are
auxiliary tools for using this package in tools/drude.</p>
<p>Contents: FEP stands for free energy perturbation. This package
provides methods for performing FEP simulations by using a <a class="reference internal" href="fix_adapt_fep.html"><span class="doc">fix adapt/fep</span></a> command with soft-core pair potentials,
which have a “soft” in their style name. See src/USER-FEP/README for
more details. There are auxiliary tools for using this package in
<p>Contents: Dozens of pair, bond, angle, dihedral, and improper styles
that are optimized for Intel CPUs and the Intel Xeon Phi (in offload
mode). All of them have an “intel” in their style name. <a class="reference internal" href="accelerate_intel.html"><span class="doc">Section accelerate intel</span></a> gives details of what hardware
and compilers are required on your system, and how to build and use
this package. Also see src/USER-INTEL/README for more details. See
the KOKKOS, OPT, and USER-OMP packages, which also have CPU and
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
* 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
.. parsed-literal::
*h5md* args = discussed on :doc:`dump h5md <dump_h5md>` doc page
.. parsed-literal::
*image* args = discussed on :doc:`dump image <dump_image>` doc page
.. parsed-literal::
*movie* args = discussed on :doc:`dump image <dump_image>` doc page
.. parsed-literal::
*molfile* args = discussed on :doc:`dump molfile <dump_molfile>` doc page
.. parsed-literal::
*local* args = list of local attributes
possible attributes = index, c_ID, c_ID[N], f_ID, f_ID[N]
index = enumeration of local values
c_ID = local vector calculated by a compute with ID
c_ID[N] = Nth column of local array calculated by a compute with ID
f_ID = local vector calculated by a fix with ID
f_ID[N] = Nth column of local array calculated by a fix with ID
.. parsed-literal::
*custom* or *custom/gz* or *custom/mpiio* args = list of atom attributes
possible attributes = id, mol, proc, procp1, type, element, mass,
x, y, z, xs, ys, zs, xu, yu, zu,
xsu, ysu, zsu, ix, iy, iz,
vx, vy, vz, fx, fy, fz,
q, mux, muy, muz, mu,
radius, diameter, omegax, omegay, omegaz,
angmomx, angmomy, angmomz, tqx, tqy, tqz,
c_ID, c_ID[N], f_ID, f_ID[N], v_name
.. parsed-literal::
id = atom ID
mol = molecule ID
proc = ID of processor that owns atom
procp1 = ID+1 of processor that owns atom
type = atom type
element = name of atom element, as defined by :doc:`dump_modify <dump_modify>` command
mass = atom mass
x,y,z = unscaled atom coordinates
xs,ys,zs = scaled atom coordinates
xu,yu,zu = unwrapped atom coordinates
xsu,ysu,zsu = scaled unwrapped atom coordinates
ix,iy,iz = box image that the atom is in
vx,vy,vz = atom velocities
fx,fy,fz = forces on atoms
q = atom charge
mux,muy,muz = orientation of dipole moment of atom
mu = magnitude of dipole moment of atom
radius,diameter = radius,diameter of spherical particle
omegax,omegay,omegaz = angular velocity of spherical particle
angmomx,angmomy,angmomz = angular momentum of aspherical particle
tqx,tqy,tqz = torque on finite-size particles
c_ID = per-atom vector calculated by a compute with ID
c_ID[N] = Nth column of per-atom array calculated by a compute with ID
f_ID = per-atom vector calculated by a fix with ID
f_ID[N] = Nth column of per-atom array calculated by a fix with ID
v_name = per-atom vector calculated by an atom-style variable with name
d_name = per-atom floating point vector with name, managed by fix property/atom
i_name = per-atom integer vector with name, managed by fix property/atom
Examples
""""""""
.. parsed-literal::
dump myDump all atom 100 dump.atom
dump myDump all atom/mpiio 100 dump.atom.mpiio
dump myDump all atom/gz 100 dump.atom.gz
dump 2 subgroup atom 50 dump.run.bin
dump 2 subgroup atom 50 dump.run.mpiio.bin
dump 4a all custom 100 dump.myforce.* id type x y vx fx
dump 4b flow custom 100 dump.%.myforce id type c_myF[3] v_ke
dump 2 inner cfg 10 dump.snap.*.cfg mass type xs ys zs vx vy vz
dump snap all cfg 100 dump.config.*.cfg mass type xs ys zs id type c_Stress[2]
dump 1 all xtc 1000 file.xtc
Description
"""""""""""
Dump a snapshot of atom quantities to one or more files every N
timesteps in one of several styles. The *image* and *movie* styles are
the exception: the *image* style renders a JPG, PNG, or PPM image file
of the atom configuration every N timesteps while the *movie* style
combines and compresses them into a movie file; both are discussed in
detail on the :doc:`dump image <dump_image>` doc page. The timesteps on
which dump output is written can also be controlled by a variable.
See the :doc:`dump_modify every <dump_modify>` command.
Only information for atoms in the specified group is dumped. The
:doc:`dump_modify thresh and region <dump_modify>` commands can also
alter what atoms are included. Not all styles support all these
options; see details below.
As described below, the filename determines the kind of output (text
or binary or gzipped, one big file or one per timestep, one big file
or multiple smaller files).
.. 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.
.. note::
Unless the :doc:`dump_modify sort <dump_modify>` option is
invoked, the lines of atom information written to dump files
(typically one line per atom) will be in an indeterminate order for
each snapshot. This is even true when running on a single processor,
if the :doc:`atom_modify sort <atom_modify>` option is on, which it is
by default. In this case atoms are re-ordered periodically during a
simulation, due to spatial sorting. It is also true when running in
parallel, because data for a single snapshot is collected from
multiple processors, each of which owns a subset of the atoms.
For the *atom*\ , *custom*\ , *cfg*\ , and *local* styles, sorting is off by
default. For the *dcd*\ , *xtc*\ , *xyz*\ , and *molfile* styles, sorting by
atom ID is on by default. See the :doc:`dump_modify <dump_modify>` doc
page for details.
The *atom/gz*\ , *cfg/gz*\ , *custom/gz*\ , and *xyz/gz* styles are identical
in command syntax to the corresponding styles without "gz", however,
they generate compressed files using the zlib library. Thus the filename
suffix ".gz" is mandatory. This is an alternative approach to writing
compressed files via a pipe, as done by the regular dump styles, which
may be required on clusters where the interface to the high-speed network
disallows using the fork() library call (which is needed for a pipe).
For the remainder of this doc page, you should thus consider the *atom*
and *atom/gz* styles (etc) to be inter-changeable, with the exception
of the required filename suffix.
As explained below, the *atom/mpiio*\ , *cfg/mpiio*\ , *custom/mpiio*\ , and
*xyz/mpiio* styles are identical in command syntax and in the format
of the dump files they create, to the corresponding styles without
"mpiio", except the single dump file they produce is written in
parallel via the MPI-IO library. For the remainder of this doc page,
you should thus consider the *atom* and *atom/mpiio* styles (etc) to
be inter-changeable. The one exception is how the filename is
specified for the MPI-IO styles, as explained below.
----------
The *style* keyword determines what atom quantities are written to the
file and in what format. Settings made via the
:doc:`dump_modify <dump_modify>` command can also alter the format of
individual values and the file itself.
The *atom*\ , *local*\ , and *custom* styles create files in a simple text
format that is self-explanatory when viewing a dump file. Many of the
LAMMPS :doc:`post-processing tools <Section_tools>`, including
`Pizza.py <http://www.sandia.gov/~sjplimp/pizza.html>`_, work with this
format, as does the :doc:`rerun <rerun>` command.
For post-processing purposes the *atom*\ , *local*\ , and *custom* text
files are self-describing in the following sense.
The dimensions of the simulation box are included in each snapshot.
For an orthogonal simulation box this information is is formatted as:
.. parsed-literal::
ITEM: BOX BOUNDS xx yy zz
xlo xhi
ylo yhi
zlo zhi
where xlo,xhi are the maximum extents of the simulation box in the
x-dimension, and similarly for y and z. The "xx yy zz" represent 6
characters that encode the style of boundary for each of the 6
simulation box boundaries (xlo,xhi and ylo,yhi and zlo,zhi). Each of
the 6 characters is either p = periodic, f = fixed, s = shrink wrap,
or m = shrink wrapped with a minimum value. See the
:doc:`boundary <boundary>` command for details.
For triclinic simulation boxes (non-orthogonal), an orthogonal
bounding box which encloses the triclinic simulation box is output,
along with the 3 tilt factors (xy, xz, yz) of the triclinic box,
formatted as follows:
.. parsed-literal::
ITEM: BOX BOUNDS xy xz yz xx yy zz
xlo_bound xhi_bound xy
ylo_bound yhi_bound xz
zlo_bound zhi_bound yz
The presence of the text "xy xz yz" in the ITEM line indicates that
the 3 tilt factors will be included on each of the 3 following lines.
This bounding box is convenient for many visualization programs. The
meaning of the 6 character flags for "xx yy zz" is the same as above.
Note that the first two numbers on each line are now xlo_bound instead
of xlo, etc, since they repesent a bounding box. See :ref:`this section <howto_12>` of the doc pages for a geometric
description of triclinic boxes, as defined by LAMMPS, simple formulas
for how the 6 bounding box extents (xlo_bound,xhi_bound,etc) are
calculated from the triclinic parameters, and how to transform those
parameters to and from other commonly used triclinic representations.
The "ITEM: ATOMS" line in each snapshot lists column descriptors for
the per-atom lines that follow. For example, the descriptors would be
"id type xs ys zs" for the default *atom* style, and would be the atom
attributes you specify in the dump command for the *custom* style.
For style *atom*\ , atom coordinates are written to the file, along with
the atom ID and atom type. By default, atom coords are written in a
scaled format (from 0 to 1). I.e. an x value of 0.25 means the atom
is at a location 1/4 of the distance from xlo to xhi of the box
boundaries. The format can be changed to unscaled coords via the
:doc:`dump_modify <dump_modify>` settings. Image flags can also be
added for each atom via dump_modify.
Style *custom* allows you to specify a list of atom attributes to be
written to the dump file for each atom. Possible attributes are
listed above and will appear in the order specified. You cannot
specify a quantity that is not defined for a particular simulation -
such as *q* for atom style *bond*\ , since that atom style doesn't
assign charges. Dumps occur at the very end of a timestep, so atom
attributes will include effects due to fixes that are applied during
the timestep. An explanation of the possible dump custom attributes
is given below.
For style *local*\ , local output generated by :doc:`computes <compute>`
and :doc:`fixes <fix>` is used to generate lines of output that is
written to the dump file. This local data is typically calculated by
each processor based on the atoms it owns, but there may be zero or
more entities per atom, e.g. a list of bond distances. An explanation
of the possible dump local attributes is given below. Note that by
using input from the :doc:`compute property/local <compute_property_local>` command with dump local,
it is possible to generate information on bonds, angles, etc that can
be cut and pasted directly into a data file read by the
:doc:`read_data <read_data>` command.
Style *cfg* has the same command syntax as style *custom* and writes
<li>group-ID = ID of the group of atoms to be dumped</li>
<li>style = <em>atom</em> or <em>atom/gz</em> or <em>atom/mpiio</em> or <em>cfg</em> or <em>cfg/gz</em> or <em>cfg/mpiio</em> or <em>dcd</em> or <em>xtc</em> or <em>xyz</em> or <em>xyz/gz</em> or <em>xyz/mpiio</em> or <em>h5md</em> or <em>image</em> or <em>movie</em> or <em>molfile</em> or <em>local</em> or <em>custom</em> or <em>custom/gz</em> or <em>custom/mpiio</em></li>
<li>N = dump every this many timesteps</li>
<li>file = name of file to write dump info to</li>
<li>args = list of arguments for a particular style</li>
</ul>
<pre class="literal-block">
<em>atom</em> args = none
<em>atom/gz</em> args = none
<em>atom/mpiio</em> args = none
<em>cfg</em> args = same as <em>custom</em> args, see below
<em>cfg/gz</em> args = same as <em>custom</em> args, see below
<em>cfg/mpiio</em> args = same as <em>custom</em> args, see below
<em>dcd</em> args = none
<em>xtc</em> args = none
<em>xyz</em> args = none
</pre>
<pre class="literal-block">
<em>xyz/gz</em> args = none
</pre>
<pre class="literal-block">
<em>xyz/mpiio</em> args = none
</pre>
<pre class="literal-block">
<em>custom/vtk</em> args = similar to custom args below, discussed on <a class="reference internal" href="dump_custom_vtk.html"><span class="doc">dump custom/vtk</span></a> doc page
<p>The presence of the text “xy xz yz” in the ITEM line indicates that
the 3 tilt factors will be included on each of the 3 following lines.
This bounding box is convenient for many visualization programs. The
meaning of the 6 character flags for “xx yy zz” is the same as above.</p>
<p>Note that the first two numbers on each line are now xlo_bound instead
of xlo, etc, since they repesent a bounding box. See <a class="reference internal" href="Section_howto.html#howto-12"><span class="std std-ref">this section</span></a> of the doc pages for a geometric
description of triclinic boxes, as defined by LAMMPS, simple formulas
for how the 6 bounding box extents (xlo_bound,xhi_bound,etc) are
calculated from the triclinic parameters, and how to transform those
parameters to and from other commonly used triclinic representations.</p>
<p>The “ITEM: ATOMS” line in each snapshot lists column descriptors for
the per-atom lines that follow. For example, the descriptors would be
“id type xs ys zs” for the default <em>atom</em> style, and would be the atom
attributes you specify in the dump command for the <em>custom</em> style.</p>
<p>For style <em>atom</em>, atom coordinates are written to the file, along with
the atom ID and atom type. By default, atom coords are written in a
scaled format (from 0 to 1). I.e. an x value of 0.25 means the atom
is at a location 1/4 of the distance from xlo to xhi of the box
boundaries. The format can be changed to unscaled coords via the
<a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> settings. Image flags can also be
added for each atom via dump_modify.</p>
<p>Style <em>custom</em> allows you to specify a list of atom attributes to be
written to the dump file for each atom. Possible attributes are
listed above and will appear in the order specified. You cannot
specify a quantity that is not defined for a particular simulation -
such as <em>q</em> for atom style <em>bond</em>, since that atom style doesn’t
assign charges. Dumps occur at the very end of a timestep, so atom
attributes will include effects due to fixes that are applied during
the timestep. An explanation of the possible dump custom attributes
is given below.</p>
<p>For style <em>local</em>, local output generated by <a class="reference internal" href="compute.html"><span class="doc">computes</span></a>
and <a class="reference internal" href="fix.html"><span class="doc">fixes</span></a> is used to generate lines of output that is
written to the dump file. This local data is typically calculated by
each processor based on the atoms it owns, but there may be zero or
more entities per atom, e.g. a list of bond distances. An explanation
of the possible dump local attributes is given below. Note that by
using input from the <a class="reference internal" href="compute_property_local.html"><span class="doc">compute property/local</span></a> command with dump local,
it is possible to generate information on bonds, angles, etc that can
be cut and pasted directly into a data file read by the
The precision used in XTC files can be adjusted via the
<a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> command. The default value of 1000
means that coordinates are stored to 1/1000 nanometer accuracy. XTC
files are portable binary files written in the NFS XDR data format,
so that any machine which supports XDR should be able to read them.
The number of atoms per snapshot cannot change with the <em>xtc</em> style.
The <em>unwrap</em> option of the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> command allows
XTC coordinates to be written “unwrapped” by the image flags for each
atom. Unwrapped means that if the atom has passed thru a periodic
boundary one or more times, the value is printed for what the
coordinate would be if it had not been wrapped back into the periodic
box. Note that these coordinates may thus be far outside the box size
stored with the snapshot.</p>
<p>The <em>xyz</em> style writes XYZ files, which is a simple text-based
coordinate format that many codes can read. Specifically it has
a line with the number of atoms, then a comment line that is
usually ignored followed by one line per atom with the atom type
and the x-, y-, and z-coordinate of that atom. You can use the
<a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify element</span></a> option to change the output
from using the (numerical) atom type to an element name (or some
other label). This will help many visualization programs to guess
bonds and colors.</p>
<p>Note that <em>atom</em>, <em>custom</em>, <em>dcd</em>, <em>xtc</em>, and <em>xyz</em> style dump files
can be read directly by <a class="reference external" href="http://www.ks.uiuc.edu/Research/vmd">VMD</a>, a
popular molecular viewing program. See <a class="reference internal" href="Section_tools.html#vmd"><span class="std std-ref">Section tools</span></a> of the manual and the
tools/lmp2vmd/README.txt file for more information about support in
VMD for reading and visualizing LAMMPS dump files.</p>
<hr class="docutils" />
<p>Dumps are performed on timesteps that are a multiple of N (including
timestep 0) and on the last timestep of a minimization if the
minimization converges. Note that this means a dump will not be
performed on the initial timestep after the dump command is invoked,
if the current timestep is not a multiple of N. This behavior can be
changed via the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify first</span></a> command, which
can also be useful if the dump command is invoked after a minimization
ended on an arbitrary timestep. N can be changed between runs by
using the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify every</span></a> command (not allowed
for <em>dcd</em> style). The <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify every</span></a> command
also allows a variable to be used to determine the sequence of
timesteps on which dump files are written. In this mode a dump on the
first timestep of a run will also not be written unless the
<a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify first</span></a> command is used.</p>
<p>The specified filename determines how the dump file(s) is written.
The default is to write one large text file, which is opened when the
dump command is invoked and closed when an <a class="reference internal" href="undump.html"><span class="doc">undump</span></a>
command is used or when LAMMPS exits. For the <em>dcd</em> and <em>xtc</em> styles,
this is a single large binary file.</p>
<p>Dump filenames can contain two wildcard characters. If a “*”
character appears in the filename, then one file per snapshot is
written and the “*” character is replaced with the timestep value.
For example, tmp.dump.* becomes tmp.dump.0, tmp.dump.10000,
tmp.dump.20000, etc. This option is not available for the <em>dcd</em> and
<em>xtc</em> styles. Note that the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify pad</span></a>
command can be used to insure all timestep numbers are the same length
(e.g. 00010), which can make it easier to read a series of dump files
in order with some post-processing tools.</p>
<p>If a “%” character appears in the filename, then each of P processors
writes a portion of the dump file, and the “%” character is replaced
with the processor ID from 0 to P-1. For example, tmp.dump.% becomes
tmp.dump.0, tmp.dump.1, ... tmp.dump.P-1, etc. This creates smaller
files and can be a fast mode of output on parallel machines that
support parallel I/O for output. This option is not available for the
<em>dcd</em>, <em>xtc</em>, and <em>xyz</em> styles.</p>
<p>By default, P = the number of processors meaning one file per
processor, but P can be set to a smaller value via the <em>nfile</em> or
<em>fileper</em> keywords of the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify</span></a> command.
These options can be the most efficient way of writing out dump files
when running on large numbers of processors.</p>
<p>Note that using the “*” and “%” characters together can produce a
large number of small dump files!</p>
<p>For the <em>atom/mpiio</em>, <em>cfg/mpiio</em>, <em>custom/mpiio</em>, and <em>xyz/mpiio</em>
styles, a single dump file is written in parallel via the MPI-IO
library, which is part of the MPI standard for versions 2.0 and above.
Using MPI-IO requires two steps. First, build LAMMPS with its MPIIO
<span class="n">make</span> <span class="n">g</span><span class="o">++</span> <span class="c1"># build LAMMPS for your platform</span>
</pre></div>
</div>
<p>Second, use a dump filename which contains ”.mpiio”. Note that it
does not have to end in ”.mpiio”, just contain those characters.
Unlike MPI-IO restart files, which must be both written and read using
MPI-IO, the dump files produced by these MPI-IO styles are identical
in format to the files produced by their non-MPI-IO style
counterparts. This means you can write a dump file using MPI-IO and
use the <a class="reference internal" href="read_dump.html"><span class="doc">read_dump</span></a> command or perform other
post-processing, just as if the dump file was not written using
MPI-IO.</p>
<p>Note that MPI-IO dump files are one large file which all processors
write to. You thus cannot use the “%” wildcard character described
above in the filename since that specifies generation of multiple
files. You can use the ”.bin” suffix described below in an MPI-IO
dump file; again this file will be written in parallel and have the
same binary format as if it were written without MPI-IO.</p>
<p>If the filename ends with ”.bin”, the dump file (or files, if “*” or
“%” is also used) is written in binary format. A binary dump file
will be about the same size as a text version, but will typically
write out much faster. Of course, when post-processing, you will need
to convert it back to text format (see the <a class="reference internal" href="Section_tools.html#binary"><span class="std std-ref">binary2txt tool</span></a>) or write your own code to read the
binary file. The format of the binary file can be understood by
looking at the tools/binary2txt.cpp file. This option is only
available for the <em>atom</em> and <em>custom</em> styles.</p>
<p>If the filename ends with ”.gz”, the dump file (or files, if “*” or “%”
is also used) is written in gzipped format. A gzipped dump file will
be about 3x smaller than the text version, but will also take longer
to write. This option is not available for the <em>dcd</em> and <em>xtc</em>
styles.</p>
<hr class="docutils" />
<p>This section explains the local attributes that can be specified as
part of the <em>local</em> style.</p>
<p>The <em>index</em> attribute can be used to generate an index number from 1
to N for each line written into the dump file, where N is the total
number of local datums from all processors, or lines of output that
will appear in the snapshot. Note that because data from different
processors depend on what atoms they currently own, and atoms migrate
between processor, there is no guarantee that the same index will be
used for the same info (e.g. a particular bond) in successive
snapshots.</p>
<p>The <em>c_ID</em> and <em>c_ID[N]</em> attributes allow local vectors or arrays
calculated by a <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> to be output. The ID in the
attribute should be replaced by the actual ID of the compute that has
been defined previously in the input script. See the
<a class="reference internal" href="compute.html"><span class="doc">compute</span></a> command for details. There are computes for
calculating local information such as indices, types, and energies for
bonds and angles.</p>
<p>Note that computes which calculate global or per-atom quantities, as
opposed to local quantities, cannot be output in a dump local command.
Instead, global quantities can be output by the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command, and per-atom quantities can be
output by the dump custom command.</p>
<p>If <em>c_ID</em> is used as a attribute, then the local vector calculated by
the compute is printed. If <em>c_ID[N]</em> is used, then N must be in the
range from 1-M, which will print the Nth column of the M-length local
array calculated by the compute.</p>
<p>The <em>f_ID</em> and <em>f_ID[N]</em> attributes allow local vectors or arrays
calculated by a <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> to be output. The ID in the attribute
should be replaced by the actual ID of the fix that has been defined
previously in the input script.</p>
<p>If <em>f_ID</em> is used as a attribute, then the local vector calculated by
the fix is printed. If <em>f_ID[N]</em> is used, then N must be in the
range from 1-M, which will print the Nth column of the M-length local
array calculated by the fix.</p>
<p>Here is an example of how to dump bond info for a system,
including the distance and energy of each bond:</p>
<em>vy</em>, <em>vz</em>, <em>fx</em>, <em>fy</em>, <em>fz</em>, <em>q</em> attributes are self-explanatory.</p>
<p><em>Id</em> is the atom ID. <em>Mol</em> is the molecule ID, included in the data
file for molecular systems. <em>Proc</em> is the ID of the processor (0 to
Nprocs-1) that currently owns the atom. <em>Procp1</em> is the proc ID+1,
which can be convenient in place of a <em>type</em> attribute (1 to Ntypes)
for coloring atoms in a visualization program. <em>Type</em> is the atom
type (1 to Ntypes). <em>Element</em> is typically the chemical name of an
element, which you must assign to each type via the <a class="reference internal" href="dump_modify.html"><span class="doc">dump_modify element</span></a> command. More generally, it can be any
string you wish to associated with an atom type. <em>Mass</em> is the atom
mass. <em>Vx</em>, <em>vy</em>, <em>vz</em>, <em>fx</em>, <em>fy</em>, <em>fz</em>, and <em>q</em> are components of
atom velocity and force and atomic charge.</p>
<p>There are several options for outputting atom coordinates. The <em>x</em>,
<em>y</em>, <em>z</em> attributes write atom coordinates “unscaled”, in the
+<p>Use <em>xu</em>, <em>yu</em>, <em>zu</em> if you want the coordinates “unwrapped” by the
+image flags for each atom. Unwrapped means that if the atom has
+passed thru a periodic boundary one or more times, the value is
+printed for what the coordinate would be if it had not been wrapped
+back into the periodic box. Note that using <em>xu</em>, <em>yu</em>, <em>zu</em> means
+that the coordinate values may be far outside the box bounds printed
+with the snapshot. Using <em>xsu</em>, <em>ysu</em>, <em>zsu</em> is similar to using
+<em>xu</em>, <em>yu</em>, <em>zu</em>, except that the unwrapped coordinates are scaled by
+the box size. Atoms that have passed through a periodic boundary will
+have the corresponding cooordinate increased or decreased by 1.0.</p>
<p>The image flags can be printed directly using the <em>ix</em>, <em>iy</em>, <em>iz</em>
attributes. For periodic dimensions, they specify which image of the
simulation box the atom is considered to be in. An image of 0 means
it is inside the box as defined. A value of 2 means add 2 box lengths
to get the true value. A value of -1 means subtract 1 box length to
get the true value. LAMMPS updates these flags as atoms cross
periodic boundaries during the simulation.</p>
<p>The <em>mux</em>, <em>muy</em>, <em>muz</em> attributes are specific to dipolar systems
defined with an atom style of <em>dipole</em>. They give the orientation of
the atom’s point dipole moment. The <em>mu</em> attribute gives the
magnitude of the atom’s dipole moment.</p>
<p>The <em>radius</em> and <em>diameter</em> attributes are specific to spherical
particles that have a finite size, such as those defined with an atom
style of <em>sphere</em>.</p>
<p>The <em>omegax</em>, <em>omegay</em>, and <em>omegaz</em> attributes are specific to
finite-size spherical particles that have an angular velocity. Only
certain atom styles, such as <em>sphere</em> define this quantity.</p>
<p>The <em>angmomx</em>, <em>angmomy</em>, and <em>angmomz</em> attributes are specific to
finite-size aspherical particles that have an angular momentum. Only
the <em>ellipsoid</em> atom style defines this quantity.</p>
<p>The <em>tqx</em>, <em>tqy</em>, <em>tqz</em> attributes are for finite-size particles that
can sustain a rotational torque due to interactions with other
particles.</p>
<p>The <em>c_ID</em> and <em>c_ID[N]</em> attributes allow per-atom vectors or arrays
calculated by a <a class="reference internal" href="compute.html"><span class="doc">compute</span></a> to be output. The ID in the
attribute should be replaced by the actual ID of the compute that has
been defined previously in the input script. See the
<a class="reference internal" href="compute.html"><span class="doc">compute</span></a> command for details. There are computes for
calculating the per-atom energy, stress, centro-symmetry parameter,
and coordination number of individual atoms.</p>
<p>Note that computes which calculate global or local quantities, as
opposed to per-atom quantities, cannot be output in a dump custom
command. Instead, global quantities can be output by the
<a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style custom</span></a> command, and local quantities
can be output by the dump local command.</p>
<p>If <em>c_ID</em> is used as a attribute, then the per-atom vector calculated
by the compute is printed. If <em>c_ID[N]</em> is used, then N must be in
the range from 1-M, which will print the Nth column of the M-length
per-atom array calculated by the compute.</p>
<p>The <em>f_ID</em> and <em>f_ID[N]</em> attributes allow vector or array per-atom
quantities calculated by a <a class="reference internal" href="fix.html"><span class="doc">fix</span></a> to be output. The ID in the
attribute should be replaced by the actual ID of the fix that has been
defined previously in the input script. The <a class="reference internal" href="fix_ave_atom.html"><span class="doc">fix ave/atom</span></a> command is one that calculates per-atom
quantities. Since it can time-average per-atom quantities produced by
any <a class="reference internal" href="compute.html"><span class="doc">compute</span></a>, <a class="reference internal" href="fix.html"><span class="doc">fix</span></a>, or atom-style
<a class="reference internal" href="variable.html"><span class="doc">variable</span></a>, this allows those time-averaged results to
be written to a dump file.</p>
<p>If <em>f_ID</em> is used as a attribute, then the per-atom vector calculated
by the fix is printed. If <em>f_ID[N]</em> is used, then N must be in the
range from 1-M, which will print the Nth column of the M-length
per-atom array calculated by the fix.</p>
<p>The <em>v_name</em> attribute allows per-atom vectors calculated by a
<a class="reference internal" href="variable.html"><span class="doc">variable</span></a> to be output. The name in the attribute
should be replaced by the actual name of the variable that has been
defined previously in the input script. Only an atom-style variable
can be referenced, since it is the only style that generates per-atom
values. Variables of style <em>atom</em> can reference individual atom
attributes, per-atom atom attributes, thermodynamic keywords, or
invoke other computes, fixes, or variables when they are evaluated, so
this is a very general means of creating quantities to output to a
dump file.</p>
<p>The <em>d_name</em> and <em>i_name</em> attributes allow to output custom per atom
floating point or integer properties that are managed by
<p>See <a class="reference internal" href="Section_modify.html"><span class="doc">Section_modify</span></a> of the manual for information
on how to add new compute and fix styles to LAMMPS to calculate
per-atom quantities which could then be output into dump files.</p>
</div>
<hr class="docutils" />
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>To write gzipped dump files, you must either compile LAMMPS with the
-DLAMMPS_GZIP option or use the styles from the COMPRESS package
- see the <a class="reference internal" href="Section_start.html#start-2"><span class="std std-ref">Making LAMMPS</span></a> section of
the documentation.</p>
<p>The <em>atom/gz</em>, <em>cfg/gz</em>, <em>custom/gz</em>, and <em>xyz/gz</em> styles are part
of the COMPRESS package. They are only enabled if LAMMPS was built
with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>The <em>atom/mpiio</em>, <em>cfg/mpiio</em>, <em>custom/mpiio</em>, and <em>xyz/mpiio</em> styles
are part of the MPIIO package. They are only enabled if LAMMPS was
built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>The <em>xtc</em> style is part of the MISC package. It is only enabled if
LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info. This is
because some machines may not support the low-level XDR data format
that XTC files are written with, which will result in a compile-time
error when a low-level include file is not found. Putting this style
in a package makes it easy to exclude from a LAMMPS build for those
machines. However, the MISC package also includes two compatibility
header files and associated functions, which should be a suitable
substitute on machines that do not have the appropriate native header
files. This option can be invoked at build time by adding
-DLAMMPS_XDR to the CCFLAGS variable in the appropriate low-level
Makefile, e.g. src/MAKE/Makefile.foo. This compatibility mode has
been tested successfully on Cray XT3/XT4/XT5 and IBM BlueGene/L
machines and should also work on IBM BG/P, and Windows XP/Vista/7
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
-<p>Use the Muller-Plathe algorithm described in <a class="reference internal" href="#muller-plathe"><span class="std std-ref">this paper</span></a> to exchange kinetic energy between two particles
+<p>Use the Muller-Plathe algorithm described in <a class="reference internal" href="fix_viscosity.html#muller-plathe"><span class="std std-ref">this paper</span></a> to exchange kinetic energy between two particles
in different regions of the simulation box every N steps. This
induces a temperature gradient in the system. As described below this
enables the thermal conductivity of a material to be calculated. This
algorithm is sometimes called a reverse non-equilibrium MD (reverse
NEMD) approach to computing thermal conductivity. This is because the
usual NEMD approach is to impose a temperature gradient on the system
and measure the response as the resulting heat flux. In the
Muller-Plathe method, the heat flux is imposed, and the temperature
gradient is the system’s response.</p>
<p>See the <a class="reference internal" href="compute_heat_flux.html"><span class="doc">compute heat/flux</span></a> command for details
on how to compute thermal conductivity in an alternate way, via the
Green-Kubo formalism.</p>
<p>The simulation box is divided into <em>Nbin</em> layers in the <em>edim</em>
direction, where the layer 1 is at the low end of that dimension and
the layer <em>Nbin</em> is at the high end. Every N steps, Nswap pairs of
atoms are chosen in the following manner. Only atoms in the fix group
are considered. The hottest Nswap atoms in layer 1 are selected.
Similarly, the coldest Nswap atoms in the “middle” layer (see below)
are selected. The two sets of Nswap atoms are paired up and their
velocities are exchanged. This effectively swaps their kinetic
energies, assuming their masses are the same. If the masses are
different, an exchange of velocities relative to center of mass motion
of the 2 atoms is performed, to conserve kinetic energy. Over time,
this induces a temperature gradient in the system which can be
measured using commands such as the following, which writes the
temperature profile (assuming z = edim) to the file tmp.profile:</p>
<p>Note that by default, Nswap = 1, though this can be changed by the
optional <em>swap</em> keyword. Setting this parameter appropriately, in
conjunction with the swap rate N, allows the heat flux to be adjusted
across a wide range of values, and the kinetic energy to be exchanged
in large chunks or more smoothly.</p>
<p>The “middle” layer for velocity swapping is defined as the <em>Nbin</em>/2 +
1 layer. Thus if <em>Nbin</em> = 20, the two swapping layers are 1 and 11.
This should lead to a symmetric temperature profile since the two
layers are separated by the same distance in both directions in a
periodic sense. This is why <em>Nbin</em> is restricted to being an even
number.</p>
<p>As described below, the total kinetic energy transferred by these
swaps is computed by the fix and can be output. Dividing this
quantity by time and the cross-sectional area of the simulation box
yields a heat flux. The ratio of heat flux to the slope of the
temperature profile is proportional to the thermal conductivity of the
-fluid, in appropriate units. See the <a class="reference internal" href="#muller-plathe"><span class="std std-ref">Muller-Plathe paper</span></a> for details.</p>
+fluid, in appropriate units. See the <a class="reference internal" href="fix_viscosity.html#muller-plathe"><span class="std std-ref">Muller-Plathe paper</span></a> for details.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If your system is periodic in the direction of the heat flux,
then the flux is going in 2 directions. This means the effective heat
flux in one direction is reduced by a factor of 2. You will see this
in the equations for thermal conductivity (kappa) in the Muller-Plathe
paper. LAMMPS is simply tallying kinetic energy which does not
account for whether or not your system is periodic; you must use the
value appropriately to yield a kappa for your system.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">After equilibration, if the temperature gradient you observe is
not linear, then you are likely swapping energy too frequently and are
not in a regime of linear response. In this case you cannot
accurately infer a thermal conductivity and should try increasing the
<h2>Restart, fix_modify, output, run start/stop, minimize info</h2>
<p>No information about this fix is written to <a class="reference internal" href="restart.html"><span class="doc">binary restart files</span></a>. None of the <a class="reference internal" href="fix_modify.html"><span class="doc">fix_modify</span></a> options
are relevant to this fix.</p>
<p>This fix computes a global scalar which can be accessed by various
<a class="reference internal" href="Section_howto.html#howto-15"><span class="std std-ref">output commands</span></a>. The scalar is the
cummulative kinetic energy transferred between the bottom and middle
of the simulation box (in the <em>edim</em> direction) is stored as a scalar
quantity by this fix. This quantity is zeroed when the fix is defined
and accumlates thereafter, once every N steps. The units of the
quantity are energy; see the <a class="reference internal" href="units.html"><span class="doc">units</span></a> command for details.
The scalar value calculated by this fix is “intensive”.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <a class="reference internal" href="run.html"><span class="doc">run</span></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><span class="doc">energy minimization</span></a>.</p>
</div>
<div class="section" id="restrictions">
<h2>Restrictions</h2>
<p>This fix is part of the MISC package. It is only enabled if LAMMPS
was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span class="std std-ref">Making LAMMPS</span></a> section for more info.</p>
<p>Swaps conserve both momentum and kinetic energy, even if the masses of
the swapped atoms are not equal. Thus you should not need to
thermostat the system. If you do use a thermostat, you may want to
apply it only to the non-swapped dimensions (other than <em>vdim</em>).</p>
<p>LAMMPS does not check, but you should not use this fix to swap the
kinetic energy of atoms that are in constrained molecules, e.g. via
<a class="reference internal" href="fix_shake.html"><span class="doc">fix shake</span></a> or <a class="reference internal" href="fix_rigid.html"><span class="doc">fix rigid</span></a>. This is
because application of the constraints will alter the amount of
transferred momentum. You should, however, be able to use flexible
molecules. See the <a class="reference internal" href="pair_gran.html#zhang"><span class="std std-ref">Zhang paper</span></a> for a discussion and results
of this idea.</p>
<p>When running a simulation with large, massive particles or molecules
in a background solvent, you may want to only exchange kinetic energy
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
- Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
+<p>See the supporting information of <a class="reference internal" href="#brennan"><span class="std std-ref">(Brennan)</span></a> or the publication by <a class="reference internal" href="#moore"><span class="std std-ref">(Moore)</span></a>
+for more details on the functional form.</p>
+<p>An interpolation table is used to evaluate the density-dependent energy (Integral(A(rho)drho) and force (A(rho)).
+Note that the pre-factor to the energy is computed after the interpolation, thus the Integral(A(rho)drho will
+have units of energy / length^4.</p>
+<p>The interpolation table is created as a pre-computation by fitting cubic splines to
+the file values and interpolating the density-dependent energy and force at each of <em>N</em> densities.
+During a simulation, the tables are used to interpolate the density-dependent energy and force as
+needed for each pair of particles separated by a distance <em>R</em>. The interpolation is done in
+one of 2 styles: <em>lookup</em> and <em>linear</em>.</p>
+<p>For the <em>lookup</em> style, the density is used to find the nearest table entry, which is the
+density-dependent energy and force.</p>
+<p>For the <em>linear</em> style, the density is used to find the 2 surrounding table values from
+which the density-dependent energy and force are computed by linear interpolation.</p>
+<p>The following coefficients must be defined for each pair of atoms
+types via the <a class="reference internal" href="pair_coeff.html"><span class="doc">pair_coeff</span></a> command as in the examples
+above.</p>
+<ul class="simple">
+<li>filename</li>
+<li>keyword</li>
+<li>cutoff (distance units)</li>
+</ul>
+<p>The filename specifies a file containing the tabulated density-dependent
+energy and force. The keyword specifies a section of the file.
+The cutoff is an optional coefficient. If not specified, the outer cutoff in the
+table itself (see below) will be used to build an interpolation table
+that extend to the largest tabulated distance. If specified, only
+file values up to the cutoff are used to create the interpolation
+table. The format of this file is described below.</p>
+<hr class="docutils" />
+<p>The format of a tabulated file is a series of one or more sections,
+defined as follows (without the parenthesized comments):</p>
+<div class="highlight-default"><div class="highlight"><pre><span></span><span class="c1"># Density-dependent function (one or more comment or blank lines)</span>
+ Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
group-ID = ID of the group of atoms to be dumped :l
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} :l
N = dump every this many timesteps :l
file = name of file to write dump info to :l
args = list of arguments for a particular style :l
{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 :pre
{xyz/gz} args = none :pre
{xyz/mpiio} args = none :pre
{custom/vtk} args = similar to custom args below, discussed on "dump custom/vtk"_dump_custom_vtk.html doc page :pre
{h5md} args = discussed on "dump h5md"_dump_h5md.html doc page :pre
{image} args = discussed on "dump image"_dump_image.html doc page :pre
{movie} args = discussed on "dump image"_dump_image.html doc page :pre
{molfile} args = discussed on "dump molfile"_dump_molfile.html doc page :pre
{local} args = list of local attributes
possible attributes = index, c_ID, c_ID\[N\], f_ID, f_ID\[N\]
index = enumeration of local values
c_ID = local vector calculated by a compute with ID
c_ID\[N\] = Nth column of local array calculated by a compute with ID
f_ID = local vector calculated by a fix with ID
f_ID\[N\] = Nth column of local array calculated by a fix with ID :pre
{custom} or {custom/gz} or {custom/mpiio} args = list of atom attributes
possible attributes = id, mol, proc, procp1, type, element, mass,
x, y, z, xs, ys, zs, xu, yu, zu,
xsu, ysu, zsu, ix, iy, iz,
vx, vy, vz, fx, fy, fz,
q, mux, muy, muz, mu,
radius, diameter, omegax, omegay, omegaz,
angmomx, angmomy, angmomz, tqx, tqy, tqz,
c_ID, c_ID\[N\], f_ID, f_ID\[N\], v_name :pre
id = atom ID
mol = molecule ID
proc = ID of processor that owns atom
procp1 = ID+1 of processor that owns atom
type = atom type
element = name of atom element, as defined by "dump_modify"_dump_modify.html command
mass = atom mass
x,y,z = unscaled atom coordinates
xs,ys,zs = scaled atom coordinates
xu,yu,zu = unwrapped atom coordinates
xsu,ysu,zsu = scaled unwrapped atom coordinates
ix,iy,iz = box image that the atom is in
vx,vy,vz = atom velocities
fx,fy,fz = forces on atoms
q = atom charge
mux,muy,muz = orientation of dipole moment of atom
mu = magnitude of dipole moment of atom
radius,diameter = radius,diameter of spherical particle
omegax,omegay,omegaz = angular velocity of spherical particle
angmomx,angmomy,angmomz = angular momentum of aspherical particle
tqx,tqy,tqz = torque on finite-size particles
c_ID = per-atom vector calculated by a compute with ID
c_ID\[N\] = Nth column of per-atom array calculated by a compute with ID
f_ID = per-atom vector calculated by a fix with ID
f_ID\[N\] = Nth column of per-atom array calculated by a fix with ID
v_name = per-atom vector calculated by an atom-style variable with name
d_name = per-atom floating point vector with name, managed by fix property/atom
i_name = per-atom integer vector with name, managed by fix property/atom :pre
:ule
[Examples:]
dump myDump all atom 100 dump.atom
dump myDump all atom/mpiio 100 dump.atom.mpiio
dump myDump all atom/gz 100 dump.atom.gz
dump 2 subgroup atom 50 dump.run.bin
dump 2 subgroup atom 50 dump.run.mpiio.bin
dump 4a all custom 100 dump.myforce.* id type x y vx fx
dump 4b flow custom 100 dump.%.myforce id type c_myF\[3\] v_ke
dump 2 inner cfg 10 dump.snap.*.cfg mass type xs ys zs vx vy vz
dump snap all cfg 100 dump.config.*.cfg mass type xs ys zs id type c_Stress\[2\]
dump 1 all xtc 1000 file.xtc :pre
[Description:]
Dump a snapshot of atom quantities to one or more files every N
timesteps in one of several styles. The {image} and {movie} styles are
the exception: the {image} style renders a JPG, PNG, or PPM image file
of the atom configuration every N timesteps while the {movie} style
combines and compresses them into a movie file; both are discussed in
detail on the "dump image"_dump_image.html doc page. The timesteps on
which dump output is written can also be controlled by a variable.
See the "dump_modify every"_dump_modify.html command.
Only information for atoms in the specified group is dumped. The
"dump_modify thresh and region"_dump_modify.html commands can also
alter what atoms are included. Not all styles support all these
options; see details below.
As described below, the filename determines the kind of output (text
or binary or gzipped, one big file or one per timestep, one big file
or multiple smaller files).
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.
NOTE: Unless the "dump_modify sort"_dump_modify.html option is
invoked, the lines of atom information written to dump files
(typically one line per atom) will be in an indeterminate order for
each snapshot. This is even true when running on a single processor,
if the "atom_modify sort"_atom_modify.html option is on, which it is
by default. In this case atoms are re-ordered periodically during a
simulation, due to spatial sorting. It is also true when running in
parallel, because data for a single snapshot is collected from
multiple processors, each of which owns a subset of the atoms.
For the {atom}, {custom}, {cfg}, and {local} styles, sorting is off by
default. For the {dcd}, {xtc}, {xyz}, and {molfile} styles, sorting by
atom ID is on by default. See the "dump_modify"_dump_modify.html doc
page for details.
The {atom/gz}, {cfg/gz}, {custom/gz}, and {xyz/gz} styles are identical
in command syntax to the corresponding styles without "gz", however,
they generate compressed files using the zlib library. Thus the filename
suffix ".gz" is mandatory. This is an alternative approach to writing
compressed files via a pipe, as done by the regular dump styles, which
may be required on clusters where the interface to the high-speed network
disallows using the fork() library call (which is needed for a pipe).
For the remainder of this doc page, you should thus consider the {atom}
and {atom/gz} styles (etc) to be inter-changeable, with the exception
of the required filename suffix.
As explained below, the {atom/mpiio}, {cfg/mpiio}, {custom/mpiio}, and
{xyz/mpiio} styles are identical in command syntax and in the format
of the dump files they create, to the corresponding styles without
"mpiio", except the single dump file they produce is written in
parallel via the MPI-IO library. For the remainder of this doc page,
you should thus consider the {atom} and {atom/mpiio} styles (etc) to
be inter-changeable. The one exception is how the filename is
specified for the MPI-IO styles, as explained below.
:line
The {style} keyword determines what atom quantities are written to the
file and in what format. Settings made via the
"dump_modify"_dump_modify.html command can also alter the format of
individual values and the file itself.
The {atom}, {local}, and {custom} styles create files in a simple text
format that is self-explanatory when viewing a dump file. Many of the
LAMMPS "post-processing tools"_Section_tools.html, including
"Pizza.py"_http://www.sandia.gov/~sjplimp/pizza.html, work with this
format, as does the "rerun"_rerun.html command.
For post-processing purposes the {atom}, {local}, and {custom} text
files are self-describing in the following sense.
The dimensions of the simulation box are included in each snapshot.
For an orthogonal simulation box this information is is formatted as:
ITEM: BOX BOUNDS xx yy zz
xlo xhi
ylo yhi
zlo zhi :pre
where xlo,xhi are the maximum extents of the simulation box in the
x-dimension, and similarly for y and z. The "xx yy zz" represent 6
characters that encode the style of boundary for each of the 6
simulation box boundaries (xlo,xhi and ylo,yhi and zlo,zhi). Each of
the 6 characters is either p = periodic, f = fixed, s = shrink wrap,
or m = shrink wrapped with a minimum value. See the
"boundary"_boundary.html command for details.
For triclinic simulation boxes (non-orthogonal), an orthogonal
bounding box which encloses the triclinic simulation box is output,
along with the 3 tilt factors (xy, xz, yz) of the triclinic box,
formatted as follows:
ITEM: BOX BOUNDS xy xz yz xx yy zz
xlo_bound xhi_bound xy
ylo_bound yhi_bound xz
zlo_bound zhi_bound yz :pre
The presence of the text "xy xz yz" in the ITEM line indicates that
the 3 tilt factors will be included on each of the 3 following lines.
This bounding box is convenient for many visualization programs. The
meaning of the 6 character flags for "xx yy zz" is the same as above.
Note that the first two numbers on each line are now xlo_bound instead
of xlo, etc, since they repesent a bounding box. See "this
section"_Section_howto.html#howto_12 of the doc pages for a geometric
description of triclinic boxes, as defined by LAMMPS, simple formulas
for how the 6 bounding box extents (xlo_bound,xhi_bound,etc) are
calculated from the triclinic parameters, and how to transform those
parameters to and from other commonly used triclinic representations.
The "ITEM: ATOMS" line in each snapshot lists column descriptors for
the per-atom lines that follow. For example, the descriptors would be
"id type xs ys zs" for the default {atom} style, and would be the atom
attributes you specify in the dump command for the {custom} style.
For style {atom}, atom coordinates are written to the file, along with
the atom ID and atom type. By default, atom coords are written in a
scaled format (from 0 to 1). I.e. an x value of 0.25 means the atom
is at a location 1/4 of the distance from xlo to xhi of the box
boundaries. The format can be changed to unscaled coords via the
"dump_modify"_dump_modify.html settings. Image flags can also be
added for each atom via dump_modify.
Style {custom} allows you to specify a list of atom attributes to be
written to the dump file for each atom. Possible attributes are
listed above and will appear in the order specified. You cannot
specify a quantity that is not defined for a particular simulation -
such as {q} for atom style {bond}, since that atom style doesn't
assign charges. Dumps occur at the very end of a timestep, so atom
attributes will include effects due to fixes that are applied during
the timestep. An explanation of the possible dump custom attributes
is given below.
For style {local}, local output generated by "computes"_compute.html
and "fixes"_fix.html is used to generate lines of output that is
written to the dump file. This local data is typically calculated by
each processor based on the atoms it owns, but there may be zero or
more entities per atom, e.g. a list of bond distances. An explanation
of the possible dump local attributes is given below. Note that by
using input from the "compute
property/local"_compute_property_local.html command with dump local,
it is possible to generate information on bonds, angles, etc that can
be cut and pasted directly into a data file read by the
"read_data"_read_data.html command.
Style {cfg} has the same command syntax as style {custom} and writes
" author = {J. P. Larentzos, J. K. Brennan, J. D. Moore, M. Lisal, W. D. Mattson},\n"
" title = {Parallel implementation of isothermal and isoenergetic Dissipative Particle Dynamics using Shardlow-like splitting algorithms},\n"
" journal = {Computer Physics Communications},\n"
" year = 2014,\n"
" volume = 185\n"
" pages = {1987--1998}\n"
"}\n\n"
"@Article{Lisal11,\n"
" author = {M. Lisal, J. K. Brennan, J. Bonet Avalos},\n"
" title = {Dissipative particle dynamics at isothermal, isobaric, isoenergetic, and isoenthalpic conditions using Shardlow-like splitting algorithms},\n"
// NOTE: this logic is specific to orthogonal boxes, not triclinic
// Enforce the constraint that ghosts must be contained in the nearest sub-domains
double bbx = domain->subhi[0] - domain->sublo[0];
double bby = domain->subhi[1] - domain->sublo[1];
double bbz = domain->subhi[2] - domain->sublo[2];
double rcut = double(2.0)*neighbor->cutneighmax;
if (domain->triclinic)
error->all(FLERR,"Fix shardlow does not yet support triclinic geometries");
if(rcut >= bbx || rcut >= bby || rcut>= bbz )
error->all(FLERR,"Shardlow algorithm requires sub-domain length > 2*(rcut+skin). Either reduce the number of processors requested, or change the cutoff/skin\n");
// Allocate memory for the dvSSA arrays
dvSSA = new double*[nall];
for (ii = 0; ii < nall; ii++) {
dvSSA[ii] = new double[3];
}
// Zero the momenta
for (ii = 0; ii < nlocal; ii++) {
dvSSA[ii][0] = double(0.0);
dvSSA[ii][1] = double(0.0);
dvSSA[ii][2] = double(0.0);
if(pairDPDE){
duCond[ii] = double(0.0);
duMech[ii] = double(0.0);
}
}
// Communicate the updated momenta and velocities to all nodes
comm->forward_comm_fix(this);
// Define pointers to access the neighbor list
if(pairDPDE){
inum = pairDPDE->list->inum;
ilist = pairDPDE->list->ilist;
numneigh = pairDPDE->list->numneigh;
firstneigh = pairDPDE->list->firstneigh;
} else {
inum = pairDPD->list->inum;
ilist = pairDPD->list->ilist;
numneigh = pairDPD->list->numneigh;
firstneigh = pairDPD->list->firstneigh;
}
//Loop over all 14 directions (8 stages)
for (int idir = 1; idir <=8; idir++){
// Loop over neighbors of my atoms
for (ii = 0; ii < inum; ii++) {
i = ilist[ii];
xtmp = x[i][0];
ytmp = x[i][1];
ztmp = x[i][2];
itype = type[i];
jlist = firstneigh[i];
jnum = numneigh[i];
// Loop over Directional Neighbors only
for (jj = 0; jj < jnum; jj++) {
j = jlist[jj];
j &= NEIGHMASK;
if (neighbor->ssa_airnum[j] != idir) continue;
jtype = type[j];
delx = xtmp - x[j][0];
dely = ytmp - x[j][1];
delz = ztmp - x[j][2];
rsq = delx*delx + dely*dely + delz*delz;
if(pairDPDE){
cut2 = pairDPDE->cutsq[itype][jtype];
cut = pairDPDE->cut[itype][jtype];
} else {
cut2 = pairDPD->cutsq[itype][jtype];
cut = pairDPD->cut[itype][jtype];
}
// if (rsq < pairDPD->cutsq[itype][jtype]) {
if (rsq < cut2) {
r = sqrt(rsq);
if (r < EPSILON) continue; // r can be 0.0 in DPD systems
rinv = double(1.0)/r;
// Store the velocities from previous Shardlow step
vx0i = v[i][0] + dvSSA[i][0];
vy0i = v[i][1] + dvSSA[i][1];
vz0i = v[i][2] + dvSSA[i][2];
vx0j = v[j][0] + dvSSA[j][0];
vy0j = v[j][1] + dvSSA[j][1];
vz0j = v[j][2] + dvSSA[j][2];
// Compute the velocity difference between atom i and atom j