ICODE-ADC/lammps
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

change to RCB cuts in load-balancing commands, also a new option for fix halt

Browse Source
This commit is contained in:
Steve Plimpton
2017-03-10 15:55:07 -07:00
parent 470353e320
commit f871ecdc67
15 changed files with 686 additions and 51 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
doc/src/Manual.txt
View File

@ -1,7 +1,7 @@
<!-- HTML_ONLY -->
<HEAD>
<TITLE>LAMMPS Users Manual</TITLE>
<META NAME="docnumber" CONTENT="7 Mar 2017 version">
<META NAME="docnumber" CONTENT="10 Mar 2017 version">
<META NAME="author" CONTENT="http://lammps.sandia.gov - Sandia National Laboratories">
<META NAME="copyright" CONTENT="Copyright (2003) Sandia Corporation. This software and manual is distributed under the GNU General Public License.">
</HEAD>
@ -21,7 +21,7 @@
<H1></H1>
LAMMPS Documentation :c,h3
7 Mar 2017 version :c,h4
10 Mar 2017 version :c,h4
Version info: :h4

38
doc/src/balance.txt
View File

@ -286,24 +286,32 @@ above. It performs a recursive coordinate bisectioning (RCB) of the
simulation domain. The basic idea is as follows.
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 particles 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 particles
on either side of the cut requires communication between all
processors at each iteration.
one of the dimensions, leaving one new sub-box on either side of the
cut. Which dimension is chosen for the cut depends on the particle
(weight) distribution within the parent box. Normally the longest
dimension of the box is cut, but if all (or most) of the particles are
at one end of the box, a cut may be performed in another dimension to
induce sub-boxes that are more cube-ish (3d) or square-ish (2d) in
shape.
After the cut is made, 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 (weighted) particles 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 of the cut is done iteratively, by a
bisectioning method (median search). Note that counting particles on
either side of the cut requires communication between all processors
at each iteration.
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 processors, and the particles
in the box in two. The recursion continues until every processor is
assigned a sub-box of the entire simulation domain, and owns the
assigned to each box make a new cut in one dimension of that box,
splitting the box, the subset of processors, and the particles in the
box in two. The recursion continues until every processor is assigned
a sub-box of the entire simulation domain, and owns the (weighted)
particles in that sub-box.
:line

4
doc/src/change_box.txt
View File

@ -101,11 +101,11 @@ Instead you could do something like this, assuming the simulation box
is non-periodic and atoms extend from 0 to 20 in all dimensions:
change_box all x final -10 20
create_atoms 1 single -5 5 5 # this will fail to insert an atom :pre
create_atoms 1 single -5 5 5 # this will fail to insert an atom :pre
change_box all x final -10 20 boundary f s s
create_atoms 1 single -5 5 5
change_box boundary s s s # this will work :pre
change_box all boundary s s s # this will work :pre
NOTE: Unlike the earlier "displace_box" version of this command, atom
remapping is NOT performed by default. This command allows remapping

11
doc/src/create_atoms.txt
View File

@ -134,6 +134,17 @@ not overlap existing atoms inappropriately, especially if molecules
are being added. The "delete_atoms"_delete_atoms.html command can be
used to remove overlapping atoms or molecules.
NOTE: You cannot use any of the styles explained above to create atoms
that are outside the simulation box; they will just be ignored by
LAMMPS. This is true even if you are using shrink-wrapped box
boundaries, as specified by the "boundary"_boundary.html command.
However, you can first use the "change_box"_change_box.html command to
temporarily expand the box, then add atoms via create_atoms, then
finally use change_box command again if needed to re-shrink-wrap the
new atoms. See the "change_box"_change_box.html doc page for an
example of how to do this, using the create_atoms {single} style to
insert a new atom outside the current simulation box.
:line
Individual atoms are inserted by this command, unless the {mol}

54
doc/src/fix_halt.txt
View File

@ -15,15 +15,16 @@ fix ID group-ID halt N attribute operator avalue keyword value ... :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
halt = style name of this fix command :l
N = check halt condition every N steps :l
attribute = hstyle or v_name :l
hstyle = {bondmax}
attribute = {bondmax} or {tlimit} or v_name :l
bondmax = length of longest bond in the system
tlimit = elapsed CPU time
v_name = name of "equal-style variable"_variable.html :pre
operator = "<" or "<=" or ">" or ">=" or "==" or "!=" or "|^" :l
avalue = numeric value to compare attribute to :l
string = text string to print with optional variable names :l
zero or more keyword/value pairs may be appended :l
keyword = {error} :l
{error} value = {hard} or {soft} or {continue} :pre
keyword = {error} or {message} :l
{error} value = {hard} or {soft} or {continue}
{message} value = {yes} or {no} :pre
:ule
[Examples:]
@ -40,14 +41,33 @@ specified by the "run"_run.html or "minimize"_minimize.html command.
The specified group-ID is ignored by this fix.
The specified {attribute} can be one of the {hstyle} options listed
above, or an "equal-style variable"_variable.html referenced as
{v_name}, where "name" is the name of a variable that has been defined
previously in the input script.
The specified {attribute} can be one of the options listed above,
namely {bondmax} or {tlimit}, or an "equal-style
variable"_variable.html referenced as {v_name}, where "name" is the
name of a variable that has been defined previously in the input
script.
The only {hstyle} option currently implemented is {bondmax}. This
will loop over all bonds in the system, compute their current
lengths, and set {attribute} to the longest bond distance.
The {bondmax} attribute will loop over all bonds in the system,
compute their current lengths, and set {attribute} to the longest bond
distance.
The {tlimit} attribute queries the elapsed CPU time (in seconds) since
the current run began, and sets {attribute} to that value. This is an
alternative way to limit the length of a simulation run, similar to
the "timer"_timer.html timeout command. There are two differences in
using this method versus the timer command option. The first is that
the clock starts at the beginning of the current run (not when the
timer or fix command is specified), so that any setup time for the run
is not included in the elapsed time. The second is that the timer
invocation and syncing across all processors (via MPI_Allreduce) is
not performed once every {N} steps by this command. Instead it is
performed (typically) only a small number of times and the elapsed
times are used to predict when the end-of-the-run will be. Both of
these attributes can be useful when performing benchmark calculations
for a desired length of time with minmimal overhead. For example, if
a run is performing 1000s of timesteps/sec, the overhead for syncing
the timer frequently across a large number of processors may be
non-negligble.
Equal-style variables evaluate to a numeric value. See the
"variable"_variable.html command for a description. They calculate
@ -100,6 +120,14 @@ Note that you may wish use the "unfix"_unfix.html command on the fix
halt ID, so that the same condition is not immediately triggered in a
subsequent run.
The optional {message} keyword determines whether a message is printed
to the screen and logfile when the half condition is triggered. If
{message} is set to yes, a one line message with the values that
triggered the halt is printed. If {message} is set to no, no message
is printed; the run simply exits. The latter may be desirable for
post-processing tools that extract thermodyanmic information from log
files.
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
@ -118,4 +146,4 @@ This fix is not invoked during "energy minimization"_minimize.html.
[Default:]
The option defaults are error = hard.
The option defaults are error = hard and message = yes.

2
doc/src/quit.txt
View File

@ -17,7 +17,7 @@ status = numerical exit status (optional)
[Examples:]
quit
if "$n > 10000" then "quit 1":pre
if "$n > 10000" then "quit 1" :pre
[Description:]

2
doc/src/thermo_style.txt
View File

@ -36,7 +36,7 @@ args = list of arguments for a particular style :l
elaplong = timesteps since start of initial run in a series of runs
dt = timestep size
time = simulation time
cpu = elapsed CPU time in seconds
cpu = elapsed CPU time in seconds since start of this run
tpcpu = time per CPU second
spcpu = timesteps per CPU second
cpuremain = estimated CPU time remaining in run