<LI>group-ID = ID of the group of atoms to be dumped
<LI>style = <I>atom</I> or <I>atom/gz</I> or <I>atom/mpiio</I> or <I>cfg</I> or <I>cfg/gz</I> or <I>cfg/mpiio</I> or <I>dcd</I> or <I>xtc</I> or <I>xyz</I> or <I>xyz/gz</I> or <I>xyz/mpiio</I> or <I>h5md</I> or <I>image</I> or <I>movie</I> or <I>molfile</I> or <I>local</I> or <I>custom</I> or <I>custom/gz</I> or <I>custom/mpiio</I>
<LI>N = dump every this many timesteps
<LI>file = name of file to write dump info to
<LI>args = list of arguments for a particular style
<PRE><I>atom</I> args = none
<I>atom/gz</I> args = none
<I>atom/mpiio</I> args = none
<I>cfg</I> args = same as <I>custom</I> args, see below
<I>cfg/gz</I> args = same as <I>custom</I> args, see below
<I>cfg/mpiio</I> args = same as <I>custom</I> args, see below
<I>dcd</I> args = none
<I>xtc</I> args = none
<I>xyz</I> args = none
</PRE>
<PRE><I>xyz/gz</I> args = none
</PRE>
<PRE><I>xyz/mpiio</I> args = none
</PRE>
<PRE><I>h5md</I> args = discussed on <AHREF ="dump_h5md.html">dump h5md</A> doc page
</PRE>
<PRE><I>image</I> args = discussed on <AHREF ="dump_image.html">dump image</A> doc page
</PRE>
<PRE><I>movie</I> args = discussed on <AHREF ="dump_image.html">dump image</A> doc page
</PRE>
<PRE><I>molfile</I> args = discussed on <AHREF ="dump_molfile.html">dump molfile</A> doc page
</PRE>
<PRE><I>local</I> 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>
<PRE><I>custom</I> or <I>custom/gz</I> or <I>custom/mpiio</I> args = list of atom attributes
possible attributes = id, mol, proc, procp1, type, element, mass,
x, y, z, xs, ys, zs, xu, yu, zu,
xsu, ysu, zsu, ix, iy, iz,
vx, vy, vz, fx, fy, fz,
q, mux, muy, muz, mu,
radius, diameter, omegax, omegay, omegaz,
angmomx, angmomy, angmomz, tqx, tqy, tqz,
c_ID, c_ID[N], f_ID, f_ID[N], v_name
</PRE>
<PRE> 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 <AHREF ="dump_modify.html">dump_modify</A> command
mass = atom mass
x,y,z = unscaled atom coordinates
xs,ys,zs = scaled atom coordinates
xu,yu,zu = unwrapped atom coordinates
xsu,ysu,zsu = scaled unwrapped atom coordinates
ix,iy,iz = box image that the atom is in
vx,vy,vz = atom velocities
fx,fy,fz = forces on atoms
q = atom charge
mux,muy,muz = orientation of dipole moment of atom
mu = magnitude of dipole moment of atom
radius,diameter = radius,diameter of spherical particle
omegax,omegay,omegaz = angular velocity of spherical particle
angmomx,angmomy,angmomz = angular momentum of aspherical particle
tqx,tqy,tqz = torque on finite-size particles
c_ID = per-atom vector calculated by a compute with ID
c_ID[N] = Nth column of per-atom array calculated by a compute with ID
f_ID = per-atom vector calculated by a fix with ID
f_ID[N] = Nth column of per-atom array calculated by a fix with ID
v_name = per-atom vector calculated by an atom-style variable with name
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>
</UL>
<P><B>Examples:</B>
</P>
<PRE>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>
<P><B>Description:</B>
</P>
<P>Dump a snapshot of atom quantities to one or more files every N
timesteps in one of several styles. The <I>image</I> and <I>movie</I> styles are
the exception: the <I>image</I> style renders a JPG, PNG, or PPM image file
of the atom configuration every N timesteps while the <I>movie</I> style
combines and compresses them into a movie file; both are discussed in
detail on the <AHREF ="dump_image.html">dump image</A> doc page. The timesteps on
which dump output is written can also be controlled by a variable.
See the <AHREF ="dump_modify.html">dump_modify every</A> command.
</P>
<P>Only information for atoms in the specified group is dumped. The
<AHREF ="dump_modify.html">dump_modify thresh and region</A> commands can also
alter what atoms are included. Not all styles support all these
options; see details below.
</P>
<P>As described below, the filename determines the kind of output (text
or binary or gzipped, one big file or one per timestep, one big file
or multiple smaller files).
</P>
<P>IMPORTANT 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.
</P>
<P>IMPORTANT NOTE: Unless the <AHREF ="dump_modify.html">dump_modify sort</A> option
is invoked, the lines of atom information written to dump files
(typically one line per atom) will be in an indeterminate order for
each snapshot. This is even true when running on a single processor,
if the <AHREF ="atom_modify.html">atom_modify sort</A> option is on, which it is
by default. In this case atoms are re-ordered periodically during a
simulation, due to spatial sorting. It is also true when running in
parallel, because data for a single snapshot is collected from
multiple processors, each of which owns a subset of the atoms.
</P>
<P>For the <I>atom</I>, <I>custom</I>, <I>cfg</I>, and <I>local</I> styles, sorting is off by
default. For the <I>dcd</I>, <I>xtc</I>, <I>xyz</I>, and <I>molfile</I> styles, sorting by
atom ID is on by default. See the <AHREF ="dump_modify.html">dump_modify</A> doc
page for details.
</P>
<P>The <I>atom/gz</I>, <I>cfg/gz</I>, <I>custom/gz</I>, and <I>xyz/gz</I> 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 <I>atom</I>
and <I>atom/gz</I> styles (etc) to be inter-changeable, with the exception
of the required filename suffix.
</P>
<P>As explained below, the <I>atom/mpiio</I>, <I>cfg/mpiio</I>, <I>custom/mpiio</I>, and
<I>xyz/mpiio</I> 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 <I>atom</I> and <I>atom/mpiio</I> styles (etc) to
be inter-changeable. The one exception is how the filename is
specified for the MPI-IO styles, as explained below.
</P>
<HR>
<P>The <I>style</I> keyword determines what atom quantities are written to the
file and in what format. Settings made via the
<AHREF ="dump_modify.html">dump_modify</A> command can also alter the format of
individual values and the file itself.
</P>
<P>The <I>atom</I>, <I>local</I>, and <I>custom</I> styles create files in a simple text
format that is self-explanatory when viewing a dump file. Many of the
LAMMPS <AHREF ="Section_tools.html">post-processing tools</A>, including
<AHREF ="http://www.sandia.gov/~sjplimp/pizza.html">Pizza.py</A>, work with this
format, as does the <AHREF ="rerun.html">rerun</A> command.
</P>
<P>For post-processing purposes the <I>atom</I>, <I>local</I>, and <I>custom</I> text
files are self-describing in the following sense.
</P>
<P>The dimensions of the simulation box are included in each snapshot.
For an orthogonal simulation box this information is is formatted as:
</P>
<PRE>ITEM: BOX BOUNDS xx yy zz
xlo xhi
ylo yhi
zlo zhi
</PRE>
<P>where xlo,xhi are the maximum extents of the simulation box in the
x-dimension, and similarly for y and z. The "xx yy zz" represent 6
characters that encode the style of boundary for each of the 6
simulation box boundaries (xlo,xhi and ylo,yhi and zlo,zhi). Each of
the 6 characters is either p = periodic, f = fixed, s = shrink wrap,
or m = shrink wrapped with a minimum value. See the
<AHREF ="boundary.html">boundary</A> command for details.
</P>
<P>For triclinic simulation boxes (non-orthogonal), an orthogonal
bounding box which encloses the triclinic simulation box is output,
along with the 3 tilt factors (xy, xz, yz) of the triclinic box,
formatted as follows:
</P>
<PRE>ITEM: BOX BOUNDS xy xz yz xx yy zz
xlo_bound xhi_bound xy
ylo_bound yhi_bound xz
zlo_bound zhi_bound yz
</PRE>
<P>The presence of the text "xy xz yz" in the ITEM line indicates that
the 3 tilt factors will be included on each of the 3 following lines.
This bounding box is convenient for many visualization programs. The
meaning of the 6 character flags for "xx yy zz" is the same as above.
</P>
<P>Note that the first two numbers on each line are now xlo_bound instead
of xlo, etc, since they repesent a bounding box. See <AHREF ="Section_howto.html#howto_12">this
section</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 <I>atom</I> style, and would be the atom
attributes you specify in the dump command for the <I>custom</I> style.
</P>
<P>For style <I>atom</I>, 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
<AHREF ="dump_modify.html">dump_modify</A> settings. Image flags can also be
added for each atom via dump_modify.
</P>
<P>Style <I>custom</I> 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 <I>q</I> for atom style <I>bond</I>, 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 <I>local</I>, local output generated by <AHREF ="compute.html">computes</A>
and <AHREF ="fix.html">fixes</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 <AHREF ="compute_property_local.html">compute
property/local</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
<AHREF ="read_data.html">read_data</A> command.
</P>
<P>Style <I>cfg</I> has the same command syntax as style <I>custom</I> and writes