<li>ID, group-ID are documented in <aclass="reference internal"href="compute.html"><spanclass="doc">compute</span></a> command</li>
<li>chunk/atom = style name of this compute command</li>
</ul>
<preclass="literal-block">
style = <em>bin/1d</em> or <em>bin/2d</em> or <em>bin/3d</em> or <em>bin/sphere</em> or <em>type</em> or <em>molecule</em> or <em>compute/fix/variable</em>
<em>bin/1d</em> args = dim origin delta
dim = <em>x</em> or <em>y</em> or <em>z</em>
origin = <em>lower</em> or <em>center</em> or <em>upper</em> or coordinate value (distance units)
delta = thickness of spatial bins in dim (distance units)
<em>bin/2d</em> args = dim origin delta dim origin delta
dim = <em>x</em> or <em>y</em> or <em>z</em>
origin = <em>lower</em> or <em>center</em> or <em>upper</em> or coordinate value (distance units)
delta = thickness of spatial bins in dim (distance units)
<em>bin/3d</em> args = dim origin delta dim origin delta dim origin delta
dim = <em>x</em> or <em>y</em> or <em>z</em>
origin = <em>lower</em> or <em>center</em> or <em>upper</em> or coordinate value (distance units)
delta = thickness of spatial bins in dim (distance units)
dim = <em>x</em> or <em>y</em> or <em>z</em> = axis of cylinder axis
origin = <em>lower</em> or <em>center</em> or <em>upper</em> or coordinate value (distance units)
delta = thickness of spatial bins in dim (distance units)
c1,c2 = coords of cylinder axis in other 2 dimensions (distance units)
crmin,crmax = bin from cylinder radius rmin to rmax (distance units)
ncbin = # of concentric circle bins between rmin and rmax
<em>type</em> args = none
<em>molecule</em> args = none
<em>compute/fix/variable</em> = 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>
<ulclass="simple">
<li>zero or more keyword/values pairs may be appended</li>
<li>keyword = <em>region</em> or <em>nchunk</em> or <em>static</em> or <em>compress</em> or <em>bound</em> or <em>discard</em> or <em>pbc</em> or <em>units</em></li>
</ul>
<preclass="literal-block">
<em>region</em> value = region-ID
region-ID = ID of region atoms must be in to be part of a chunk
<em>nchunk</em> value = <em>once</em> or <em>every</em>
once = only compute the number of chunks once
every = re-compute the number of chunks whenever invoked
<em>limit</em> 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
<em>ids</em> value = <em>once</em> or <em>nfreq</em> or <em>every</em>
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 <aclass="reference internal"href="fix_ave_chunk.html"><spanclass="doc">fix ave/chunk</span></a> which sets Nfreq)
every = assign chunk IDs to atoms whenever invoked
<em>compress</em> value = <em>yes</em> or <em>no</em>
yes = compress chunk IDs to eliminate IDs with no atoms
no = do not compress chunk IDs even if some IDs have no atoms
<em>discard</em> value = <em>yes</em> or <em>no</em> or <em>mixed</em>
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
<em>bound</em> values = x/y/z lo hi
x/y/z = <em>x</em> or <em>y</em> or <em>z</em> to bound sptial bins in this dimension
lo = <em>lower</em> or coordinate value (distance units)
hi = <em>upper</em> or coordinate value (distance units)
<em>pbc</em> value = <em>no</em> or <em>yes</em>
yes = use periodic distance for bin/sphere and bin/cylinder styles
<em>units</em> value = <em>box</em> or <em>lattice</em> or <em>reduced</em>
<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 <em>style</em> 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 <aclass="reference internal"href="compute.html"><spanclass="doc">compute</span></a>, <aclass="reference internal"href="fix.html"><spanclass="doc">fix</span></a>, or <aclass="reference internal"href="variable.html"><spanclass="doc">atom-style variable</span></a>. Per-atom chunk IDs can be used by other
computes with “chunk” in their style name, such as <aclass="reference internal"href="compute_com_chunk.html"><spanclass="doc">compute com/chunk</span></a> or <aclass="reference internal"href="compute_msd_chunk.html"><spanclass="doc">compute msd/chunk</span></a>. Or they can be used by the <aclass="reference internal"href="fix_ave_chunk.html"><spanclass="doc">fix ave/chunk</span></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 <aclass="reference internal"href="Section_howto.html#howto-15"><spanclass="std std-ref">Section_howto 15</span></a>.</p>
<p>See <aclass="reference internal"href="Section_howto.html#howto-23"><spanclass="std std-ref">Section_howto 23</span></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 <em>Nchunk</em> = 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 <em>Nchunk</em> 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 <em>Nchunk</em>), 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
<em>Nchunk</em> 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 <em>Nchunk</em> is
calculated, and how and when chunk IDs are assigned to atoms. The
details depend on the chunk <em>style</em> and its <em>args</em>, as well as
optional keyword settings. They can also depend on whether a <aclass="reference internal"href="fix_ave_chunk.html"><spanclass="doc">fix ave/chunk</span></a> command is using this compute, since
that command requires <em>Nchunk</em> to remain static across windows of
timesteps it specifies, while it accumulates per-chunk averages.</p>
<p>The details are described below.</p>
<p>The different chunk styles operate as follows. For each style, how it
calculates <em>Nchunk</em> 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>
<hrclass="docutils"/>
<p>The <em>binning</em> styles perform a spatial binning of atoms, and assign an
atom the chunk ID corresponding to the bin number it is in. <em>Nchunk</em>
is set to the number of bins, which can change if the simulation box
size changes.</p>
<p>The <em>bin/1d</em>, <em>bin/2d</em>, and <em>bin/3d</em> styles define bins as 1d layers
(slabs), 2d pencils, or 3d boxes. The <em>dim</em>, <em>origin</em>, and <em>delta</em>
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 <em>dim</em> have a bin size in that
dimension given by <em>delta</em>. In each dimension, bins are defined
relative to a specified <em>origin</em>, 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 <em>bounds</em> 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 <aclass="reference internal"href="Section_howto.html#howto-12"><spanclass="std std-ref">this section</span></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 <em>units</em> option must be set
to <em>reduced</em> when using a triclinic simulation box, as noted below.</p>
<p>The meaning of <em>origin</em> and <em>delta</em> 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 <em>origin</em> of 0.0
means start layers at the lower “b” cross “c” plane of the simulation
box and an <em>origin</em> of 1.0 means to start layers at the upper “b”
cross “c” face of the box. A <em>delta</em> value of 0.1 in <em>reduced</em> 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 <em>bin/sphere</em> style defines a set of spherical shell bins around
the origin (<em>xorig</em>,<em>yorig</em>,<em>zorig</em>), using <em>nsbin</em> bins with radii
equally spaced between <em>srmin</em> and <em>srmax</em>. This is effectively a 1d
vector of bins. For example, if <em>srmin</em> = 1.0 and <em>srmax</em> = 10.0 and
<em>nsbin</em> = 9, then the first bin spans 1.0 < r < 2.0, and the last bin
spans 9.0 < r 10.0. The geometry of the bins is the same whether the
simulation box is orthogonal or triclinic; i.e. the spherical shells
are not tilted or scaled differently in different dimensions to
transform them into ellipsoidal shells.</p>
<p>The <em>bin/cylinder</em> style defines bins for a cylinder oriented along
the axis <em>dim</em> with the axis coordinates in the other two radial
dimensions at (<em>c1</em>,<em>c2</em>). For dim = x, c1/c2 = y/z; for dim = y,
c1/c2 = x/z; for dim = z, c1/c2 = x/y. This is effectively a 2d array
of bins. The first dimension is along the cylinder axis, the second
dimension is radially outward from the cylinder axis. The bin size
and positions along the cylinder axis are specified by the <em>origin</em>
and <em>delta</em> values, the same as for the <em>bin/1d</em>, <em>bin/2d</em>, and
<em>bin/3d</em> styles. There are <em>ncbin</em> concentric circle bins in the
radial direction from the cylinder axis with radii equally spaced
between <em>crmin</em> and <em>crmax</em>. For example, if <em>crmin</em> = 1.0 and
<em>crmax</em> = 10.0 and <em>ncbin</em> = 9, then the first bin spans 1.0 < r <
2.0, and the last bin spans 9.0 < r 10.0. The geometry of the bins in
the radial dimensions is the same whether the simulation box is
orthogonal or triclinic; i.e. the concetric circles are not tilted or
scaled differently in the two different dimensions to transform them
into ellipses.</p>
<p>The created bins (and hence the chunk IDs) are numbered consecutively
from 1 to the number of bins = <em>Nchunk</em>. For <em>bin2d</em> and <em>bin3d</em>, 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. For <em>bin/sphere</em>, the bin with smallest radii is chunk
1 and the bni with largest radii is chunk Nchunk = <em>ncbin</em>. For
<em>bin/cylinder</em>, the numbering varies most rapidly in the dimension
along the cylinder axis and most slowly in the radial direction.</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 <em>discard</em> keyword is used to determine how a chunk ID is
assigned to the atom.</p>
<hrclass="docutils"/>
<p>The <em>type</em> style uses the atom type as the chunk ID. <em>Nchunk</em> is set
to the number of atom types defined for the simulation, e.g. via the
<aclass="reference internal"href="create_box.html"><spanclass="doc">create_box</span></a> or <aclass="reference internal"href="read_data.html"><spanclass="doc">read_data</span></a> commands.</p>
<hrclass="docutils"/>
<p>The <em>molecule</em> style uses the molecule ID of each atom as its chunk
ID. <em>Nchunk</em> 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 <em>Nchunk</em> 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 <em>Nchunk</em>,
depending on the value of the <em>discard</em> keyword.</p>
<hrclass="docutils"/>
<p>The <em>compute/fix/variable</em> 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. <em>Nchunk</em> 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 “<ahref="#id1"><spanclass="problematic"id="id2">c_</span></a>”, 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 <aclass="reference internal"href="Section_modify.html"><spanclass="doc">add them to LAMMPS</span></a>.</p>
<p>If the style begins with “<ahref="#id3"><spanclass="problematic"id="id4">f_</span></a>”, 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 <aclass="reference internal"href="Section_modify.html"><spanclass="doc">add them to LAMMPS</span></a>.</p>
<p>If a value begins with “<ahref="#id5"><spanclass="problematic"id="id6">v_</span></a>”, a variable name for an <em>atom</em> or
<em>atomfile</em> style <aclass="reference internal"href="variable.html"><spanclass="doc">variable</span></a> must follow which has been
previously defined in the input script. Variables of style <em>atom</em> 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>
<p>Normally, <em>Nchunk</em> = 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 <em>nchunk</em> keyword can be set to <em>once</em> which means
<em>Nchunk</em> will never change.</p>
<p>If a <aclass="reference internal"href="fix_ave_chunk.html"><spanclass="doc">fix ave/chunk</span></a> command uses this compute, it
can also turn off the re-calculation of <em>Nchunk</em> for one or more
windows of timesteps. The extent of the windows, during which Nchunk
is held constant, are determined by the <em>Nevery</em>, <em>Nrepeat</em>, <em>Nfreq</em>
values and the <em>ave</em> keyword setting that are used by the <aclass="reference internal"href="fix_ave_chunk.html"><spanclass="doc">fix ave/chunk</span></a> command.</p>
<p>Specifically, if <em>ave</em> = <em>one</em>, then for each span of <em>Nfreq</em>
timesteps, <em>Nchunk</em> 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 <em>ave</em> =
<em>running</em> or <em>window</em>, then <em>Nchunk</em> is held constant forever,
starting on the first timestep when the <aclass="reference internal"href="fix_ave_chunk.html"><spanclass="doc">fix ave/chunk</span></a> command invokes this compute.</p>
<p>Note that multiple <aclass="reference internal"href="fix_ave_chunk.html"><spanclass="doc">fix ave/chunk</span></a> commands can use
the same compute chunk/atom compute. However, the time windows they
induce for holding <em>Nchunk</em> constant must be identical, else an error
will be generated.</p>
<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 <em>region</em> keyword applies to all chunk styles. If used, an atom
must be in both the specified group and the specified geometric
<aclass="reference internal"href="region.html"><spanclass="doc">region</span></a> to be assigned to a chunk.</p>
<hrclass="docutils"/>
<p>The <em>nchunk</em> keyword applies to all chunk styles. It specifies how
often <em>Nchunk</em> is recalculated, which in turn can affect the chunk IDs
assigned to individual atoms.</p>
<p>If <em>nchunk</em> is set to <em>once</em>, then <em>Nchunk</em> is only calculated once,
the first time this compute is invoked. If <em>nchunk</em> is set to
<em>every</em>, then <em>Nchunk</em> is re-calculated every time the compute is
invoked. Note that, as described above, the use of this compute
by the <aclass="reference internal"href="fix_ave_chunk.html"><spanclass="doc">fix ave/chunk</span></a> command can override
the <em>every</em> setting.</p>
<p>The default values for <em>nchunk</em> 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
<em>nchunk</em> value can always be set explicitly if desired.</p>
<hrclass="docutils"/>
<p>The <em>limit</em> keyword can be used to limit the calculated value of
<em>Nchunk</em> = the number of chunks. The limit is applied each time
<em>Nchunk</em> is calculated, which also limits the chunk IDs assigned to
any atom. The <em>limit</em> keyword is used by all chunk styles except the
<em>binning</em> styles, which ignore it. This is because the number of bins
can be tailored using the <em>bound</em> keyword (described below) which
effectively limits the size of <em>Nchunk</em>.</p>
<p>If <em>limit</em> is set to <em>Nc</em> = 0, then no limit is imposed on <em>Nchunk</em>,
though the <em>compress</em> keyword can still be used to reduce <em>Nchunk</em>, as
described below.</p>
<p>If <em>Nc</em>> 0, then the effect of the <em>limit</em> keyword depends on whether
the <em>compress</em> keyword is also used with a setting of <em>yes</em>, and
whether the <em>compress</em> keyword is specified before the <em>limit</em> keyword
or after.</p>
<p>In all cases, <em>Nchunk</em> is first calculated in the usual way for each
chunk style, as described above.</p>
<p>First, here is what occurs if <em>compress yes</em> is not set. If <em>limit</em>
is set to <em>Nc max</em>, then <em>Nchunk</em> is reset to the smaller of <em>Nchunk</em>
and <em>Nc</em>. If <em>limit</em> is set to <em>Nc exact</em>, then <em>Nchunk</em> is reset to
<em>Nc</em>, whether the original <em>Nchunk</em> was larger or smaller than <em>Nc</em>.
If <em>Nchunk</em> shrank due to the <em>limit</em> setting, then atom chunk IDs >
<em>Nchunk</em> will be reset to 0 or <em>Nchunk</em>, depending on the setting of
the <em>discard</em> keyword. If <em>Nchunk</em> grew, there will simply be some
chunks with no atoms assigned to them.</p>
<p>If <em>compress yes</em> is set, and the <em>compress</em> keyword comes before the
<em>limit</em> keyword, the compression operation is performed first, as
described below, which resets <em>Nchunk</em>. The <em>limit</em> keyword is then
applied to the new <em>Nchunk</em> value, exactly as described in the
preceeding paragraph. Note that in this case, all atoms will end up
with chunk IDs <= <em>Nc</em>, but their original values (e.g. molecule ID or
compute/fix/variable value) may have been ><em>Nc</em>, because of the
compression operation.</p>
<p>If <em>compress yes</em> is set, and the <em>compress</em> keyword comes after the
<em>limit</em> keyword, then the <em>limit</em> value of <em>Nc</em> is applied first to
the uncompressed value of <em>Nchunk</em>, but only if <em>Nc</em><<em>Nchunk</em>
(whether <em>Nc max</em> or <em>Nc exact</em> is used). This effectively means all
atoms with chunk IDs ><em>Nc</em> have their chunk IDs reset to 0 or <em>Nc</em>,
depending on the setting of the <em>discard</em> keyword. The compression
operation is then performed, which may shrink <em>Nchunk</em> further. If
the new <em>Nchunk</em><<em>Nc</em> and <em>limit</em> = <em>Nc exact</em> is specified, then
<em>Nchunk</em> is reset to <em>Nc</em>, which results in extra chunks with no atoms
assigned to them. Note that in this case, all atoms will end up with
chunk IDs <= <em>Nc</em>, and their original values (e.g. molecule ID or
compute/fix/variable value) will also have been <= <em>Nc</em>.</p>
<hrclass="docutils"/>
<p>The <em>ids</em> keyword applies to all chunk styles. If the setting is
<em>once</em> 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 <em>nfreq</em> and if a <aclass="reference internal"href="fix_ave_chunk.html"><spanclass="doc">fix ave/chunk</span></a>
command is using this compute, then in each of the <em>Nchunk</em> = 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 <em>every</em>, which is the default, then chunk IDs are
re-calculated on any timestep this compute is invoked.</p>
<divclass="admonition note">
<pclass="first admonition-title">Note</p>
<pclass="last">If you want the persistent chunk-IDs calculated by this compute
to be continuous when running from a <aclass="reference internal"href="read_restart.html"><spanclass="doc">restart file</span></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>
</div>
<hrclass="docutils"/>
<p>The <em>compress</em> keyword applies to all chunk styles and affects how
<em>Nchunk</em> 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 <em>binning</em> style may produce many bins
with no atoms. If <em>compress</em> is set to <em>yes</em>, only bins with atoms
will be contribute to <em>Nchunk</em>. Likewise, the <em>molecule</em> or
<em>compute/fix/variable</em> styles may produce large <em>Nchunk</em> values. For
example, the <aclass="reference internal"href="compute_cluster_atom.html"><spanclass="doc">compute cluster/atom</span></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 <em>Nchunk</em> = 1 million. If <em>compress</em> is set to <em>yes</em>,
<em>Nchunk</em> will be reset to 5.</p>
<p>If <em>compress</em> is set to <em>no</em>, which is the default, no compression is
done. If it is set to <em>yes</em>, 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 <em>Nchunk</em> where <em>Nchunk</em> is the new
length of the list. The chunk IDs assigned to each atom reflect
the new renumbering from 1 to <em>Nchunk</em>.</p>
<p>The original chunk IDs (before renumbering) can be accessed by the
<aclass="reference internal"href="compute_property_chunk.html"><spanclass="doc">compute property/chunk</span></a> command and its
<em>id</em> keyword, or by the <aclass="reference internal"href="fix_ave_chunk.html"><spanclass="doc">fix ave/chunk</span></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 <aclass="reference internal"href="fix_ave_chunk.html"><spanclass="doc">fix ave/chunk</span></a> command,
or by using the <aclass="reference internal"href="fix_ave_time.html"><spanclass="doc">fix ave/time</span></a> command in
conjunction with the <aclass="reference internal"href="compute_property_chunk.html"><spanclass="doc">compute property/chunk</span></a> command.</p>
<divclass="admonition note">
<pclass="first admonition-title">Note</p>
<pclass="last">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 <em>limit</em> keyword in conjunction with the <em>compress</em> keyword
can affect these costs, depending on which keyword is used first. So
use this option with care.</p>
</div>
<hrclass="docutils"/>
<p>The <em>discard</em> 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 <em>Nchunk</em>. 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
<em>Nchunk</em> then it is a “discard” atom. Note that <em>Nchunk</em> may have
been shrunk by the <em>limit</em> keyword. Or the <em>compress</em> 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
<em>molecule</em> chunk style, if new molecules are added to the system,
their chunk IDs may exceed a previously calculated <em>Nchunk</em>.
Likewise, evaluation of a compute/fix/variable on a later timestep may
return chunk IDs that are invalid for the previously calculated
<em>Nchunk</em>.</p>
<p>All the chunk styles except the <em>binning</em> styles, must use <em>discard</em>
set to either <em>yes</em> or <em>no</em>. If <em>discard</em> is set to <em>yes</em>, which is
the default, then every “discard” atom has its chunk ID set to 0. If
<em>discard</em> is set to <em>no</em>, every “discard” atom has its chunk ID set to
<em>Nchunk</em>. I.e. it becomes part of the last chunk.</p>
<p>The <em>binning</em> styles use the <em>discard</em> 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.</p>
<p>For the <em>bin/1d</em>, <em>bin/2d</em>, <em>bin/3d</em> styles the details are as
follows. If <em>discard</em> is set to <em>yes</em>, an out-of-domain atom will
have its chunk ID set to 0. If <em>discard</em> is set to <em>no</em>, the atom
will have its chunk ID set to the first or last bin in that dimension.
If <em>discard</em> is set to <em>mixed</em>, 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
<em>bound</em> keyword settings are <em>lower</em> and <em>upper</em>, which is the
default. If the <em>bound</em> 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 <em>bounds</em> settings, depending on
the specified <em>origin</em>. 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 <em>bounds</em> setting.</p>
<p>For the <em>bin/sphere</em> style the details are as follows. If <em>discard</em>
is set to <em>yes</em>, an out-of-domain atom will have its chunk ID set to
0. If <em>discard</em> is set to <em>no</em> or <em>mixed</em>, the atom will have its
chunk ID set to the first or last bin, i.e. the innermost or outermost
spherical shell. If the distance of the atom from the origin is less
than <em>rmin</em>, it will be assigned to the first bin. If the distance of
the atom from the origin is greater than <em>rmax</em>, it will be assigned
to the last bin.</p>
<p>For the <em>bin/cylinder</em> style the details are as follows. If <em>discard</em>
is set to <em>yes</em>, an out-of-domain atom will have its chunk ID set to
0. If <em>discard</em> is set to <em>no</em>, the atom will have its chunk ID set
to the first or last bin in both the radial and axis dimensions. If
<em>discard</em> is set to <em>mixed</em>, which is the default, the the radial
dimension is treated the same as for <em>discard</em> = no. But for the axis
dimensinon, it will only have its chunk ID set to the first or last
bin if bins extend to the simulation box boundary in the axis
dimension. This is the case if the <em>bound</em> keyword settings are
<em>lower</em> and <em>upper</em>, which is the default. If the <em>bound</em> 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
<em>bounds</em> settings, depending on the specified <em>origin</em>. 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
<em>bounds</em> setting.</p>
<p>If <em>discard</em> is set to <em>no</em> or <em>mixed</em>, the atom will have its
chunk ID set to the first or last bin, i.e. the innermost or outermost
spherical shell. If the distance of the atom from the origin is less
than <em>rmin</em>, it will be assigned to the first bin. If the distance of
the atom from the origin is greater than <em>rmax</em>, it will be assigned
to the last bin.</p>
<hrclass="docutils"/>
<p>The <em>bound</em> keyword only applies to the <em>bin/1d</em>, <em>bin/2d</em>, <em>bin/3d</em>
styles and to the axis dimension of the <em>bin/cylinder</em> style;
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 <em>lo</em> setting is <em>lower</em> or the <em>hi</em>
setting is <em>upper</em>, the bin extent in that direction extends to the
box boundary. If a numeric value is used for <em>lo</em> and/or <em>hi</em>, then
the bin extent in the <em>lo</em> or <em>hi</em> 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 <em>bound</em> keyword typically reduces the total number of bins
and thus the number of chunks <em>Nchunk</em>.</p>
<p>The <em>pbc</em> keyword only applies to the <em>bin/sphere</em> and <em>bin/cylinder</em>
styles. If set to <em>yes</em>, the distance an atom is from the sphere
origin or cylinder axis is calculated in a minimum image sense with
respect to periodic dimensions, when determining which bin the atom is
in. I.e. if x is a periodic dimension and the distance between the
atom and the sphere center in the x dimension is greater than 0.5 *
simulation box length in x, then a box length is subtracted to give a
distance < 0.5 * simulation box length. This allosws the sphere or
cylinder center to be near a box edge, and atoms on the other side of
the periodic box will still be close to the center point/axis. Note
that with a setting of <em>yes</em>, the outer sphere or cylinder radius must
also be <= 0.5 * simulation box length in any periodic dimension
except for the cylinder axis dimension, or an error is generated.</p>
<p>The <em>units</em> keyword only applies to the <em>binning</em> styles; otherwise it
is ignored. For the <em>bin/1d</em>, <em>bin/2d</em>, <em>bin/3d</em> styles, it
determines the meaning of the distance units used for the bin sizes
<em>delta</em> and for <em>origin</em> and <em>bounds</em> values if they are coordinate
values. For the <em>bin/sphere</em> style it determines the meaning of the
distance units used for <em>xorig</em>,<em>yorig</em>,<em>zorig</em> and the radii <em>srmin</em>
and <em>srmax</em>. For the <em>bin/cylinder</em> style it determines the meaning
of the distance units used for <em>delta</em>,<em>c1</em>,<em>c2</em> and the radii <em>crmin</em>
and <em>crmax</em>.</p>
<p>For orthogonal simulation boxes, any of the 3 options may
be used. For non-orthogonal (triclinic) simulation boxes, only the
<em>reduced</em> option may be used.</p>
<p>A <em>box</em> value selects standard distance units as defined by the
<aclass="reference internal"href="units.html"><spanclass="doc">units</span></a> command, e.g. Angstroms for units = real or metal.
A <em>lattice</em> value means the distance units are in lattice spacings.
The <aclass="reference internal"href="lattice.html"><spanclass="doc">lattice</span></a> command must have been previously used to
define the lattice spacing. A <em>reduced</em> value means normalized
unitless values between 0 and 1, which represent the lower and upper
faces of the simulation box respectively. Thus an <em>origin</em> value of
0.5 means the center of the box in any dimension. A <em>delta</em> value of
0.1 means 10 bins span the box in that dimension.</p>
<p>Note that for the <em>bin/sphere</em> style, the radii <em>srmin</em> and <em>srmax</em> are
scaled by the lattice spacing or reduced value of the <em>x</em> dimension.</p>
<p>Note that for the <em>bin/cylinder</em> style, the radii <em>crmin</em> and <em>crmax</em>
are scaled by the lattice spacing or reduced value of the 1st
dimension perpendicular to the cylinder axis. E.g. y for an x-axis
cylinder, x for a y-axis cylinder, and x for a z-axis cylinder.</p>
<hrclass="docutils"/>
<p><strong>Output info:</strong></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
<aclass="reference internal"href="Section_howto.html#howto-15"><spanclass="std std-ref">Section_howto 15</span></a> for an overview of
LAMMPS output options.</p>
<p>The per-atom vector values are unitless chunk IDs, ranging from 1 to
<em>Nchunk</em> (inclusive) for atoms assigned to chunks, and 0 for atoms not
belonging to a chunk.</p>
</div>
<divclass="section"id="restrictions">
<h2>Restrictions</h2>
<p>Even if the <em>nchunk</em> keyword is set to <em>once</em>, 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
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>.