forked from lijiext/lammps
535 lines
24 KiB
HTML
535 lines
24 KiB
HTML
|
|
|
|
<!DOCTYPE html>
|
|
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
|
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
|
<head>
|
|
<meta charset="utf-8">
|
|
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
|
|
|
<title>fix balance command — LAMMPS 15 May 2015 version documentation</title>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
|
|
|
|
|
|
|
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
|
|
|
|
|
|
|
<link rel="top" title="LAMMPS 15 May 2015 version documentation" href="index.html"/>
|
|
|
|
|
|
<script src="_static/js/modernizr.min.js"></script>
|
|
|
|
</head>
|
|
|
|
<body class="wy-body-for-nav" role="document">
|
|
|
|
<div class="wy-grid-for-nav">
|
|
|
|
|
|
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
|
<div class="wy-side-nav-search">
|
|
|
|
|
|
|
|
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
|
|
|
|
|
|
|
</a>
|
|
|
|
|
|
<div role="search">
|
|
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
|
<input type="text" name="q" placeholder="Search docs" />
|
|
<input type="hidden" name="check_keywords" value="yes" />
|
|
<input type="hidden" name="area" value="default" />
|
|
</form>
|
|
</div>
|
|
|
|
|
|
</div>
|
|
|
|
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
|
|
|
|
|
|
|
<ul>
|
|
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
|
</ul>
|
|
|
|
|
|
|
|
</div>
|
|
|
|
</nav>
|
|
|
|
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
|
|
|
|
|
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
|
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
|
<a href="Manual.html">LAMMPS</a>
|
|
</nav>
|
|
|
|
|
|
|
|
<div class="wy-nav-content">
|
|
<div class="rst-content">
|
|
<div role="navigation" aria-label="breadcrumbs navigation">
|
|
<ul class="wy-breadcrumbs">
|
|
<li><a href="Manual.html">Docs</a> »</li>
|
|
|
|
<li>fix balance command</li>
|
|
<li class="wy-breadcrumbs-aside">
|
|
|
|
|
|
<a href="http://lammps.sandia.gov">Website</a>
|
|
<a href="Section_commands.html#comm">Commands</a>
|
|
|
|
</li>
|
|
</ul>
|
|
<hr/>
|
|
|
|
</div>
|
|
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
|
<div itemprop="articleBody">
|
|
|
|
<div class="section" id="fix-balance-command">
|
|
<span id="index-0"></span><h1>fix balance command<a class="headerlink" href="#fix-balance-command" title="Permalink to this headline">¶</a></h1>
|
|
<div class="section" id="syntax">
|
|
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
|
|
<div class="highlight-python"><div class="highlight"><pre>fix ID group-ID balance Nfreq thresh style args keyword value ...
|
|
</pre></div>
|
|
</div>
|
|
<ul class="simple">
|
|
<li>ID, group-ID are documented in <a class="reference internal" href="fix.html"><em>fix</em></a> command</li>
|
|
<li>balance = style name of this fix command</li>
|
|
<li>Nfreq = perform dynamic load balancing every this many steps</li>
|
|
<li>thresh = imbalance threshhold that must be exceeded to perform a re-balance</li>
|
|
<li>style = <em>shift</em> or <em>rcb</em></li>
|
|
</ul>
|
|
<div class="highlight-python"><div class="highlight"><pre>shift args = dimstr Niter stopthresh
|
|
dimstr = sequence of letters containing "x" or "y" or "z", each not more than once
|
|
Niter = # of times to iterate within each dimension of dimstr sequence
|
|
stopthresh = stop balancing when this imbalance threshhold is reached
|
|
rcb args = none
|
|
</pre></div>
|
|
</div>
|
|
<ul class="simple">
|
|
<li>zero or more keyword/value pairs may be appended</li>
|
|
<li>keyword = <em>out</em></li>
|
|
</ul>
|
|
<pre class="literal-block">
|
|
<em>out</em> value = filename
|
|
filename = write each processor's sub-domain to a file, at each re-balancing
|
|
</pre>
|
|
</div>
|
|
<div class="section" id="examples">
|
|
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
|
|
<div class="highlight-python"><div class="highlight"><pre>fix 2 all balance 1000 1.05 shift x 10 1.05
|
|
fix 2 all balance 100 0.9 shift xy 20 1.1 out tmp.balance
|
|
fix 2 all balance 1000 1.1 rcb
|
|
</pre></div>
|
|
</div>
|
|
</div>
|
|
<div class="section" id="description">
|
|
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
|
|
<p>This command adjusts the size and shape of processor sub-domains
|
|
within the simulation box, to attempt to balance the number of
|
|
particles and thus the computational cost (load) evenly across
|
|
processors. The load balancing is “dynamic” in the sense that
|
|
rebalancing is performed periodically during the simulation. To
|
|
perform “static” balancing, before or between runs, see the
|
|
<a class="reference internal" href="balance.html"><em>balance</em></a> command.</p>
|
|
<p>Load-balancing is typically only useful if the particles in the
|
|
simulation box have a spatially-varying density distribution. E.g. a
|
|
model of a vapor/liquid interface, or a solid with an irregular-shaped
|
|
geometry containing void regions. In this case, the LAMMPS default of
|
|
dividing the simulation box volume into a regular-spaced grid of 3d
|
|
bricks, with one equal-volume sub-domain per processor, may assign
|
|
very different numbers of particles per processor. This can lead to
|
|
poor performance when the simulation is run in parallel.</p>
|
|
<p>Note that the <a class="reference internal" href="processors.html"><em>processors</em></a> command allows some control
|
|
over how the box volume is split across processors. Specifically, for
|
|
a Px by Py by Pz grid of processors, it allows choice of Px, Py, and
|
|
Pz, subject to the constraint that Px * Py * Pz = P, the total number
|
|
of processors. This is sufficient to achieve good load-balance for
|
|
some problems on some processor counts. However, all the processor
|
|
sub-domains will still have the same shape and same volume.</p>
|
|
<p>On a particular timestep, a load-balancing operation is only performed
|
|
if the current “imbalance factor” in particles owned by each processor
|
|
exceeds the specified <em>thresh</em> parameter. The imbalance factor is
|
|
defined as the maximum number of particles owned by any processor,
|
|
divided by the average number of particles per processor. Thus an
|
|
imbalance factor of 1.0 is perfect balance.</p>
|
|
<p>As an example, for 10000 particles running on 10 processors, if the
|
|
most heavily loaded processor has 1200 particles, then the factor is
|
|
1.2, meaning there is a 20% imbalance. Note that re-balances can be
|
|
forced even if the current balance is perfect (1.0) be specifying a
|
|
<em>thresh</em> < 1.0.</p>
|
|
<div class="admonition warning">
|
|
<p class="first admonition-title">Warning</p>
|
|
<p class="last">This command attempts to minimize the imbalance
|
|
factor, as defined above. But depending on the method a perfect
|
|
balance (1.0) may not be achieved. For example, “grid” methods
|
|
(defined below) that create a logical 3d grid cannot achieve perfect
|
|
balance for many irregular distributions of particles. Likewise, if a
|
|
portion of the system is a perfect lattice, e.g. the initial system is
|
|
generated by the <a class="reference internal" href="create_atoms.html"><em>create_atoms</em></a> command, then “grid”
|
|
methods may be unable to achieve exact balance. This is because
|
|
entire lattice planes will be owned or not owned by a single
|
|
processor.</p>
|
|
</div>
|
|
<div class="admonition warning">
|
|
<p class="first admonition-title">Warning</p>
|
|
<p class="last">The imbalance factor is also an estimate of the
|
|
maximum speed-up you can hope to achieve by running a perfectly
|
|
balanced simulation versus an imbalanced one. In the example above,
|
|
the 10000 particle simulation could run up to 20% faster if it were
|
|
perfectly balanced, versus when imbalanced. However, computational
|
|
cost is not strictly proportional to particle count, and changing the
|
|
relative size and shape of processor sub-domains may lead to
|
|
additional computational and communication overheads, e.g. in the PPPM
|
|
solver used via the <a class="reference internal" href="kspace_style.html"><em>kspace_style</em></a> command. Thus
|
|
you should benchmark the run times of a simulation before and after
|
|
balancing.</p>
|
|
</div>
|
|
<hr class="docutils" />
|
|
<p>The method used to perform a load balance is specified by one of the
|
|
listed styles, which are described in detail below. There are 2 kinds
|
|
of styles.</p>
|
|
<p>The <em>shift</em> style is a “grid” method which produces a logical 3d grid
|
|
of processors. It operates by changing the cutting planes (or lines)
|
|
between processors in 3d (or 2d), to adjust the volume (area in 2d)
|
|
assigned to each processor, as in the following 2d diagram where
|
|
processor sub-domains are shown and atoms are colored by the processor
|
|
that owns them. The leftmost diagram is the default partitioning of
|
|
the simulation box across processors (one sub-box for each of 16
|
|
processors); the middle diagram is after a “grid” method has been
|
|
applied.</p>
|
|
<a data-lightbox="group-default"
|
|
href="_images/balance_uniform.jpg"
|
|
class=""
|
|
title=""
|
|
data-title=""
|
|
><img src="_images/balance_uniform.jpg"
|
|
class="align-center"
|
|
width="25%"
|
|
height="auto"
|
|
alt=""/>
|
|
</a><a data-lightbox="group-default"
|
|
href="_images/balance_nonuniform.jpg"
|
|
class=""
|
|
title=""
|
|
data-title=""
|
|
><img src="_images/balance_nonuniform.jpg"
|
|
class="align-center"
|
|
width="25%"
|
|
height="auto"
|
|
alt=""/>
|
|
</a><a data-lightbox="group-default"
|
|
href="_images/balance_rcb.jpg"
|
|
class=""
|
|
title=""
|
|
data-title=""
|
|
><img src="_images/balance_rcb.jpg"
|
|
class="align-center"
|
|
width="25%"
|
|
height="auto"
|
|
alt=""/>
|
|
</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
|
|
<a class="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 <a class="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>
|
|
<hr class="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 <a class="reference internal" href="neighbor.html"><em>neighbor</em></a> and <a class="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>
|
|
<hr class="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 <a class="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 <a class="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>
|
|
<div class="admonition warning">
|
|
<p class="first admonition-title">Warning</p>
|
|
<p class="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>
|
|
<hr class="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>
|
|
<hr class="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
|
|
<a class="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
|
|
processors for a 2d problem:</p>
|
|
<div class="highlight-python"><div class="highlight"><pre>ITEM: TIMESTEP
|
|
0
|
|
ITEM: NUMBER OF NODES
|
|
16
|
|
ITEM: BOX BOUNDS
|
|
0 10
|
|
0 10
|
|
0 10
|
|
ITEM: NODES
|
|
1 1 0 0 0
|
|
2 1 5 0 0
|
|
3 1 5 5 0
|
|
4 1 0 5 0
|
|
5 1 5 0 0
|
|
6 1 10 0 0
|
|
7 1 10 5 0
|
|
8 1 5 5 0
|
|
9 1 0 5 0
|
|
10 1 5 5 0
|
|
11 1 5 10 0
|
|
12 1 10 5 0
|
|
13 1 5 5 0
|
|
14 1 10 5 0
|
|
15 1 10 10 0
|
|
16 1 5 10 0
|
|
ITEM: TIMESTEP
|
|
0
|
|
ITEM: NUMBER OF SQUARES
|
|
4
|
|
ITEM: SQUARES
|
|
1 1 1 2 3 4
|
|
2 1 5 6 7 8
|
|
3 1 9 10 11 12
|
|
4 1 13 14 15 16
|
|
</pre></div>
|
|
</div>
|
|
<p>The coordinates of all the vertices are listed in the NODES section, 5
|
|
per processor. Note that the 4 sub-domains share vertices, so there
|
|
will be duplicate nodes in the list.</p>
|
|
<p>The “SQUARES” section lists the node IDs of the 4 vertices in a
|
|
rectangle for each processor (1 to 4).</p>
|
|
<p>For a 3d problem, the syntax is similar with 8 vertices listed for
|
|
each processor, instead of 4, and “SQUARES” replaced by “CUBES”.</p>
|
|
</div>
|
|
<hr class="docutils" />
|
|
<div class="section" id="restart-fix-modify-output-run-start-stop-minimize-info">
|
|
<h2>Restart, fix_modify, output, run start/stop, minimize info<a class="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 <a class="reference internal" href="restart.html"><em>binary restart files</em></a>. None of the <a class="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>
|
|
<ul class="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 <a class="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 <a class="reference internal" href="run.html"><em>run</em></a> command. This fix is not invoked during <a class="reference internal" href="minimize.html"><em>energy minimization</em></a>.</p>
|
|
</div>
|
|
<hr class="docutils" />
|
|
<div class="section" id="restrictions">
|
|
<h2>Restrictions<a class="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>
|
|
<div class="section" id="related-commands">
|
|
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
|
|
<p><a class="reference internal" href="processors.html"><em>processors</em></a>, <a class="reference internal" href="balance.html"><em>balance</em></a></p>
|
|
<p><strong>Default:</strong> none</p>
|
|
</div>
|
|
</div>
|
|
|
|
|
|
</div>
|
|
</div>
|
|
<footer>
|
|
|
|
|
|
<hr/>
|
|
|
|
<div role="contentinfo">
|
|
<p>
|
|
© Copyright .
|
|
</p>
|
|
</div>
|
|
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
|
|
|
</footer>
|
|
|
|
</div>
|
|
</div>
|
|
|
|
</section>
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
<script type="text/javascript">
|
|
var DOCUMENTATION_OPTIONS = {
|
|
URL_ROOT:'./',
|
|
VERSION:'15 May 2015 version',
|
|
COLLAPSE_INDEX:false,
|
|
FILE_SUFFIX:'.html',
|
|
HAS_SOURCE: true
|
|
};
|
|
</script>
|
|
<script type="text/javascript" src="_static/jquery.js"></script>
|
|
<script type="text/javascript" src="_static/underscore.js"></script>
|
|
<script type="text/javascript" src="_static/doctools.js"></script>
|
|
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
|
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
|
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
|
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
|
|
|
|
|
|
|
|
|
|
|
<script type="text/javascript" src="_static/js/theme.js"></script>
|
|
|
|
|
|
|
|
|
|
<script type="text/javascript">
|
|
jQuery(function () {
|
|
SphinxRtdTheme.StickyNav.enable();
|
|
});
|
|
</script>
|
|
|
|
|
|
</body>
|
|
</html> |