diff --git a/doc/src/fix_eos_table_rx.rst b/doc/src/fix_eos_table_rx.rst index 104fa79c20..df95b736df 100644 --- a/doc/src/fix_eos_table_rx.rst +++ b/doc/src/fix_eos_table_rx.rst @@ -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 diff --git a/doc/src/package.rst b/doc/src/package.rst index ddb3656027..cde9855c5f 100644 --- a/doc/src/package.rst +++ b/doc/src/package.rst @@ -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 ` computations and communications. This can improve parallel performance on processors supporting diff --git a/doc/src/pair_bop.rst b/doc/src/pair_bop.rst index 42b9c54406..013dcbc46b 100644 --- a/doc/src/pair_bop.rst +++ b/doc/src/pair_bop.rst @@ -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 `, -:ref:`Pettifor_2 `, :ref:`Pettifor_3 `) and later updated -by Murdick, Zhou, and Ward (:ref:`Murdick `, :ref:`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 `, +:ref:`Pettifor_2 `, :ref:`Pettifor_3 `) and +later updated by Murdick, Zhou, and Ward (:ref:`Murdick `, +:ref:`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 +`, 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 `); 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 ` 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 ` 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 ` +* 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 ` 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). diff --git a/doc/src/pair_eim.rst b/doc/src/pair_eim.rst index c84bce9d53..2de2a124e2 100644 --- a/doc/src/pair_eim.rst +++ b/doc/src/pair_eim.rst @@ -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 `. 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 ` 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.