1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
|
<HTML>
<CENTER> <A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> - <A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A>
</CENTER>
<HR>
<H3>dump command
</H3>
<H3><A HREF = "dump_image.html">dump image</A> command
</H3>
<H3><A HREF = "dump_image.html">dump movie</A> command
</H3>
<H3><A HREF = "dump_molfile.html">dump molfile</A> command
</H3>
<P><B>Syntax:</B>
</P>
<PRE>dump ID group-ID style N file args
</PRE>
<UL><LI>ID = user-assigned name for the dump
<LI>group-ID = ID of the group of atoms to be dumped
<LI>style = <I>atom</I> or <I>atom/vtk</I> or <I>cfg</I> or <I>dcd</I> or <I>xtc</I> or <I>xyz</I> or <I>image</I> or <I>molfile</I> or <I>local</I> or <I>custom</I> or <I>mesh/stl</I> or <I>mesh/vtk</I> or <I>mesh/vtk</I> or <I>decomposition/vtk</I> or <I>euler/vtk</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/vtk</I> args = none
<I>cfg</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>image</I> args = discussed on <A HREF = "dump_image.html">dump image</A> doc page
</PRE>
<PRE> <I>molfile</I> args = discussed on <A HREF = "dump_molfile.html">dump molfile</A> doc page
</PRE>
<PRE> <I>mesh/stl</I> args = 'local' or 'ghost' or 'all' or 'region' or any ID of a <A HREF = "fix_mesh_surface.html">fix mesh/surface</A>
<I>region</I> values = ID for region threshold
<I>mesh/vtk</I> args = zero or more keyword/ value pairs and one or more dump-identifiers
keywords = <I>output</I>
<I>output</I> values = face or interpolate
dump-identifier = 'stress' or 'id' or 'wear' or 'vel' or 'stresscomponents' or 'owner' or 'area' or 'aedges' or 'acorners' or 'nneigs' or any ID of a <A HREF = "fix_mesh_surface.html">fix mesh/surface</A>
<I>euler/vtk</I> args = none
<I>decomposition/vtk</I> args = none
</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> args = list of atom attributes
possible attributes = id, mol, 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,
spin, eradius, ervel, erforce,
c_ID, c_ID[N], f_ID, f_ID[N], v_name
</PRE>
<PRE> id = atom ID
mol = molecule ID
type = atom type
element = name of atom element, as defined by <A HREF = "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
spin = electron spin
eradius = electron radius
ervel = electron radial velocity
erforce = electron radial force
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
</PRE>
</UL>
<P><B>Examples:</B>
</P>
<PRE>dump myDump all atom 100 dump.atom
dump 2 subgroup atom 50 dump.run.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<B>2</B>
dump 1 all xtc 1000 file.xtc
dump e_data all custom 100 dump.eff id type x y z spin eradius fx fy fz eforce
</PRE>
<P><B>LIGGGHTS vs. LAMMPS Info:</B>
</P>
<P>Two new styles (<I>mesh/stl</I> and <I>mesh/vtk</I>) are available for dumping
granular mesh geometry into STL files or VTK files. The former is used
for dumping only the geometry, while the latter command is used to dump
the mesh IDs, stress etc- calculated on a granular mesh using the
<A HREF = "fix_mesh_surface_stress.html">fix mesh/surface/stress</A> command.
Furthermore, style <I>decomposition/vtk</I> can be used to dump the current
parallel domain decomposition to a VTK file.
Style <I>euler/vtk</I> can be used to dump cell-based averages to a VTK file.
</P>
<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> style is the
exception; it creates a JPG or PPM image file of the atom
configuration every N timesteps, as discussed on the <A HREF = "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 <A HREF = "dump_modify.html">dump_modify
every</A> command for details.
</P>
<P>Only information for atoms in the specified group is dumped. The
<A HREF = "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 <A HREF = "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 <A HREF = "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 <A HREF = "dump_modify.html">dump_modify</A> doc
page for details.
</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
<A HREF = "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 <A HREF = "Section_tools.html">post-processing tools</A>, including
<A HREF = "http://www.sandia.gov/~sjplimp/pizza.html">Pizza.py</A>, work with this
format, as does the <A HREF = "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
<A HREF = "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 <A HREF = "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
<A HREF = "dump_modify.html">dump_modify</A> settings. Image flags can also be
added for each atom via dump_modify.
</P>
<P>For style <I>atom/vtk</I>, atom coordinates, velocity, rotational
velocity, force, atom ID, atom radius and atom type are written to
VTK files. Note that you have to link against VTK libraries to use
this functionality.
</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 <A HREF = "compute.html">computes</A>
and <A HREF = "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 <A HREF = "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
<A HREF = "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
extended CFG format files, as used by the
<A HREF = "http://mt.seas.upenn.edu/Archive/Graphics/A">AtomEye</A> visualization
package. Since the extended CFG format uses a single snapshot of the
system per file, a wildcard "*" must be included in the filename, as
discussed below. The list of atom attributes for style <I>cfg</I> must
begin with either "mass type xs ys zs" or "mass type xsu ysu zsu"
since these quantities are needed to write the CFG files in the
appropriate format (though the "mass" and "type" fields do not appear
explicitly in the file). Any remaining attributes will be stored as
"auxiliary properties" in the CFG files. Note that you will typically
want to use the <A HREF = "dump_modify.html">dump_modify element</A> command with
CFG-formatted files, to associate element names with atom types, so
that AtomEye can render atoms appropriately. When unwrapped
coordinates <I>xsu</I>, <I>ysu</I>, and <I>zsu</I> are requested, the nominal AtomEye
periodic cell dimensions are expanded by a large factor UNWRAPEXPAND =
10.0, which ensures atoms that are displayed correctly for up to
UNWRAPEXPAND/2 periodic boundary crossings in any direction. Beyond
this, AtomEye will rewrap the unwrapped coordinates. The expansion
causes the atoms to be drawn farther away from the viewer, but it is
easy to zoom the atoms closer, and the interatomic distances are
unaffected.
</P>
<P>The <I>dcd</I> style writes DCD files, a standard atomic trajectory format
used by the CHARMM, NAMD, and XPlor molecular dynamics packages. DCD
files are binary and thus may not be portable to different machines.
The number of atoms per snapshot cannot change with the <I>dcd</I> style.
The <I>unwrap</I> option of the <A HREF = "dump_modify.html">dump_modify</A> command
allows DCD coordinates to be written "unwrapped" by the image flags
for each atom. Unwrapped means that if the atom has passed through
a periodic boundary one or more times, the value is printed for what
the coordinate would be if it had not been wrapped back into the
periodic box. Note that these coordinates may thus be far outside
the box size stored with the snapshot.
</P>
<P>The <I>xtc</I> style writes XTC files, a compressed trajectory format used
by the GROMACS molecular dynamics package, and described
<A HREF = "http://manual.gromacs.org/current/online/xtc.html">here</A>.
The precision used in XTC files can be adjusted via the
<A HREF = "dump_modify.html">dump_modify</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 <I>xtc</I> style.
The <I>unwrap</I> option of the <A HREF = "dump_modify.html">dump_modify</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 <I>xyz</I> 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 HREF = "dump_modify.html">dump_modify element</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 <I>atom</I>, <I>custom</I>, <I>dcd</I>, <I>xtc</I>, and <I>xyz</I> style dump files
can be read directly by <A HREF = "http://www.ks.uiuc.edu/Research/vmd">VMD</A>, a
popular molecular viewing program. See <A HREF = "Section_tools.html#vmd">Section
tools</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>
<P>The <I>mesh/stl</I> style dumps active STL geometries defined via
<A HREF = "fix_mesh.html">fix mesh</A> commands into the specified file.
If you do not supply the optional list of mesh IDs, all meshes are dumped,
irrespective of whether they are used in a <A HREF = "fix_wall_gran.html">fix wall/gran</A>
command or not. By specifying a list of mesh IDs you can explicitly
choose which meshes to dump. The group-ID is ignored, because the command
is not applied to particles, but to mesh geometries.
With keywords 'local', 'owned' or 'ghost' you can decide which parts
of the parallel meshes you want to dump (default is 'local'). If the
multiprocessor option is not used (no '%' in filename), data is gathered
from all processors, so using the default will output the whole mesh
data across all processors.
</P>
<P>Examples:
</P>
<PRE>dump stl1 all mesh/stl 300 post/dump*.stl
dump stl2 all mesh/stl 300 post/dump_proc%_local*.stl local
dump stl3 all mesh/stl 300 post/dump_proc%_ghost*.stl ghost
dump stl4 all mesh/stl 300 post/dump_proc_all_ghost*.stl ghost
</PRE>
<P>The first command will write one file per time-step containing the complete
mesh. The second command will output one file per time-step per processor
containing the local (owned) mesh elements of each processor.
The third command will output one file per time-step per processor
containing the ghost (corona) mesh elements of each processor.
The third command will output one file per time-step containing the
ghost (corona) mesh elements of all processors.
</P>
<P>With the <I>region</I> keyword, just those mesh element where the element center
(arithmetic average of all nodes) is in the specified region, will be
dumped.
</P>
<P>This dump is especially useful if a
<A HREF = "fix_move_mesh.html">fix move/mesh</A> is registered. If the position
of the mesh is changed over time and you want to dump one file for each dump
timestep for post-processing together with the particle data, you should use
a filename like 'mydumpfile*.stl'. Note: This series of files can then be
post-processed together with the particle dump file converted to VTK in
Paraview , www.paraview.org
</P>
<P>By providing any ID (or a list of IDs) of <A HREF = "fix_mesh_surface.html">fix mesh/surface</A>
commands, you can specify which meshes to dump. If no meshes are specified,
all meshes used in the simulation are dumped.
</P>
<P>The <I>mesh/vtk</I> style can be used to dump active mesh geometries
defined via <A HREF = "fix_mesh.html">fix mesh</A> commands to a series of VTK files.
Different keywords can be used to dump the per-triangle stress (force
magnitude / element area), id, velocity, wear, stress components
(fx / element area, fy / element area, fz / element area), area (area
of each element) or the process which owns the element
(visulatisation of the parallel decomposition) into the specified file using a
VTK file format. The list of mesh IDs is optional. As with the stl style,
all active meshes are dumped if you do not supply the optional list of
mesh IDs. By specifying list of mesh IDs you can explicitly choose
which meshes to dump. The group-ID is ignored. Again, a series of files
can be post-processed in Paraview , www.paraview.org
Most keywords as used for the <I>mesh/vtk</I> style are self-explanatory.
Keyword <I>output</I> controlls if the data is written in a per-face manner
or as interpolated values to VTK. Keywords <I>aedges</I> and <I>acorners</I> dump
the number of active edges/corners per face. Keyword <I>nneighs</I> dumps the
number of face neighbors LIGGGHTS has recognized for each face.
</P>
<P>By providing any ID (or a list of IDs) of <A HREF = "fix_mesh_surface.html">fix mesh/surface</A>
commands, you can specify which meshes to dump. If no meshes are specified,
all meshes used in the simulation are dumped.
</P>
<P>The <I>euler/vtk</I> style dumps the output of a <A HREF = "fix_ave_euler.html">fix ave/euler</A>
command into a series of VTK files. No further args are expected.
</P>
<P>The <I>decomposition/vtk</I> style dumps the processor grid decomposition
into a series of VTK files. No further args are expected.
</P>
<HR>
<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 HREF = "dump_modify.html">dump_modify first</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 HREF = "dump_modify.html">dump_modify every</A> command (not allowed
for <I>dcd</I> style). The <A HREF = "dump_modify.html">dump_modify every</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 HREF = "dump_modify.html">dump_modify first</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 HREF = "undump.html">undump</A>
command is used or when LAMMPS exits. For the <I>dcd</I> and <I>xtc</I> 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 <I>dcd</I> and
<I>xtc</I> styles. Note that the <A HREF = "dump_modify.html">dump_modify pad</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
<I>dcd</I>, <I>xtc</I>, and <I>xyz</I> 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 <I>nfile</I> or
<I>fileper</I> keywords of the <A HREF = "dump_modify.html">dump_modify</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>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 HREF = "Section_tools.html#binary">binary2txt
tool</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 <I>atom</I> and <I>custom</I> 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 <I>dcd</I> and <I>xtc</I>
styles.
</P>
<HR>
<P>This section explains the local attributes that can be specified as
part of the <I>local</I> style.
</P>
<P>The <I>index</I> 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 <I>c_ID</I> and <I>c_ID[N]</I> attributes allow local vectors or arrays
calculated by a <A HREF = "compute.html">compute</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 HREF = "compute.html">compute</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 HREF = "thermo_style.html">thermo_style
custom</A> command, and per-atom quantities can be
output by the dump custom command.
</P>
<P>If <I>c_ID</I> is used as a attribute, then the local vector calculated by
the compute is printed. If <I>c_ID[N]</I> 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 <I>f_ID</I> and <I>f_ID[N]</I> attributes allow local vectors or arrays
calculated by a <A HREF = "fix.html">fix</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 <I>f_ID</I> is used as a attribute, then the local vector calculated by
the fix is printed. If <I>f_ID[N]</I> 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>
<PRE>compute 1 all property/local batom1 batom2 btype
compute 2 all bond/local dist eng
dump 1 all local 1000 tmp.dump index c_1[1] c_1[2] c_1[3] c_2[1] c_2[2]
</PRE>
<HR>
<P>This section explains the atom attributes that can be specified as
part of the <I>custom</I> and <I>cfg</I> styles.
</P>
<P>The <I>id</I>, <I>mol</I>, <I>type</I>, <I>element</I>, <I>mass</I>, <I>vx</I>, <I>vy</I>, <I>vz</I>, <I>fx</I>, <I>fy</I>,
<I>fz</I>, <I>q</I> attributes are self-explanatory.
</P>
<P><I>Id</I> is the atom ID. <I>Mol</I> is the molecule ID, included in the data
file for molecular systems. <I>Type</I> is the atom type. <I>Element</I> is
typically the chemical name of an element, which you must assign to
each type via the <A HREF = "dump_modify.html">dump_modify element</A> command.
More generally, it can be any string you wish to associated with an
atom type. <I>Mass</I> is the atom mass. <I>Vx</I>, <I>vy</I>, <I>vz</I>, <I>fx</I>, <I>fy</I>,
<I>fz</I>, and <I>q</I> are components of atom velocity and force and atomic
charge.
</P>
<P>There are several options for outputting atom coordinates. The <I>x</I>,
<I>y</I>, <I>z</I> attributes write atom coordinates "unscaled", in the
appropriate distance <A HREF = "units.html">units</A> (Angstroms, sigma, etc). Use
<I>xs</I>, <I>ys</I>, <I>zs</I> if you want the coordinates "scaled" to the box size,
so that each value is 0.0 to 1.0. If the simulation box is triclinic
(tilted), then all atom coords will still be between 0.0 and 1.0. Use
<I>xu</I>, <I>yu</I>, <I>zu</I> 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 <I>xu</I>, <I>yu</I>, <I>zu</I> means that the
coordinate values may be far outside the box bounds printed with the
snapshot. Using <I>xsu</I>, <I>ysu</I>, <I>zsu</I> is similar to using <I>xu</I>, <I>yu</I>, <I>zu</I>,
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 <I>ix</I>, <I>iy</I>, <I>iz</I>
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 <I>mux</I>, <I>muy</I>, <I>muz</I> attributes are specific to dipolar systems
defined with an atom style of <I>dipole</I>. They give the orientation of
the atom's point dipole moment. The <I>mu</I> attribute gives the
magnitude of the atom's dipole moment.
</P>
<P>The <I>radius</I> and <I>diameter</I> attributes are specific to spherical
particles that have a finite size, such as those defined with an atom
style of <I>sphere</I>.
</P>
<P>The <I>omegax</I>, <I>omegay</I>, and <I>omegaz</I> attributes are specific to
finite-size spherical particles that have an angular velocity. Only
certain atom styles, such as <I>sphere</I> define this quantity.
</P>
<P>The <I>angmomx</I>, <I>angmomy</I>, and <I>angmomz</I> attributes are specific to
finite-size aspherical particles that have an angular momentum. Only
the <I>ellipsoid</I> atom style defines this quantity.
</P>
<P>The <I>tqx</I>, <I>tqy</I>, <I>tqz</I> attributes are for finite-size particles that
can sustain a rotational torque due to interactions with other
particles.
</P>
<P>The <I>spin</I>, <I>eradius</I>, <I>ervel</I>, and <I>erforce</I> attributes are for
particles that represent nuclei and electrons modeled with the
electronic force field (EFF). See <A HREF = "atom_style.html">atom_style
electron</A> and <A HREF = "pair_eff.html">pair_style eff</A> for more
details.
</P>
<P>The <I>c_ID</I> and <I>c_ID[N]</I> attributes allow per-atom vectors or arrays
calculated by a <A HREF = "compute.html">compute</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 HREF = "compute.html">compute</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 HREF = "thermo_style.html">thermo_style custom</A> command, and local quantities
can be output by the dump local command.
</P>
<P>If <I>c_ID</I> is used as a attribute, then the per-atom vector calculated
by the compute is printed. If <I>c_ID[N]</I> 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 <I>f_ID</I> and <I>f_ID[N]</I> attributes allow vector or array per-atom
quantities calculated by a <A HREF = "fix.html">fix</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 HREF = "fix_ave_atom.html">fix
ave/atom</A> command is one that calculates per-atom
quantities. Since it can time-average per-atom quantities produced by
any <A HREF = "compute.html">compute</A>, <A HREF = "fix.html">fix</A>, or atom-style
<A HREF = "variable.html">variable</A>, this allows those time-averaged results to
be written to a dump file.
</P>
<P>If <I>f_ID</I> is used as a attribute, then the per-atom vector calculated
by the fix is printed. If <I>f_ID[N]</I> 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 <I>v_name</I> attribute allows per-atom vectors calculated by a
<A HREF = "variable.html">variable</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 <I>atom</I> 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>See <A HREF = "Section_modify.html">Section_modify</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>
<HR>
<P><B>Restrictions:</B>
</P>
<P>To write gzipped dump files, you must compile LAMMPS with the
-DLAMMPS_GZIP option - see the <A HREF = "Section_start.html#start_2">Making
LAMMPS</A> section of the documentation.
</P>
<P>To be able to use <I>atom/vtk</I>, you have to link to VTK libraries,
please adapt your Makefile accordingly.
</P>
<P>The <I>xtc</I> style is part of the XTC package. It is only enabled if
LAMMPS was built with that package. See the <A HREF = "Section_start.html#start_3">Making
LAMMPS</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 XTC 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
machines.
</P>
<P><B>Related commands:</B>
</P>
<P><A HREF = "dump_image.html">dump image</A>, <A HREF = "dump_modify.html">dump_modify</A>,
<A HREF = "undump.html">undump</A>
</P>
<P><B>Default:</B>
</P>
<P>The defaults for the image style are listed on the <A HREF = "dump_image.html">dump
image</A> doc page.
</P>
</HTML>
|
