</a><p>The <em>rcb</em> style is a “tiling” method which does not produce a logical
3d grid of processors. Rather it tiles the simulation domain with
rectangular sub-boxes of varying size and shape in an irregular
fashion so as to have equal numbers of particles in each sub-box, as
in the rightmost diagram above.</p>
<p>The “grid” methods can be used with either of the
<aclass="reference internal"href="comm_style.html"><em>comm_style</em></a> command options, <em>brick</em> or <em>tiled</em>. The
“tiling” methods can only be used with <aclass="reference internal"href="comm_style.html"><em>comm_style tiled</em></a>.</p>
<p>When a “grid” method is specified, the current domain partitioning can
be either a logical 3d grid or a tiled partitioning. In the former
case, the current logical 3d grid is used as a starting point and
changes are made to improve the imbalance factor. In the latter case,
the tiled partitioning is discarded and a logical 3d grid is created
with uniform spacing in all dimensions. This is the starting point
for the balancing operation.</p>
<p>When a “tiling” method is specified, the current domain partitioning
(“grid” or “tiled”) is ignored, and a new partitioning is computed
from scratch.</p>
<hrclass="docutils"/>
<p>The <em>group-ID</em> is currently ignored. In the future it may be used to
determine what particles are considered for balancing. Normally it
would only makes sense to use the <em>all</em> group. But in some cases it
may be useful to balance on a subset of the particles, e.g. when
modeling large nanoparticles in a background of small solvent
particles.</p>
<p>The <em>Nfreq</em> setting determines how often a rebalance is performed. If
<em>Nfreq</em>> 0, then rebalancing will occur every <em>Nfreq</em> steps. Each
time a rebalance occurs, a reneighboring is triggered, so <em>Nfreq</em>
should not be too small. If <em>Nfreq</em> = 0, then rebalancing will be
done every time reneighboring normally occurs, as determined by the
the <aclass="reference internal"href="neighbor.html"><em>neighbor</em></a> and <aclass="reference internal"href="neigh_modify.html"><em>neigh_modify</em></a>
command settings.</p>
<p>On rebalance steps, rebalancing will only be attempted if the current
imbalance factor, as defined above, exceeds the <em>thresh</em> setting.</p>
<hrclass="docutils"/>
<p>The <em>shift</em> style invokes a “grid” method for balancing, as described
above. It changes the positions of cutting planes between processors
in an iterative fashion, seeking to reduce the imbalance factor.</p>
<p>The <em>dimstr</em> argument is a string of characters, each of which must be
an “x” or “y” or “z”. Eacn character can appear zero or one time,
since there is no advantage to balancing on a dimension more than
once. You should normally only list dimensions where you expect there
to be a density variation in the particles.</p>
<p>Balancing proceeds by adjusting the cutting planes in each of the
dimensions listed in <em>dimstr</em>, one dimension at a time. For a single
dimension, the balancing operation (described below) is iterated on up
to <em>Niter</em> times. After each dimension finishes, the imbalance factor
is re-computed, and the balancing operation halts if the <em>stopthresh</em>
criterion is met.</p>
<p>A rebalance operation in a single dimension is performed using a
density-dependent recursive multisectioning algorithm, where the
position of each cutting plane (line in 2d) in the dimension is
adjusted independently. This is similar to a recursive bisectioning
for a single value, except that the bounds used for each bisectioning
take advantage of information from neighboring cuts if possible, as
well as counts of particles at the bounds on either side of each cuts,
which themselves were cuts in previous iterations. The latter is used
to infer a density of pariticles near each of the current cuts. At
each iteration, the count of particles on either side of each plane is
tallied. If the counts do not match the target value for the plane,
the position of the cut is adjusted based on the local density. The
low and high bounds are adjusted on each iteration, using new count
information, so that they become closer together over time. Thus as
the recursion progresses, the count of particles on either side of the
plane gets closer to the target value.</p>
<p>The density-dependent part of this algorithm is often an advantage
when you rebalance a system that is already nearly balanced. It
typically converges more quickly than the geometric bisectioning
algorithm used by the <aclass="reference internal"href="balance.html"><em>balance</em></a> command. However, if can
be a disadvantage if you attempt to rebalance a system that is far
from balanced, and converge more slowly. In this case you probably
want to use the <aclass="reference internal"href="balance.html"><em>balance</em></a> command before starting a run,
so that you begin the run with a balanced system.</p>
<p>Once the rebalancing is complete and final processor sub-domains
assigned, particles migrate to their new owning processor as part of
the normal reneighboring procedure.</p>
<divclass="admonition warning">
<pclass="first admonition-title">Warning</p>
<pclass="last">At each rebalance operation, the bisectioning for each
cutting plane (line in 2d) typcially starts with low and high bounds
separated by the extent of a processor’s sub-domain in one dimension.
The size of this bracketing region shrinks based on the local density,
as described above, which should typically be 1/2 or more every
iteration. Thus if <em>Niter</em> is specified as 10, the cutting plane will
typically be positioned to better than 1 part in 1000 accuracy
(relative to the perfect target position). For <em>Niter</em> = 20, it will
be accurate to better than 1 part in a million. Thus there is no need
to set <em>Niter</em> to a large value. This is especially true if you are
rebalancing often enough that each time you expect only an incremental
adjustement in the cutting planes is necessary. LAMMPS will check if
the threshold accuracy is reached (in a dimension) is less iterations
than <em>Niter</em> and exit early.</p>
</div>
<hrclass="docutils"/>
<p>The <em>rcb</em> style invokes a “tiled” method for balancing, as described
above. It performs a recursive coordinate bisectioning (RCB) of the
simulation domain. The basic idea is as follows.</p>
<p>The simulation domain is cut into 2 boxes by an axis-aligned cut in
the longest dimension, leaving one new box on either side of the cut.
All the processors are also partitioned into 2 groups, half assigned
to the box on the lower side of the cut, and half to the box on the
upper side. (If the processor count is odd, one side gets an extra
processor.) The cut is positioned so that the number of atoms in the
lower box is exactly the number that the processors assigned to that
box should own for load balance to be perfect. This also makes load
balance for the upper box perfect. The positioning is done
iteratively, by a bisectioning method. Note that counting atoms on
either side of the cut requires communication between all processors
at each iteration.</p>
<p>That is the procedure for the first cut. Subsequent cuts are made
recursively, in exactly the same manner. The subset of processors
assigned to each box make a new cut in the longest dimension of that
box, splitting the box, the subset of processsors, and the atoms in
the box in two. The recursion continues until every processor is
assigned a sub-box of the entire simulation domain, and owns the atoms
in that sub-box.</p>
<hrclass="docutils"/>
<p>The <em>out</em> keyword writes a text file to the specified <em>filename</em> with
the results of each rebalancing operation. The file contains the
bounds of the sub-domain for each processor after the balancing
operation completes. The format of the file is compatible with the
<aclass="reference external"href="pizza">Pizza.py</a><em>mdump</em> tool which has support for manipulating and
visualizing mesh files. An example is shown here for a balancing by 4
<h2>Restart, fix_modify, output, run start/stop, minimize info<aclass="headerlink"href="#restart-fix-modify-output-run-start-stop-minimize-info"title="Permalink to this headline">¶</a></h2>
<p>No information about this fix is written to <aclass="reference internal"href="restart.html"><em>binary restart files</em></a>. None of the <aclass="reference internal"href="fix_modify.html"><em>fix_modify</em></a> options
are relevant to this fix.</p>
<p>This fix computes a global scalar which is the imbalance factor
after the most recent rebalance and a global vector of length 3 with
additional information about the most recent rebalancing. The 3
values in the vector are as follows:</p>
<ulclass="simple">
<li>1 = max # of particles per processor</li>
<li>2 = total # iterations performed in last rebalance</li>
<li>3 = imbalance factor right before the last rebalance was performed</li>
</ul>
<p>As explained above, the imbalance factor is the ratio of the maximum
number of particles on any processor to the average number of
particles per processor.</p>
<p>These quantities can be accessed by various <aclass="reference internal"href="Section_howto.html#howto-15"><span>output commands</span></a>. The scalar and vector values
calculated by this fix are “intensive”.</p>
<p>No parameter of this fix can be used with the <em>start/stop</em> keywords of
the <aclass="reference internal"href="run.html"><em>run</em></a> command. This fix is not invoked during <aclass="reference internal"href="minimize.html"><em>energy minimization</em></a>.</p>
</div>
<hrclass="docutils"/>
<divclass="section"id="restrictions">
<h2>Restrictions<aclass="headerlink"href="#restrictions"title="Permalink to this headline">¶</a></h2>
<p>For 2d simulations, a “z” cannot appear in <em>dimstr</em> for the <em>shift</em>
style.</p>
</div>
<divclass="section"id="related-commands">
<h2>Related commands<aclass="headerlink"href="#related-commands"title="Permalink to this headline">¶</a></h2>
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>.