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

Math-related edits and code-block swaps; checkd builds for pdf and html docs

Browse Source
This commit is contained in:
Karl Hammond
2022-09-02 17:44:45 -05:00
parent 9928d41233
commit d548c02a9e
8 changed files with 277 additions and 246 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
doc/src/dump_image.rst
View File

@ -775,7 +775,7 @@ specifies the bin size to use within the range for assigning
consecutive colors to. For example, if the range is from :math:`-10.0` to
:math:`10.0` and a *delta* of :math:`1.0` is used, then 20 colors will be
assigned to the range. The first will be from
:math:`-10.0 \le \text{color1} < -9.0`, then second from
:math:`-10.0 \le \text{color1} < -9.0`, then second from
:math:`-9.0 \le color2 < -8.0`, etc.
The *N* setting is how many entries follow. The format of the entries

4
doc/src/fix_ave_correlate.rst
View File

@ -264,7 +264,7 @@ samples every :math:`N_\text{freq}` timesteps. If the *ave* setting is *one*,
then the accumulation is restarted or zeroed every :math:`N_\text{freq}`
timesteps. Thus the outputs on successive :math:`N_\text{freq}` timesteps are
essentially independent of each other. The exception is that the
:math:`C_{ij}(0) = V_i(t) V_j(t)` value at a time step :math:`t`, where
:math:`C_{ij}(0) = V_i(t) V_j(t)` value at a time step :math:`t,` where
:math:`t` is a multiple of :math:`N_\text{freq}`, contributes to the
correlation output both at time :math:`t` and at time :math:`t+N_\text{freq}`.
@ -287,7 +287,7 @@ window or other unit conversions.
The *file* keyword allows a filename to be specified. Every
:math:`N_\text{freq}` steps, an array of correlation data is written to the
file. The number of rows is :math:`N_\text{repeat}`, as described above.
The number of columns is the :math:`N_\text{pair}+2`, also as described above.
The number of columns is :math:`N_\text{pair}+2`, also as described above.
Thus the file ends up to be a series of these array sections.
The *overwrite* keyword will continuously overwrite the output file

59
doc/src/fix_ave_correlate_long.rst
View File

@ -6,14 +6,14 @@ fix ave/correlate/long command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
fix ID group-ID ave/correlate/long Nevery Nfreq value1 value2 ... keyword args ...
* ID, group-ID are documented in :doc:`fix <fix>` command
* ave/correlate/long = style name of this fix command
* Nevery = use input values every this many timesteps
* Nfreq = save state of the time correlation functions every this many timesteps
* Nevery = use input values every this many time steps
* Nfreq = save state of the time correlation functions every this many time steps
* one or more input values can be listed
* value = c_ID, c_ID[N], f_ID, f_ID[N], v_name
@ -38,7 +38,7 @@ Syntax
auto/lower = auto + lower
full = correlate each value with every other value, including itself = auto + upper + lower
*start* args = Nstart
Nstart = start accumulating correlations on this timestep
Nstart = start accumulating correlations on this time step
*file* arg = filename
filename = name of file to output correlation data to
*overwrite* arg = none = overwrite output file with only latest output
@ -66,10 +66,11 @@ Examples
Description
"""""""""""
This fix is similar in spirit and syntax to the :doc:`fix ave/correlate <fix_ave_correlate>`.
This fix is similar in spirit and syntax to the
:doc:`fix ave/correlate <fix_ave_correlate>`.
However, this fix allows the efficient calculation of time correlation
functions on-the-fly over extremely long time windows with little
additional CPU overhead, using a multiple-tau method
additional CPU overhead, using a multiple-:math:`\tau` method
:ref:`(Ramirez) <Ramirez>` that decreases the resolution of the stored
correlation function with time. It is not a full drop-in replacement.
@ -78,37 +79,41 @@ specified values may represent calculations performed by computes and
fixes which store their own "group" definitions.
Each listed value can be the result of a compute or fix or the
evaluation of an equal-style variable. See the :doc:`fix ave/correlate <fix_ave_correlate>` page for details.
evaluation of an equal-style variable. See the
:doc:`fix ave/correlate <fix_ave_correlate>` page for details.
The *Nevery* and *Nfreq* arguments specify on what timesteps the input
values will be used to calculate correlation data, and the frequency
with which the time correlation functions will be output to a file.
Note that there is no *Nrepeat* argument, unlike the :doc:`fix ave/correlate <fix_ave_correlate>` command.
The *Nevery* and *Nfreq* arguments specify on what time steps the input
values will be used to calculate correlation data and the frequency
with which the time correlation functions will be output to a file,
respectively.
Note that there is no *Nrepeat* argument, unlike the
:doc:`fix ave/correlate <fix_ave_correlate>` command.
The optional keywords *ncorr*, *nlen*, and *ncount* are unique to this
command and determine the number of correlation points calculated and
the memory and CPU overhead used by this calculation. *Nlen* and
*ncount* determine the amount of averaging done at longer correlation
times. The default values *nlen=16*, *ncount=2* ensure that the
systematic error of the multiple-tau correlator is always below the
times. The default values *nlen* = 16 and *ncount* = 2 ensure that the
systematic error of the multiple-:math:`\tau` correlator is always below the
level of the statistical error of a typical simulation (which depends
on the ensemble size and the simulation length).
The maximum correlation time (in time steps) that can be reached is
given by the formula (nlen-1) \* ncount\^(ncorr-1). Longer correlation
given by the formula :math:`(nlen-1) ncount^{(ncorr-1)}`. Longer correlation
times are discarded and not calculated. With the default values of
the parameters (ncorr=20, nlen=16 and ncount=2), this corresponds to
7864320 time steps. If longer correlation times are needed, the value
of ncorr should be increased. Using nlen=16 and ncount=2, with
ncorr=30, the maximum number of steps that can be correlated is
80530636808. If ncorr=40, correlation times in excess of 8e12 time
steps can be calculated.
the parameters (:math:`ncorr=20`, :math:`nlen=16` and :math:`ncount=2`),
this corresponds to 7864320 time steps. If longer correlation times are
needed, the value of ncorr should be increased. Using :math:`nlen=16` and
:math:`ncount=2`, with :math:`ncorr=30`, the maximum number of steps that can
be correlated is 80530636808. If :math:`ncorr=40`, correlation times in excess
of :math:`8\times 10^{12}` time steps can be calculated.
The total memory needed for each correlation pair is roughly
4\*ncorr\*nlen\*8 bytes. With the default values of the parameters, this
corresponds to about 10 KB.
:math:`4 \times ncorr\times nlen \times 8` bytes.
With the default values of the parameters, this corresponds to about 10 KB.
For the meaning of the additional optional keywords, see the :doc:`fix ave/correlate <fix_ave_correlate>` doc page.
For the meaning of the additional optional keywords, see the
:doc:`fix ave/correlate <fix_ave_correlate>` doc page.
Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
@ -128,7 +133,8 @@ Restrictions
""""""""""""
This compute is part of the EXTRA-FIX package. It is only enabled if
LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info.
LAMMPS was built with that package. See the
:doc:`Build package <Build_package>` page for more info.
Related commands
""""""""""""""""
@ -140,8 +146,9 @@ Default
none
The option defaults for keywords that are also keywords for the :doc:`fix ave/correlate <fix_ave_correlate>` command are as follows: type =
auto, start = 0, no file output, title 1,2 = strings as described on
The option defaults for keywords that are also keywords for the
:doc:`fix ave/correlate <fix_ave_correlate>` command are as follows:
type = auto, start = 0, no file output, title 1,2 = strings as described on
the :doc:`fix ave/correlate <fix_ave_correlate>` doc page.
The option defaults for keywords unique to this command are as

189
doc/src/fix_ave_histo.rst
View File

@ -10,7 +10,7 @@ fix ave/histo/weight command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
fix ID group-ID style Nevery Nrepeat Nfreq lo hi Nbin value1 value2 ... keyword args ...
@ -22,7 +22,7 @@ Syntax
* lo,hi = lo/hi bounds within which to histogram
* Nbin = # of histogram bins
* one or more input values can be listed
* value = x, y, z, vx, vy, vz, fx, fy, fz, c_ID, c_ID[N], f_ID, f_ID[N], v_name
* value = *x*, *y*, *z*, *vx*, *vy*, *vz*, *fx*, *fy*, *fz*, c_ID, c_ID[N], f_ID, f_ID[N], v_name
.. parsed-literal::
@ -126,26 +126,27 @@ length. The first value (a scalar or vector) is what is histogrammed
into bins, in the same manner the fix ave/histo command operates. The
second value (a scalar or vector) is used as a "weight". This means
that instead of each value tallying a "1" to its bin, the
corresponding weight is tallied. E.g. The Nth entry (weight) in the
second vector is tallied to the bin corresponding to the Nth entry in
the first vector.
corresponding weight is tallied. For example, the :math:`N^\text{th}` entry
(weight) in the second vector is tallied to the bin corresponding to the
:math:`N^\text{th}` entry in the first vector.
----------
For input values from a compute or fix or variable, the bracketed
index I can be specified using a wildcard asterisk with the index to
effectively specify multiple values. This takes the form "\*" or
"\*n" or "n\*" or "m\*n". If N = the size of the vector (for *mode* =
scalar) or the number of columns in the array (for *mode* = vector),
then an asterisk with no numeric values means all indices from 1 to N.
"\*n" or "m\*" or "m\*n". If :math:`N` is the size of the vector
(for *mode* = scalar) or the number of columns in the array
(for *mode* = vector), then an asterisk with no numeric values means all
indices from 1 to :math:`N`\ .
A leading asterisk means all indices from 1 to n (inclusive). A
trailing asterisk means all indices from n to N (inclusive). A middle
trailing asterisk means all indices from m to :math:`N` (inclusive). A middle
asterisk means all indices from m to n (inclusive).
Using a wildcard is the same as if the individual elements of the
vector or columns of the array had been listed one by one. E.g. these
2 fix ave/histo commands are equivalent, since the :doc:`compute
com/chunk <compute_com_chunk>` command creates a global array with 3
vector or columns of the array had been listed one by one. For example, the
following two fix ave/histo commands are equivalent, since the :doc:`compute
com/chunk <compute_com_chunk>` command creates a global array with three
columns:
.. code-block:: LAMMPS
@ -164,31 +165,35 @@ columns:
----------
The *Nevery*, *Nrepeat*, and *Nfreq* arguments specify on what
timesteps the input values will be used in order to contribute to the
histogram. The final histogram is generated on timesteps that are
multiple of *Nfreq*\ . It is averaged over *Nrepeat* histograms,
computed in the preceding portion of the simulation every *Nevery*
timesteps. *Nfreq* must be a multiple of *Nevery* and *Nevery* must
be non-zero even if *Nrepeat* is 1. Also, the timesteps
contributing to the histogram value cannot overlap,
i.e. Nrepeat\*Nevery can not exceed Nfreq.
The :math:`N_\text{every}`, :math:`N_\text{repeat}`, and :math:`N_\text{freq}`
arguments specify on what time steps the input values will be used in order to
contribute to the histogram. The final histogram is generated on time steps
that are multiple of :math:`N_\text{freq}`\ . It is averaged over
:math:`N_\text{repeat}` histograms, computed in the preceding portion of the
simulation every :math:`N_\text{every}` time steps.
:math:`N_\text{freq}` must be a multiple of :math:`N_\text{every}` and
:math:`N_\text{every}` must be non-zero even if :math:`N_\text{repeat}` is 1.
Also, the time steps contributing to the histogram value cannot overlap
(i.e., :math:`N_\text{repeat}\times N_\text{every}` cannot exceed
:math:`N_\text{freq}`).
For example, if Nevery=2, Nrepeat=6, and Nfreq=100, then input values
on timesteps 90,92,94,96,98,100 will be used to compute the final
histogram on timestep 100. Similarly for timesteps
190,192,194,196,198,200 on timestep 200, etc. If Nrepeat=1 and Nfreq
= 100, then no time averaging of the histogram is done; a histogram is
simply generated on timesteps 100,200,etc.
For example, if :math:`N_\text{every}=2`, :math:`N_\text{repeat}=6`, and
:math:`N_\text{freq}=100`, then input values on time steps 90, 92, 94, 96, 98,
and 100 will be used to compute the final histogram on timestep 100.
Similarly for timesteps 190, 192, 194, 196, 198, and 200 on timestep 200, etc.
If :math:`N_\text{repeat}=1` and :math:`N_\text{freq} = 100`, then no time
averaging of the histogram is done; a histogram is simply generated on
timesteps 100, 200, etc.
----------
The atom attribute values (x,y,z,vx,vy,vz,fx,fy,fz) are
self-explanatory. Note that other atom attributes can be used as
inputs to this fix by using the :doc:`compute property/atom <compute_property_atom>` command and then specifying
an input value from that compute.
The atom attribute values (*x*, *y*, *z*, *vx*, *vy*, *vz*, *fx*, *fy*, and
*fz*) are self-explanatory. Note that other atom attributes can be used as
inputs to this fix by using the
:doc:`compute property/atom <compute_property_atom>` command and then
specifying an input value from that compute.
If a value begins with "c\_", a compute ID must follow which has been
If a value begins with "c\_," a compute ID must follow which has been
previously defined in the input script. If *mode* = scalar, then if
no bracketed term is appended, the global scalar calculated by the
compute is used. If a bracketed term is appended, the Ith element of
@ -201,35 +206,38 @@ how I can be specified with a wildcard asterisk to effectively specify
multiple values.
Note that there is a :doc:`compute reduce <compute_reduce>` command
which can sum per-atom quantities into a global scalar or vector which
can thus be accessed by fix ave/histo. Or it can be a compute defined
not in your input script, but by :doc:`thermodynamic output <thermo_style>` or other fixes such as :doc:`fix nvt <fix_nh>`
that can sum per-atom quantities into a global scalar or vector, which
can then be accessed by fix ave/histo. It can also be a compute defined
not in your input script, but by :doc:`thermodynamic output <thermo_style>`
or other fixes such as :doc:`fix nvt <fix_nh>`
or :doc:`fix temp/rescale <fix_temp_rescale>`. See the doc pages for
these commands which give the IDs of these computes. Users can also
write code for their own compute styles and :doc:`add them to LAMMPS <Modify>`.
write code for their own compute styles and
:doc:`add them to LAMMPS <Modify>`.
If a value begins with "f\_", a fix ID must follow which has been
If a value begins with "f\_," a fix ID must follow which has been
previously defined in the input script. If *mode* = scalar, then if
no bracketed term is appended, the global scalar calculated by the fix
is used. If a bracketed term is appended, the Ith element of the
global vector calculated by the fix is used. If *mode* = vector, then
if no bracketed term is appended, the global or per-atom or local
vector calculated by the fix is used. If a bracketed term is
appended, the Ith column of the global or per-atom or local array
calculated by the fix is used. See the discussion above for how I can
be specified with a wildcard asterisk to effectively specify multiple
values.
appended, the :math:`I^\text{th}` column of the global or per-atom or local
array calculated by the fix is used. See the discussion above for how
:math:`I` can be specified with a wildcard asterisk to effectively specify
multiple values.
Note that some fixes only produce their values on certain timesteps,
which must be compatible with *Nevery*, else an error will result.
Users can also write code for their own fix styles and :doc:`add them to LAMMPS <Modify>`.
which must be compatible with :math:`N_\text{every}`, else an error will
result. Users can also write code for their own fix styles and
:doc:`add them to LAMMPS <Modify>`.
If a value begins with "v\_", a variable name must follow which has
If a value begins with "v\_," a variable name must follow which has
been previously defined in the input script. If *mode* = scalar, then
only equal-style or vector-style variables can be used, which both
produce global values. In this mode, a vector-style variable requires
a bracketed term to specify the Ith element of the vector calculated
by the variable. If *mode* = vector, then only vector-style or
a bracketed term to specify the :math:`I^\text{th}` element of the vector
calculated by the variable. If *mode* = vector, then only vector-style or
atom-style variables can be used, which produce a global or per-atom
vector respectively. The vector-style variable must be used without a
bracketed term. See the :doc:`variable <variable>` command for details.
@ -259,44 +267,44 @@ keyword should be used to specify which output will be used. The
remaining input arguments must still be consistent.
The *beyond* keyword determines how input values that fall outside the
*lo* to *hi* bounds are treated. Values such that *lo* <= value <=
*hi* are assigned to one bin. Values on a bin boundary are assigned
to the lower of the 2 bins. If *beyond* is set to *ignore* then
values < *lo* and values > *hi* are ignored, i.e. they are not binned.
If *beyond* is set to *end* then values < *lo* are counted in the
first bin and values > *hi* are counted in the last bin. If *beyond*
is set to *extend* then two extra bins are created, so that there are
Nbins+2 total bins. Values < *lo* are counted in the first bin and
values > *hi* are counted in the last bin (Nbins+2). Values between
*lo* and *hi* (inclusive) are counted in bins 2 through Nbins+1. The
"coordinate" stored and printed for these two extra bins is *lo* and
*hi*\ .
*lo* to *hi* bounds are treated. Values such that *lo* :math:`\le` value
:math:`\le` *hi* are assigned to one bin. Values on a bin boundary are
assigned to the lower of the two bins. If *beyond* is set to *ignore* then
values :math:`<` *lo* and values :math:`>` *hi* are ignored (i.e., they are not
binned). If *beyond* is set to *end*, then values :math:`<` *lo* are counted in
the first bin and values :math:`>` *hi* are counted in the last bin.
If *beyond* is set to *extend*, then two extra bins are created so that there
are :math:`N_\text{bins}+2` total bins. Values :math:`<` *lo* are counted in
the first bin and values :math:`>` *hi* are counted in the last bin
:math:`(N_\text{bins}+2)`\ . Values between
*lo* and *hi* (inclusive) are counted in bins 2 through
:math:`N_\text{bins}+1`\ . The "coordinate" stored and printed for these two
extra bins is *lo* and *hi*\ .
The *ave* keyword determines how the histogram produced every *Nfreq*
steps are averaged with histograms produced on previous steps that
were multiples of *Nfreq*, before they are accessed by another output
command or written to a file.
The *ave* keyword determines how the histogram produced every
:math:`N_\text{freq}` steps are averaged with histograms produced on previous
steps that were multiples of :math:`N_\text{freq}`, before they are accessed by
another output command or written to a file.
If the *ave* setting is *one*, then the histograms produced on
timesteps that are multiples of *Nfreq* are independent of each other;
they are output as-is without further averaging.
timesteps that are multiples of :math:`N_\text{freq}` are independent of each
other; they are output as-is without further averaging.
If the *ave* setting is *running*, then the histograms produced on
timesteps that are multiples of *Nfreq* are summed and averaged in a
cumulative sense before being output. Each bin value in the histogram
is thus the average of the bin value produced on that timestep with
all preceding values for the same bin. This running average begins
when the fix is defined; it can only be restarted by deleting the fix
via the :doc:`unfix <unfix>` command, or by re-defining the fix by
re-specifying it.
timesteps that are multiples of :math:`N_\text{freq}` are summed and averaged
in a cumulative sense before being output. Each bin value in the histogram
is thus the average of the bin value produced on that timestep with all
preceding values for the same bin. This running average begins when the fix is
defined; it can only be restarted by deleting the fix via the
:doc:`unfix <unfix>` command, or by re-defining the fix by re-specifying it.
If the *ave* setting is *window*, then the histograms produced on
timesteps that are multiples of *Nfreq* are summed within a moving
"window" of time, so that the last M histograms are used to produce
the output. E.g. if M = 3 and Nfreq = 1000, then the output on step
10000 will be the combined histogram of the individual histograms on
steps 8000,9000,10000. Outputs on early steps will be sums over less
than M histograms if they are not available.
timesteps that are multiples of :math:`N_\text{freq}` are summed within a
moving "window" of time, so that the last :math:`M` histograms are used to
produce the output (e.g., if :math:`M = 3` and :math:`N_\text{freq} = 1000`,
then the output on step 10000 will be the combined histogram of the individual
histograms on steps 8000, 9000, and 10000. Outputs on early steps will be sums
over less than :math:`M` histograms if they are not available.
The *start* keyword specifies what timestep histogramming will begin
on. The default is step 0. Often input values can be 0.0 at time 0,
@ -321,8 +329,8 @@ The *overwrite* keyword will continuously overwrite the output file
with the latest output, so that it only contains one timestep worth of
output. This option can only be used with the *ave running* setting.
The *title1* and *title2* and *title3* keywords allow specification of
the strings that will be printed as the first 3 lines of the output
The *title1*, *title2*, and *title3* keywords allow specification of
the strings that will be printed as the first three lines of the output
file, assuming the *file* keyword was used. LAMMPS uses default
values for each of these, so they do not need to be specified.
@ -336,7 +344,7 @@ By default, these header lines are as follows:
In the first line, ID is replaced with the fix-ID. The second line
describes the six values that are printed at the first of each section
of output. The third describes the 4 values printed for each bin in
of output. The third describes the four values printed for each bin in
the histogram.
----------
@ -344,13 +352,14 @@ the histogram.
Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
No information about this fix is written to :doc:`binary restart files <restart>`. None of the :doc:`fix_modify <fix_modify>` options
are relevant to this fix.
No information about this fix is written to
:doc:`binary restart files <restart>`.
None of the :doc:`fix_modify <fix_modify>` options are relevant to this fix.
This fix produces a global vector and global array which can be
accessed by various :doc:`output commands <Howto_output>`. The values
can only be accessed on timesteps that are multiples of *Nfreq* since
that is when a histogram is generated. The global vector has 4
can only be accessed on timesteps that are multiples of :math:`N_\text{freq}`
since that is when a histogram is generated. The global vector has four
values:
* 1 = total counts in the histogram
@ -358,19 +367,20 @@ values:
* 3 = min value of all input values, including ones not histogrammed
* 4 = max value of all input values, including ones not histogrammed
The global array has # of rows = Nbins and # of columns = 3. The
The global array has :math:`N_\text{bins}` rows and three columns. The
first column has the bin coordinate, the second column has the count of
values in that histogram bin, and the third column has the bin count
divided by the total count (not including missing counts), so that the
values in the third column sum to 1.0.
The vector and array values calculated by this fix are all treated as
intensive. If this is not the case, e.g. due to histogramming
per-atom input values, then you will need to account for that when
intensive. If this is not the case (e.g., due to histogramming
per-atom input values), then you will need to account for that when
interpreting the values produced by this fix.
No parameter of this fix can be used with the *start/stop* keywords of
the :doc:`run <run>` command. This fix is not invoked during :doc:`energy minimization <minimize>`.
the :doc:`run <run>` command.
This fix is not invoked during :doc:`energy minimization <minimize>`.
Restrictions
""""""""""""
@ -379,7 +389,8 @@ Restrictions
Related commands
""""""""""""""""
:doc:`compute <compute>`, :doc:`fix ave/atom <fix_ave_atom>`, :doc:`fix ave/chunk <fix_ave_chunk>`, :doc:`fix ave/time <fix_ave_time>`,
:doc:`compute <compute>`, :doc:`fix ave/atom <fix_ave_atom>`,
:doc:`fix ave/chunk <fix_ave_chunk>`, :doc:`fix ave/time <fix_ave_time>`,
:doc:`variable <variable>`, :doc:`fix ave/correlate <fix_ave_correlate>`,
Default

130
doc/src/fix_ave_time.rst
View File

@ -6,15 +6,15 @@ fix ave/time command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
fix ID group-ID ave/time Nevery Nrepeat Nfreq value1 value2 ... keyword args ...
* ID, group-ID are documented in :doc:`fix <fix>` command
* ave/time = style name of this fix command
* Nevery = use input values every this many timesteps
* Nevery = use input values every this many time steps
* Nrepeat = # of times to use input values for calculating averages
* Nfreq = calculate averages every this many timesteps
* Nfreq = calculate averages every this many time steps
* one or more input values can be listed
* value = c_ID, c_ID[N], f_ID, f_ID[N], v_name
@ -40,7 +40,7 @@ Syntax
running = output cumulative average of all previous Nfreq steps
window M = output average of M most recent Nfreq steps
*start* args = Nstart
Nstart = start averaging on this timestep
Nstart = start averaging on this time step
*off* arg = M = do not average this value
M = value # from 1 to Nvalues
*file* arg = filename
@ -69,7 +69,7 @@ Examples
Description
"""""""""""
Use one or more global values as inputs every few timesteps, and
Use one or more global values as inputs every few time steps, and
average them over longer timescales. The resulting averages can be
used by other :doc:`output commands <Howto_output>` such as
:doc:`thermo_style custom <thermo_style>`, and can also be written to a
@ -86,9 +86,11 @@ Each listed value can be the result of a :doc:`compute <compute>` or
:doc:`variable <variable>`. In each case, the compute, fix, or variable
must produce a global quantity, not a per-atom or local quantity. If
you wish to spatial- or time-average or histogram per-atom quantities
from a compute, fix, or variable, then see the :doc:`fix ave/chunk <fix_ave_chunk>`, :doc:`fix ave/atom <fix_ave_atom>`,
from a compute, fix, or variable, then see the
:doc:`fix ave/chunk <fix_ave_chunk>`, :doc:`fix ave/atom <fix_ave_atom>`,
or :doc:`fix ave/histo <fix_ave_histo>` commands. If you wish to sum a
per-atom quantity into a single global quantity, see the :doc:`compute reduce <compute_reduce>` command.
per-atom quantity into a single global quantity, see the
:doc:`compute reduce <compute_reduce>` command.
:doc:`Computes <compute>` that produce global quantities are those which
do not have the word *atom* in their style name. Only a few
@ -100,13 +102,13 @@ be used, since they produce per-atom values.
The input values must either be all scalars or all vectors depending
on the setting of the *mode* keyword. In both cases, the averaging is
performed independently on each input value. I.e. each input scalar
performed independently on each input value (i.e., each input scalar
is averaged independently or each element of each input vector is
averaged independently.
averaged independently).
If *mode* = scalar, then the input values must be scalars, or vectors
with a bracketed term appended, indicating the Ith value of the vector
is used.
with a bracketed term appended, indicating the :math:`I^\text{th}` value of the
vector is used.
If *mode* = vector, then the input values must be vectors, or arrays
with a bracketed term appended, indicating the Ith column of the array
@ -118,17 +120,17 @@ the vector or number of rows in the array.
For input values from a compute or fix or variable, the bracketed
index I can be specified using a wildcard asterisk with the index to
effectively specify multiple values. This takes the form "\*" or
"\*n" or "n\*" or "m\*n". If N = the size of the vector (for *mode* =
"\*n" or "m\*" or "m\*n". If :math:`N` is the size of the vector (for *mode* =
scalar) or the number of columns in the array (for *mode* = vector),
then an asterisk with no numeric values means all indices from 1 to N.
A leading asterisk means all indices from 1 to n (inclusive). A
trailing asterisk means all indices from n to N (inclusive). A middle
asterisk means all indices from m to n (inclusive).
then an asterisk with no numeric values means all indices from 1 to :math:`N`.
A leading asterisk means all indices from 1 to n (inclusive). A trailing
asterisk means all indices from n to :math:`N` (inclusive). A middle asterisk
means all indices from m to n (inclusive).
Using a wildcard is the same as if the individual elements of the
vector or columns of the array had been listed one by one. E.g. these
2 fix ave/time commands are equivalent, since the :doc:`compute rdf
<compute_rdf>` command creates, in this case, a global array with 3
vector or columns of the array had been listed one by one. For example, the
following two fix ave/time commands are equivalent, since the :doc:`compute rdf
<compute_rdf>` command creates, in this case, a global array with three
columns, each of length 50:
.. code-block:: LAMMPS
@ -147,22 +149,24 @@ columns, each of length 50:
----------
The *Nevery*, *Nrepeat*, and *Nfreq* arguments specify on what
timesteps the input values will be used in order to contribute to the
average. The final averaged quantities are generated on timesteps
that are a multiple of *Nfreq*\ . The average is over *Nrepeat*
quantities, computed in the preceding portion of the simulation every
*Nevery* timesteps. *Nfreq* must be a multiple of *Nevery* and
*Nevery* must be non-zero even if *Nrepeat* is 1. Also, the timesteps
The :math:`N_\text{every}`, :math:`N_\text{repeat}`, and :math:`N_\text{freq}`
arguments specify on what time steps the input values will be used in order to
contribute to the average. The final averaged quantities are generated on
time steps that are a multiple of :math:`N_\text{freq}`\ . The average is over
:math:`N_\text{repeat}` quantities, computed in the preceding portion of the
simulation every :math:`N_\text{every}` time steps. :math:`N_\text{freq}` must
be a multiple of :math:`N_\text{every}` and :math:`N_\text{every}` must be
non-zero even if :math:`N_\text{repeat} = 1`. Also, the time steps
contributing to the average value cannot overlap,
i.e. Nrepeat\*Nevery can not exceed Nfreq.
For example, if Nevery=2, Nrepeat=6, and Nfreq=100, then values on
timesteps 90,92,94,96,98,100 will be used to compute the final average
on timestep 100. Similarly for timesteps 190,192,194,196,198,200 on
timestep 200, etc. If Nrepeat=1 and Nfreq = 100, then no time
averaging is done; values are simply generated on timesteps
100,200,etc.
For example, if :math:`N_\text{every}=2`, :math:`N_\text{repeat}=6`, and
:math:`N_\text{freq}=100`, then values on time steps 90, 92, 94, 96, 98, and
100 will be used to compute the final average on time step 100. Similarly for
time steps 190, 192, 194, 196, 198, and 200 on time step 200, etc.
If :math:`N_\text{repeat}=1` and :math:`N_\text{freq} = 100`, then no time
averaging is done; values are simply generated on time steps
100, 200, etc.
----------
@ -178,8 +182,8 @@ See the discussion above for how I can be specified with a wildcard
asterisk to effectively specify multiple values.
Note that there is a :doc:`compute reduce <compute_reduce>` command
which can sum per-atom quantities into a global scalar or vector which
can thus be accessed by fix ave/time. Or it can be a compute defined
that can sum per-atom quantities into a global scalar or vector, which
can then be accessed by fix ave/time. It can also be a compute defined
not in your input script, but by :doc:`thermodynamic output
<thermo_style>` or other fixes such as :doc:`fix nvt <fix_nh>` or
:doc:`fix temp/rescale <fix_temp_rescale>`. See the doc pages for
@ -198,7 +202,7 @@ global array calculated by the fix is used. See the discussion above
for how I can be specified with a wildcard asterisk to effectively
specify multiple values.
Note that some fixes only produce their values on certain timesteps,
Note that some fixes only produce their values on certain time steps,
which must be compatible with *Nevery*, else an error will result.
Users can also write code for their own fix styles and :doc:`add them to LAMMPS <Modify>`.
@ -228,32 +232,32 @@ vectors, or columns of global arrays. They can also be global arrays,
which are converted into a series of global vectors (one per column),
as explained above.
The *ave* keyword determines how the values produced every *Nfreq*
steps are averaged with values produced on previous steps that were
multiples of *Nfreq*, before they are accessed by another output
command or written to a file.
The *ave* keyword determines how the values produced every
:math:`N_\text{freq}` steps are averaged with values produced on previous steps
that were multiples of :math:`N_\text{freq}`, before they are accessed by
another output command or written to a file.
If the *ave* setting is *one*, then the values produced on timesteps
that are multiples of *Nfreq* are independent of each other; they are
output as-is without further averaging.
If the *ave* setting is *one*, then the values produced on time steps
that are multiples of :math:`N_\text{freq}` are independent of each other; they
are output as-is without further averaging.
If the *ave* setting is *running*, then the values produced on
timesteps that are multiples of *Nfreq* are summed and averaged in a
cumulative sense before being output. Each output value is thus the
average of the value produced on that timestep with all preceding
time steps that are multiples of :math:`N_\text{freq}` are summed and averaged
in a cumulative sense before being output. Each output value is thus the
average of the value produced on that time step with all preceding
values. This running average begins when the fix is defined; it can
only be restarted by deleting the fix via the :doc:`unfix <unfix>`
command, or by re-defining the fix by re-specifying it.
If the *ave* setting is *window*, then the values produced on
timesteps that are multiples of *Nfreq* are summed and averaged within
time steps that are multiples of *Nfreq* are summed and averaged within
a moving "window" of time, so that the last M values are used to
produce the output. E.g. if M = 3 and Nfreq = 1000, then the output
on step 10000 will be the average of the individual values on steps
8000,9000,10000. Outputs on early steps will average over less than M
values if they are not available.
produce the output. For example, if :math:`M = 3` and
:math:`N_\text{freq} = 1000`, then the output on step 10000 will be the average
of the individual values on steps 8000, 9000, and 10000. Outputs on early
steps will average over less than :math:`M` values if they are not available.
The *start* keyword specifies what timestep averaging will begin on.
The *start* keyword specifies what time step averaging will begin on.
The default is step 0. Often input values can be 0.0 at time 0, so
setting *start* to a larger value can avoid including a 0.0 in a
running or windowed average.
@ -262,9 +266,9 @@ The *off* keyword can be used to flag any of the input values. If a
value is flagged, it will not be time averaged. Instead the most
recent input value will always be stored and output. This is useful
if one of more of the inputs produced by a compute or fix or variable
are effectively constant or are simply current values. E.g. they are
are effectively constant or are simply current values (e.g., they are
being written to a file with other time-averaged values for purposes
of creating well-formatted output.
of creating well-formatted output).
The *file* keyword allows a filename to be specified. Every *Nfreq*
steps, one quantity or vector of quantities is written to the file for
@ -288,13 +292,13 @@ effort in Python using the *pyyaml*, *pandas*, and *matplotlib*
packages.
The *overwrite* keyword will continuously overwrite the output file
with the latest output, so that it only contains one timestep worth of
with the latest output, so that it only contains one time step worth of
output. This option can only be used with the *ave running* setting.
The *format* keyword sets the numeric format of each value when it is
printed to a file via the *file* keyword. Note that all values are
floating point quantities. The default format is %g. You can specify
a higher precision if desired, e.g. %20.16g.
a higher precision if desired (e.g., %20.16g).
The *title1* and *title2* and *title3* keywords allow specification of
the strings that will be printed as the first 2 or 3 lines of the
@ -340,8 +344,8 @@ a YAML format file this name will be in the list of keywords.
This fix produces a global scalar or global vector or global array
which can be accessed by various :doc:`output commands <Howto_output>`.
The values can only be accessed on timesteps that are multiples of
*Nfreq* since that is when averaging is performed.
The values can only be accessed on time steps that are multiples of
:math:`N_\text{freq}` since that is when averaging is performed.
A scalar is produced if only a single input value is averaged and
*mode* = scalar. A vector is produced if multiple input values are
@ -354,17 +358,18 @@ of rows = length of the input vectors and # of columns = number of
inputs.
If the fix produces a scalar or vector, then the scalar and each
element of the vector can be either "intensive" or "extensive",
element of the vector can be either "intensive" or "extensive,"
depending on whether the values contributing to the scalar or vector
element are "intensive" or "extensive". If the fix produces an array,
element are "intensive" or "extensive." If the fix produces an array,
then all elements in the array must be the same, either "intensive" or
"extensive". If a compute or fix provides the value being time
"extensive." If a compute or fix provides the value being time
averaged, then the compute or fix determines whether the value is
intensive or extensive; see the page for that compute or fix for
further info. Values produced by a variable are treated as intensive.
No parameter of this fix can be used with the *start/stop* keywords of
the :doc:`run <run>` command. This fix is not invoked during :doc:`energy minimization <minimize>`.
the :doc:`run <run>` command. This fix is not invoked during
:doc:`energy minimization <minimize>`.
Restrictions
""""""""""""
@ -373,7 +378,8 @@ Restrictions
Related commands
""""""""""""""""
:doc:`compute <compute>`, :doc:`fix ave/atom <fix_ave_atom>`, :doc:`fix ave/chunk <fix_ave_chunk>`, :doc:`fix ave/histo <fix_ave_histo>`,
:doc:`compute <compute>`, :doc:`fix ave/atom <fix_ave_atom>`,
:doc:`fix ave/chunk <fix_ave_chunk>`, :doc:`fix ave/histo <fix_ave_histo>`,
:doc:`variable <variable>`, :doc:`fix ave/correlate <fix_ave_correlate>`,
Default

18
doc/src/fix_aveforce.rst
View File

@ -6,7 +6,7 @@ fix aveforce command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
fix ID group-ID aveforce fx fy fz keyword value ...
@ -48,13 +48,13 @@ component. The actual force on each atom is then set to the average
value plus the component specified in this command. This means each
atom in the group receives the same force.
Any of the fx,fy,fz values can be specified as NULL which means the
force in that dimension is not changed. Note that this is not the
Any of the *fx*, *fy*, or *fz* values can be specified as :code:`NULL`, which
means the force in that dimension is not changed. Note that this is not the
same as specifying a 0.0 value, since that sets all forces to the same
average value without adding in any additional force.
Any of the 3 quantities defining the force components can be specified
as an equal-style :doc:`variable <variable>`, namely *fx*, *fy*, *fz*\ .
Any of the three quantities defining the force components, namely *fx*, *fy*,
and *fz*, can be specified as an equal-style :doc:`variable <variable>`\ .
If the value is a variable, it should be specified as v_name, where
name is the variable name. In this case, the variable will be
evaluated each timestep, and its value used to determine the average
@ -78,17 +78,17 @@ to it.
Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
No information about this fix is written to :doc:`binary restart files <restart>`.
No information about this fix is written to
:doc:`binary restart files <restart>`.
The :doc:`fix_modify <fix_modify>` *respa* option is supported by this
fix. This allows to set at which level of the :doc:`r-RESPA <run_style>`
integrator the fix is adding its forces. Default is the outermost level.
This fix computes a global 3-vector of forces, which can be accessed
This fix computes a global three-vector of forces, which can be accessed
by various :doc:`output commands <Howto_output>`. This is the total
force on the group of atoms before the forces on individual atoms are
changed by the fix. The vector values calculated by this fix are
"extensive".
changed by the fix. The vector values calculated by this fix are "extensive".
No parameter of this fix can be used with the *start/stop* keywords of
the :doc:`run <run>` command.

119
doc/src/fix_balance.rst
View File

@ -6,7 +6,7 @@ fix balance command
Syntax
""""""
.. parsed-literal::
.. code-block:: LAMMPS
fix ID group-ID balance Nfreq thresh style args keyword args ...
@ -19,7 +19,7 @@ Syntax
.. parsed-literal::
shift args = dimstr Niter stopthresh
dimstr = sequence of letters containing "x" or "y" or "z", each not more than once
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 threshold is reached
*rcb* args = none
@ -72,10 +72,10 @@ perform "static" balancing, before or between runs, see the
Load-balancing is typically most useful if the particles in the
simulation box have a spatially-varying density distribution or
where the computational cost varies significantly between different
atoms. E.g. a model of a vapor/liquid interface, or a solid with
atoms (e.g., a model of a vapor/liquid interface, or a solid with
an irregular-shaped geometry containing void regions, or
:doc:`hybrid pair style simulations <pair_hybrid>` which combine
pair styles with different computational cost. In these cases, the
:doc:`hybrid pair style simulations <pair_hybrid>` that combine
pair styles with different computational cost). In these cases, 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 numbers of particles per processor in a
@ -92,28 +92,30 @@ processor.
.. note::
The weighting options listed above are documented with the
:doc:`balance <balance>` command in :ref:`this section of the balance command <weighted_balance>` doc page. That section
:doc:`balance <balance>` command in :ref:`this section of the balance
command <weighted_balance>` doc page. That section
describes the various weighting options and gives a few examples of
how they can be used. The weighting options are the same for both the
fix balance and :doc:`balance <balance>` commands.
Note that the :doc:`processors <processors>` 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
a :math:`P_x \times P_y \times P_z` grid of processors, it allows choices of
:math:`P_x`, :math:`P_y`, and :math:`P_z` subject to the constraint that
:math:`P_x P_y P_z = 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.
sub-domains will still have the same shape and the same volume.
On a particular timestep, a load-balancing operation is only performed
On a particular time step, a load-balancing operation is only performed
if the current "imbalance factor" in particles owned by each processor
exceeds the specified *thresh* parameter. The imbalance factor is
defined as the maximum number of particles (or weight) owned by any
processor, divided by the average number of particles (or weight) per
processor. Thus an imbalance factor of 1.0 is perfect balance.
processor. Thus, an imbalance factor of 1.0 is perfect balance.
As an example, for 10000 particles running on 10 processors, if the
most heavily loaded processor has 1200 particles, then the factor is
most heavily loaded processor has 1200 particles, then the imbalance 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
*thresh* < 1.0.
@ -125,28 +127,29 @@ forced even if the current balance is perfect (1.0) be specifying a
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 :doc:`create_atoms <create_atoms>` 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.
system is a perfect, non-rotated lattice (e.g., the initial system is
generated by the :doc:`create_atoms <create_atoms>` command with no
rotations), 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.
.. note::
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
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
:doc:`kspace_style <kspace_style>` command. Thus you should benchmark
and communication overheads (e.g., in the PPPM solver used via the
:doc:`kspace_style <kspace_style>` command). Thus, you should benchmark
the run times of a simulation before and after balancing.
----------
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
listed styles, which are described in detail below. There are two kinds
of styles.
The *shift* style is a "grid" method which produces a logical 3d grid
@ -198,11 +201,12 @@ The *group-ID* is ignored. However the impact of balancing on
different groups of atoms can be affected by using the *group* weight
style as described below.
The *Nfreq* setting determines how often a re-balance is performed. If
*Nfreq* > 0, then re-balancing will occur every *Nfreq* steps. Each
time a re-balance occurs, a reneighboring is triggered, so *Nfreq*
should not be too small. If *Nfreq* = 0, then re-balancing will be
done every time reneighboring normally occurs, as determined by the
The :math:`N_\text{freq}` setting determines how often a re-balance is
performed. If :math:`N_\text{freq} > 0`, then re-balancing will occur every
:math:`N_\text{freq}` steps. Each time a re-balance occurs, a reneighboring is
triggered, so :math:`N_\text{freq}` should not be too small. If
:math:`N_\text{freq} = 0`, then re-balancing will be done every time
reneighboring normally occurs, as determined by the
the :doc:`neighbor <neighbor>` and :doc:`neigh_modify <neigh_modify>`
command settings.
@ -216,7 +220,7 @@ above. It changes the positions of cutting planes between processors
in an iterative fashion, seeking to reduce the imbalance factor.
The *dimstr* argument is a string of characters, each of which must be
an "x" or "y" or "z". Each character can appear zero or one time,
*x* or *y* or *z*. Each 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.
@ -224,8 +228,8 @@ to be a density variation in the particles.
Balancing proceeds by adjusting the cutting planes in each of the
dimensions listed in *dimstr*, one dimension at a time. For a single
dimension, the balancing operation (described below) is iterated on up
to *Niter* times. After each dimension finishes, the imbalance factor
is re-computed, and the balancing operation halts if the *stopthresh*
to :math:`N_\text{iter}` times. After each dimension finishes, the imbalance
factor is re-computed, and the balancing operation halts if the *stopthresh*
criterion is met.
A re-balance operation in a single dimension is performed using a
@ -265,15 +269,15 @@ the normal reneighboring procedure.
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 *Niter* 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 *Niter* = 20, it will
be accurate to better than 1 part in a million. Thus there is no need
to set *Niter* to a large value. This is especially true if you are
re-balancing often enough that each time you expect only an incremental
adjustment in the cutting planes is necessary. LAMMPS will check if
the threshold accuracy is reached (in a dimension) is less iterations
than *Niter* and exit early.
iteration. Thus if :math:`N_\text{iter}` 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 :math:`N_\text{iter} = 20`,
it will be accurate to better than 1 part in a million. Thus there is no
need to set :math:`N_\text{iter}` to a large value. This is especially true
if you are re-balancing often enough that each time you expect only an
incremental adjustment in the cutting planes is necessary. LAMMPS will
check if the threshold accuracy is reached (in a dimension) is less
iterations than :math:`N_\text{iter}` and exit early.
----------
@ -281,12 +285,12 @@ The *rcb* 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.
The simulation domain is cut into 2 boxes by an axis-aligned cut in
The simulation domain is cut into two 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
All the processors are also partitioned into two 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
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
@ -309,7 +313,7 @@ results of each re-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 shown here for a balancing by 4
visualizing mesh files. An example is shown here for a balancing by four
processors for a 2d problem:
.. parsed-literal::
@ -349,27 +353,28 @@ processors for a 2d problem:
3 1 9 10 11 12
4 1 13 14 15 16
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
The coordinates of all the vertices are listed in the NODES section, five
per processor. Note that the four sub-domains share vertices, so there
will be duplicate nodes in the list.
The "SQUARES" section lists the node IDs of the 4 vertices in a
The "SQUARES" section lists the node IDs of the four vertices in a
rectangle for each processor (1 to 4).
For a 3d problem, the syntax is similar with 8 vertices listed for
each processor, instead of 4, and "SQUARES" replaced by "CUBES".
For a 3d problem, the syntax is similar but with eight vertices listed for
each processor instead of four, and "SQUARES" replaced by "CUBES."
----------
Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
No information about this fix is written to :doc:`binary restart files <restart>`. None of the :doc:`fix_modify <fix_modify>` options
are relevant to this fix.
No information about this fix is written to
:doc:`binary restart files <restart>`. None of the
:doc:`fix_modify <fix_modify>` options are relevant to this fix.
This fix computes a global scalar which is the imbalance factor
after the most recent re-balance and a global vector of length 3 with
additional information about the most recent re-balancing. The 3
additional information about the most recent re-balancing. The three
values in the vector are as follows:
* 1 = max # of particles per processor
@ -380,22 +385,24 @@ As explained above, the imbalance factor is the ratio of the maximum
number of particles (or total weight) on any processor to the average
number of particles (or total weight) per processor.
These quantities can be accessed by various :doc:`output commands <Howto_output>`. The scalar and vector values calculated
by this fix are "intensive".
These quantities can be accessed by various
:doc:`output commands <Howto_output>`. The scalar and vector values calculated
by this fix are "intensive."
No parameter of this fix can be used with the *start/stop* keywords of
the :doc:`run <run>` command. This fix is not invoked during :doc:`energy minimization <minimize>`.
the :doc:`run <run>` command. This fix is not invoked during
:doc:`energy minimization <minimize>`.
----------
Restrictions
""""""""""""
For 2d simulations, the *z* style cannot be used. Nor can a "z"
For 2d simulations, the *z* style cannot be used, nor can *z*
appear in *dimstr* for the *shift* style.
Balancing through recursive bisectioning (\ *rcb* style) requires
:doc:`comm_style tiled <comm_style>`
:doc:`comm_style tiled <comm_style>`\ .
Related commands
""""""""""""""""

2
doc/src/pair_mesocnt.rst
View File

@ -92,7 +92,7 @@ segments. Friction forces are a function of the relative velocity
between a segment and its neighboring approximate chain (even in
*segment* mode) and only act along the axes of the interacting segment
and chain. In this potential, friction forces acting per unit length
of a nanotube segent are modelled as a shifted logistic function:
of a nanotube segment are modelled as a shifted logistic function:
.. math::