<li><pclass="first">file = name of data file to read in</p>
</li>
<li><pclass="first">zero or more keyword/arg pairs may be appended</p>
</li>
<li><pclass="first">keyword = <em>add</em> or <em>offset</em> or <em>shift</em> or <em>extra/atom/types</em> or <em>extra/bond/types</em> or <em>extra/angle/types</em> or <em>extra/dihedral/types</em> or <em>extra/improper/types</em> or <em>group</em> or <em>nocoeff</em> or <em>fix</em></p>
<preclass="literal-block">
<em>add</em> arg = <em>append</em> or <em>Nstart</em> or <em>merge</em>
append = add new atoms with IDs appended to current IDs
Nstart = add new atoms with IDs starting with Nstart
merge = add new atoms with their IDs unchanged
<em>offset</em> args = toff boff aoff doff ioff
toff = offset to add to atom types
boff = offset to add to bond types
aoff = offset to add to angle types
doff = offset to add to dihedral types
ioff = offset to add to improper types
<em>shift</em> args = Sx Sy Sz
Sx,Sy,Sz = distance to shift atoms when adding to system (distance units)
<em>extra/atom/types</em> arg = # of extra atom types
<em>extra/bond/types</em> arg = # of extra bond types
<em>extra/angle/types</em> arg = # of extra angle types
<em>extra/dihedral/types</em> arg = # of extra dihedral types
<em>extra/improper/types</em> arg = # of extra improper types
<p>Read in a data file containing information LAMMPS needs to run a
simulation. The file can be ASCII text or a gzipped text file
(detected by a .gz suffix). This is one of 3 ways to specify initial
atom coordinates; see the <aclass="reference internal"href="read_restart.html"><spanclass="doc">read_restart</span></a> and
<aclass="reference internal"href="create_atoms.html"><spanclass="doc">create_atoms</span></a> commands for alternative methods.
Also see the explanation of the <aclass="reference internal"href="Section_start.html#start-7"><spanclass="std std-ref">-restart command-line switch</span></a> which can convert a restart file to
a data file.</p>
<p>This command can be used multiple times to add new atoms and their
properties to an existing system by using the <em>add</em>, <em>offset</em>, and
<em>shift</em> keywords. See more details below, which includes the use case
for the <em>extra</em> keywords.</p>
<p>The <em>group</em> keyword adds all the atoms in the data file to the
specified group-ID. The group will be created if it does not already
exist. This is useful if you are reading multiple data files and wish
to put sets of atoms into different groups so they can be operated on
later. E.g. a group of added atoms can be moved to new positions via
the <aclass="reference internal"href="displace_atoms.html"><spanclass="doc">displace_atoms</span></a> command. Note that atoms
read from the data file are also always added to the “all” group. The
<aclass="reference internal"href="group.html"><spanclass="doc">group</span></a> command discusses atom groups, as used in LAMMPS.</p>
<p>The <em>nocoeff</em> keyword tells read_data to ignore force field parameters.
The various Coeff sections are still read and have to have the correct
number of lines, but they are not applied. This also allows to read a
data file without having any pair, bond, angle, dihedral or improper
styles defined, or to read a data file for a different force field.</p>
<p>The use of the <em>fix</em> keyword is discussed below.</p>
<hrclass="docutils"/>
<p><strong>Reading multiple data files</strong></p>
<p>The read_data command can be used multiple times with the same or
different data files to build up a complex system from components
contained in individual data files. For example one data file could
contain fluid in a confined domain; a second could contain wall atoms,
and the second file could be read a third time to create a wall on the
other side of the fluid. The third set of atoms could be rotated to
an opposing direction using the <aclass="reference internal"href="displace_atoms.html"><spanclass="doc">displace_atoms</span></a>
command, after the third read_data command is used.</p>
<p>The <em>add</em>, <em>offset</em>, <em>shift</em>, <em>extra</em>, and <em>group</em> keywords are
useful in this context.</p>
<p>If a simulation box does not yet exist, the <em>add</em> keyword
cannot be used; the read_data command is being used for the first
time. If a simulation box does exist, due to using the
<aclass="reference internal"href="create_box.html"><spanclass="doc">create_box</span></a> command, or a previous read_data command,
then the <em>add</em> keyword must be used.</p>
<divclass="admonition note">
<pclass="first admonition-title">Note</p>
<pclass="last">The simulation box size (xlo to xhi, ylo to yhi, zlo to zhi) in
the new data file will be merged with the existing simulation box to
create a large enough box in each dimension to contain both the
existing and new atoms. Each box dimension never shrinks due to this
merge operation, it only stays the same or grows. Care must be used if
you are growing the existing simulation box in a periodic dimension.
If there are existing atoms with bonds that straddle that periodic
boundary, then the atoms may become far apart if the box size grows.
This will separate the atoms in the bond, which can lead to “lost”
bond atoms or bad dynamics.</p>
</div>
<p>The three choices for the <em>add</em> argument affect how the IDs of atoms
in the data file are treated. If <em>append</em> is specified, atoms in the
data file are added to the current system, with their atom IDs reset
so that an atomID = M in the data file becomes atomID = N+M, where N
is the largest atom ID in the current system. This rule is applied to
all occurrences of atom IDs in the data file, e.g. in the Velocity or
Bonds section. If <em>Nstart</em> is specified, then <em>Nstart</em> is a numeric
value is given, e.g. 1000, so that an atomID = M in the data file
becomes atomID = 1000+M. If <em>merge</em> is specified, the data file atoms
are added to the current system without changing their IDs. They are
assumed to merge (without duplication) with the currently defined
atoms. It is up to you to insure there are no multiply defined atom
IDs, as LAMMPS only performs an incomplete check that this is the case
by insuring the resulting max atomID >= the number of atoms.</p>
<p>The <em>offset</em> and <em>shift</em> keywords can only be used if the <em>add</em>
keyword is also specified.</p>
<p>The <em>offset</em> keyword adds the specified offset values to the atom
types, bond types, angle types, dihedral types, and improper types as
they are read from the data file. E.g. if <em>toff</em> = 2, and the file
uses atom types 1,2,3, then the added atoms will have atom types
3,4,5. These offsets apply to all occurrences of types in the data
file, e.g. for the Atoms or Masses or Pair Coeffs or Bond Coeffs
sections. This makes it easy to use atoms and molecules and their
attributes from a data file in different simulations, where you want
their types (atom, bond, angle, etc) to be different depending on what
other types already exist. All five offset values must be specified,
but individual values will be ignored if the data file does not use
that attribute (e.g. no bonds).</p>
<p>The <em>shift</em> keyword can be used to specify an (Sx, Sy, Sz)
displacement applied to the coordinates of each atom. Sz must be 0.0
for a 2d simulation. This is a mechanism for adding structured
collections of atoms at different locations within the simulation box,
to build up a complex geometry. It is up to you to insure atoms do
not end up overlapping unphysically which would lead to bad dynamics.
Note that the <aclass="reference internal"href="displace_atoms.html"><spanclass="doc">displace_atoms</span></a> command can be used
to move a subset of atoms after they have been read from a data file.
Likewise, the <aclass="reference internal"href="delete_atoms.html"><spanclass="doc">delete_atoms</span></a> command can be used to
remove overlapping atoms. Note that the shift values (Sx, Sy, Sz) are
also added to the simulation box information (xlo, xhi, ylo, yhi, zlo,
zhi) in the data file to shift its boundaries. E.g. xlo_new = xlo +
Sx, xhi_new = xhi + Sx.</p>
<p>The <em>extra</em> keywords can only be used the first time the read_data
command is used. They are useful if you intend to add new atom, bond,
angle, etc types later with additional read_data commands. This is
because the maximum number of allowed atom, bond, angle, etc types is
set by LAMMPS when the system is first initialized. If you do not use
the <em>extra</em> keywords, then the number of these types will be limited
to what appears in the first data file you read. For example, if the
first data file is a solid substrate of Si, it will likely specify a
single atom type. If you read a second data file with a different
material (water molecules) that sit on top of the substrate, you will
want to use different atom types for those atoms. You can only do
this if you set the <em>extra/atom/types</em> keyword to a sufficiently large
value when reading the substrate data file. Note that use of the
<em>extra</em> keywords also allows each data file to contain sections like
Masses or Pair Coeffs or Bond Coeffs which are sized appropriately for
the number of types in that data file. If the <em>offset</em> keyword is
used appropriately when each data file is read, the values in those
sections will be stored correctly in the larger data structures
allocated by the use of the <em>extra</em> keywords. E.g. the substrate file
can list mass and pair coefficients for type 1 silicon atoms. The
water file can list mass and pair coeffcients for type 1 and type 2
hydrogen and oxygen atoms. Use of the <em>extra</em> and <em>offset</em> keywords
will store those mass and pair coefficient values appropriately in
data structures that allow for 3 atom types (Si, H, O). Of course,
you would still need to specify coefficients for H/Si and O/Si
interactions in your input script to have a complete pairwise
interaction model.</p>
<p>An alternative to using the <em>extra</em> keywords with the read_data
command, is to use the <aclass="reference internal"href="create_box.html"><spanclass="doc">create_box</span></a> command to
initialize the simulation box and all the various type limits you need
via its <em>extra</em> keywords. Then use the read_data command one or more
times to populate the system with atoms, bonds, angles, etc, using the
<em>offset</em> keyword if desired to alter types used in the various data
files you read.</p>
<hrclass="docutils"/>
<p><strong>Format of a data file</strong></p>
<p>The structure of the data file is important, though many settings and
sections are optional or can come in any order. See the examples
directory for sample data files for different problems.</p>
<p>A data file has a header and a body. The header appears first. The
first line of the header is always skipped; it typically contains a
description of the file. Then lines are read one at a time. Lines
can have a trailing comment starting with ‘#’ that is ignored. If the
line is blank (only whitespace after comment is deleted), it is
skipped. If the line contains a header keyword, the corresponding
value(s) is read from the line. If it doesn’t contain a header
keyword, the line begins the body of the file.</p>
<p>The body of the file contains zero or more sections. The first line
of a section has only a keyword. This line can have a trailing
comment starting with ‘#’ that is either ignored or can be used to
check for a style match, as described below. The next line is
skipped. The remaining lines of the section contain values. The
number of lines depends on the section keyword as described below.
Zero or more blank lines can be used between sections. Sections can
appear in any order, with a few exceptions as noted below.</p>
<p>The keyword <em>fix</em> can be used one or more times. Each usage specifies
a fix that will be used to process a specific portion of the data
file. Any header line containing <em>header-string</em> and any section with
a name containing <em>section-string</em> will be passed to the specified
fix. See the <aclass="reference internal"href="fix_property_atom.html"><spanclass="doc">fix property/atom</span></a> command for
an example of a fix that operates in this manner. The doc page for
the fix defines the syntax of the header line(s) and section(s) that
it reads from the data file. Note that the <em>header-string</em> can be
specified as NULL, in which case no header lines are passed to the
fix. This means that it can infer the length of its Section from
standard header settings, such as the number of atoms.</p>
<p>The formatting of individual lines in the data file (indentation,
spacing between words and numbers) is not important except that header
and section keywords (e.g. atoms, xlo xhi, Masses, Bond Coeffs) must
be capitalized as shown and can’t have extra white space between their
words - e.g. two spaces or a tab between the 2 words in “xlo xhi” or
the 2 words in “Bond Coeffs”, is not valid.</p>
<hrclass="docutils"/>
<p><strong>Format of the header of a data file</strong></p>
<p>These are the recognized header keywords. Header lines can come in
any order. The value(s) are read from the beginning of the line.
Thus the keyword <em>atoms</em> should be in a line like “1000 atoms”; the
keyword <em>ylo yhi</em> should be in a line like “-10.0 10.0 ylo yhi”; the
keyword <em>xy xz yz</em> should be in a line like “0.0 5.0 6.0 xy xz yz”.
All these settings have a default value of 0, except the lo/hi box
size defaults are -0.5 and 0.5. A line need only appear if the value
is different than the default.</p>
<ulclass="simple">
<li><em>atoms</em> = # of atoms in system</li>
<li><em>bonds</em> = # of bonds in system</li>
<li><em>angles</em> = # of angles in system</li>
<li><em>dihedrals</em> = # of dihedrals in system</li>
<li><em>impropers</em> = # of impropers in system</li>
<li><em>atom types</em> = # of atom types in system</li>
<li><em>bond types</em> = # of bond types in system</li>
<li><em>angle types</em> = # of angle types in system</li>
<li><em>dihedral types</em> = # of dihedral types in system</li>
<li><em>improper types</em> = # of improper types in system</li>
<li><em>extra bond per atom</em> = leave space for this many new bonds per atom</li>
<li><em>extra angle per atom</em> = leave space for this many new angles per atom</li>
<li><em>extra dihedral per atom</em> = leave space for this many new dihedrals per atom</li>
<li><em>extra improper per atom</em> = leave space for this many new impropers per atom</li>
<li><em>extra special per atom</em> = leave space for this many new special bonds per atom</li>
<li><em>ellipsoids</em> = # of ellipsoids in system</li>
<li><em>lines</em> = # of line segments in system</li>
<li><em>triangles</em> = # of triangles in system</li>
<li><em>bodies</em> = # of bodies in system</li>
<li><em>xlo xhi</em> = simulation box boundaries in x dimension</li>
<li><em>ylo yhi</em> = simulation box boundaries in y dimension</li>
<li><em>zlo zhi</em> = simulation box boundaries in z dimension</li>
<p>If the <em>xy xz yz</em> line does not appear, LAMMPS will set up an
axis-aligned (orthogonal) simulation box. If the line does appear,
LAMMPS creates a non-orthogonal simulation domain shaped as a
parallelepiped with triclinic symmetry. The parallelepiped has its
“origin” at (xlo,ylo,zlo) and is defined by 3 edge vectors starting
from the origin given by A = (xhi-xlo,0,0); B = (xy,yhi-ylo,0); C =
(xz,yz,zhi-zlo). <em>Xy,xz,yz</em> can be 0.0 or positive or negative values
and are called “tilt factors” because they are the amount of
displacement applied to faces of an originally orthogonal box to
transform it into the parallelepiped.</p>
<p>By default, the tilt factors (xy,xz,yz) can not skew the box more than
half the distance of the corresponding parallel box length. For
example, if xlo = 2 and xhi = 12, then the x box length is 10 and the
xy tilt factor must be between -5 and 5. Similarly, both xz and yz
must be between -(xhi-xlo)/2 and +(yhi-ylo)/2. Note that this is not
a limitation, since if the maximum tilt factor is 5 (as in this
example), then configurations with tilt = ..., -15, -5, 5, 15, 25,
... are all geometrically equivalent. If you wish to define a box
with tilt factors that exceed these limits, you can use the <aclass="reference internal"href="box.html"><spanclass="doc">box tilt</span></a> command, with a setting of <em>large</em>; a setting of
<em>small</em> is the default.</p>
<p>See <aclass="reference internal"href="Section_howto.html#howto-12"><spanclass="std std-ref">Section 6.12</span></a> of the doc pages
for a geometric description of triclinic boxes, as defined by LAMMPS,
and how to transform these parameters to and from other commonly used
triclinic representations.</p>
<p>When a triclinic system is used, the simulation domain should normally
be periodic in the dimension that the tilt is applied to, which is
given by the second dimension of the tilt factor (e.g. y for xy tilt).
This is so that pairs of atoms interacting across that boundary will
have one of them shifted by the tilt factor. Periodicity is set by
the <aclass="reference internal"href="boundary.html"><spanclass="doc">boundary</span></a> command. For example, if the xy tilt
factor is non-zero, then the y dimension should be periodic.
Similarly, the z dimension should be periodic if xz or yz is non-zero.
LAMMPS does not require this periodicity, but you may lose atoms if
this is not the case.</p>
<p>Also note that if your simulation will tilt the box, e.g. via the <aclass="reference internal"href="fix_deform.html"><spanclass="doc">fix deform</span></a> command, the simulation box must be setup to
be triclinic, even if the tilt factors are initially 0.0. You can
also change an orthogonal box to a triclinic box or vice versa by
using the <aclass="reference internal"href="change_box.html"><spanclass="doc">change box</span></a> command with its <em>ortho</em> and
<em>triclinic</em> options.</p>
<p>For 2d simulations, the <em>zlo zhi</em> values should be set to bound the z
coords for atoms that appear in the file; the default of -0.5 0.5 is
valid if all z coords are 0.0. For 2d triclinic simulations, the xz
and yz tilt factors must be 0.0.</p>
<p>If the system is periodic (in a dimension), then atom coordinates can
be outside the bounds (in that dimension); they will be remapped (in a
periodic sense) back inside the box. Note that if the <em>add</em> option is
being used to add atoms to a simulation box that already exists, this
periodic remapping will be performed using simulation box bounds that
are the union of the existing box and the box boundaries in the new
data file.</p>
<divclass="admonition note">
<pclass="first admonition-title">Note</p>
<pclass="last">If the system is non-periodic (in a dimension), then all atoms
in the data file must have coordinates (in that dimension) that are
“greater than or equal to” the lo value and “less than or equal to”
the hi value. If the non-periodic dimension is of style “fixed” (see
the <aclass="reference internal"href="boundary.html"><spanclass="doc">boundary</span></a> command), then the atom coords must be
strictly “less than” the hi value, due to the way LAMMPS assign atoms
to processors. Note that you should not make the lo/hi values
radically smaller/larger than the extent of the atoms. For example,
if your atoms extend from 0 to 50, you should not specify the box
bounds as -10000 and 10000. This is because LAMMPS uses the specified
box size to layout the 3d grid of processors. A huge (mostly empty)
box will be sub-optimal for performance when using “fixed” boundary
conditions (see the <aclass="reference internal"href="boundary.html"><spanclass="doc">boundary</span></a> command). When using
“shrink-wrap” boundary conditions (see the <aclass="reference internal"href="boundary.html"><spanclass="doc">boundary</span></a>
command), a huge (mostly empty) box may cause a parallel simulation to
lose atoms when LAMMPS shrink-wraps the box around the atoms. The
read_data command will generate an error in this case.</p>
</div>
<p>The “extra bond per atom” setting (angle, dihedral, improper) is only
needed if new bonds (angles, dihedrals, impropers) will be added to
the system when a simulation runs, e.g. by using the <aclass="reference internal"href="fix_bond_create.html"><spanclass="doc">fix bond/create</span></a> command. This will pre-allocate
space in LAMMPS data structures for storing the new bonds (angles,
dihedrals, impropers).</p>
<p>The “extra special per atom” setting is typically only needed if new
bonds/angles/etc will be added to the system, e.g. by using the <aclass="reference internal"href="fix_bond_create.html"><spanclass="doc">fix bond/create</span></a> command. Or if entire new molecules
will be added to the system, e.g. by using the <aclass="reference internal"href="fix_deposit.html"><spanclass="doc">fix deposit</span></a> or <aclass="reference internal"href="fix_pour.html"><spanclass="doc">fix pour</span></a> commands, which
will have more special 1-2,1-3,1-4 neighbors than any other molecules
defined in the data file. Using this setting will pre-allocate space
in the LAMMPS data structures for storing these neighbors. See the
<aclass="reference internal"href="special_bonds.html"><spanclass="doc">special_bonds</span></a> and <aclass="reference internal"href="molecule.html"><spanclass="doc">molecule</span></a> doc
pages for more discussion of 1-2,1-3,1-4 neighbors.</p>
<divclass="admonition note">
<pclass="first admonition-title">Note</p>
<pclass="last">All of the “extra” settings are only used if they appear in the
first data file read; see the description of the <em>add</em> keyword above
for reading multiple data files. If they appear in later data files,
they are ignored.</p>
</div>
<p>The “ellipsoids” and “lines” and “triangles” and “bodies” settings are
only used with <aclass="reference internal"href="atom_style.html"><spanclass="doc">atom_style ellipsoid or line or tri or body</span></a> and specify how many of the atoms are
finite-size ellipsoids or lines or triangles or bodies; the remainder
are point particles. See the discussion of ellipsoidflag and the
<em>Ellipsoids</em> section below. See the discussion of lineflag and the
<em>Lines</em> section below. See the discussion of triangleflag and the
<em>Triangles</em> section below. See the discussion of bodyflag and the
<em>Bodies</em> section below.</p>
<divclass="admonition note">
<pclass="first admonition-title">Note</p>
<pclass="last">For <aclass="reference internal"href="atom_style.html"><spanclass="doc">atom_style template</span></a>, the molecular
topology (bonds,angles,etc) is contained in the molecule templates
read-in by the <aclass="reference internal"href="molecule.html"><spanclass="doc">molecule</span></a> command. This means you
cannot set the <em>bonds</em>, <em>angles</em>, etc header keywords in the data
file, nor can you define <em>Bonds</em>, <em>Angles</em>, etc sections as discussed
below. You can set the <em>bond types</em>, <em>angle types</em>, etc header
keywords, though it is not necessary. If specified, they must match
the maximum values defined in any of the template molecules.</p>
</div>
<hrclass="docutils"/>
<p><strong>Format of the body of a data file</strong></p>
<p>These are the section keywords for the body of the file.</p>
<p>will check if the currently-defined <aclass="reference internal"href="atom_style.html"><spanclass="doc">atom_style</span></a> is
<em>sphere</em>, and the current <aclass="reference external"href="pair_style">pair_style</a> is <em>lj/cut</em>. If
not, LAMMPS will issue a warning to indicate that the data file
section likely does not contain the correct number or type of
parameters expected for the currently-defined style.</p>
<p>Each section is listed below in alphabetic order. The format of each
section is described including the number of lines it must contain and
rules (if any) for where it can appear in the data file.</p>
<p>Any individual line in the various sections can have a trailing
comment starting with “#” for annotation purposes. E.g. in the
Atoms section:</p>
<divclass="highlight-default"><divclass="highlight"><pre><span></span><spanclass="mi">10</span><spanclass="mi">1</span><spanclass="mi">17</span><spanclass="o">-</span><spanclass="mf">1.0</span><spanclass="mf">10.0</span><spanclass="mf">5.0</span><spanclass="mf">6.0</span><spanclass="c1"># salt ion</span>
<p>Atom lines specify the (x,y,z) coordinates of atoms. These can be
inside or outside the simulation box. When the data file is read,
LAMMPS wraps coordinates outside the box back into the box for
dimensions that are periodic. As discussed above, if an atom is
outside the box in a non-periodic dimension, it will be lost.</p>
<p>LAMMPS always stores atom coordinates as values which are inside the
simulation box. It also stores 3 flags which indicate which image of
the simulation box (in each dimension) the atom would be in if its
coordinates were unwrapped across periodic boundaries. An image flag
of 0 means the atom is still inside the box when unwrapped. A value
of 2 means add 2 box lengths to get the unwrapped coordinate. A value
of -1 means subtract 1 box length to get the unwrapped coordinate.
LAMMPS updates these flags as atoms cross periodic boundaries during
the simulation. The <aclass="reference internal"href="dump.html"><spanclass="doc">dump</span></a> command can output atom atom
coordinates in wrapped or unwrapped form, as well as the 3 image
flags.</p>
<p>In the data file, atom lines (all lines or none of them) can
optionally list 3 trailing integer values (nx,ny,nz), which are used
to initialize the atom’s image flags. If nx,ny,nz values are not
listed in the data file, LAMMPS initializes them to 0. Note that the
image flags are immediately updated if an atom’s coordinates need to
wrapped back into the simulation box.</p>
<p>It is only important to set image flags correctly in a data file if a
simulation model relies on unwrapped coordinates for some calculation;
otherwise they can be left unspecified. Examples of LAMMPS commands
that use unwrapped coordinates internally are as follows:</p>
<ulclass="simple">
<li>Atoms in a rigid body (see <aclass="reference internal"href="fix_rigid.html"><spanclass="doc">fix rigid</span></a>, <aclass="reference internal"href="fix_rigid.html"><spanclass="doc">fix rigid/small</span></a>) must have consistent image flags, so that
when the atoms are unwrapped, they are near each other, i.e. as a
single body.</li>
<li>If the <aclass="reference internal"href="replicate.html"><spanclass="doc">replicate</span></a> command is used to generate a larger
system, image flags must be consistent for bonded atoms when the bond
crosses a periodic boundary. I.e. the values of the image flags
should be different by 1 (in the appropriate dimension) for the two
atoms in such a bond.</li>
<li>If you plan to <aclass="reference internal"href="dump.html"><spanclass="doc">dump</span></a> image flags and perform post-analysis
that will unwrap atom coordinates, it may be important that a
continued run (restarted from a data file) begins with image flags
that are consistent with the previous run.</li>
</ul>
<divclass="admonition note">
<pclass="first admonition-title">Note</p>
<pclass="last">If your system is an infinite periodic crystal with bonds then
it is impossible to have fully consistent image flags. This is because
some bonds will cross periodic boundaries and connect two atoms with the
same image flag.</p>
</div>
<p>Atom velocities and other atom quantities not defined above are set to
0.0 when the <em>Atoms</em> section is read. Velocities can be set later by
a <em>Velocities</em> section in the data file or by a
<aclass="reference internal"href="velocity.html"><spanclass="doc">velocity</span></a> or <aclass="reference internal"href="set.html"><spanclass="doc">set</span></a> command in the input
script.</p>
<hrclass="docutils"/>
<p><em>Bodies</em> section:</p>
<ul>
<li><pclass="first">one or more lines per body</p>
</li>
<li><pclass="first">first line syntax: atom-ID Ninteger Ndouble</p>
<divclass="highlight-default"><divclass="highlight"><pre><span></span><spanclass="n">Ninteger</span><spanclass="o">=</span><spanclass="c1"># of integer quantities for this particle</span>
<spanclass="n">Ndouble</span><spanclass="o">=</span><spanclass="c1"># of floating-point quantities for this particle</span>
</pre></div>
</div>
</li>
<li><pclass="first">0 or more integer lines with total of Ninteger values</p>
</li>
<li><pclass="first">0 or more double lines with total of Ndouble values</p>
<p>The <em>Ellipsoids</em> section must appear if <aclass="reference internal"href="atom_style.html"><spanclass="doc">atom_style ellipsoid</span></a> is used and any atoms are listed in the
<em>Atoms</em> section with an ellipsoidflag = 1. The number of ellipsoids
should be specified in the header section via the “ellipsoids”
keyword.</p>
<p>The 3 shape values specify the 3 diameters or aspect ratios of a
finite-size ellipsoidal particle, when it is oriented along the 3
coordinate axes. They must all be non-zero values.</p>
<p>The values <em>quatw</em>, <em>quati</em>, <em>quatj</em>, and <em>quatk</em> set the orientation
of the atom as a quaternion (4-vector). Note that the shape
attributes specify the aspect ratios of an ellipsoidal particle, which
is oriented by default with its x-axis along the simulation box’s
x-axis, and similarly for y and z. If this body is rotated (via the
right-hand rule) by an angle theta around a unit vector (a,b,c), then
the quaternion that represents its new orientation is given by
(cos(theta/2), a*sin(theta/2), b*sin(theta/2), c*sin(theta/2)). These
4 components are quatw, quati, quatj, and quatk as specified above.
LAMMPS normalizes each atom’s quaternion in case (a,b,c) is not
specified as a unit vector.</p>
<p>The <em>Ellipsoids</em> section must appear after the <em>Atoms</em> section.</p>
<hrclass="docutils"/>
<p><em>EndBondTorsion Coeffs</em> section:</p>
<ul>
<li><pclass="first">one line per dihedral type</p>
</li>
<li><pclass="first">line syntax: ID coeffs</p>
<preclass="literal-block">
ID = dihedral type (1-N)
coeffs = list of coeffs (see class 2 section of <aclass="reference internal"href="dihedral_coeff.html"><spanclass="doc">dihedral_coeff</span></a>)
</pre>
</li>
</ul>
<hrclass="docutils"/>
<p><em>Improper Coeffs</em> section:</p>
<ul>
<li><pclass="first">one line per improper type</p>
<p>The ordering of the 4 atoms determines the definition of the improper
angle used in the formula for each <aclass="reference internal"href="improper_style.html"><spanclass="doc">improper style</span></a>. See the doc pages for individual styles
for details.</p>
<p>The <em>Impropers</em> section must appear after the <em>Atoms</em> section. All
values in this section must be integers (1, not 1.0).</p>
<p>The number and meaning of the coefficients are specific to the defined
pair style. See the <aclass="reference internal"href="pair_style.html"><spanclass="doc">pair_style</span></a> and
<aclass="reference internal"href="pair_coeff.html"><spanclass="doc">pair_coeff</span></a> commands for details. Since pair
coefficients for types I != J are not specified, these will be
generated automatically by the pair style’s mixing rule. See the
individual pair_style doc pages and the <aclass="reference internal"href="pair_modify.html"><spanclass="doc">pair_modify mix</span></a> command for details. Pair coefficients can also
be set via the <aclass="reference internal"href="pair_coeff.html"><spanclass="doc">pair_coeff</span></a> command in the input
script.</p>
<hrclass="docutils"/>
<p><em>PairIJ Coeffs</em> section:</p>
<ul>
<li><pclass="first">one line per pair of atom types for all I,J with I <= J</p>
<p>This section must have N*(N+1)/2 lines where N = # of atom types. The
number and meaning of the coefficients are specific to the defined
pair style. See the <aclass="reference internal"href="pair_style.html"><spanclass="doc">pair_style</span></a> and
<aclass="reference internal"href="pair_coeff.html"><spanclass="doc">pair_coeff</span></a> commands for details. Since pair
coefficients for types I != J are all specified, these values will
turn off the default mixing rule defined by the pair style. See the
individual pair_style doc pages and the <aclass="reference internal"href="pair_modify.html"><spanclass="doc">pair_modify mix</span></a> command for details. Pair coefficients can also
be set via the <aclass="reference internal"href="pair_coeff.html"><spanclass="doc">pair_coeff</span></a> command in the input
<p>The <em>Triangles</em> section must appear if <aclass="reference internal"href="atom_style.html"><spanclass="doc">atom_style tri</span></a> is used and any atoms are listed in the <em>Atoms</em>
section with a triangleflag = 1. The number of lines should be
specified in the header section via the “triangles” keyword.</p>
<p>The 3 corner points are the corner points of the triangle. The
ordering of the 3 points should be such that using a right-hand rule
to go from point1 to point2 to point3 gives an “outward” normal vector
to the face of the triangle. I.e. normal = (c2-c1) x (c3-c1). This
orientation may be important for defining some interactions.</p>
<p>The <em>Triangles</em> section must appear after the <em>Atoms</em> section.</p>
<hrclass="docutils"/>
<p><em>Velocities</em> section:</p>
<ulclass="simple">
<li>one line per atom</li>
<li>line syntax: depends on atom style</li>
</ul>
<tableborder="1"class="docutils">
<colgroup>
<colwidth="42%"/>
<colwidth="58%"/>
</colgroup>
<tbodyvalign="top">
<trclass="row-odd"><td>all styles except those listed</td>
<p>Translational velocities can also be set by the
<aclass="reference internal"href="velocity.html"><spanclass="doc">velocity</span></a> command in the input script.</p>
</div>
<hrclass="docutils"/>
<divclass="section"id="restrictions">
<h2>Restrictions</h2>
<p>To read gzipped data files, you must compile LAMMPS with the
-DLAMMPS_GZIP option - see the <aclass="reference internal"href="Section_start.html#start-2"><spanclass="std std-ref">Making LAMMPS</span></a> section of the documentation.</p>
Built with <ahref="http://sphinx-doc.org/">Sphinx</a> using a <ahref="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <ahref="https://readthedocs.org">Read the Docs</a>.