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

Merge branch 'lammps:develop' into cg-dna

Browse Source
This commit is contained in:
Oliver Henrich
2024-04-05 11:40:16 +01:00
committed by GitHub
parent b5d769bbbf 2927471892
commit dc1bc8a8cf
83 changed files with 2090 additions and 2325 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
doc/src/Developer_utils.rst
View File

@ -635,10 +635,10 @@ Tohoku University (under MIT license)
----------
.. doxygenfunction:: MathEigen::jacobi3(double const *const *mat, double *eval, double **evec)
.. doxygenfunction:: MathEigen::jacobi3(double const *const *mat, double *eval, double **evec, int sort)
:project: progguide
.. doxygenfunction:: MathEigen::jacobi3(double const mat[3][3], double *eval, double evec[3][3])
.. doxygenfunction:: MathEigen::jacobi3(double const mat[3][3], double *eval, double evec[3][3], int sort)
:project: progguide
---------------------------

49
doc/src/Errors_details.rst
View File

@ -13,15 +13,44 @@ discussions of such cases.
Unknown identifier in data file
-------------------------------
This error happens when LAMMPS encounters a line of text in an unexpected format
while reading a data file. This is most commonly cause by inconsistent header and
section data. The header section informs LAMMPS how many entries or lines are expected in the
various sections (like Atoms, Masses, Pair Coeffs, *etc.*\ ) of the data file.
If there is a mismatch, LAMMPS will either keep reading beyond the end of a section
or stop reading before the section has ended.
This error happens when LAMMPS encounters a line of text with an
unexpected keyword while :doc:`reading a data file <read_data>`. This
would be either header keywords or section header keywords. This is
most commonly due to a mistyped keyword or due to a keyword that is
inconsistent with the :doc:`atom style <atom_style>` used.
Such a mismatch can happen unexpectedly when the first line of the data
is *not* a comment as required by the format. That would result in
LAMMPS expecting, for instance, 0 atoms because the "atoms" header line
is treated as a comment.
The header section informs LAMMPS how many entries or lines are expected
in the various sections (like Atoms, Masses, Pair Coeffs, *etc.*\ ) of
the data file. If there is a mismatch, LAMMPS will either keep reading
beyond the end of a section or stop reading before the section has
ended. In that case the next line will not contain a recognized keyword.
Such a mismatch can also happen when the first line of the data
is *not* a comment as required by the format, but a line with a valid
header keyword. That would result in LAMMPS expecting, for instance,
0 atoms because the "atoms" header line is the first line and thus
treated as a comment.
Another possibility to trigger this error is to have a keyword in the
data file that corresponds to a fix (e.g. :doc:`fix cmap <fix_cmap>`)
but the :doc:`read_data <read_data>` command is missing the (optional)
arguments that identify the fix and the header keyword and section
keyword or those arguments are inconsistent with the keywords in the
data file.
.. _err0002:
Incorrect format in ... section of data file
--------------------------------------------
This error happens when LAMMPS reads the contents of a section of a
:doc:`data file <read_data>` and the number of parameters in the line
differs from what is expected. This most commonly happens, when the
atom style is different from what is expected for a specific data file
since changing the atom style usually changes the format of the line.
This error can also happen when the number of entries indicated in the
header of a data file (e.g. the number of atoms) is larger than the
number of lines provided (e.g. in the corresponding Atoms section)
and then LAMMPS will continue reading into the next section and that
would have a completely different format.

4
doc/src/Fortran.rst
View File

@ -1255,8 +1255,8 @@ Procedures Bound to the :f:type:`lammps` Derived Type
three elements of the global vector calculated by fix recenter into the
variables *dx*, *dy*, and *dz*, respectively.
If asked for per-atom or local data, :f:func:`extract_compute` returns a
pointer to actual LAMMPS data. The pointer so returned will have the
If asked for per-atom or local data, :f:func:`extract_fix` returns a
pointer to actual LAMMPS data. The pointer returned will have the
appropriate size to match the internal data, and will be
type/kind/rank-checked at the time of the assignment. For example,

28
doc/src/fix_ave_chunk.rst
View File

@ -31,7 +31,7 @@ Syntax
v_name = per-atom vector calculated by an atom-style variable with name
* zero or more keyword/arg pairs may be appended
* keyword = *norm* or *ave* or *bias* or *adof* or *cdof* or *file* or *overwrite* or *format* or *title1* or *title2* or *title3*
* keyword = *norm* or *ave* or *bias* or *adof* or *cdof* or *file* or *append* or *overwrite* or *format* or *title1* or *title2* or *title3*
.. parsed-literal::
@ -51,6 +51,8 @@ Syntax
dof_per_chunk = define this many degrees-of-freedom per chunk for temperature calculation
*file* arg = filename
filename = file to write results to
*append* arg = filename
filename = file to append results to
*overwrite* arg = none = overwrite output file with only latest output
*format* arg = string
string = C-style format string
@ -433,15 +435,21 @@ molecule.
----------
The *file* keyword allows a filename to be specified. Every
:math:`N_\text{freq}` timesteps, a section of chunk info will be written to a
text file in the following format. A line with the timestep and number of
chunks is written. Then one line per chunk is written, containing the chunk
ID :math:`(1-N_\text{chunk}),` an optional original ID value, optional
coordinate values for chunks that represent spatial bins, the number of atoms
in the chunk, and one or more calculated values. More explanation of the
optional values is given below. The number of values in each line
corresponds to the number of values specified in the fix ave/chunk
.. versionadded:: TBD
new keyword *append*
The *file* or *append* keywords allow a filename to be specified. If
*file* is used, then the filename is overwritten if it already exists.
If *append* is used, then the filename is appended to if it already
exists, or created if it does not exist. Every :math:`N_\text{freq}`
timesteps, a section of chunk info will be written to a text file in the
following format. A line with the timestep and number of chunks is
written. Then one line per chunk is written, containing the chunk ID
:math:`(1-N_\text{chunk}),` an optional original ID value, optional
coordinate values for chunks that represent spatial bins, the number of
atoms in the chunk, and one or more calculated values. More explanation
of the optional values is given below. The number of values in each
line corresponds to the number of values specified in the fix ave/chunk
command. The number of atoms and the value(s) are summed or average
quantities, as explained above.

1
doc/src/fix_ave_correlate.rst
View File

@ -65,7 +65,6 @@ Examples
fix 1 all ave/correlate 1 50 10000 &
c_thermo_press[1] c_thermo_press[2] c_thermo_press[3] &
type upper ave running title1 "My correlation data"
fix 1 all ave/correlate 1 50 10000 c_thermo_press[*]
Description

13
doc/src/fix_ave_correlate_long.rst
View File

@ -20,11 +20,11 @@ Syntax
.. parsed-literal::
c_ID = global scalar calculated by a compute with ID
c_ID[I] = Ith component of global vector calculated by a compute with ID
c_ID[I] = Ith component of global vector calculated by a compute with ID, I can include wildcard (see below)
f_ID = global scalar calculated by a fix with ID
f_ID[I] = Ith component of global vector calculated by a fix with ID
f_ID[I] = Ith component of global vector calculated by a fix with ID, I can include wildcard (see below)
v_name = global value calculated by an equal-style variable with name
v_name[I] = Ith component of global vector calculated by a vector-style variable with name
v_name[I] = Ith component of a vector-style variable with name, I can include wildcard (see below)
* zero or more keyword/arg pairs may be appended
* keyword = *type* or *start* or *file* or *overwrite* or *title1* or *title2* or *ncorr* or *nlen* or *ncount*
@ -63,6 +63,7 @@ Examples
fix 1 all ave/correlate/long 1 10000 &
c_thermo_press[1] c_thermo_press[2] c_thermo_press[3] &
type upper title1 "My correlation data" nlen 15 ncount 3
fix 1 all ave/correlate/long 1 10000 c_thermo_press[*]
Description
"""""""""""
@ -80,8 +81,10 @@ 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 or vector-style variable. For
vector-style variables, the specified indices can include a wildcard
character. See the :doc:`fix ave/correlate <fix_ave_correlate>` page
for details.
The *Nevery* and *Nfreq* arguments specify on what time steps the input
values will be used to calculate correlation data and the frequency

36
doc/src/fix_ave_histo.rst
View File

@ -35,7 +35,7 @@ Syntax
v_name[I] = value calculated by a vector-style variable with name, I can include wildcard (see below)
* zero or more keyword/arg pairs may be appended
* keyword = *mode* or *kind* or *file* or *ave* or *start* or *beyond* or *overwrite* or *title1* or *title2* or *title3*
* keyword = *mode* or *kind* or *file* or *append* or *ave* or *start* or *beyond* or *overwrite* or *title1* or *title2* or *title3*
.. parsed-literal::
@ -45,6 +45,8 @@ Syntax
*kind* arg = *global* or *peratom* or *local*
*file* arg = filename
filename = name of file to output histogram(s) to
*append* arg = filename
filename = name of file to append histogram(s) to
*ave* args = *one* or *running* or *window*
one = output a new average value every Nfreq steps
running = output cumulative average of all previous Nfreq steps
@ -317,19 +319,25 @@ 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 histogram.
The *file* keyword allows a filename to be specified. Every *Nfreq*
steps, one histogram is written to the file. This includes a leading
line that contains the timestep, number of bins, the total count of
values contributing to the histogram, the count of values that were
not histogrammed (see the *beyond* keyword), the minimum value
encountered, and the maximum value encountered. The min/max values
include values that were not histogrammed. Following the leading
line, one line per bin is written into the file. Each line contains
the bin #, the coordinate for the center of the bin (between *lo* and
*hi*\ ), the count of values in the bin, and the normalized count. The
normalized count is the bin count divided by the total count (not
including values not histogrammed), so that the normalized values sum
to 1.0 across all bins.
.. versionadded:: TBD
new keyword *append*
The *file* or *append* keywords allow a filename to be specified. If
*file* is used, then the filename is overwritten if it already exists.
If *append* is used, then the filename is appended to if it already
exists, or created if it does not exist. Every *Nfreq* steps, one
histogram is written to the file. This includes a leading line that
contains the timestep, number of bins, the total count of values
contributing to the histogram, the count of values that were not
histogrammed (see the *beyond* keyword), the minimum value encountered,
and the maximum value encountered. The min/max values include values
that were not histogrammed. Following the leading line, one line per
bin is written into the file. Each line contains the bin #, the
coordinate for the center of the bin (between *lo* and *hi*\ ), the
count of values in the bin, and the normalized count. The normalized
count is the bin count divided by the total count (not including values
not histogrammed), so that the normalized values sum to 1.0 across all
bins.
The *overwrite* keyword will continuously overwrite the output file
with the latest output, so that it only contains one timestep worth of

29
doc/src/fix_ave_time.rst
View File

@ -28,7 +28,7 @@ Syntax
v_name[I] = value calculated by a vector-style variable with name, I can include wildcard (see below)
* zero or more keyword/arg pairs may be appended
* keyword = *mode* or *file* or *ave* or *start* or *off* or *overwrite* or *format* or *title1* or *title2* or *title3*
* keyword = *mode* or *file* or *append* or *ave* or *start* or *off* or *overwrite* or *format* or *title1* or *title2* or *title3*
.. parsed-literal::
@ -45,6 +45,8 @@ Syntax
M = value # from 1 to Nvalues
*file* arg = filename
filename = name of file to output time averages to
*append* arg = filename
filename = name of file to append time averages to
*overwrite* arg = none = overwrite output file with only latest output
*format* arg = string
string = C-style format string
@ -270,16 +272,21 @@ 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).
The *file* keyword allows a filename to be specified. Every *Nfreq*
steps, one quantity or vector of quantities is written to the file for
each input value specified in the fix ave/time command. For *mode* =
scalar, this means a single line is written each time output is
performed. Thus the file ends up to be a series of lines, i.e. one
column of numbers for each input value. For *mode* = vector, an array
of numbers is written each time output is performed. The number of rows
is the length of the input vectors, and the number of columns is the
number of values. Thus the file ends up to be a series of these array
sections.
.. versionadded:: TBD
new keyword *append*
The *file* or *append* keywords allow a filename to be specified. If
*file* is used, then the filename is overwritten if it already exists.
If *append* is used, then the filename is appended to if it already
exists, or created if it does not exist. Every *Nfreq* steps, one
quantity or vector of quantities is written to the file for each input
value specified in the fix ave/time command. For *mode* = scalar, this
means a single line is written each time output is performed. Thus the
file ends up to be a series of lines, i.e. one column of numbers for
each input value. For *mode* = vector, an array of numbers is written
each time output is performed. The number of rows is the length of the
input vectors, and the number of columns is the number of values. Thus
the file ends up to be a series of these array sections.
.. versionadded:: 4May2022

29
doc/src/fix_electrode.rst
View File

@ -255,23 +255,24 @@ and the fix will issue an error in that case.
.. versionadded:: TBD
The keyword *qtotal* causes *fix electrode/conp* and *fix electrode/thermo*
to add an overall potential to all electrodes so that the total charge on
the electrodes is a specified amount (which may be an equal-style variable).
For example, if a user wanted to simulate a solution of excess cations
such that the total electrolyte charge is +2, setting *qtotal -2* would cause
the total electrode charge to be -2, so that the simulation box remains overall
electroneutral. Since *fix electrode/conq* constrains the total charges of
individual electrodes, and since *symm on* constrains the total charge of all
electrodes to be zero, either option is incompatible with the *qtotal* keyword
(even if *qtotal* is set to zero).
The keyword *qtotal* causes *fix electrode/conp* and *fix
electrode/thermo* to add an overall potential to all electrodes so that
the total charge on the electrodes is a specified amount (which may be
an equal-style variable). For example, if a user wanted to simulate a
solution of excess cations such that the total electrolyte charge is +2,
setting *qtotal -2* would cause the total electrode charge to be -2, so
that the simulation box remains overall electroneutral. Since *fix
electrode/conq* constrains the total charges of individual electrodes,
and since *symm on* constrains the total charge of all electrodes to be
zero, either option is incompatible with the *qtotal* keyword (even if
*qtotal* is set to zero).
.. versionadded:: TBD
The keyword *eta* takes the name of a custom double vector defined via fix
property/atom. The values will be used instead of the standard eta value. The
property/atom fix must be for vector of double values and use the *ghost on*
option.
The keyword *eta* takes the name of a custom double vector defined via
fix property/atom. The values will be used instead of the standard eta
value. The property/atom fix must be for vector of double values and
use the *ghost on* option.
Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

75
doc/src/fix_ttm.rst
View File

@ -136,23 +136,23 @@ transfer between the subsystems:
\bigtriangledown (\kappa_e \bigtriangledown T_e) -
g_p (T_e - T_a) + g_s T_a'
where C_e is the specific heat, rho_e is the density, kappa_e is the
thermal conductivity, T is temperature, the "e" and "a" subscripts
represent electronic and atomic subsystems respectively, g_p is the
coupling constant for the electron-ion interaction, and g_s is the
electron stopping coupling parameter. C_e, rho_e, and kappa_e are
specified as parameters to the fix. The other quantities are derived.
The form of the heat diffusion equation used here is almost the same
as that in equation 6 of :ref:`(Duffy) <Duffy>`, with the exception that the
electronic density is explicitly represented, rather than being part
of the specific heat parameter.
where :math:`C_e` is the specific heat, :math:`\rho_e` is the density,
:math:`\kappa_e` is the thermal conductivity, *T* is temperature, the
"e" and "a" subscripts represent electronic and atomic subsystems
respectively, :math:`g_p` is the coupling constant for the electron-ion
interaction, and :math:`g_s` is the electron stopping coupling
parameter. :math:`C_e`, :math:`\rho_e`, and :math:`\kappa_e` are
specified as parameters to the fix *ttm* or *ttm/grid*. The other
quantities are derived. The form of the heat diffusion equation used
here is almost the same as that in equation 6 of :ref:`(Duffy) <Duffy>`,
with the exception that the electronic density is explicitly
represented, rather than being part of the specific heat parameter.
Currently, the TTM fixes assume that none of the user-supplied
parameters will vary with temperature. Note that :ref:`(Duffy)
<Duffy>` used a tanh() functional form for the temperature dependence
of the electronic specific heat, but ignored temperature dependencies
of any of the other parameters. See more discussion below for fix
ttm/mod.
parameters will vary with temperature. Note that :ref:`(Duffy) <Duffy>`
used a tanh() functional form for the temperature dependence of the
electronic specific heat, but ignored temperature dependencies of any of
the other parameters. See more discussion below for fix *ttm/mod*.
.. note::
@ -265,27 +265,27 @@ heat sources (e.g. laser heating in ablation simulations):
\bigtriangledown (\kappa_e \bigtriangledown T_e) -
g_p (T_e - T_a) + g_s T_a' + \theta (x-x_{surface})I_0 \exp(-x/l_{skin})
where theta is the Heaviside step function, I_0 is the (absorbed)
laser pulse intensity for ablation simulations, l_skin is the depth
of skin-layer, and all other designations have the same meaning as in
the former equation. The duration of the pulse is set by the parameter
*tau* in the *init_file*.
where :math:`\theta` is the Heaviside step function, :math:`I_0` is the
(absorbed) laser pulse intensity for ablation simulations,
:math:`l_{skin}` is the depth of the skin-layer, and all other
designations have the same meaning as in the former equation. The
duration of the pulse is set by the parameter *tau* in the *init_file*.
Fix ttm/mod also allows users to specify the dependencies of C_e and
kappa_e on the electronic temperature. The specific heat is expressed
as
Fix *ttm/mod* also allows users to specify the dependencies of
:math:`C_e` and :math:`\kappa_e` on the electronic temperature. The
specific heat is expressed as
.. math::
C_e = C_0 + (a_0 + a_1 X + a_2 X^2 + a_3 X^3 + a_4 X^4) \exp (-(AX)^2)
where *X* = T_e/1000, and the thermal conductivity is defined as
kappa_e = D_e\*rho_e\*C_e, where D_e is the thermal diffusion
coefficient.
where :math:`X = \frac{T_e}{1000}`, and the thermal conductivity is
defined as :math:`\kappa_e = D_e \cdot rho_e \cdot C_e`, where
:math:`D_e` is the thermal diffusion coefficient.
Electronic pressure effects are included in the TTM model to account
for the blast force acting on ions because of electronic pressure
gradient (see :ref:`(Chen) <Chen>`, :ref:`(Norman) <Norman>`). The total force
Electronic pressure effects are included in the TTM model to account for
the blast force acting on ions because of electronic pressure gradient
(see :ref:`(Chen) <Chen>`, :ref:`(Norman) <Norman>`). The total force
acting on an ion is:
.. math::
@ -293,13 +293,14 @@ acting on an ion is:
{\vec F}_i = - \partial U / \partial {\vec r}_i + {\vec
F}_{langevin} - \nabla P_e/n_{ion}
where F_langevin is a force from Langevin thermostat simulating
electron-phonon coupling, and nabla P_e/n_ion is the electron blast
force.
where :math:`F_{langevin}` is a force from Langevin thermostat
simulating electron-phonon coupling, and :math:`\nabla P_e/n_{ion}` is
the electron blast force.
The electronic pressure is taken to be P_e = B\*rho_e\*C_e\*T_e
The electronic pressure is taken to be :math:`P_e = B \cdot rho_e \cdot
C_e \cdot T_e`
The current fix ttm/mod implementation allows TTM simulations with a
The current fix *ttm/mod* implementation allows TTM simulations with a
vacuum. The vacuum region is defined as the grid cells with zero
electronic temperature. The numerical scheme does not allow energy
exchange with such cells. Since the material can expand to previously
@ -319,10 +320,10 @@ electronic pressure gradient is calculated as
\frac{x}{x+\lambda}\frac{(C_e{}T_e)_{x+\Delta
x}-(C_e{}T_e)_{x}}{\Delta x} \right]
where lambda is the electron mean free path (see :ref:`(Norman) <Norman>`,
:ref:`(Pisarev) <Pisarev>`)
where :math:`\lambda` is the electron mean free path (see :ref:`(Norman)
<Norman>`, :ref:`(Pisarev) <Pisarev>`)
The fix ttm/mod parameter file *init_file* has the following syntax.
The fix *ttm/mod* parameter file *init_file* has the following syntax.
Every line with an odd number is considered as a comment and
ignored. The lines with the even numbers are treated as follows:

26
doc/src/processors.rst
View File

@ -159,17 +159,17 @@ surface-to-volume ratio of each processor's subdomain.
for most MPI implementations, but some MPIs provide options for this
ordering, e.g. via environment variable settings.
The *numa* style operates similar to the *twolevel* keyword except
that it auto-detects which cores are running on which nodes.
It will also subdivide the cores into numa domains. Currently, the
number of numa domains is not autodetected and must be specified using
the *numa_nodes* keyword; otherwise, the default value is used. The
*numa* style uses a different algorithm than the *twolevel* keyword for
doing the two-level factorization of the simulation box into a 3d
processor grid to minimize off-node communication and communication
across numa domains. It does its own MPI-based mapping of nodes and
cores to the regular 3d grid. Thus it may produce a different layout
of the processors than the *twolevel* options.
The *numa* style operates similar to the *twolevel* keyword except that
it auto-detects which cores are running on which nodes. It will also
subdivide the cores into numa domains. Currently, the number of numa
domains is not auto-detected and must be specified using the
*numa_nodes* keyword; otherwise, the default value is used. The *numa*
style uses a different algorithm than the *twolevel* keyword for doing
the two-level factorization of the simulation box into a 3d processor
grid to minimize off-node communication and communication across numa
domains. It does its own MPI-based mapping of nodes and cores to the
regular 3d grid. Thus it may produce a different layout of the
processors than the *twolevel* options.
The *numa* style will give an error if the number of MPI processes is
not divisible by the number of cores used per node, or any of the Px
@ -182,7 +182,7 @@ or Py or Pz values is greater than 1.
is because it auto-detects which processes are running on which nodes.
However, it assumes that the lowest ranks are in the first numa
domain, and so forth. MPI rank orderings that do not preserve this
property might result in more intranode communication between CPUs.
property might result in more intra-node communication between CPUs.
The *custom* style uses the file *infile* to define both the 3d
factorization and the mapping of processors to the grid.
@ -213,7 +213,7 @@ any order, but no processor ID should appear more than once.
----------
The *numa_nodes* keyword is used to specifiy the number of numa domains
The *numa_nodes* keyword is used to specify the number of numa domains
per node. It is currently only used by the *numa* style for two-level
factorization to reduce the amount of MPI communications between CPUs.
A good setting for this will typically be equal to the number of CPU

31
doc/src/variable.rst
View File

@ -1174,12 +1174,17 @@ custom atom properties are the same; just replace the leading "i" with
+--------+---------------+------------------------------------------+
| equal | i_name[I] | element of per-atom vector (I = atom ID) |
+--------+---------------+------------------------------------------+
| equal | i2_name[I][J] | element of per-atom array (I = atom ID) |
+--------+---------------+------------------------------------------+
+--------+---------------+------------------------------------------+
| vector | i_name[I] | element of per-atom vector (I = atom ID) |
+--------+---------------+------------------------------------------+
| vector | i2_name[I][J] | element of per-atom array (I = atom ID) |
+--------+---------------+------------------------------------------+
+--------+---------------+------------------------------------------+
| atom | i_name | per-atom vector |
+--------+---------------+------------------------------------------+
| atom | i2_name[I] | column of per-atom array |
+--------+---------------+------------------------------------------+
@ -1222,15 +1227,23 @@ table:
+--------+------------+------------------------------------------+
| equal | c_ID | global scalar |
+--------+------------+------------------------------------------+
| equal | c_ID[I] | element of global vector |
+--------+------------+------------------------------------------+
| equal | c_ID[I][J] | element of global array |
+--------+------------+------------------------------------------+
| equal | C_ID[I] | element of per-atom vector (I = atom ID) |
+--------+------------+------------------------------------------+
| equal | C_ID[I][J] | element of per-atom array (I = atom ID) |
+--------+------------+------------------------------------------+
+--------+------------+------------------------------------------+
| vector | c_ID | global vector |
+--------+------------+------------------------------------------+
| vector | c_ID[I] | column of global array |
+--------+------------+------------------------------------------+
+--------+------------+------------------------------------------+
| atom | c_ID | per-atom vector |
+--------+------------+------------------------------------------+
| atom | c_ID[I] | column of per-atom array |
+--------+------------+------------------------------------------+
@ -1286,15 +1299,23 @@ and atom-style variables are listed in the following table:
+--------+------------+------------------------------------------+
| equal | f_ID | global scalar |
+--------+------------+------------------------------------------+
| equal | f_ID[I] | element of global vector |
+--------+------------+------------------------------------------+
| equal | f_ID[I][J] | element of global array |
+--------+------------+------------------------------------------+
| equal | F_ID[I] | element of per-atom vector (I = atom ID) |
+--------+------------+------------------------------------------+
| equal | F_ID[I][J] | element of per-atom array (I = atom ID) |
+--------+------------+------------------------------------------+
+--------+------------+------------------------------------------+
| vector | f_ID | global vector |
+--------+------------+------------------------------------------+
| vector | f_ID[I] | column of global array |
+--------+------------+------------------------------------------+
+--------+------------+------------------------------------------+
| atom | f_ID | per-atom vector |
+--------+------------+------------------------------------------+
| atom | f_ID[I] | column of per-atom array |
+--------+------------+------------------------------------------+
@ -1365,17 +1386,27 @@ per-atom vector.
+--------+-----------+-----------------------------------------------------------------------------------+
| equal | v_name | global scalar from an equal-style variable |
+--------+-----------+-----------------------------------------------------------------------------------+
| equal | v_name[I] | element of global vector from a vector-style variable |
+--------+-----------+-----------------------------------------------------------------------------------+
| equal | v_name[I] | element of per-atom vector (I = atom ID) from an atom- or atomfile-style variable |
+--------+-----------+-----------------------------------------------------------------------------------+
+--------+-----------+-----------------------------------------------------------------------------------+
| vector | v_name | global scalar from an equal-style variable |
+--------+-----------+-----------------------------------------------------------------------------------+
| vector | v_name | global vector from a vector-style variable |
+--------+-----------+-----------------------------------------------------------------------------------+
| vector | v_name[I] | element of global vector from a vector-style variable |
+--------+-----------+-----------------------------------------------------------------------------------+
| vector | v_name[I] | element of per-atom vector (I = atom ID) from an atom- or atomfile-style variable |
+--------+-----------+-----------------------------------------------------------------------------------+
+--------+-----------+-----------------------------------------------------------------------------------+
| atom | v_name | global scalar from an equal-style variable |
+--------+-----------+-----------------------------------------------------------------------------------+
| atom | v_name | per-atom vector from an atom-style or atomfile-style variable |
+--------+-----------+-----------------------------------------------------------------------------------+
| atom | v_name[I] | element of global vector from a vector-style variable |
+--------+-----------+-----------------------------------------------------------------------------------+
| atom | v_name[I] | element of per-atom vector (I = atom ID) from an atom- or atomfile-style variable |
+--------+-----------+-----------------------------------------------------------------------------------+