forked from lijiext/lammps
569 lines
29 KiB
HTML
569 lines
29 KiB
HTML
<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>compute chunk/atom command
|
|
</H3>
|
|
<P><B>Syntax:</B>
|
|
</P>
|
|
<PRE>compute ID group-ID chunk/atom style args keyword values ...
|
|
</PRE>
|
|
<UL><LI>ID, group-ID are documented in <A HREF = "compute.html">compute</A> command
|
|
|
|
<LI>chunk/atom = style name of this compute command
|
|
|
|
<PRE>style = <I>bin/1d</I> or <I>bin/2d</I> or <I>bin/3d</I> or <I>type</I> or <I>molecule</I> or <I>compute/fix/variable</I>
|
|
<I>bin/1d</I> args = dim origin delta
|
|
dim = <I>x</I> or <I>y</I> or <I>z</I>
|
|
origin = <I>lower</I> or <I>center</I> or <I>upper</I> or coordinate value (distance units)
|
|
delta = thickness of spatial bins in dim (distance units)
|
|
<I>bin/2d</I> args = dim origin delta dim origin delta
|
|
dim = <I>x</I> or <I>y</I> or <I>z</I>
|
|
origin = <I>lower</I> or <I>center</I> or <I>upper</I> or coordinate value (distance units)
|
|
delta = thickness of spatial bins in dim (distance units)
|
|
<I>bin/3d</I> args = dim origin delta dim origin delta dim origin delta
|
|
dim = <I>x</I> or <I>y</I> or <I>z</I>
|
|
origin = <I>lower</I> or <I>center</I> or <I>upper</I> or coordinate value (distance units)
|
|
delta = thickness of spatial bins in dim (distance units)
|
|
<I>type</I> args = none
|
|
<I>molecule</I> args = none
|
|
<I>compute/fix/variable</I> = c_ID, c_ID[I], f_ID, f_ID[I], v_name with no args
|
|
c_ID = per-atom vector calculated by a compute with ID
|
|
c_ID[I] = Ith column of per-atom array calculated by a compute with ID
|
|
f_ID = per-atom vector calculated by a fix with ID
|
|
f_ID[I] = Ith 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>
|
|
<LI>zero or more keyword/values pairs may be appended
|
|
|
|
<LI>keyword = <I>region</I> or <I>nchunk</I> or <I>static</I> or <I>compress</I> or <I>bound</I> or <I>discard</I> or <I>units</I>
|
|
|
|
<PRE> <I>region</I> value = region-ID
|
|
region-ID = ID of region atoms must be in to be part of a chunk
|
|
<I>nchunk</I> value = <I>once</I> or <I>every</I>
|
|
once = only compute the number of chunks once
|
|
every = re-compute the number of chunks whenever invoked
|
|
<I>limit</I> values = 0 or Nc max or Nc exact
|
|
0 = no limit on the number of chunks
|
|
Nc max = limit number of chunks to be <= Nc
|
|
Nc exact = set number of chunks to exactly Nc
|
|
<I>ids</I> value = <I>once</I> or <I>nfreq</I> or <I>every</I>
|
|
once = assign chunk IDs to atoms only once, they persist thereafter
|
|
nfreq = assign chunk IDs to atoms only once every Nfreq steps (if invoked by <A HREF = "fix_ave_chunk.html">fix ave/chunk</A> which sets Nfreq)
|
|
every = assign chunk IDs to atoms whenever invoked
|
|
<I>compress</I> value = <I>yes</I> or <I>no</I>
|
|
yes = compress chunk IDs to eliminate IDs with no atoms
|
|
no = do not compress chunk IDs even if some IDs have no atoms
|
|
<I>discard</I> value = <I>yes</I> or <I>no</I> or <I>mixed</I>
|
|
yes = discard atoms with out-of-range chunk IDs by assigning a chunk ID = 0
|
|
no = keep atoms with out-of-range chunk IDs by assigning a valid chunk ID
|
|
mixed = keep or discard such atoms according to spatial binning rule
|
|
<I>bound</I> values = x/y/z lo hi
|
|
x/y/z = <I>x</I> or <I>y</I> or <I>z</I> to bound sptial bins in this dimension
|
|
lo = <I>lower</I> or coordinate value (distance units)
|
|
hi = <I>upper</I> or coordinate value (distance units)
|
|
<I>units</I> value = <I>box</I> or <I>lattice</I> or <I>reduced</I>
|
|
</PRE>
|
|
|
|
</UL>
|
|
<P><B>Examples:</B>
|
|
</P>
|
|
<PRE>compute 1 all chunk/atom type
|
|
compute 1 all chunk/atom bin/1d z lower 0.02 units reduced
|
|
compute 1 all chunk/atom bin/2d z lower 1.0 y 0.0 2.5
|
|
compute 1 all chunk/atom molecule region sphere nchunk once ids once compress yes
|
|
</PRE>
|
|
<P><B>Description:</B>
|
|
</P>
|
|
<P>Define a computation that calculates an integer chunk ID from 1 to
|
|
Nchunk for each atom in the group. Values of chunk IDs are determined
|
|
by the <I>style</I> of chunk, which can be based on atom type or molecule
|
|
ID or spatial binning or a per-atom property or value calculated by
|
|
another <A HREF = "compute.html">compute</A>, <A HREF = "fix.html">fix</A>, or <A HREF = "variable.html">atom-style
|
|
variable</A>. Per-atom chunk IDs can be used by other
|
|
computes with "chunk" in their style name, such as <A HREF = "compute_com_chunk.html">compute
|
|
com/chunk</A> or <A HREF = "compute_msd_chunk.html">compute
|
|
msd/chunk</A>. Or they can be used by the <A HREF = "fix_ave_chunk.html">fix
|
|
ave/chunk</A> command to sum and time average a
|
|
variety of per-atom properties over the atoms in each chunk. Or they
|
|
can simply be accessed by any command that uses per-atom values from a
|
|
compute as input, as discussed in <A HREF = "Section_howto.html#howto_15">Section_howto
|
|
15</A>.
|
|
</P>
|
|
<P>See <A HREF = "Section_howto.html#howto_23">Section_howto 23</A> for an overview of
|
|
how this compute can be used with a variety of other commands to
|
|
tabulate properties of a simulation. The howto section gives several
|
|
examples of input script commands that can be used to calculate
|
|
interesting properties.
|
|
</P>
|
|
<P>Conceptually it is important to realize that this compute does two
|
|
simple things. First, it sets the value of <I>Nchunk</I> = the number of
|
|
chunks, which can be a constant value or change over time. Second, it
|
|
assigns each atom to a chunk via a chunk ID. Chunk IDs range from 1
|
|
to <I>Nchunk</I> inclusive; some chunks may have no atoms assigned to them.
|
|
Atoms that do not belong to any chunk are assigned a value of 0. Note
|
|
that the two operations are not always performed together. For
|
|
example, spatial bins can be setup once (which sets <I>Nchunk</I>), and
|
|
atoms assigned to those bins many times thereafter (setting their
|
|
chunk IDs).
|
|
</P>
|
|
<P>All other commands in LAMMPS that use chunk IDs assume there are
|
|
<I>Nchunk</I> number of chunks, and that every atom is assigned to one of
|
|
those chunks, or not assigned to any chunk.
|
|
</P>
|
|
<P>There are many options for specifying for how and when <I>Nchunk</I> is
|
|
calculated, and how and when chunk IDs are assigned to atoms. The
|
|
details depend on the chunk <I>style</I> and its <I>args</I>, as well as
|
|
optional keyword settings. They can also depend on whether a <A HREF = "fix_ave_chunk.html">fix
|
|
ave/chunk</A> command is using this compute, since
|
|
that command requires <I>Nchunk</I> to remain static across windows of
|
|
timesteps it specifies, while it accumulates per-chunk averages.
|
|
</P>
|
|
<P>The details are described below.
|
|
</P>
|
|
<HR>
|
|
|
|
<HR>
|
|
|
|
<P>The different chunk styles operate as follows. For each style, how it
|
|
calculates <I>Nchunk</I> and assigns chunk IDs to atoms is explained. Note
|
|
that using the optional keywords can change both of those actions, as
|
|
described further below where the keywords are discussed.
|
|
</P>
|
|
<HR>
|
|
|
|
<P>The <I>binning</I> styles perform a spatial binning of atoms, and assign an
|
|
atom the chunk ID corresponding to the bin number it is in. <I>Nchunk</I>
|
|
is set to the number of bins, which can change if the simulation box
|
|
size changes.
|
|
</P>
|
|
<P>The <I>bin/1d</I>, <I>bin/2d</I>, and <I>bin/3d</I> styles define bins as 1d layers
|
|
(slabs), 2d pencils, or 3d boxes. The <I>dim</I>, <I>origin</I>, and <I>delta</I>
|
|
settings are specified 1, 2, or 3 times. For 2d or 3d bins, there is
|
|
no restriction on specifying dim = x before dim = y or z, or dim = y
|
|
before dim = z. Bins in a particular <I>dim</I> have a bin size in that
|
|
dimension given by <I>delta</I>. In each dimension, bins are defined
|
|
relative to a specified <I>origin</I>, which may be the lower/upper edge of
|
|
the simulation box (in that dimension), or its center point, or a
|
|
specified coordinate value. Starting at the origin, sufficient bins
|
|
are created in both directions to completely span the simulation box
|
|
or the bounds specified by the optional <I>bounds</I> keyword.
|
|
</P>
|
|
<P>For orthogonal simulation boxes, the bins are layers, pencils, or
|
|
boxes aligned with the xyz coordinate axes. For triclinic
|
|
(non-orthogonal) simulation boxes, the bin faces are parallel to the
|
|
tilted faces of the simulation box. See <A HREF = "Section_howto.html#howto_12">this
|
|
section</A> of the manual for a discussion of
|
|
the geometry of triclinic boxes in LAMMPS. As described there, a
|
|
tilted simulation box has edge vectors a,b,c. In that nomenclature,
|
|
bins in the x dimension have faces with normals in the "b" cross "c"
|
|
direction. Bins in y have faces normal to the "a" cross "c"
|
|
direction. And bins in z have faces normal to the "a" cross "b"
|
|
direction. Note that in order to define the size and position of
|
|
these bins in an unambiguous fashion, the <I>units</I> option must be set
|
|
to <I>reduced</I> when using a triclinic simulation box, as noted below.
|
|
</P>
|
|
<P>The meaning of <I>origin</I> and <I>delta</I> for triclinic boxes is as follows.
|
|
Consider a triclinic box with bins that are 1d layers or slabs in the
|
|
x dimension. No matter how the box is tilted, an <I>origin</I> of 0.0
|
|
means start layers at the lower "b" cross "c" plane of the simulation
|
|
box and an <I>origin</I> of 1.0 means to start layers at the upper "b"
|
|
cross "c" face of the box. A <I>delta</I> value of 0.1 in <I>reduced</I> units
|
|
means there will be 10 layers from 0.0 to 1.0, regardless of the
|
|
current size or shape of the simulation box.
|
|
</P>
|
|
<P>The created bins (and hence the chunk IDs) are numbered consecutively
|
|
from 1 to the number of bins = <I>Nchunk</I>. For 2d and 3d bins, the
|
|
numbering varies most rapidly in the first dimension (which could be
|
|
x, y, or z), next rapidly in the 2nd dimension, and most slowly in the
|
|
3rd dimension.
|
|
</P>
|
|
<P>Each time this compute is invoked, each atom is mapped to a bin based
|
|
on its current position. Note that between reneighboring timesteps,
|
|
atoms can move outside the current simulation box. If the box is
|
|
periodic (in that dimension) the atom is remapping into the periodic
|
|
box for purposes of binning. If the box in not periodic, the atom may
|
|
have moved outside the bounds of all bins. If an atom is not inside
|
|
any bin, the <I>discard</I> keyword is used to determine how a chunk ID is
|
|
assigned to the atom.
|
|
</P>
|
|
<HR>
|
|
|
|
<P>The <I>type</I> style uses the atom type as the chunk ID. <I>Nchunk</I> is set
|
|
to the number of atom types defined for the simulation, e.g. via the
|
|
<A HREF = "create_box.html">create_box</A> or <A HREF = "read_data.html">read_data</A> commands.
|
|
</P>
|
|
<HR>
|
|
|
|
<P>The <I>molecule</I> style uses the molecule ID of each atom as its chunk
|
|
ID. <I>Nchunk</I> is set to the largest chunk ID. Note that this excludes
|
|
molecule IDs for atoms which are not in the specified group or
|
|
optional region.
|
|
</P>
|
|
<P>There is no requirement that all atoms in a particular molecule are
|
|
assigned the same chunk ID (zero or non-zero), though you probably
|
|
want that to be the case, if you wish to compute a per-molecule
|
|
property. LAMMPS will issue a warning if that is not the case, but
|
|
only the first time that <I>Nchunk</I> is calculated.
|
|
</P>
|
|
<P>Note that atoms with a molecule ID = 0, which may be non-molecular
|
|
solvent atoms, have an out-of-range chunk ID. These atoms are
|
|
discarded (not assigned to any chunk) or assigned to <I>Nchunk</I>,
|
|
depending on the value of the <I>discard</I> keyword.
|
|
</P>
|
|
<HR>
|
|
|
|
<P>The <I>compute/fix/variable</I> styles set the chunk ID of each atom based
|
|
on a quantity calculated and stored by a compute, fix, or variable.
|
|
In each case, it must be a per-atom quantity. In each case the
|
|
referenced floating point values are converted to an integer chunk ID
|
|
as follows. The floating point value is truncated (rounded down) to
|
|
an integer value. If the integer value is <= 0, then a chunk ID of 0
|
|
is assigned to the atom. If the integer value is > 0, it becomes the
|
|
chunk ID to the atom. <I>Nchunk</I> is set to the largest chunk ID. Note
|
|
that this excludes atoms which are not in the specified group or
|
|
optional region.
|
|
</P>
|
|
<P>If the style begins with "c_", a compute ID must follow which has been
|
|
previously defined in the input script. If no bracketed integer is
|
|
appended, the per-atom vector calculated by the compute is used. If a
|
|
bracketed integer is appended, the Ith column of the per-atom array
|
|
calculated by the compute is used. Users can also write code for
|
|
their own compute styles and <A HREF = "Section_modify.html">add them to LAMMPS</A>.
|
|
</P>
|
|
<P>If the style begins with "f_", a fix ID must follow which has been
|
|
previously defined in the input script. If no bracketed integer is
|
|
appended, the per-atom vector calculated by the fix is used. If a
|
|
bracketed integer is appended, the Ith column of the per-atom array
|
|
calculated by the fix is used. Note that some fixes only produce
|
|
their values on certain timesteps, which must be compatible with the
|
|
timestep on which this compute accesses the fix, else an error
|
|
results. Users can also write code for their own fix styles and <A HREF = "Section_modify.html">add
|
|
them to LAMMPS</A>.
|
|
</P>
|
|
<P>If a value begins with "v_", a variable name for an <I>atom</I> or
|
|
<I>atomfile</I> style <A HREF = "variable.html">variable</A> must follow which has been
|
|
previously defined in the input script. Variables of style <I>atom</I> can
|
|
reference thermodynamic keywords and various per-atom attributes, or
|
|
invoke other computes, fixes, or variables when they are evaluated, so
|
|
this is a very general means of generating per-atom quantities to
|
|
treat as a chunk ID.
|
|
</P>
|
|
<HR>
|
|
|
|
<HR>
|
|
|
|
<P>Normally, <I>Nchunk</I> = the number of chunks, is re-calculated every time
|
|
this fix is invoked, though the value may or may not change. As
|
|
explained below, the <I>nchunk</I> keyword can be set to <I>once</I> which means
|
|
<I>Nchunk</I> will never change.
|
|
</P>
|
|
<P>If a <A HREF = "fix_ave_chunk.html">fix ave/chunk</A> command uses this compute, it
|
|
can also turn off the re-calculation of <I>Nchunk</I> for one or more
|
|
windows of timesteps. The extent of the windows, during which Nchunk
|
|
is held constant, are determined by the <I>Nevery</I>, <I>Nrepeat</I>, <I>Nfreq</I>
|
|
values and the <I>ave</I> keyword setting that are used by the <A HREF = "fix_ave_chunk.html">fix
|
|
ave/chunk</A> command.
|
|
</P>
|
|
<P>Specifically, if <I>ave</I> = <I>one</I>, then for each span of <I>Nfreq</I>
|
|
timesteps, <I>Nchunk</I> is held constant between the first timestep when
|
|
averaging is done (within the Nfreq-length window), and the last
|
|
timestep when averaging is done (multiple of Nfreq). If <I>ave</I> =
|
|
<I>running</I> or <I>window</I>, then <I>Nchunk</I> is held constant forever,
|
|
starting on the first timestep when the <A HREF = "fix_ave_chunk.html">fix
|
|
ave/chunk</A> command invokes this compute.
|
|
</P>
|
|
<P>Note that multiple <A HREF = "fix_ave_chunk.html">fix ave/chunk</A> commands can use
|
|
the same compute chunk/atom compute. However, the time windows they
|
|
induce for holding <I>Nchunk</I> constant must be identical, else an error
|
|
will be generated.
|
|
</P>
|
|
<HR>
|
|
|
|
<HR>
|
|
|
|
<P>The various optional keywords operate as follows. Note that some of
|
|
them function differently or are ignored by different chunk styles.
|
|
Some of them also have different default values, depending on
|
|
the chunk style, as listed below.
|
|
</P>
|
|
<P>The <I>region</I> keyword applies to all chunk styles. If used, an atom
|
|
must be in both the specified group and the specified geometric
|
|
<A HREF = "region.html">region</A> to be assigned to a chunk.
|
|
</P>
|
|
<HR>
|
|
|
|
<P>The <I>nchunk</I> keyword applies to all chunk styles. It specifies how
|
|
often <I>Nchunk</I> is recalculated, which in turn can affect the chunk IDs
|
|
assigned to individual atoms.
|
|
</P>
|
|
<P>If <I>nchunk</I> is set to <I>once</I>, then <I>Nchunk</I> is only calculated once,
|
|
the first time this compute is invoked. If <I>nchunk</I> is set to
|
|
<I>every</I>, then <I>Nchunk</I> is re-calculated every time the compute is
|
|
invoked. Note that, as described above, the use of this compute
|
|
by the <A HREF = "fix_ave_chunk.html">fix ave/chunk</A> command can override
|
|
the <I>every</I> setting.
|
|
</P>
|
|
<P>The default values for <I>nchunk</I> are listed below and depend on the
|
|
chunk style and other system and keyword settings. They attempt to
|
|
represent typical use cases for the various chunk styles. The
|
|
<I>nchunk</I> value can always be set explicitly if desired.
|
|
</P>
|
|
<HR>
|
|
|
|
<P>The <I>limit</I> keyword can be used to limit the calculated value of
|
|
<I>Nchunk</I> = the number of chunks. The limit is applied each time
|
|
<I>Nchunk</I> is calculated, which also limits the chunk IDs assigned to
|
|
any atom. The <I>limit</I> keyword is used by all chunk styles except the
|
|
<I>binning</I> styles, which ignore it. This is because the number of bins
|
|
can be tailored using the <I>bound</I> keyword (described below) which
|
|
effectively limits the size of <I>Nchunk</I>.
|
|
</P>
|
|
<P>If <I>limit</I> is set to <I>Nc</I> = 0, then no limit is imposed on <I>Nchunk</I>,
|
|
though the <I>compress</I> keyword can still be used to reduce <I>Nchunk</I>, as
|
|
described below.
|
|
</P>
|
|
<P>If <I>Nc</I> > 0, then the effect of the <I>limit</I> keyword depends on whether
|
|
the <I>compress</I> keyword is also used with a setting of <I>yes</I>, and
|
|
whether the <I>compress</I> keyword is specified before the <I>limit</I> keyword
|
|
or after.
|
|
</P>
|
|
<P>In all cases, <I>Nchunk</I> is first calculated in the usual way for each
|
|
chunk style, as described above.
|
|
</P>
|
|
<P>First, here is what occurs if <I>compress yes</I> is not set. If <I>limit</I>
|
|
is set to <I>Nc max</I>, then <I>Nchunk</I> is reset to the smaller of <I>Nchunk</I>
|
|
and <I>Nc</I>. If <I>limit</I> is set to <I>Nc exact</I>, then <I>Nchunk</I> is reset to
|
|
<I>Nc</I>, whether the original <I>Nchunk</I> was larger or smaller than <I>Nc</I>.
|
|
If <I>Nchunk</I> shrank due to the <I>limit</I> setting, then atom chunk IDs >
|
|
<I>Nchunk</I> will be reset to 0 or <I>Nchunk</I>, depending on the setting of
|
|
the <I>discard</I> keyword. If <I>Nchunk</I> grew, there will simply be some
|
|
chunks with no atoms assigned to them.
|
|
</P>
|
|
<P>If <I>compress yes</I> is set, and the <I>compress</I> keyword comes before the
|
|
<I>limit</I> keyword, the compression operation is performed first, as
|
|
described below, which resets <I>Nchunk</I>. The <I>limit</I> keyword is then
|
|
applied to the new <I>Nchunk</I> value, exactly as described in the
|
|
preceeding paragraph. Note that in this case, all atoms will end up
|
|
with chunk IDs <= <I>Nc</I>, but their original values (e.g. molecule ID or
|
|
compute/fix/variable value) may have been > <I>Nc</I>, because of the
|
|
compression operation.
|
|
</P>
|
|
<P>If <I>compress yes</I> is set, and the <I>compress</I> keyword comes after the
|
|
<I>limit</I> keyword, then the <I>limit</I> value of <I>Nc</I> is applied first to
|
|
the uncompressed value of <I>Nchunk</I>, but only if <I>Nc</I> < <I>Nchunk</I>
|
|
(whether <I>Nc max</I> or <I>Nc exact</I> is used). This effectively means all
|
|
atoms with chunk IDs > <I>Nc</I> have their chunk IDs reset to 0 or <I>Nc</I>,
|
|
depending on the setting of the <I>discard</I> keyword. The compression
|
|
operation is then performed, which may shrink <I>Nchunk</I> further. If
|
|
the new <I>Nchunk</I> < <I>Nc</I> and <I>limit</I> = <I>Nc exact</I> is specified, then
|
|
<I>Nchunk</I> is reset to <I>Nc</I>, which results in extra chunks with no atoms
|
|
assigned to them. Note that in this case, all atoms will end up with
|
|
chunk IDs <= <I>Nc</I>, and their original values (e.g. molecule ID or
|
|
compute/fix/variable value) will also have been <= <I>Nc</I>.
|
|
</P>
|
|
<HR>
|
|
|
|
<P>The <I>ids</I> keyword applies to all chunk styles. If the setting is
|
|
<I>once</I> then the chunk IDs assigned to atoms the first time this
|
|
compute is invoked will be permanent, and never be re-computed.
|
|
</P>
|
|
<P>If the setting is <I>nfreq</I> and if a <A HREF = "fix_ave_chunk.html">fix ave/chunk</A>
|
|
command is using this compute, then in each of the <I>Nchunk</I> = constant
|
|
time windows (discussed above), the chunk ID's assigned to atoms on
|
|
the first step of the time window will persist until the end of the
|
|
time window.
|
|
</P>
|
|
<P>If the setting is <I>every</I>, which is the default, then chunk IDs are
|
|
re-calculated on any timestep this compute is invoked.
|
|
</P>
|
|
<P>IMPORTANT NOTE: If you want the persistent chunk-IDs calculated by
|
|
this compute to be continuous when running from a <A HREF = "read_restart.html">restart
|
|
file</A>, then you should use the same ID for this
|
|
compute, as in the original run. This is so that the fix this compute
|
|
creates to store per-atom quantities will also have the same ID, and
|
|
thus be initialized correctly with chunk IDs from the restart file.
|
|
</P>
|
|
<HR>
|
|
|
|
<P>The <I>compress</I> keyword applies to all chunk styles and affects how
|
|
<I>Nchunk</I> is calculated, which in turn affects the chunk IDs assigned
|
|
to each atom. It is useful for converting a "sparse" set of chunk IDs
|
|
(with many IDs that have no atoms assigned to them), into a "dense"
|
|
set of IDs, where every chunk has one or more atoms assigned to it.
|
|
</P>
|
|
<P>Two possible use cases are as follows. If a large simulation box is
|
|
mostly empty space, then the <I>binning</I> style may produce many bins
|
|
with no atoms. If <I>compress</I> is set to <I>yes</I>, only bins with atoms
|
|
will be contribute to <I>Nchunk</I>. Likewise, the <I>molecule</I> or
|
|
<I>compute/fix/variable</I> styles may produce large <I>Nchunk</I> values. For
|
|
example, the <A HREF = "compute_cluster_atom.html">compute cluster/atom</A> command
|
|
assigns every atom an atom ID for one of the atoms it is clustered
|
|
with. For a million-atom system with 5 clusters, there would only be
|
|
5 unique chunk IDs, but the largest chunk ID might be 1 million,
|
|
resulting in <I>Nchunk</I> = 1 million. If <I>compress</I> is set to <I>yes</I>,
|
|
<I>Nchunk</I> will be reset to 5.
|
|
</P>
|
|
<P>If <I>compress</I> is set to <I>no</I>, which is the default, no compression is
|
|
done. If it is set to <I>yes</I>, all chunk IDs with no atoms are removed
|
|
from the list of chunk IDs, and the list is sorted. The remaining
|
|
chunk IDs are renumbered from 1 to <I>Nchunk</I> where <I>Nchunk</I> is the new
|
|
length of the list. The chunk IDs assigned to each atom reflect
|
|
the new renumbering from 1 to <I>Nchunk</I>.
|
|
</P>
|
|
<P>The original chunk IDs (before renumbering) can be accessed by the
|
|
<A HREF = "compute_property_chunk.html">compute property/chunk</A> command and its
|
|
<I>id</I> keyword, or by the <A HREF = "fix_ave_chunk.html">fix ave/chunk</A> command
|
|
which outputs the original IDs as one of the columns in its global
|
|
output array. For example, using the "compute cluster/atom" command
|
|
discussed above, the original 5 unique chunk IDs might be atom IDs
|
|
(27,4982,58374,857838,1000000). After compresion, these will be
|
|
renumbered to (1,2,3,4,5). The original values (27,...,1000000) can
|
|
be output to a file by the <A HREF = "fix_ave_chunk.html">fix ave/chunk</A> command,
|
|
or by using the <A HREF = "fix_ave_time.html">fix ave/time</A> command in
|
|
conjunction with the <A HREF = "compute_property_chunk.html">compute
|
|
property/chunk</A> command.
|
|
</P>
|
|
<P>IMPORTANT NOTE: The compression operation requires global
|
|
communication across all processors to share their chunk ID values.
|
|
It can require large memory on every processor to store them, even
|
|
after they are compressed, if there are are a large number of unique
|
|
chunk IDs with atoms assigned to them. It uses a STL map to find
|
|
unique chunk IDs and store them in sorted order. Each time an atom is
|
|
assigned a compressed chunk ID, it must access the STL map. All of
|
|
this means that compression can be expensive, both in memory and CPU
|
|
time. The use of the <I>limit</I> keyword in conjunction with the
|
|
<I>compress</I> keyword can affect these costs, depending on which keyword
|
|
is used first. So use this option with care.
|
|
</P>
|
|
<HR>
|
|
|
|
<P>The <I>discard</I> keyword applies to all chunk styles. It affects what
|
|
chunk IDs are assigned to atoms that do not match one of the valid
|
|
chunk IDs from 1 to <I>Nchunk</I>. Note that it does not apply to atoms
|
|
that are not in the specified group or optionally specified region.
|
|
Those atoms are always assigned a chunk ID = 0.
|
|
</P>
|
|
<P>If the calculated chunk ID for an atom is not within the range 1 to
|
|
<I>Nchunk</I> then it is a "discard" atom. Note that <I>Nchunk</I> may have
|
|
been shrunk by the <I>limit</I> keyword. Or the <I>compress</I> keyword may
|
|
have eliminated chunk IDs that were valid before the compression took
|
|
place, and are now not in the compressed list. Also note that for the
|
|
<I>molecule</I> chunk style, if new molecules are added to the system,
|
|
their chunk IDs may exceed a previously calculated <I>Nchunk</I>.
|
|
Likewise, evaluation of a compute/fix/variable on a later timestep may
|
|
return chunk IDs that are invalid for the previously calculated
|
|
<I>Nchunk</I>.
|
|
</P>
|
|
<P>All the chunk styles except the <I>binning</I> styles, must use <I>discard</I>
|
|
set to either <I>yes</I> or <I>no</I>. If <I>discard</I> is set to <I>yes</I>, which is
|
|
the default, then every "discard" atom has its chunk ID set to 0. If
|
|
<I>discard</I> is set to <I>no</I>, every "discard" atom has its chunk ID set to
|
|
<I>Nchunk</I>. I.e. it becomes part of the last chunk.
|
|
</P>
|
|
<P>The <I>binning</I> styles use the <I>discard</I> keyword to decide whether to
|
|
discard atoms outside the spatial domain covered by bins, or to assign
|
|
them to the bin they are nearest to. Details are as follows.
|
|
</P>
|
|
<P>If <I>discard</I> is set to <I>yes</I>, an out-of-domain atom will have its
|
|
chunk ID set to 0. If <I>discard</I> is set to <I>no</I>, the atom will have
|
|
its chunk ID set to the first or last bin in that dimension. If
|
|
(discard</I> is set to <I>mixed</I>, which is the default, it will only have
|
|
its chunk ID set to the first or last bin if bins extend to the
|
|
simulation box boundary in that dimension. This is the case if the
|
|
<I>bound</I> keyword settings are <I>lower</I> and <I>upper</I>, which is the
|
|
default. If the <I>bound</I> keyword settings are numeric values, then the
|
|
atom will have its chunk ID set to 0 if it is outside the bounds of
|
|
any bin. Note that in this case, it is possible that the first or
|
|
last bin extends beyond the numeric <I>bounds</I> settings, depending on
|
|
the specified <I>origin</I>. If this is the case, the chunk ID of the atom
|
|
is only set to 0 if it is outside the first or last bin, not if it is
|
|
simply outside the numeric <I>bounds</I> setting.
|
|
</P>
|
|
<HR>
|
|
|
|
<P>The <I>bound</I> keyword only applies to the <I>binning</I> styles; otherwise it
|
|
is ignored. It can be used one or more times to limit the extent of
|
|
bin coverage in a specified dimension, i.e. to only bin a portion of
|
|
the box. If the <I>lo</I> setting is <I>lower</I> or the <I>hi</I> setting is
|
|
<I>upper</I>, the bin extent in that direction extends to the box boundary.
|
|
If a numeric value is used for <I>lo</I> and/or <I>hi</I>, then the bin extent
|
|
in the <I>lo</I> or <I>hi</I> direction extends only to that value, which is
|
|
assumed to be inside (or at least near) the simulation box boundaries,
|
|
though LAMMPS does not check for this. Note that using the <I>bound</I>
|
|
keyword typically reduces the total number of bins and thus the number
|
|
of chunks <I>Nchunk</I>.
|
|
</P>
|
|
<P>The <I>units</I> keyword only applies to the <I>binning</I> styles; otherwise it
|
|
is ignored. It determines the meaning of the distance units used for
|
|
the bin sizes <I>delta</I> and for <I>origin</I> and <I>bounds</I> values if they are
|
|
coordinate values. For orthogonal simulation boxes, any of the 3
|
|
options may be used. For non-orthogonal (triclinic) simulation boxes,
|
|
only the <I>reduced</I> option may be used.
|
|
</P>
|
|
<P>A <I>box</I> value selects standard distance units as defined by the
|
|
<A HREF = "units.html">units</A> command, e.g. Angstroms for units = real or metal.
|
|
A <I>lattice</I> value means the distance units are in lattice spacings.
|
|
The <A HREF = "lattice.html">lattice</A> command must have been previously used to
|
|
define the lattice spacing. A <I>reduced</I> value means normalized
|
|
unitless values between 0 and 1, which represent the lower and upper
|
|
faces of the simulation box respectively. Thus an <I>origin</I> value of
|
|
0.5 means the center of the box in any dimension. A <I>delta</I> value of
|
|
0.1 means 10 bins span the box in that dimension.
|
|
</P>
|
|
<HR>
|
|
|
|
<HR>
|
|
|
|
<P><B>Output info:</B>
|
|
</P>
|
|
<P>This compute calculates a per-atom vector, which can be accessed by
|
|
any command that uses per-atom values from a compute as input. See
|
|
<A HREF = "Section_howto.html#howto_15">Section_howto 15</A> for an overview of
|
|
LAMMPS output options.
|
|
</P>
|
|
<P>The per-atom vector values are unitless chunk IDs, ranging from 1 to
|
|
<I>Nchunk</I> (inclusive) for atoms assigned to chunks, and 0 for atoms not
|
|
belonging to a chunk.
|
|
</P>
|
|
<P><B>Restrictions:</B>
|
|
</P>
|
|
<P>Even if the <I>nchunk</I> keyword is set to <I>once</I>, the chunk IDs assigned
|
|
to each atom are not stored in a restart files. This means you cannot
|
|
expect those assignments to persist in a restarted simulation.
|
|
Instead you must re-specify this command and assign atoms to chunks when
|
|
the restarted simulation begins.
|
|
</P>
|
|
<P><B>Related commands:</B>
|
|
</P>
|
|
<P><A HREF = "fix_ave_chunk.html">fix ave/chunk</A>
|
|
</P>
|
|
<P><B>Default:</B>
|
|
</P>
|
|
<P>The option defaults are as follows:
|
|
</P>
|
|
<UL><LI>region = none
|
|
<LI>nchunk = every if compress is yes, overriding other defaults listed here
|
|
<LI>nchunk = once for type style
|
|
<LI>nchunk = once for mol style if region is none
|
|
<LI>nchunk = every for mol style if region is set
|
|
<LI>nchunk = once for binning style if the simulation box size is static or units = reduced
|
|
<LI>nchunk = every for binning style if the simulation box size is dynamic and units is lattice or box
|
|
<LI>nchunk = every for compute/fix/variable style
|
|
<LI>limit = 0
|
|
<LI>ids = every
|
|
<LI>compress = no
|
|
<LI>discard = yes for all styles except binning
|
|
<LI>discard = mixed for binning styles
|
|
<LI>bound = lower and upper in all dimensions
|
|
<LI>units = lattice
|
|
</UL>
|
|
</HTML>
|