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

fix a few more .rst formatting issues flagged by pandoc

Browse Source
This commit is contained in:
Axel Kohlmeyer
2025-03-15 12:35:12 -04:00
parent b9218528cf
commit 546ea917c7
4 changed files with 235 additions and 234 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
doc/src/fix_eos_table_rx.rst
View File

@ -49,7 +49,7 @@ computed according to the following relation:
where *m* is the number of species, :math:`c_{i,j}` is the
concentration of species *j* in particle *i*, :math:`u_j` is the
internal energy of species j, :math:`\Delta H_{f,j} is the heat of
internal energy of species j, :math:`\Delta H_{f,j}` is the heat of
formation of species *j*, N is the number of molecules represented
by the coarse-grained particle, :math:`k_B` is the Boltzmann constant,
and :math:`T` is the temperature of the system. Additionally, it is

254
doc/src/package.rst
View File

@ -15,115 +15,115 @@ Syntax
.. parsed-literal::
*gpu* args = Ngpu keyword value ...
Ngpu = # of GPUs per node
zero or more keyword/value pairs may be appended
keywords = *neigh* or *newton* or *pair/only* or *binsize* or *split* or *gpuID* or *tpa* or *blocksize* or *omp* or *platform* or *device_type* or *ocl_args*
*neigh* value = *yes* or *no*
*yes* = neighbor list build on GPU (default)
*no* = neighbor list build on CPU
*newton* = *off* or *on*
*off* = set Newton pairwise flag off (default and required)
*on* = set Newton pairwise flag on (currently not allowed)
*pair/only* = *off* or *on*
*off* = apply "gpu" suffix to all available styles in the GPU package (default)
*on* = apply "gpu" suffix only pair styles
*binsize* value = size
size = bin size for neighbor list construction (distance units)
*split* = fraction
fraction = fraction of atoms assigned to GPU (default = 1.0)
*tpa* value = Nlanes
Nlanes = # of GPU vector lanes (CUDA threads) used per atom
*blocksize* value = size
size = thread block size for pair force computation
*omp* value = Nthreads
Nthreads = number of OpenMP threads to use on CPU (default = 0)
*platform* value = id
id = For OpenCL, platform ID for the GPU or accelerator
*gpuID* values = id
id = ID of first GPU to be used on each node
*device_type* value = *intelgpu* or *nvidiagpu* or *amdgpu* or *applegpu* or *generic* or *custom*,val1,val2,...
val1,val2,... = custom OpenCL accelerator configuration parameters (see below for details)
*ocl_args* value = args
args = List of additional OpenCL compiler arguments delimited by colons
*intel* args = NPhi keyword value ...
Nphi = # of co-processors per node
zero or more keyword/value pairs may be appended
keywords = *mode* or *omp* or *lrt* or *balance* or *ghost* or *tpc* or *tptask* or *pppm_table* or *no_affinity*
*mode* value = *single* or *mixed* or *double*
single = perform force calculations in single precision
mixed = perform force calculations in mixed precision
double = perform force calculations in double precision
*omp* value = Nthreads
Nthreads = number of OpenMP threads to use on CPU (default = 0)
*lrt* value = *yes* or *no*
*yes* = use additional thread dedicated for some PPPM calculations
*no* = do not dedicate an extra thread for some PPPM calculations
*balance* value = split
split = fraction of work to offload to co-processor, -1 for dynamic
*ghost* value = *yes* or *no*
*yes* = include ghost atoms for offload
*no* = do not include ghost atoms for offload
*tpc* value = Ntpc
Ntpc = max number of co-processor threads per co-processor core (default = 4)
*tptask* value = Ntptask
Ntptask = max number of co-processor threads per MPI task (default = 240)
*pppm_table* value = *yes* or *no*
*yes* = Precompute pppm values in table (doesn't change accuracy)
*no* = Compute pppm values on the fly
*no_affinity* values = none
*kokkos* args = keyword value ...
zero or more keyword/value pairs may be appended
keywords = *neigh* or *neigh/qeq* or *neigh/thread* or *neigh/transpose* or *newton* or *binsize* or *comm* or *comm/exchange* or *comm/forward* or *comm/pair/forward* or *comm/fix/forward* or *comm/reverse* or *comm/pair/reverse* or *sort* or *atom/map* or *gpu/aware* or *pair/only*
*neigh* value = *full* or *half*
full = full neighbor list
half = half neighbor list built in thread-safe manner
*neigh/qeq* value = *full* or *half*
full = full neighbor list
half = half neighbor list built in thread-safe manner
*neigh/thread* value = *off* or *on*
*off* = thread only over atoms
*on* = thread over both atoms and neighbors
*neigh/transpose* value = *off* or *on*
*off* = use same memory layout for GPU neigh list build as pair style
*on* = use transposed memory layout for GPU neigh list build
*newton* = *off* or *on*
*off* = set Newton pairwise and bonded flags off
*on* = set Newton pairwise and bonded flags on
*binsize* value = size
size = bin size for neighbor list construction (distance units)
*comm* value = *no* or *host* or *device*
use value for comm/exchange and comm/forward and comm/pair/forward and comm/fix/forward and comm/reverse
*comm/exchange* value = *no* or *host* or *device*
*comm/forward* value = *no* or *host* or *device*
*comm/pair/forward* value = *no* or *device*
*comm/fix/forward* value = *no* or *device*
*comm/reverse* value = *no* or *host* or *device*
*no* = perform communication pack/unpack in non-KOKKOS mode
*host* = perform pack/unpack on host (e.g. with OpenMP threading)
*device* = perform pack/unpack on device (e.g. on GPU)
*comm/pair/reverse* value = *no* or *device*
*no* = perform communication pack/unpack in non-KOKKOS mode
*device* = perform pack/unpack on device (e.g. on GPU)
*sort* value = *no* or *device*
*no* = perform atom sorting in non-KOKKOS mode
*device* = perform atom sorting on device (e.g. on GPU)
*atom/map* value = *no* or *device*
*no* = build atom map in non-KOKKOS mode
*device* = build atom map on device (e.g. on GPU)
*gpu/aware* = *off* or *on*
*off* = do not use GPU-aware MPI
*on* = use GPU-aware MPI (default)
*pair/only* = *off* or *on*
*off* = use device acceleration (e.g. GPU) for all available styles in the KOKKOS package (default)
*on* = use device acceleration only for pair styles (and host acceleration for others)
*omp* args = Nthreads keyword value ...
Nthreads = # of OpenMP threads to associate with each MPI process
zero or more keyword/value pairs may be appended
keywords = *neigh*
*neigh* value = *yes* or *no*
*yes* = threaded neighbor list build (default)
*no* = non-threaded neighbor list build
*gpu* args = Ngpu keyword value ...
Ngpu = # of GPUs per node
zero or more keyword/value pairs may be appended
keywords = *neigh* or *newton* or *pair/only* or *binsize* or *split* or *gpuID* or *tpa* or *blocksize* or *omp* or *platform* or *device_type* or *ocl_args*
*neigh* value = *yes* or *no*
*yes* = neighbor list build on GPU (default)
*no* = neighbor list build on CPU
*newton* = *off* or *on*
*off* = set Newton pairwise flag off (default and required)
*on* = set Newton pairwise flag on (currently not allowed)
*pair/only* = *off* or *on*
*off* = apply "gpu" suffix to all available styles in the GPU package (default)
*on* = apply "gpu" suffix only pair styles
*binsize* value = size
size = bin size for neighbor list construction (distance units)
*split* = fraction
fraction = fraction of atoms assigned to GPU (default = 1.0)
*tpa* value = Nlanes
Nlanes = # of GPU vector lanes (CUDA threads) used per atom
*blocksize* value = size
size = thread block size for pair force computation
*omp* value = Nthreads
Nthreads = number of OpenMP threads to use on CPU (default = 0)
*platform* value = id
id = For OpenCL, platform ID for the GPU or accelerator
*gpuID* values = id
id = ID of first GPU to be used on each node
*device_type* value = *intelgpu* or *nvidiagpu* or *amdgpu* or *applegpu* or *generic* or *custom*,val1,val2,...
val1,val2,... = custom OpenCL accelerator configuration parameters (see below for details)
*ocl_args* value = args
args = List of additional OpenCL compiler arguments delimited by colons
*intel* args = NPhi keyword value ...
Nphi = # of co-processors per node
zero or more keyword/value pairs may be appended
keywords = *mode* or *omp* or *lrt* or *balance* or *ghost* or *tpc* or *tptask* or *pppm_table* or *no_affinity*
*mode* value = *single* or *mixed* or *double*
single = perform force calculations in single precision
mixed = perform force calculations in mixed precision
double = perform force calculations in double precision
*omp* value = Nthreads
Nthreads = number of OpenMP threads to use on CPU (default = 0)
*lrt* value = *yes* or *no*
*yes* = use additional thread dedicated for some PPPM calculations
*no* = do not dedicate an extra thread for some PPPM calculations
*balance* value = split
split = fraction of work to offload to co-processor, -1 for dynamic
*ghost* value = *yes* or *no*
*yes* = include ghost atoms for offload
*no* = do not include ghost atoms for offload
*tpc* value = Ntpc
Ntpc = max number of co-processor threads per co-processor core (default = 4)
*tptask* value = Ntptask
Ntptask = max number of co-processor threads per MPI task (default = 240)
*pppm_table* value = *yes* or *no*
*yes* = Precompute pppm values in table (doesn't change accuracy)
*no* = Compute pppm values on the fly
*no_affinity* values = none
*kokkos* args = keyword value ...
zero or more keyword/value pairs may be appended
keywords = *neigh* or *neigh/qeq* or *neigh/thread* or *neigh/transpose* or *newton* or *binsize* or *comm* or *comm/exchange* or *comm/forward* or *comm/pair/forward* or *comm/fix/forward* or *comm/reverse* or *comm/pair/reverse* or *sort* or *atom/map* or *gpu/aware* or *pair/only*
*neigh* value = *full* or *half*
full = full neighbor list
half = half neighbor list built in thread-safe manner
*neigh/qeq* value = *full* or *half*
full = full neighbor list
half = half neighbor list built in thread-safe manner
*neigh/thread* value = *off* or *on*
*off* = thread only over atoms
*on* = thread over both atoms and neighbors
*neigh/transpose* value = *off* or *on*
*off* = use same memory layout for GPU neigh list build as pair style
*on* = use transposed memory layout for GPU neigh list build
*newton* = *off* or *on*
*off* = set Newton pairwise and bonded flags off
*on* = set Newton pairwise and bonded flags on
*binsize* value = size
size = bin size for neighbor list construction (distance units)
*comm* value = *no* or *host* or *device*
use value for comm/exchange and comm/forward and comm/pair/forward and comm/fix/forward and comm/reverse
*comm/exchange* value = *no* or *host* or *device*
*comm/forward* value = *no* or *host* or *device*
*comm/pair/forward* value = *no* or *device*
*comm/fix/forward* value = *no* or *device*
*comm/reverse* value = *no* or *host* or *device*
*no* = perform communication pack/unpack in non-KOKKOS mode
*host* = perform pack/unpack on host (e.g. with OpenMP threading)
*device* = perform pack/unpack on device (e.g. on GPU)
*comm/pair/reverse* value = *no* or *device*
*no* = perform communication pack/unpack in non-KOKKOS mode
*device* = perform pack/unpack on device (e.g. on GPU)
*sort* value = *no* or *device*
*no* = perform atom sorting in non-KOKKOS mode
*device* = perform atom sorting on device (e.g. on GPU)
*atom/map* value = *no* or *device*
*no* = build atom map in non-KOKKOS mode
*device* = build atom map on device (e.g. on GPU)
*gpu/aware* = *off* or *on*
*off* = do not use GPU-aware MPI
*on* = use GPU-aware MPI (default)
*pair/only* = *off* or *on*
*off* = use device acceleration (e.g. GPU) for all available styles in the KOKKOS package (default)
*on* = use device acceleration only for pair styles (and host acceleration for others)
*omp* args = Nthreads keyword value ...
Nthreads = # of OpenMP threads to associate with each MPI process
zero or more keyword/value pairs may be appended
keywords = *neigh*
*neigh* value = *yes* or *no*
*yes* = threaded neighbor list build (default)
*no* = non-threaded neighbor list build
Examples
""""""""
@ -200,7 +200,7 @@ number of compute cores. If there are more devices than MPI tasks,
the additional devices will be unused. The auto-selection of GPUs/
accelerator devices and platforms can be restricted by specifying
a non-zero value for *Ngpu* and / or using the *gpuID*, *platform*,
and *device_type* keywords as described below. If there are more MPI
and *device\_type* keywords as described below. If there are more MPI
tasks (per node) than GPUs, multiple MPI tasks will share each GPU.
Optional keyword/value pairs can also be specified. Each has a
@ -274,8 +274,8 @@ the other particles.
The *gpuID* keyword is used to specify the first ID for the GPU or
other accelerator that LAMMPS will use. For example, if the ID is
1 and *Ngpu* is 3, GPUs 1-3 will be used. Device IDs should be
determined from the output of nvc_get_devices, ocl_get_devices,
or hip_get_devices
determined from the output of nvc\_get\_devices, ocl\_get\_devices,
or hip\_get\_devices
as provided in the lib/gpu directory. When using OpenCL with
accelerators that have main memory NUMA, the accelerators can be
split into smaller virtual accelerators for more efficient use
@ -308,15 +308,15 @@ The meaning of *Nthreads* is exactly the same for the GPU, INTEL,
and GPU packages.
The *platform* keyword is only used with OpenCL to specify the ID for
an OpenCL platform. See the output from ocl_get_devices in the lib/gpu
an OpenCL platform. See the output from ocl\_get\_devices in the lib/gpu
directory. In LAMMPS only one platform can be active at a time and by
default (id=-1) the platform is auto-selected to find the GPU with the
most compute cores. When *Ngpu* or other keywords are specified, the
auto-selection is appropriately restricted. For example, if *Ngpu* is
3, only platforms with at least 3 accelerators are considered. Similar
restrictions can be enforced by the *gpuID* and *device_type* keywords.
restrictions can be enforced by the *gpuID* and *device\_type* keywords.
The *device_type* keyword can be used for OpenCL to specify the type of
The *device\_type* keyword can be used for OpenCL to specify the type of
GPU to use or specify a custom configuration for an accelerator. In most
cases this selection will be automatic and there is no need to use the
keyword. The *applegpu* type is not specific to a particular GPU vendor,
@ -324,25 +324,25 @@ but is separate due to the more restrictive Apple OpenCL implementation.
For expert users, to specify a custom configuration, the *custom* keyword
followed by the next parameters can be specified:
CONFIG_ID, SIMD_SIZE, MEM_THREADS, SHUFFLE_AVAIL, FAST_MATH,
THREADS_PER_ATOM, THREADS_PER_CHARGE, THREADS_PER_THREE, BLOCK_PAIR,
BLOCK_BIO_PAIR, BLOCK_ELLIPSE, PPPM_BLOCK_1D, BLOCK_NBOR_BUILD,
BLOCK_CELL_2D, BLOCK_CELL_ID, MAX_SHARED_TYPES, MAX_BIO_SHARED_TYPES,
PPPM_MAX_SPLINE, NBOR_PREFETCH.
CONFIG\_ID, SIMD\_SIZE, MEM\_THREADS, SHUFFLE\_AVAIL, FAST\_MATH,
THREADS\_PER\_ATOM, THREADS\_PER\_CHARGE, THREADS\_PER\_THREE, BLOCK\_PAIR,
BLOCK\_BIO\_PAIR, BLOCK\_ELLIPSE, PPPM\_BLOCK\_1D, BLOCK\_NBOR\_BUILD,
BLOCK\_CELL\_2D, BLOCK\_CELL\_ID, MAX\_SHARED\_TYPES, MAX\_BIO\_SHARED\_TYPES,
PPPM\_MAX\_SPLINE, NBOR\_PREFETCH.
CONFIG_ID can be 0. SHUFFLE_AVAIL in {0,1} indicates that inline-PTX
CONFIG\_ID can be 0. SHUFFLE\_AVAIL in {0,1} indicates that inline-PTX
(NVIDIA) or OpenCL extensions (Intel) should be used for horizontal
vector operations. FAST_MATH in {0,1} indicates that OpenCL fast math
vector operations. FAST\_MATH in {0,1} indicates that OpenCL fast math
optimizations are used during the build and hardware-accelerated
transcendental functions are used when available. THREADS_PER_* give the
transcendental functions are used when available. THREADS\_PER\_\* give the
default *tpa* values for ellipsoidal models, styles using charge, and
any other styles. The BLOCK_* parameters specify the block sizes for
various kernel calls and the MAX_*SHARED*_ parameters are used to
any other styles. The BLOCK\_\* parameters specify the block sizes for
various kernel calls and the MAX\_\*SHARED\_\* parameters are used to
determine the amount of local shared memory to use for storing model
parameters.
For OpenCL, the routines are compiled at runtime for the specified GPU
or accelerator architecture. The *ocl_args* keyword can be used to
or accelerator architecture. The *ocl\_args* keyword can be used to
specify additional flags for the runtime build.
----------
@ -381,7 +381,7 @@ force calculation.
The *lrt* keyword can be used to enable "Long Range Thread (LRT)"
mode. It can take a value of *yes* to enable and *no* to disable.
LRT mode generates an extra thread (in addition to any OpenMP threads
specified with the OMP_NUM_THREADS environment variable or the *omp*
specified with the OMP\_NUM\_THREADS environment variable or the *omp*
keyword). The extra thread is dedicated for performing part of the
:doc:`PPPM solver <kspace_style>` computations and communications. This
can improve parallel performance on processors supporting

188
doc/src/pair_bop.rst
View File

@ -32,20 +32,20 @@ Description
"""""""""""
The *bop* pair style computes Bond-Order Potentials (BOP) based on
quantum mechanical theory incorporating both :math:`\sigma` and :math:`\pi` bonding.
By analytically deriving the BOP from quantum mechanical theory its
transferability to different phases can approach that of quantum
mechanical methods. This potential is similar to the original BOP
developed by Pettifor (:ref:`Pettifor_1 <Pettifor_1>`,
:ref:`Pettifor_2 <Pettifor_2>`, :ref:`Pettifor_3 <Pettifor_3>`) and later updated
by Murdick, Zhou, and Ward (:ref:`Murdick <Murdick>`, :ref:`Ward <Ward>`).
Currently, BOP potential files for these systems are provided with
LAMMPS: AlCu, CCu, CdTe, CdTeSe, CdZnTe, CuH, GaAs. A system with
only a subset of these elements, including a single element (e.g. C or
Cu or Al or Ga or Zn or CdZn), can also be modeled by using the
appropriate alloy file and assigning all atom types to the
single element or subset of elements via the pair_coeff command, as
discussed below.
quantum mechanical theory incorporating both :math:`\sigma` and
:math:`\pi` bonding. By analytically deriving the BOP from quantum
mechanical theory its transferability to different phases can approach
that of quantum mechanical methods. This potential is similar to the
original BOP developed by Pettifor (:ref:`Pettifor_1 <Pettifor_1>`,
:ref:`Pettifor_2 <Pettifor_2>`, :ref:`Pettifor_3 <Pettifor_3>`) and
later updated by Murdick, Zhou, and Ward (:ref:`Murdick <Murdick>`,
:ref:`Ward <Ward>`). Currently, BOP potential files for these systems
are provided with LAMMPS: AlCu, CCu, CdTe, CdTeSe, CdZnTe, CuH, GaAs. A
system with only a subset of these elements, including a single element
(e.g. C or Cu or Al or Ga or Zn or CdZn), can also be modeled by using
the appropriate alloy file and assigning all atom types to the single
element or subset of elements via the :doc:`pair_coeff command
<pair_coeff>`, as discussed below.
The BOP potential consists of three terms:
@ -58,7 +58,7 @@ representing the repulsion between a pair of ion cores,
:math:`\beta_{\sigma,ij}(r_{ij})` and :math:`\beta_{\sigma,ij}(r_{ij})`
are respectively sigma and :math:`\pi` bond integrals, :math:`\Theta_{\sigma,ij}`
and :math:`\Theta_{\pi,ij}` are :math:`\sigma` and :math:`\pi`
bond-orders, and U_prom is the promotion energy for sp-valent systems.
bond-orders, and U\_prom is the promotion energy for sp-valent systems.
The detailed formulas for this potential are given in Ward
(:ref:`Ward <Ward>`); here we provide only a brief description.
@ -96,7 +96,7 @@ length 4. This enables the incorporation of dihedral angles effects.
.. note::
Note that unlike for other potentials, cutoffs for BOP
potentials are not set in the pair_style or pair_coeff command; they
potentials are not set in the pair\_style or pair\_coeff command; they
are specified in the BOP potential files themselves. Likewise, the
BOP potential files list atomic masses; thus you do not need to use
the :doc:`mass <mass>` command to specify them. Note that for BOP
@ -106,7 +106,7 @@ length 4. This enables the incorporation of dihedral angles effects.
:doc:`pair_coeff <pair_coeff>` command to read the BOP potential
file.
One option can be specified as a keyword with the pair_style command.
One option can be specified as a keyword with the pair\_style command.
The *save* keyword gives you the option to calculate in advance and
store a set of distances, angles, and derivatives of angles. The
@ -118,10 +118,10 @@ system configuration.
----------
Only a single pair_coeff command is used with the *bop* style which
Only a single pair\_coeff command is used with the *bop* style which
specifies a BOP potential file, with parameters for all needed
elements. These are mapped to LAMMPS atom types by specifying
N additional arguments after the filename in the pair_coeff command,
N additional arguments after the filename in the pair\_coeff command,
where N is the number of LAMMPS atom types:
* filename
@ -130,7 +130,7 @@ where N is the number of LAMMPS atom types:
As an example, imagine the CdTe.bop file has BOP values for Cd
and Te. If your LAMMPS simulation has 4 atoms types and you want the
first 3 to be Cd, and the fourth to be Te, you would use the following
pair_coeff command:
pair\_coeff command:
.. code-block:: LAMMPS
@ -143,8 +143,8 @@ element in the BOP file. The final Te argument maps LAMMPS atom type
BOP files in the *potentials* directory of the LAMMPS distribution
have a ".bop" suffix. The potentials are in tabulated form containing
pre-tabulated pair functions for phi_ij(r_ij), beta_(sigma,ij)(r_ij),
and beta_pi,ij)(r_ij).
pre-tabulated pair functions for phi\_ij(r\_ij), beta\_(sigma,ij)(r\_ij),
and beta\_pi,ij)(r\_ij).
The parameters/coefficients format for the different kinds of BOP
files are given below with variables matching the formulation of Ward
@ -170,89 +170,89 @@ the tabulated functions are given.
* Line 1: nr, nBOt (nr is the number of divisions the radius is broken
into for function tables and MUST be a factor of 5; nBOt is the number
of divisions for the tabulated values of THETA_(S,ij)
* Line 2: delta_1-delta_7 (if all are not used in the particular
of divisions for the tabulated values of THETA\_(S,ij)
* Line 2: delta\_1-delta\_7 (if all are not used in the particular
* formulation, set unused values to 0.0)
Following this N lines for e_1-e_N containing p_pi.
Following this N lines for e\_1-e\_N containing p\_pi.
* Line 3: p_pi (for e_1)
* Line 4: p_pi (for e_2 and continues to e_N)
* Line 3: p\_pi (for e\_1)
* Line 4: p\_pi (for e\_2 and continues to e\_N)
The next section contains several pair constants for the number of
interaction types e_i-e_j, with i=1->N, j=i->N
interaction types e\_i-e\_j, with i=1->N, j=i->N
* Line 1: r_cut (for e_1-e_1 interactions)
* Line 2: c_sigma, a_sigma, c_pi, a_pi
* Line 3: delta_sigma, delta_pi
* Line 4: f_sigma, k_sigma, delta_3 (This delta_3 is similar to that of
* Line 1: r\_cut (for e\_1-e\_1 interactions)
* Line 2: c\_sigma, a\_sigma, c\_pi, a\_pi
* Line 3: delta\_sigma, delta\_pi
* Line 4: f\_sigma, k\_sigma, delta\_3 (This delta\_3 is similar to that of
the previous section but is interaction type dependent)
The next section contains a line for each three body interaction type
e_j-e_i-e_k with i=0->N, j=0->N, k=j->N
e\_j-e\_i-e\_k with i=0->N, j=0->N, k=j->N
* Line 1: g_(sigma0), g_(sigma1), g_(sigma2) (These are coefficients for
g_(sigma,jik)(THETA_ijk) for e_1-e_1-e_1 interaction. :ref:`Ward <Ward>`
* Line 1: g\_(sigma0), g\_(sigma1), g\_(sigma2) (These are coefficients for
g\_(sigma,jik)(THETA\_ijk) for e\_1-e\_1-e\_1 interaction. :ref:`Ward <Ward>`
contains the full expressions for the constants as functions of
b_(sigma,ijk), p_(sigma,ijk), u_(sigma,ijk))
* Line 2: g_(sigma0), g_(sigma1), g_(sigma2) (for e_1-e_1-e_2)
b\_(sigma,ijk), p\_(sigma,ijk), u\_(sigma,ijk))
* Line 2: g\_(sigma0), g\_(sigma1), g\_(sigma2) (for e\_1-e\_1-e\_2)
The next section contains a block for each interaction type for the
phi_ij(r_ij). Each block has nr entries with 5 entries per line.
phi\_ij(r\_ij). Each block has nr entries with 5 entries per line.
* Line 1: phi(r1), phi(r2), phi(r3), phi(r4), phi(r5) (for the e_1-e_1
* Line 1: phi(r1), phi(r2), phi(r3), phi(r4), phi(r5) (for the e\_1-e\_1
interaction type)
* Line 2: phi(r6), phi(r7), phi(r8), phi(r9), phi(r10) (this continues
until nr)
* ...
* Line nr/5_1: phi(r1), phi(r2), phi(r3), phi(r4), phi(r5), (for the
e_1-e_1 interaction type)
* Line nr/5\_1: phi(r1), phi(r2), phi(r3), phi(r4), phi(r5), (for the
e\_1-e\_1 interaction type)
The next section contains a block for each interaction type for the
beta_(sigma,ij)(r_ij). Each block has nr entries with 5 entries per
beta\_(sigma,ij)(r\_ij). Each block has nr entries with 5 entries per
line.
* Line 1: beta_sigma(r1), beta_sigma(r2), beta_sigma(r3), beta_sigma(r4),
beta_sigma(r5) (for the e_1-e_1 interaction type)
* Line 2: beta_sigma(r6), beta_sigma(r7), beta_sigma(r8), beta_sigma(r9),
beta_sigma(r10) (this continues until nr)
* Line 1: beta\_sigma(r1), beta\_sigma(r2), beta\_sigma(r3), beta\_sigma(r4),
beta\_sigma(r5) (for the e\_1-e\_1 interaction type)
* Line 2: beta\_sigma(r6), beta\_sigma(r7), beta\_sigma(r8), beta\_sigma(r9),
beta\_sigma(r10) (this continues until nr)
* ...
* Line nr/5+1: beta_sigma(r1), beta_sigma(r2), beta_sigma(r3),
beta_sigma(r4), beta_sigma(r5) (for the e_1-e_2 interaction type)
* Line nr/5+1: beta\_sigma(r1), beta\_sigma(r2), beta\_sigma(r3),
beta\_sigma(r4), beta\_sigma(r5) (for the e\_1-e\_2 interaction type)
The next section contains a block for each interaction type for
beta_(pi,ij)(r_ij). Each block has nr entries with 5 entries per line.
beta\_(pi,ij)(r\_ij). Each block has nr entries with 5 entries per line.
* Line 1: beta_pi(r1), beta_pi(r2), beta_pi(r3), beta_pi(r4), beta_pi(r5)
(for the e_1-e_1 interaction type)
* Line 2: beta_pi(r6), beta_pi(r7), beta_pi(r8), beta_pi(r9),
beta_pi(r10) (this continues until nr)
* Line 1: beta\_pi(r1), beta\_pi(r2), beta\_pi(r3), beta\_pi(r4), beta\_pi(r5)
(for the e\_1-e\_1 interaction type)
* Line 2: beta\_pi(r6), beta\_pi(r7), beta\_pi(r8), beta\_pi(r9),
beta\_pi(r10) (this continues until nr)
* ...
* Line nr/5+1: beta_pi(r1), beta_pi(r2), beta_pi(r3), beta_pi(r4),
beta_pi(r5) (for the e_1-e_2 interaction type)
* Line nr/5+1: beta\_pi(r1), beta\_pi(r2), beta\_pi(r3), beta\_pi(r4),
beta\_pi(r5) (for the e\_1-e\_2 interaction type)
The next section contains a block for each interaction type for the
THETA_(S,ij)((THETA_(sigma,ij))\^(1/2), f_(sigma,ij)). Each block has
THETA\_(S,ij)((THETA\_(sigma,ij))\^(1/2), f\_(sigma,ij)). Each block has
nBOt entries with 5 entries per line.
* Line 1: THETA_(S,ij)(r1), THETA_(S,ij)(r2), THETA_(S,ij)(r3),
THETA_(S,ij)(r4), THETA_(S,ij)(r5) (for the e_1-e_2 interaction type)
* Line 2: THETA_(S,ij)(r6), THETA_(S,ij)(r7), THETA_(S,ij)(r8),
THETA_(S,ij)(r9), THETA_(S,ij)(r10) (this continues until nBOt)
* Line 1: THETA\_(S,ij)(r1), THETA\_(S,ij)(r2), THETA\_(S,ij)(r3),
THETA\_(S,ij)(r4), THETA\_(S,ij)(r5) (for the e\_1-e\_2 interaction type)
* Line 2: THETA\_(S,ij)(r6), THETA\_(S,ij)(r7), THETA\_(S,ij)(r8),
THETA\_(S,ij)(r9), THETA\_(S,ij)(r10) (this continues until nBOt)
* ...
* Line nBOt/5+1: THETA_(S,ij)(r1), THETA_(S,ij)(r2), THETA_(S,ij)(r3),
THETA_(S,ij)(r4), THETA_(S,ij)(r5) (for the e_1-e_2 interaction type)
* Line nBOt/5+1: THETA\_(S,ij)(r1), THETA\_(S,ij)(r2), THETA\_(S,ij)(r3),
THETA\_(S,ij)(r4), THETA\_(S,ij)(r5) (for the e\_1-e\_2 interaction type)
The next section contains a block of N lines for e_1-e_N
The next section contains a block of N lines for e\_1-e\_N
* Line 1: delta\^mu (for e_1)
* Line 2: delta\^mu (for e_2 and repeats to e_N)
* Line 1: delta\^mu (for e\_1)
* Line 2: delta\^mu (for e\_2 and repeats to e\_N)
The last section contains more constants for e_i-e_j interactions with
The last section contains more constants for e\_i-e\_j interactions with
i=0->N, j=i->N
* Line 1: (A_ij)\^(mu\*nu) (for e1-e1)
* Line 2: (A_ij)\^(mu\*nu) (for e1-e2 and repeats as above)
* Line 1: (A\_ij)\^(mu\*nu) (for e1-e1)
* Line 2: (A\_ij)\^(mu\*nu) (for e1-e2 and repeats as above)
----------
@ -274,34 +274,34 @@ the tabulated functions are given.
* Line 1: nr, ntheta, nBOt (nr is the number of divisions the radius is broken
into for function tables and MUST be a factor of 5; ntheta is the power of the
power of the spline used to fit the angular function; nBOt is the number
of divisions for the tabulated values of THETA_(S,ij)
* Line 2: delta_1-delta_7 (if all are not used in the particular
of divisions for the tabulated values of THETA\_(S,ij)
* Line 2: delta\_1-delta\_7 (if all are not used in the particular
* formulation, set unused values to 0.0)
Following this N lines for e_1-e_N containing p_pi.
Following this N lines for e\_1-e\_N containing p\_pi.
* Line 3: p_pi (for e_1)
* Line 4: p_pi (for e_2 and continues to e_N)
* Line 3: p\_pi (for e\_1)
* Line 4: p\_pi (for e\_2 and continues to e\_N)
The next section contains several pair constants for the number of
interaction types e_i-e_j, with i=1->N, j=i->N
interaction types e\_i-e\_j, with i=1->N, j=i->N
* Line 1: r_cut (for e_1-e_1 interactions)
* Line 2: c_sigma, a_sigma, c_pi, a_pi
* Line 3: delta_sigma, delta_pi
* Line 4: f_sigma, k_sigma, delta_3 (This delta_3 is similar to that of
* Line 1: r\_cut (for e\_1-e\_1 interactions)
* Line 2: c\_sigma, a\_sigma, c\_pi, a\_pi
* Line 3: delta\_sigma, delta\_pi
* Line 4: f\_sigma, k\_sigma, delta\_3 (This delta\_3 is similar to that of
the previous section but is interaction type dependent)
The next section contains a line for each three body interaction type
e_j-e_i-e_k with i=0->N, j=0->N, k=j->N
e\_j-e\_i-e\_k with i=0->N, j=0->N, k=j->N
* Line 1: g0, g1, g2... (These are coefficients for the angular spline
of the g_(sigma,jik)(THETA_ijk) for e_1-e_1-e_1 interaction. The
of the g\_(sigma,jik)(THETA\_ijk) for e\_1-e\_1-e\_1 interaction. The
function can contain up to 10 term thus 10 constants. The first line
can contain up to five constants. If the spline has more than five
terms the second line will contain the remaining constants The
following lines will then contain the constants for the remaining g0,
g1, g2... (for e_1-e_1-e_2) and the other three body
g1, g2... (for e\_1-e\_1-e\_2) and the other three body
interactions
The rest of the table has the same structure as the previous section
@ -327,34 +327,34 @@ the tabulated functions are given.
* Line 1: nr, ntheta, nBOt (nr is the number of divisions the radius is broken
into for function tables and MUST be a factor of 5; ntheta is the number of
divisions for the tabulated values of the g angular function; nBOt is the number
of divisions for the tabulated values of THETA_(S,ij)
* Line 2: delta_1-delta_7 (if all are not used in the particular
of divisions for the tabulated values of THETA\_(S,ij)
* Line 2: delta\_1-delta\_7 (if all are not used in the particular
* formulation, set unused values to 0.0)
Following this N lines for e_1-e_N containing p_pi.
Following this N lines for e\_1-e\_N containing p\_pi.
* Line 3: p_pi (for e_1)
* Line 4: p_pi (for e_2 and continues to e_N)
* Line 3: p\_pi (for e\_1)
* Line 4: p\_pi (for e\_2 and continues to e\_N)
The next section contains several pair constants for the number of
interaction types e_i-e_j, with i=1->N, j=i->N
interaction types e\_i-e\_j, with i=1->N, j=i->N
* Line 1: r_cut (for e_1-e_1 interactions)
* Line 2: c_sigma, a_sigma, c_pi, a_pi
* Line 3: delta_sigma, delta_pi
* Line 4: f_sigma, k_sigma, delta_3 (This delta_3 is similar to that of
* Line 1: r\_cut (for e\_1-e\_1 interactions)
* Line 2: c\_sigma, a\_sigma, c\_pi, a\_pi
* Line 3: delta\_sigma, delta\_pi
* Line 4: f\_sigma, k\_sigma, delta\_3 (This delta\_3 is similar to that of
the previous section but is interaction type dependent)
The next section contains a line for each three body interaction type
e_j-e_i-e_k with i=0->N, j=0->N, k=j->N
e\_j-e\_i-e\_k with i=0->N, j=0->N, k=j->N
* Line 1: g(theta1), g(theta2), g(theta3), g(theta4), g(theta5) (for the e_1-e_1-e_1
* Line 1: g(theta1), g(theta2), g(theta3), g(theta4), g(theta5) (for the e\_1-e\_1-e\_1
interaction type)
* Line 2: g(theta6), g(theta7), g(theta8), g(theta9), g(theta10) (this continues
until ntheta)
* ...
* Line ntheta/5+1: g(theta1), g(theta2), g(theta3), g(theta4), g(theta5), (for the
e_1-e_1-e_2 interaction type)
e\_1-e\_1-e\_2 interaction type)
The rest of the table has the same structure as the previous section (see above).

25
doc/src/pair_eim.rst
View File

@ -37,10 +37,11 @@ energy of the system E is given by
E = \frac{1}{2} \sum_{i=1}^{N} \sum_{j=i_1}^{i_N} \phi_{ij} \left(r_{ij}\right) + \sum_{i=1}^{N}E_i\left(q_i,\sigma_i\right)
The first term is a double pairwise sum over the J neighbors of all I
atoms, where :math:`\phi_{ij}` is a pair potential. The second term sums over
the embedding energy E_i of atom I, which is a function of its charge
q_i and the electrical potential :math:`\sigma_i` at its location. E_i, q_i,
and :math:`sigma_i` are calculated as
atoms, where :math:`\phi_{ij}` is a pair potential. The second term
sums over the embedding energy :math:`E_i` of atom I, which is a
function of its charge :math:`q_i` and the electrical potential
:math:`\sigma_i` at its location. :math:`E_i`, :math:`q_i`, and
:math:`\sigma_i` are calculated as
.. math::
@ -77,7 +78,7 @@ atoms in the atomic pair.
charge on each atom and thus requires you to assign a charge to each
atom, e.g. the *charge* or *full* atom styles. This is because the
EIM potential infers the charge on an atom from the equation above for
q_i; you do not assign charges explicitly.
:math:`q_i`; you do not assign charges explicitly.
----------
@ -90,15 +91,15 @@ A system with any combination of these elements can be modeled. This
file is parameterized in terms of LAMMPS :doc:`metal units <units>`.
Note that unlike other potentials, cutoffs for EIM potentials are not
set in the pair_style or pair_coeff command; they are specified in the
set in the pair\_style or pair\_coeff command; they are specified in the
EIM potential file itself. Likewise, the EIM potential file lists
atomic masses; thus you do not need to use the :doc:`mass <mass>`
command to specify them.
Only a single pair_coeff command is used with the *eim* style which
Only a single pair\_coeff command is used with the *eim* style which
specifies an EIM potential file and the element(s) to extract
information for. The EIM elements are mapped to LAMMPS atom types by
specifying N additional arguments after the filename in the pair_coeff
specifying N additional arguments after the filename in the pair\_coeff
command, where N is the number of LAMMPS atom types:
* Elem1, Elem2, ...
@ -111,7 +112,7 @@ to specify the path for the potential file.
As an example like one of those above, suppose you want to model a
system with Na and Cl atoms. If your LAMMPS simulation has 4 atoms
types and you want the first 3 to be Na, and the fourth to be Cl, you would
use the following pair_coeff command:
use the following pair\_coeff command:
.. code-block:: LAMMPS
@ -147,9 +148,9 @@ radius (LAMMPS ignores it), ionic radius (LAMMPS ignores it), cohesive
energy (LAMMPS ignores it), and q0 (must be 0).
Lines starting with "pair:" are entered as: element 1, element 2,
r_(c,phi), r_(c,phi) (redundant for historical reasons), E_b, r_e,
alpha, beta, r_(c,eta), A_(eta), r_(s,eta), r_(c,psi), A_(psi), zeta,
r_(s,psi), and p.
r\_(c,phi), r\_(c,phi) (redundant for historical reasons), E\_b, r\_e,
alpha, beta, r\_(c,eta), A\_(eta), r\_(s,eta), r\_(c,psi), A\_(psi), zeta,
r\_(s,psi), and p.
The lines in the file can be in any order; LAMMPS extracts the info it
needs.