Merge branch 'lammps:develop' into type-labels
This commit is contained in:
Jacob Gissinger
@ -341,6 +341,18 @@ minutes to hours) to build. Of course you only need to do that once.)
|
||||
$ make lib-kim args="-p /usr/local" # use an existing KIM API installation at the provided location
|
||||
$ make lib-kim args="-p /usr/local -a EAM_Dynamo_Ackland_W__MO_141627196590_002" # ditto but add one model or driver
|
||||
|
||||
When using the "-b " option, the KIM library is built using its native
|
||||
cmake build system. The ``lib/kim/Install.py`` script supports a
|
||||
``CMAKE`` environment variable if the cmake executable is named other
|
||||
than ``cmake`` on your system. Additional environment variables may be
|
||||
provided on the command line for use by cmake. For example, to use the
|
||||
``cmake3`` executable and tell it to use the gnu version 11 compilers
|
||||
to build KIM, one could use the following command line.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ CMAKE=cmake3 CXX=g++-11 CC=gcc-11 FC=gfortran-11 make lib-kim args="-b " # (re-)install KIM API lib using cmake3 and gnu v11 compilers with only example models
|
||||
|
||||
Settings for debugging OpenKIM web queries discussed below need to
|
||||
be applied by adding them to the ``LMP_INC`` variable through
|
||||
editing the ``Makefile.machine`` you are using. For example:
|
||||
@ -560,11 +572,26 @@ They must be specified in uppercase.
|
||||
* - VEGA908
|
||||
- GPU
|
||||
- AMD GPU MI100 GFX908
|
||||
* - INTEL_GEN
|
||||
* - VEGA90A
|
||||
- GPU
|
||||
- Intel GPUs Gen9+
|
||||
- AMD GPU
|
||||
* - INTEL_DG1
|
||||
- GPU
|
||||
- Intel Iris XeMAX GPU
|
||||
* - INTEL_GEN9
|
||||
- GPU
|
||||
- Intel GPU Gen9
|
||||
* - INTEL_GEN11
|
||||
- GPU
|
||||
- Intel GPU Gen11
|
||||
* - INTEL_GEN12LP
|
||||
- GPU
|
||||
- Intel GPU Gen12LP
|
||||
* - INTEL_XEHP
|
||||
- GPU
|
||||
- Intel GPUs Xe-HP
|
||||
|
||||
This list was last updated for version 3.4.1 of the Kokkos library.
|
||||
This list was last updated for version 3.5.0 of the Kokkos library.
|
||||
|
||||
.. tabs::
|
||||
|
||||
|
||||
@ -141,7 +141,8 @@ unrelated feature, you should switch branches!
|
||||
Committing changes to the *develop*, *release*, or *stable* branches
|
||||
is strongly discouraged. While it may be convenient initially, it
|
||||
will create more work in the long run. Various texts and tutorials
|
||||
on using git effectively discuss the motivation for this.
|
||||
on using git effectively discuss the motivation for using feature
|
||||
branches instead.
|
||||
|
||||
**After changes are made**
|
||||
|
||||
|
||||
@ -28,8 +28,9 @@ provides `limited support for subversion clients <svn_>`_.
|
||||
|
||||
You can follow the LAMMPS development on 3 different git branches:
|
||||
|
||||
* **stable** : this branch is updated with every stable release;
|
||||
updates are always "fast forward" merges from *develop*
|
||||
* **stable** : this branch is updated from the *release* branch with
|
||||
every stable release version and also has selected bug fixes and updates
|
||||
back-ported from the *develop* branch
|
||||
* **release** : this branch is updated with every patch release;
|
||||
updates are always "fast forward" merges from *develop*
|
||||
* **develop** : this branch follows the ongoing development and
|
||||
@ -47,20 +48,22 @@ your machine and "release" is one of the 3 branches listed above.
|
||||
(Note that you actually download all 3 branches; you can switch
|
||||
between them at any time using "git checkout <branch name>".)
|
||||
|
||||
.. note::
|
||||
.. admonition:: Saving time and disk space when using ``git clone``
|
||||
|
||||
The complete git history of the LAMMPS project is quite large because
|
||||
it contains the entire commit history of the project since fall 2006,
|
||||
which includes the time when LAMMPS was managed with subversion. This
|
||||
also includes commits that have added and removed some large files
|
||||
(mostly by accident). If you do not need access to the entire commit
|
||||
history, you can speed up the "cloning" process and reduce local disk
|
||||
space requirements by using the *--depth* git command line flag thus
|
||||
create a "shallow clone" of the repository that contains only a
|
||||
subset of the git history. Using a depth of 1000 is usually sufficient
|
||||
to include the head commits of the *develop* and the *release* branches.
|
||||
To include the head commit of the *stable* branch you may need a depth
|
||||
of up to 10000.
|
||||
which includes the time when LAMMPS was managed with subversion.
|
||||
This includes a few commits that have added and removed some large
|
||||
files (mostly by accident). If you do not need access to the entire
|
||||
commit history (most people don't), you can speed up the "cloning"
|
||||
process and reduce local disk space requirements by using the
|
||||
*--depth* git command line flag. That will create a "shallow clone"
|
||||
of the repository containing only a subset of the git history. Using
|
||||
a depth of 1000 is usually sufficient to include the head commits of
|
||||
the *develop* and the *release* branches. To include the head commit
|
||||
of the *stable* branch you may need a depth of up to 10000. If you
|
||||
later need more of the git history, you can always convert the
|
||||
shallow clone into a "full clone".
|
||||
|
||||
Once the command completes, your directory will contain the same files
|
||||
as if you unpacked a current LAMMPS tarball, with the exception, that
|
||||
|
||||
@ -10,23 +10,31 @@ Whenever we fix a bug or update or add a feature, it will be merged into
|
||||
the *develop* branch of the git repository. When a sufficient number of
|
||||
changes have accumulated *and* the software passes a set of automated
|
||||
tests, we release it in the next *patch* release, which are made every
|
||||
few weeks. Info on patch releases are on `this website page
|
||||
few weeks. The *release* branch of the git repository is updated with
|
||||
every such release. Info on patch releases are on `this website page
|
||||
<https://www.lammps.org/bug.html>`_.
|
||||
|
||||
Once or twice a year, only bug fixes and small, non-intrusive changes are
|
||||
included for a period of time, and the code is subjected to more detailed
|
||||
Once or twice a year, we apply only bug fixes and small, non-intrusive
|
||||
changes to the *develop* branch and the code is subjected to more detailed
|
||||
and thorough testing than the default automated testing. The latest
|
||||
patch release after such a period is then labeled as a *stable* version.
|
||||
patch release after such a period is then also labeled as a *stable* version
|
||||
and the *stable* branch is updated with it. Between stable releases
|
||||
we occasionally release some updates to the stable release containing
|
||||
only bug fixes and updates back-ported from *develop* but no new features
|
||||
and update the *stable* branch accordingly.
|
||||
|
||||
Each version of LAMMPS contains all the features and bug-fixes up to
|
||||
and including its version date.
|
||||
Each version of LAMMPS contains all the documented features up to and
|
||||
including its version date.
|
||||
|
||||
The version date is printed to the screen and logfile every time you
|
||||
run LAMMPS. It is also in the file src/version.h and in the LAMMPS
|
||||
directory name created when you unpack a tarball. And it is on the
|
||||
first page of the :doc:`manual <Manual>`.
|
||||
|
||||
* If you browse the HTML pages on the LAMMPS WWW site, they always
|
||||
describe the most current patch release of LAMMPS.
|
||||
* If you browse the HTML pages on the LAMMPS WWW site, they will by
|
||||
default describe the most current patch release version of LAMMPS.
|
||||
In the navigation bar on the bottom left, there is the option to
|
||||
view instead the documentation for the most recent *stable* version
|
||||
or the latest version from the current development branch.
|
||||
* If you browse the HTML pages included in your tarball, they
|
||||
describe the version you have, which may be older.
|
||||
|
||||
@ -13,7 +13,7 @@ Syntax
|
||||
* ID, group-ID are documented in :doc:`compute <compute>` command
|
||||
* bond/local = style name of this compute command
|
||||
* one or more values may be appended
|
||||
* value = *dist* or *engpot* or *force* or *fx* or *fy* or *fz* or *engvib* or *engrot* or *engtrans* or *omega* or *velvib* or *v_name*
|
||||
* value = *dist* or *dx* or *dy* or *dz* or *engpot* or *force* or *fx* or *fy* or *fz* or *engvib* or *engrot* or *engtrans* or *omega* or *velvib* or *v_name*
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
@ -21,6 +21,7 @@ Syntax
|
||||
*engpot* = bond potential energy
|
||||
*force* = bond force
|
||||
|
||||
*dx*,\ *dy*,\ *dz* = components of pairwise distance
|
||||
*fx*,\ *fy*,\ *fz* = components of bond force
|
||||
*engvib* = bond kinetic energy of vibration
|
||||
*engrot* = bond kinetic energy of rotation
|
||||
@ -63,6 +64,9 @@ whether the 2 atoms represent a simple diatomic molecule, or are part
|
||||
of some larger molecule.
|
||||
|
||||
The value *dist* is the current length of the bond.
|
||||
The values *dx*, *dy*, and *dz* are the xyz components of the
|
||||
*distance* between the pair of atoms. This value is always the
|
||||
distance from the atom of lower to the one with the higher id.
|
||||
|
||||
The value *engpot* is the potential energy for the bond,
|
||||
based on the current separation of the pair of atoms in the bond.
|
||||
|
||||
@ -13,11 +13,12 @@ Syntax
|
||||
* ID, group-ID are documented in :doc:`compute <compute>` command
|
||||
* pair/local = style name of this compute command
|
||||
* one or more values may be appended
|
||||
* value = *dist* or *eng* or *force* or *fx* or *fy* or *fz* or *pN*
|
||||
* value = *dist* or *dx* or *dy* or *dz* or *eng* or *force* or *fx* or *fy* or *fz* or *pN*
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
*dist* = pairwise distance
|
||||
*dx*,\ *dy*,\ *dz* = components of pairwise distance
|
||||
*eng* = pairwise energy
|
||||
*force* = pairwise force
|
||||
*fx*,\ *fy*,\ *fz* = components of pairwise force
|
||||
@ -56,6 +57,9 @@ force cutoff distance for that interaction, as defined by the
|
||||
commands.
|
||||
|
||||
The value *dist* is the distance between the pair of atoms.
|
||||
The values *dx*, *dy*, and *dz* are the xyz components of the
|
||||
*distance* between the pair of atoms. This value is always the
|
||||
distance from the atom of lower to the one with the higher id.
|
||||
|
||||
The value *eng* is the interaction energy for the pair of atoms.
|
||||
|
||||
@ -89,10 +93,10 @@ from the second of the two sub-styles. If the referenced *pN*
|
||||
is not computed for the specific pairwise interaction (based on
|
||||
atom types), then the output will be 0.0.
|
||||
|
||||
The value *dist* will be in distance :doc:`units <units>`. The value
|
||||
*eng* will be in energy :doc:`units <units>`. The values *force*, *fx*,
|
||||
*fy*, and *fz* will be in force :doc:`units <units>`. The values *pN*
|
||||
will be in whatever units the pair style defines.
|
||||
The value *dist*, *dx*, *dy* and *dz* will be in distance :doc:`units <units>`.
|
||||
The value *eng* will be in energy :doc:`units <units>`.
|
||||
The values *force*, *fx*, *fy*, and *fz* will be in force :doc:`units <units>`.
|
||||
The values *pN* will be in whatever units the pair style defines.
|
||||
|
||||
The optional *cutoff* keyword determines how the force cutoff distance
|
||||
for an interaction is determined. For the default setting of *type*,
|
||||
|
||||
@ -20,8 +20,10 @@ Syntax
|
||||
cutoff = delete one atom from pairs of atoms within the cutoff (distance units)
|
||||
group1-ID = one atom in pair must be in this group
|
||||
group2-ID = other atom in pair must be in this group
|
||||
*porosity* args = region-ID fraction seed
|
||||
*porosity* args = group-ID region-ID fraction seed
|
||||
group-ID = group within which to perform deletions
|
||||
region-ID = region within which to perform deletions
|
||||
or NULL to only impose the group criterion
|
||||
fraction = delete this fraction of atoms
|
||||
seed = random number seed (positive integer)
|
||||
|
||||
@ -43,7 +45,8 @@ Examples
|
||||
delete_atoms region sphere compress no
|
||||
delete_atoms overlap 0.3 all all
|
||||
delete_atoms overlap 0.5 solvent colloid
|
||||
delete_atoms porosity cube 0.1 482793 bond yes
|
||||
delete_atoms porosity all cube 0.1 482793 bond yes
|
||||
delete_atoms porosity polymer cube 0.1 482793 bond yes
|
||||
|
||||
Description
|
||||
"""""""""""
|
||||
@ -76,12 +79,17 @@ have occurred that no atom pairs within the cutoff will remain
|
||||
minimum number of atoms will be deleted, or that the same atoms will
|
||||
be deleted when running on different numbers of processors.
|
||||
|
||||
For style *porosity* a specified *fraction* of atoms are deleted
|
||||
within the specified region. For example, if fraction is 0.1, then
|
||||
10% of the atoms will be deleted. The atoms to delete are chosen
|
||||
randomly. There is no guarantee that the exact fraction of atoms will
|
||||
be deleted, or that the same atoms will be deleted when running on
|
||||
different numbers of processors.
|
||||
For style *porosity* a specified *fraction* of atoms are deleted which
|
||||
are both in the specified group and within the specified region. The
|
||||
region-ID can be specified as NULL to only impose the group criterion.
|
||||
Likewise, specifying the group-ID as *all* will only impose the region
|
||||
criterion.
|
||||
|
||||
For example, if fraction is 0.1, then 10% of the eligible atoms will
|
||||
be deleted. The atoms to delete are chosen randomly. There is no
|
||||
guarantee that the exact fraction of atoms will be deleted, or that
|
||||
the same atoms will be deleted when running on different numbers of
|
||||
processors.
|
||||
|
||||
If the *compress* keyword is set to *yes*, then after atoms are
|
||||
deleted, then atom IDs are re-assigned so that they run from 1 to the
|
||||
@ -89,8 +97,8 @@ number of atoms in the system. Note that this is not done for
|
||||
molecular systems (see the :doc:`atom_style <atom_style>` command),
|
||||
regardless of the *compress* setting, since it would foul up the bond
|
||||
connectivity that has already been assigned. However, the
|
||||
:doc:`reset_atom_ids <reset_atom_ids>` command can be used after this command to
|
||||
accomplish the same thing.
|
||||
:doc:`reset_atom_ids <reset_atom_ids>` command can be used after this
|
||||
command to accomplish the same thing.
|
||||
|
||||
Note that the re-assignment of IDs is not really a compression, where
|
||||
gaps in atom IDs are removed by decrementing atom IDs that are larger.
|
||||
@ -100,15 +108,15 @@ the :doc:`create_atoms <create_atoms>` command explains.
|
||||
|
||||
A molecular system with fixed bonds, angles, dihedrals, or improper
|
||||
interactions, is one where the topology of the interactions is
|
||||
typically defined in the data file read by the
|
||||
:doc:`read_data <read_data>` command, and where the interactions
|
||||
themselves are defined with the :doc:`bond_style <bond_style>`,
|
||||
:doc:`angle_style <angle_style>`, etc commands. If you delete atoms
|
||||
from such a system, you must be careful not to end up with bonded
|
||||
interactions that are stored by remaining atoms but which include
|
||||
deleted atoms. This will cause LAMMPS to generate a "missing atoms"
|
||||
error when the bonded interaction is computed. The *bond* and *mol*
|
||||
keywords offer two ways to do that.
|
||||
typically defined in the data file read by the :doc:`read_data
|
||||
<read_data>` command, and where the interactions themselves are
|
||||
defined with the :doc:`bond_style <bond_style>`, :doc:`angle_style
|
||||
<angle_style>`, etc commands. If you delete atoms from such a system,
|
||||
you must be careful not to end up with bonded interactions that are
|
||||
stored by remaining atoms but which include deleted atoms. This will
|
||||
cause LAMMPS to generate a "missing atoms" error when the bonded
|
||||
interaction is computed. The *bond* and *mol* keywords offer two ways
|
||||
to do that.
|
||||
|
||||
It the *bond* keyword is set to *yes* then any bond or angle or
|
||||
dihedral or improper interaction that includes a deleted atom is also
|
||||
|
||||
@ -710,7 +710,9 @@ default and it can be disabled with the :code:`checksum` keyword.
|
||||
|
||||
Restrictions
|
||||
""""""""""""
|
||||
none
|
||||
|
||||
Not all *dump_modify* options can be applied to all dump styles.
|
||||
Details are in the discussions of the individual options.
|
||||
|
||||
Related commands
|
||||
""""""""""""""""
|
||||
|
||||
@ -205,7 +205,7 @@ For *damping mass_velocity*, the normal damping is given by:
|
||||
\eta_n = \eta_{n0} m_{eff}
|
||||
|
||||
Here, :math:`\eta_{n0}` is the damping coefficient specified for the normal
|
||||
contact model, in units of *mass*\ /\ *time* and
|
||||
contact model, in units of 1/\ *time* and
|
||||
:math:`m_{eff} = m_i m_j/(m_i + m_j)` is the effective mass.
|
||||
Use *damping mass_velocity* to reproduce the damping behavior of
|
||||
*pair gran/hooke/\**.
|
||||
|
||||
@ -74,14 +74,17 @@ atoms interact with each other via an *eam* potential, the surface atoms
|
||||
interact with each other via a *lj/cut* potential, and the metal/surface
|
||||
interaction is also computed via a *lj/cut* potential. The
|
||||
*hybrid/overlay* style could be used as in the second example above,
|
||||
where multiple potentials are superposed in an additive fashion to
|
||||
where multiple potentials are superimposed in an additive fashion to
|
||||
compute the interaction between atoms. In this example, using *lj/cut*
|
||||
and *coul/long* together gives the same result as if the
|
||||
*lj/cut/coul/long* potential were used by itself. In this case, it
|
||||
would be more efficient to use the single combined potential, but in
|
||||
general any combination of pair potentials can be used together in to
|
||||
produce an interaction that is not encoded in any single pair_style
|
||||
file, e.g. adding Coulombic forces between granular particles.
|
||||
file, e.g. adding Coulombic forces between granular particles. Another
|
||||
limitation of using the *hybrid/overlay* variant, that it does not generate
|
||||
*lj/cut* parameters for mixed atom types from a mixing rule due to
|
||||
restrictions discussed below.
|
||||
|
||||
If the *hybrid/scaled* style is used instead of *hybrid/overlay*,
|
||||
contributions from sub-styles are weighted by their scale factors, which
|
||||
@ -150,10 +153,14 @@ with Tersoff, and the cross-interactions with Lennard-Jones:
|
||||
pair_coeff * * tersoff 2 C.tersoff NULL C
|
||||
pair_coeff 1 2 lj/cut 1.0 1.5
|
||||
|
||||
If pair coefficients are specified in the data file read via the
|
||||
:doc:`read_data <read_data>` command, then the same rule applies.
|
||||
E.g. "eam/alloy" or "lj/cut" must be added after the atom type, for
|
||||
each line in the "Pair Coeffs" section, e.g.
|
||||
|
||||
It is not recommended to read pair coefficients for a hybrid style from a "Pair Coeffs"
|
||||
or "PairIJ Coeffs" section of a data file via the :doc:`read_data <read_data>` command,
|
||||
since those sections expect a fixed number of lines, either one line per atom type or
|
||||
one line pair pair of atom types, respectively. When reading from a data file, the
|
||||
lines of the "Pair Coeffs" and "PairIJ Coeffs" are changed in the same way as the *pair_coeff*
|
||||
command, i.e. the name of the pair style to which the parameters apply must follow the
|
||||
atom type (or atom types), e.g.
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
@ -162,6 +169,11 @@ each line in the "Pair Coeffs" section, e.g.
|
||||
1 lj/cut/coul/cut 1.0 1.0
|
||||
...
|
||||
|
||||
PairIJ Coeffs
|
||||
|
||||
1 1 lj/cut/coul/cut 1.0 1.0
|
||||
...
|
||||
|
||||
Note that the pair_coeff command for some potentials such as
|
||||
:doc:`pair_style eam/alloy <pair_eam>` includes a mapping specification
|
||||
of elements to all atom types, which in the hybrid case, can include
|
||||
@ -208,12 +220,22 @@ examples above, or in the data file read by the :doc:`read_data
|
||||
<read_data>`, or by mixing as described below. Also all sub-styles
|
||||
must be used at least once in a :doc:`pair_coeff <pair_coeff>` command.
|
||||
|
||||
.. note::
|
||||
.. warning::
|
||||
|
||||
LAMMPS never performs mixing of parameters from different sub-styles,
|
||||
**even** if they use the same type of coefficients, e.g. contain
|
||||
a Lennard-Jones potential variant. Those parameters must be provided
|
||||
explicitly.
|
||||
With hybrid pair styles the use of mixing to generate pair
|
||||
coefficients is significantly limited compared to the individual pair
|
||||
styles. LAMMPS **never** performs mixing of parameters from
|
||||
different sub-styles, **even** if they use the same type of
|
||||
coefficients, e.g. contain a Lennard-Jones potential variant. Those
|
||||
parameters must be provided explicitly. Also for *hybrid/overlay*
|
||||
and *hybrid/scaled* mixing is **only** performed for pairs of atom
|
||||
types for which only a single pair style is assigned.
|
||||
|
||||
Thus it is strongly recommended to provide all mixed terms
|
||||
explicitly. For non-hybrid styles those could be generated and
|
||||
written out using the :doc:`write_coeff command <write_coeff>` and
|
||||
then edited as needed to comply with the requirements for hybrid
|
||||
styles as explained above.
|
||||
|
||||
If you want there to be no interactions between a particular pair of
|
||||
atom types, you have 3 choices. You can assign the pair of atom types
|
||||
|
||||
@ -26,15 +26,29 @@ Examples
|
||||
Description
|
||||
"""""""""""
|
||||
|
||||
The *lebedeva/z* style computes the Lebedeva interaction
|
||||
potential as described in :ref:`(Lebedeva et al.) <Leb01>`. An important simplification is made,
|
||||
which is to take all normals along the z-axis.
|
||||
The *lebedeva/z* pair style computes the Lebedeva interaction potential
|
||||
as described in :ref:`(Lebedeva1) <Leb01>` and :ref:`(Lebedeva2)
|
||||
<Leb02>`. An important simplification is made, which is to take all
|
||||
normals along the z-axis.
|
||||
|
||||
The Lebedeva potential is intended for the description of the interlayer
|
||||
interaction between graphene layers. To perform a realistic simulation,
|
||||
this potential must be used in combination with an intralayer potential
|
||||
such as :doc:`AIREBO <pair_airebo>` or :doc:`Tersoff <pair_tersoff>`
|
||||
facilitated by using pair style :doc:`hybrid/overlay <pair_hybrid>`. To
|
||||
keep the intralayer properties unaffected, the interlayer interaction
|
||||
within the same layers should be avoided. This can be achieved by
|
||||
assigning different atom types to atoms of different layers (e.g. 1 and
|
||||
2 in the examples above).
|
||||
|
||||
Other interactions can be set to zero using pair_style *none*\ .
|
||||
|
||||
|
||||
.. math::
|
||||
|
||||
E = & \frac{1}{2} \sum_i \sum_{i \neq j} V_{ij}\\
|
||||
E = & \frac{1}{2} \sum_i \sum_{j \neq i} V_{ij}\\
|
||||
V_{ij} = & B e^{-\alpha(r_{ij} - z_0)} \\
|
||||
& + C(1 + D_1\rho^2_{ij} + D_2\rho^4_{ij} e^{-\lambda_1\rho^2_{ij}} e^{-\lambda_2 (z^2_{ij} - z^2_0)} \\
|
||||
& + C(1 + D_1\rho^2_{ij} + D_2\rho^4_{ij}) e^{-\lambda_1\rho^2_{ij}} e^{-\lambda_2 (z^2_{ij} - z^2_0)} \\
|
||||
& - A \left(\frac{z_0}{r_ij}\right)^6 + A \left( \frac{z_0}{r_c} \right)^6 \\
|
||||
\rho^2_{ij} = & x^2_{ij} + y^2_{ij} \qquad (\mathbf{n_i} \equiv \mathbf{\hat{z}})
|
||||
|
||||
@ -43,12 +57,15 @@ Energies are shifted so that they go continuously to zero at the cutoff assuming
|
||||
that the exponential part of :math:`V_{ij}` (first term) decays sufficiently fast.
|
||||
This shift is achieved by the last term in the equation for :math:`V_{ij}` above.
|
||||
|
||||
The parameter file (e.g. CC.Lebedeva), is intended for use with metal
|
||||
:doc:`units <units>`, with energies in meV. An additional parameter, *S*,
|
||||
is available to facilitate scaling of energies.
|
||||
The provided parameter file (CC.Lebedeva) contains two sets of parameters.
|
||||
|
||||
This potential must be used in combination with hybrid/overlay.
|
||||
Other interactions can be set to zero using pair_style *none*\ .
|
||||
- The first set (element name "C") is suitable for normal conditions and
|
||||
is taken from :ref:`(Popov1) <Popov>`
|
||||
- The second set (element name "C1") is suitable for high-pressure
|
||||
conditions and is taken from :ref:`(Koziol1) <Koziol>`
|
||||
|
||||
Both sets contain an additional parameter, *S*, that can be used to
|
||||
facilitate scaling of energies and is set to 1.0 by default.
|
||||
|
||||
Restrictions
|
||||
""""""""""""
|
||||
@ -77,4 +94,16 @@ none
|
||||
|
||||
.. _Leb01:
|
||||
|
||||
**(Lebedeva et al.)** I. V. Lebedeva, A. A. Knizhnik, A. M. Popov, Y. E. Lozovik, B. V. Potapkin, Phys. Rev. B, 84, 245437 (2011)
|
||||
**(Lebedeva1)** I. V. Lebedeva, A. A. Knizhnik, A. M. Popov, Y. E. Lozovik, B. V. Potapkin, Phys. Rev. B, 84, 245437 (2011)
|
||||
|
||||
.. _Leb02:
|
||||
|
||||
**(Lebedeva2)** I. V. Lebedeva, A. A. Knizhnik, A. M. Popov, Y. E. Lozovik, B. V. Potapkin, Physica E: 44, 949-954 (2012)
|
||||
|
||||
.. _Popov:
|
||||
|
||||
**(Popov1)** A.M. Popov, I. V. Lebedeva, A. A. Knizhnik, Y. E. Lozovik and B. V. Potapkin, Chem. Phys. Lett. 536, 82-86 (2012).
|
||||
|
||||
.. _Koziol:
|
||||
|
||||
**(Koziol1)** Z. Koziol, G. Gawlik and J. Jagielski, Chinese Phys. B 28, 096101 (2019).
|
||||
|
||||
@ -71,21 +71,23 @@ The *mix* keyword affects pair coefficients for interactions between
|
||||
atoms of type I and J, when I != J and the coefficients are not
|
||||
explicitly set in the input script. Note that coefficients for I = J
|
||||
must be set explicitly, either in the input script via the
|
||||
:doc:`pair_coeff <pair_coeff>` command or in the "Pair Coeffs" section of the
|
||||
:doc:`data file <read_data>`. For some pair styles it is not
|
||||
:doc:`pair_coeff <pair_coeff>` command or in the "Pair Coeffs" or "PairIJ Coeffs"
|
||||
sections of the :doc:`data file <read_data>`. For some pair styles it is not
|
||||
necessary to specify coefficients when I != J, since a "mixing" rule
|
||||
will create them from the I,I and J,J settings. The pair_modify
|
||||
*mix* value determines what formulas are used to compute the mixed
|
||||
coefficients. In each case, the cutoff distance is mixed the same way
|
||||
as sigma.
|
||||
|
||||
Note that not all pair styles support mixing and some mix options
|
||||
are not available for certain pair styles. Also, there are additional
|
||||
restrictions when using :doc:`pair style hybrid or hybrid/overlay <pair_hybrid>`.
|
||||
See the page for individual pair styles for those restrictions. Note also that the
|
||||
:doc:`pair_coeff <pair_coeff>` command also can be used to directly set
|
||||
coefficients for a specific I != J pairing, in which case no mixing is
|
||||
performed.
|
||||
Note that not all pair styles support mixing and some mix options are
|
||||
not available for certain pair styles. Also, there are additional
|
||||
restrictions when using :doc:`pair style hybrid or hybrid/overlay
|
||||
<pair_hybrid>`. See the page for individual pair styles for those
|
||||
restrictions. Note also that the :doc:`pair_coeff <pair_coeff>` command
|
||||
also can be used to directly set coefficients for a specific I != J
|
||||
pairing, in which case no mixing is performed. If possible, LAMMPS will
|
||||
print an informational message about how many of the mixed pair
|
||||
coefficients were generated and which mixing rule was applied.
|
||||
|
||||
- mix *geometric*
|
||||
|
||||
|
||||
Reference in New Issue
Block a user