forked from lijiext/lammps
git-svn-id: svn://svn.icms.temple.edu/lammps-ro/trunk@8288 f3b2605a-c512-4ea7-a41b-209d697bcdaa
This commit is contained in:
parent
6e45914023
commit
5b52b62ff1
|
@ -22,21 +22,21 @@ balancing has not yet been released.
|
|||
</UL>
|
||||
<LI>keyword = <I>x</I> or <I>y</I> or <I>z</I> or <I>dynamic</I> or <I>out</I>
|
||||
|
||||
<PRE> <I>x</I> args = <I>uniform</I> or Px-1 numbers between 0 and 1
|
||||
<I>uniform</I> = evenly spaced cuts between processors in x dimension
|
||||
numbers = Px-1 ascending values between 0 and 1, Px - # of processors in x dimension
|
||||
<I>y</I> args = <I>uniform</I> or Py-1 numbers between 0 and 1
|
||||
<I>uniform</I> = evenly spaced cuts between processors in y dimension
|
||||
numbers = Py-1 ascending values between 0 and 1, Py - # of processors in y dimension
|
||||
<I>z</I> args = <I>uniform</I> or Pz-1 numbers between 0 and 1
|
||||
<I>uniform</I> = evenly spaced cuts between processors in z dimension
|
||||
numbers = Pz-1 ascending values between 0 and 1, Pz - # of processors in z dimension
|
||||
<I>dynamic</I> args = dimstr Niter thresh
|
||||
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
|
||||
thresh = stop balancing when this imbalance threshhold is reached
|
||||
<I>out</I> arg = filename
|
||||
filename = output file to write each processor's sub-domain to
|
||||
<PRE> <I>x</I> args = <I>uniform</I> or Px-1 numbers between 0 and 1
|
||||
<I>uniform</I> = evenly spaced cuts between processors in x dimension
|
||||
numbers = Px-1 ascending values between 0 and 1, Px - # of processors in x dimension
|
||||
<I>y</I> args = <I>uniform</I> or Py-1 numbers between 0 and 1
|
||||
<I>uniform</I> = evenly spaced cuts between processors in y dimension
|
||||
numbers = Py-1 ascending values between 0 and 1, Py - # of processors in y dimension
|
||||
<I>z</I> args = <I>uniform</I> or Pz-1 numbers between 0 and 1
|
||||
<I>uniform</I> = evenly spaced cuts between processors in z dimension
|
||||
numbers = Pz-1 ascending values between 0 and 1, Pz - # of processors in z dimension
|
||||
<I>dynamic</I> args = dimstr Niter thresh
|
||||
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
|
||||
thresh = stop balancing when this imbalance threshhold is reached
|
||||
<I>out</I> arg = filename
|
||||
filename = output file to write each processor's sub-domain to
|
||||
</PRE>
|
||||
|
||||
</UL>
|
||||
|
@ -161,8 +161,30 @@ except that the bounds used for each bisectioning take advantage of
|
|||
information from neighboring cuts if possible. 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. As the recustion progresses, the count of
|
||||
particles on either side of the plane gets closer to the target value.
|
||||
the cut is adjusted to be halfway between a low and high bound. 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 recustion progresses, the count of particles on either side of the
|
||||
plane gets closer to the target value.
|
||||
</P>
|
||||
<P>Once the rebalancing is complete and final processor sub-domains
|
||||
assigned, particles are migrated to their new owning processor, and
|
||||
the balance procedure ends.
|
||||
</P>
|
||||
<P>IMPORTANT NOTE: At each rebalance operation, the recursive
|
||||
bisectioning operation 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 by 1/2 every iteration. Thus if <I>Niter</I> is specified
|
||||
as 10, the cutting plane will typically be positioned to 1 part in
|
||||
1000 accuracy (relative to the perfect target position). For <I>Niter</I>
|
||||
= 20, it will be accurate to 1 part in a million. Tus there is no
|
||||
need ot set <I>Niter</I> to a large value. LAMMPS will check if the
|
||||
threshold accuracy is reached (in a dimension) is less iterations than
|
||||
<I>Niter</I> and exit early. However, <I>Niter</I> should also not be set too
|
||||
small, since it will take roughly the same number of iterations to
|
||||
converge even if the cutting plane is initially close to the target
|
||||
value.
|
||||
</P>
|
||||
<HR>
|
||||
|
||||
|
@ -171,7 +193,7 @@ the results of the balancing 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 HREF = "pizza">Pizza.py</A> <I>mdump</I> tool which has support for manipulating and
|
||||
visualizing mesh files. An example is show here for a balancing by 4
|
||||
visualizing mesh files. An example is shown here for a balancing by 4
|
||||
processors for a 2d problem:
|
||||
</P>
|
||||
<PRE>ITEM: TIMESTEP
|
||||
|
|
|
@ -17,21 +17,21 @@ balance keyword args ... :pre
|
|||
|
||||
one or more keyword/arg pairs may be appended :ule,l
|
||||
keyword = {x} or {y} or {z} or {dynamic} or {out} :l
|
||||
{x} args = {uniform} or Px-1 numbers between 0 and 1
|
||||
{uniform} = evenly spaced cuts between processors in x dimension
|
||||
numbers = Px-1 ascending values between 0 and 1, Px - # of processors in x dimension
|
||||
{y} args = {uniform} or Py-1 numbers between 0 and 1
|
||||
{uniform} = evenly spaced cuts between processors in y dimension
|
||||
numbers = Py-1 ascending values between 0 and 1, Py - # of processors in y dimension
|
||||
{z} args = {uniform} or Pz-1 numbers between 0 and 1
|
||||
{uniform} = evenly spaced cuts between processors in z dimension
|
||||
numbers = Pz-1 ascending values between 0 and 1, Pz - # of processors in z dimension
|
||||
{dynamic} args = dimstr Niter thresh
|
||||
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
|
||||
thresh = stop balancing when this imbalance threshhold is reached
|
||||
{out} arg = filename
|
||||
filename = output file to write each processor's sub-domain to :pre
|
||||
{x} args = {uniform} or Px-1 numbers between 0 and 1
|
||||
{uniform} = evenly spaced cuts between processors in x dimension
|
||||
numbers = Px-1 ascending values between 0 and 1, Px - # of processors in x dimension
|
||||
{y} args = {uniform} or Py-1 numbers between 0 and 1
|
||||
{uniform} = evenly spaced cuts between processors in y dimension
|
||||
numbers = Py-1 ascending values between 0 and 1, Py - # of processors in y dimension
|
||||
{z} args = {uniform} or Pz-1 numbers between 0 and 1
|
||||
{uniform} = evenly spaced cuts between processors in z dimension
|
||||
numbers = Pz-1 ascending values between 0 and 1, Pz - # of processors in z dimension
|
||||
{dynamic} args = dimstr Niter thresh
|
||||
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
|
||||
thresh = stop balancing when this imbalance threshhold is reached
|
||||
{out} arg = filename
|
||||
filename = output file to write each processor's sub-domain to :pre
|
||||
:ule
|
||||
|
||||
[Examples:]
|
||||
|
@ -155,8 +155,30 @@ except that the bounds used for each bisectioning take advantage of
|
|||
information from neighboring cuts if possible. 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. As the recustion progresses, the count of
|
||||
particles on either side of the plane gets closer to the target value.
|
||||
the cut is adjusted to be halfway between a low and high bound. 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 recustion progresses, the count of particles on either side of the
|
||||
plane gets closer to the target value.
|
||||
|
||||
Once the rebalancing is complete and final processor sub-domains
|
||||
assigned, particles are migrated to their new owning processor, and
|
||||
the balance procedure ends.
|
||||
|
||||
IMPORTANT NOTE: At each rebalance operation, the recursive
|
||||
bisectioning operation 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 by 1/2 every iteration. Thus if {Niter} is specified
|
||||
as 10, the cutting plane will typically be positioned to 1 part in
|
||||
1000 accuracy (relative to the perfect target position). For {Niter}
|
||||
= 20, it will be accurate to 1 part in a million. Tus there is no
|
||||
need ot set {Niter} to a large value. LAMMPS will check if the
|
||||
threshold accuracy is reached (in a dimension) is less iterations than
|
||||
{Niter} and exit early. However, {Niter} should also not be set too
|
||||
small, since it will take roughly the same number of iterations to
|
||||
converge even if the cutting plane is initially close to the target
|
||||
value.
|
||||
|
||||
:line
|
||||
|
||||
|
@ -165,7 +187,7 @@ the results of the balancing 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
|
||||
"Pizza.py"_pizza {mdump} tool which has support for manipulating and
|
||||
visualizing mesh files. An example is show here for a balancing by 4
|
||||
visualizing mesh files. An example is shown here for a balancing by 4
|
||||
processors for a 2d problem:
|
||||
|
||||
ITEM: TIMESTEP
|
||||
|
|
|
@ -143,7 +143,20 @@ points to consider, as discussed here.
|
|||
</P>
|
||||
<P>Fixes that perform time integration, such as <A HREF = "fix_nve.html">fix nve</A> or
|
||||
<A HREF = "fix_nh.html">fix npt</A> are not invoked, since no time integration is
|
||||
performed.
|
||||
performed. Fixes that perturb or constrain the forces on atoms will
|
||||
be invoked, just as they would during a normal run. Examples are <A HREF = "fix_indent.html">fix
|
||||
indent</A> and <A HREF = "fix_langevin.html">fix langevin</A>. So you
|
||||
should think carefully as to whether that makes sense for the manner
|
||||
in which you are reprocessing the dump snapshots.
|
||||
</P>
|
||||
<P>If you only want the rerun script to perform analyses that do not
|
||||
involve pair interactions, such as use compute msd to calculated
|
||||
displacements over time, you do not need to define a <A HREF = "pair_style.html">pair
|
||||
style</A>, which may also mean neighbor lists will not
|
||||
need to be calculated which saves time. The <A HREF = "communicate.html">communicate
|
||||
cutoff</A> command can also be used to insure ghost
|
||||
atoms are acquired from far enough away for operations like bond and
|
||||
angle evaluations, if no pair style is being used.
|
||||
</P>
|
||||
<P>Every time a snapshot is read, the timestep for the simulation is
|
||||
reset, as if the <A HREF = "reset_timestep.html<A HREF = "fix_deposit.html">>reset_timestep</A> command were
|
||||
|
|
|
@ -137,7 +137,20 @@ points to consider, as discussed here.
|
|||
|
||||
Fixes that perform time integration, such as "fix nve"_fix_nve.html or
|
||||
"fix npt"_fix_nh.html are not invoked, since no time integration is
|
||||
performed.
|
||||
performed. Fixes that perturb or constrain the forces on atoms will
|
||||
be invoked, just as they would during a normal run. Examples are "fix
|
||||
indent"_fix_indent.html and "fix langevin"_fix_langevin.html. So you
|
||||
should think carefully as to whether that makes sense for the manner
|
||||
in which you are reprocessing the dump snapshots.
|
||||
|
||||
If you only want the rerun script to perform analyses that do not
|
||||
involve pair interactions, such as use compute msd to calculated
|
||||
displacements over time, you do not need to define a "pair
|
||||
style"_pair_style.html, which may also mean neighbor lists will not
|
||||
need to be calculated which saves time. The "communicate
|
||||
cutoff"_communicate.html command can also be used to insure ghost
|
||||
atoms are acquired from far enough away for operations like bond and
|
||||
angle evaluations, if no pair style is being used.
|
||||
|
||||
Every time a snapshot is read, the timestep for the simulation is
|
||||
reset, as if the "reset_timestep"_reset_timestep.html command were
|
||||
|
|
Loading…
Reference in New Issue