forked from lijiext/lammps
git-svn-id: svn://svn.icms.temple.edu/lammps-ro/trunk@9726 f3b2605a-c512-4ea7-a41b-209d697bcdaa
This commit is contained in:
parent
9b753bd19f
commit
45d187463d
|
@ -333,15 +333,21 @@ 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 by some post-processing tools.
|
||||
</P>
|
||||
<P>If a "%" character appears in the filename, then one file is written
|
||||
for each processor and the "%" character is replaced with the
|
||||
processor ID from 0 to P-1. For example, tmp.dump.% becomes
|
||||
<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>Note that the "*" and "%" characters can be used together to produce a
|
||||
<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
|
||||
|
|
14
doc/dump.txt
14
doc/dump.txt
|
@ -321,15 +321,21 @@ 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 by some post-processing tools.
|
||||
|
||||
If a "%" character appears in the filename, then one file is written
|
||||
for each processor and the "%" character is replaced with the
|
||||
processor ID from 0 to P-1. For example, tmp.dump.% becomes
|
||||
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
|
||||
{dcd}, {xtc}, and {xyz} styles.
|
||||
|
||||
Note that the "*" and "%" characters can be used together to produce a
|
||||
By default, P = the number of processors meaning one file per
|
||||
processor, but P can be set to a smaller value via the {nfile} or
|
||||
{fileper} keywords of the "dump_modify"_dump_modify.html command.
|
||||
These options can be the most efficient way of writing out dump files
|
||||
when running on large numbers of processors.
|
||||
|
||||
Note that using the "*" and "%" characters together can produce a
|
||||
large number of small dump files!
|
||||
|
||||
If the filename ends with ".bin", the dump file (or files, if "*" or
|
||||
|
|
|
@ -66,12 +66,16 @@
|
|||
<I>every</I> arg = N
|
||||
N = dump every this many timesteps
|
||||
N can be a variable (see below)
|
||||
<I>fileper</I> arg = Np
|
||||
Np = write one file for every this many processors
|
||||
<I>first</I> arg = <I>yes</I> or <I>no</I>
|
||||
<I>format</I> arg = C-style format string for one line of output
|
||||
<I>flush</I> arg = <I>yes</I> or <I>no</I>
|
||||
<I>image</I> arg = <I>yes</I> or <I>no</I>
|
||||
<I>label</I> arg = string
|
||||
string = character string (e.g. BONDS) to use in header of dump local file
|
||||
<I>nfile</I> arg = Nf
|
||||
Nf = write this many files, one from each of Nf processors
|
||||
<I>pad</I> arg = Nchar = # of characters to convert timestep to
|
||||
<I>precision</I> arg = power-of-10 value from 10 to 1000000
|
||||
<I>region</I> arg = region-ID or "none"
|
||||
|
@ -96,7 +100,7 @@
|
|||
dump_modify myDump image yes scale no flush yes
|
||||
dump_modify 1 region mySphere thresh x < 0.0 thresh epair >= 3.2
|
||||
dump_modify xtcdump precision 10000
|
||||
dump_modify 1 every 1000
|
||||
dump_modify 1 every 1000 nfile 20
|
||||
dump_modify 1 every v_myVar
|
||||
dump_modify 1 amap min max cf 0.0 3 min green 0.5 yellow max blue boxcolor red
|
||||
</PRE>
|
||||
|
@ -436,6 +440,8 @@ the first two fields (atom id and type) are not actually written into
|
|||
the CFG file, though you must include formats for them in the format
|
||||
string.
|
||||
</P>
|
||||
<P>The <I>fileper</I> keyword is documented below with the <I>nfile</I> keyword.
|
||||
</P>
|
||||
<HR>
|
||||
|
||||
<P>The <I>image</I> keyword applies only to the dump <I>atom</I> style. If the
|
||||
|
@ -463,6 +469,28 @@ e.g. BONDS or ANGLES.
|
|||
</P>
|
||||
<HR>
|
||||
|
||||
<P>The <I>nfile</I> or <I>fileper</I> keywords can be used in conjunction with the
|
||||
"%" wildcard character in the specified dump file name, for all dump
|
||||
styles except the <I>dcd</I>, <I>xtc</I>, and <I>xyz</I> styles (for which "%" is not
|
||||
allowed). As explained on the <A HREF = "dump.html">dump</A> command doc page, the
|
||||
"%" character causes the dump file to be written in pieces, one piece
|
||||
for each of P processors. By default P = the number of processors the
|
||||
simulation is running on. The <I>nfile</I> or <I>fileper</I> keyword can be
|
||||
used to set P to a smaller value, which can be more efficient when
|
||||
running on a large number of processors.
|
||||
</P>
|
||||
<P>The <I>nfile</I> keyword sets P to the specified Nf value. For example, if
|
||||
Nf = 4, and the simulation is running on 100 processors, 4 files will
|
||||
be written, by processors 0,25,50,75. Each will collect information
|
||||
from itself and the next 24 processors and write it to a dump file.
|
||||
</P>
|
||||
<P>For the <I>fileper</I> keyword, the specified value of Np means write one
|
||||
file for every Np processors. For example, if Np = 4, every 4th
|
||||
processor (0,4,8,12,etc) will collect information from itself and the
|
||||
next 3 processors and write it to a dump file.
|
||||
</P>
|
||||
<HR>
|
||||
|
||||
<P>The <I>pad</I> keyword only applies when the dump filename is specified
|
||||
with a wildcard "*" character which becomes the timestep. If <I>pad</I> is
|
||||
0, which is the default, the timestep is converted into a string of
|
||||
|
@ -509,10 +537,14 @@ sort</A> option is turned on, which it is by default, to
|
|||
improve performance. A sort value of <I>id</I> means sort the output by
|
||||
atom ID. A sort value of N or -N means sort the output by the value
|
||||
in the Nth column of per-atom info in either ascending or descending
|
||||
order. The dump <I>local</I> style cannot be sorted by atom ID, since
|
||||
there are typically multiple lines of output per atom. Some dump
|
||||
styles, such as <I>dcd</I> and <I>xtc</I>, require sorting by atom ID to format
|
||||
the output file correctly.
|
||||
order.
|
||||
</P>
|
||||
<P>The dump <I>local</I> style cannot be sorted by atom ID, since there are
|
||||
typically multiple lines of output per atom. Some dump styles, such
|
||||
as <I>dcd</I> and <I>xtc</I>, require sorting by atom ID to format the output
|
||||
file correctly. If multiple processors are writing the dump file, via
|
||||
the "%" wildcard in the dump filename, then sorting cannot be
|
||||
performed.
|
||||
</P>
|
||||
<P>IMPORTANT NOTE: Unless it is required by the dump style, sorting dump
|
||||
file output requires extra overhead in terms of CPU and communication
|
||||
|
|
|
@ -60,12 +60,16 @@ keyword = {acolor} or {adiam} or {amap} or {append} or {bcolor} or {bdiam} or {b
|
|||
{every} arg = N
|
||||
N = dump every this many timesteps
|
||||
N can be a variable (see below)
|
||||
{fileper} arg = Np
|
||||
Np = write one file for every this many processors
|
||||
{first} arg = {yes} or {no}
|
||||
{format} arg = C-style format string for one line of output
|
||||
{flush} arg = {yes} or {no}
|
||||
{image} arg = {yes} or {no}
|
||||
{label} arg = string
|
||||
string = character string (e.g. BONDS) to use in header of dump local file
|
||||
{nfile} arg = Nf
|
||||
Nf = write this many files, one from each of Nf processors
|
||||
{pad} arg = Nchar = # of characters to convert timestep to
|
||||
{precision} arg = power-of-10 value from 10 to 1000000
|
||||
{region} arg = region-ID or "none"
|
||||
|
@ -89,7 +93,7 @@ dump_modify 1 format "%d %d %20.15g %g %g" scale yes
|
|||
dump_modify myDump image yes scale no flush yes
|
||||
dump_modify 1 region mySphere thresh x < 0.0 thresh epair >= 3.2
|
||||
dump_modify xtcdump precision 10000
|
||||
dump_modify 1 every 1000
|
||||
dump_modify 1 every 1000 nfile 20
|
||||
dump_modify 1 every v_myVar
|
||||
dump_modify 1 amap min max cf 0.0 3 min green 0.5 yellow max blue boxcolor red :pre
|
||||
|
||||
|
@ -429,6 +433,8 @@ the first two fields (atom id and type) are not actually written into
|
|||
the CFG file, though you must include formats for them in the format
|
||||
string.
|
||||
|
||||
The {fileper} keyword is documented below with the {nfile} keyword.
|
||||
|
||||
:line
|
||||
|
||||
The {image} keyword applies only to the dump {atom} style. If the
|
||||
|
@ -456,6 +462,28 @@ e.g. BONDS or ANGLES.
|
|||
|
||||
:line
|
||||
|
||||
The {nfile} or {fileper} keywords can be used in conjunction with the
|
||||
"%" wildcard character in the specified dump file name, for all dump
|
||||
styles except the {dcd}, {xtc}, and {xyz} styles (for which "%" is not
|
||||
allowed). As explained on the "dump"_dump.html command doc page, the
|
||||
"%" character causes the dump file to be written in pieces, one piece
|
||||
for each of P processors. By default P = the number of processors the
|
||||
simulation is running on. The {nfile} or {fileper} keyword can be
|
||||
used to set P to a smaller value, which can be more efficient when
|
||||
running on a large number of processors.
|
||||
|
||||
The {nfile} keyword sets P to the specified Nf value. For example, if
|
||||
Nf = 4, and the simulation is running on 100 processors, 4 files will
|
||||
be written, by processors 0,25,50,75. Each will collect information
|
||||
from itself and the next 24 processors and write it to a dump file.
|
||||
|
||||
For the {fileper} keyword, the specified value of Np means write one
|
||||
file for every Np processors. For example, if Np = 4, every 4th
|
||||
processor (0,4,8,12,etc) will collect information from itself and the
|
||||
next 3 processors and write it to a dump file.
|
||||
|
||||
:line
|
||||
|
||||
The {pad} keyword only applies when the dump filename is specified
|
||||
with a wildcard "*" character which becomes the timestep. If {pad} is
|
||||
0, which is the default, the timestep is converted into a string of
|
||||
|
@ -502,10 +530,14 @@ sort"_atom_modify.html option is turned on, which it is by default, to
|
|||
improve performance. A sort value of {id} means sort the output by
|
||||
atom ID. A sort value of N or -N means sort the output by the value
|
||||
in the Nth column of per-atom info in either ascending or descending
|
||||
order. The dump {local} style cannot be sorted by atom ID, since
|
||||
there are typically multiple lines of output per atom. Some dump
|
||||
styles, such as {dcd} and {xtc}, require sorting by atom ID to format
|
||||
the output file correctly.
|
||||
order.
|
||||
|
||||
The dump {local} style cannot be sorted by atom ID, since there are
|
||||
typically multiple lines of output per atom. Some dump styles, such
|
||||
as {dcd} and {xtc}, require sorting by atom ID to format the output
|
||||
file correctly. If multiple processors are writing the dump file, via
|
||||
the "%" wildcard in the dump filename, then sorting cannot be
|
||||
performed.
|
||||
|
||||
IMPORTANT NOTE: Unless it is required by the dump style, sorting dump
|
||||
file output requires extra overhead in terms of CPU and communication
|
||||
|
|
Loading…
Reference in New Issue