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

Merge branch 'master' into pair_drip

Browse Source
This commit is contained in:
Axel Kohlmeyer
2019-05-09 12:19:41 -04:00
parent da6e576ffd 928600a878
commit 47cf17e5c8
191 changed files with 47351 additions and 2349 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
doc/src/Build_extras.txt
View File

@ -247,7 +247,10 @@ Maxwell50 = NVIDIA Maxwell generation CC 5.0
Maxwell52 = NVIDIA Maxwell generation CC 5.2
Maxwell53 = NVIDIA Maxwell generation CC 5.3
Pascal60 = NVIDIA Pascal generation CC 6.0
Pascal61 = NVIDIA Pascal generation CC 6.1 :ul
Pascal61 = NVIDIA Pascal generation CC 6.1
Volta70 = NVIDIA Volta generation CC 7.0
Volta72 = NVIDIA Volta generation CC 7.2
Turing75 = NVIDIA Turing generation CC 7.5 :ul
[CMake build]:

1
doc/src/Commands_all.txt
View File

@ -83,6 +83,7 @@ An alphabetic list of all general LAMMPS commands.
"molecule"_molecule.html,
"ndx2group"_group2ndx.html,
"neb"_neb.html,
"neb_spin"_neb_spin.html,
"neigh_modify"_neigh_modify.html,
"neighbor"_neighbor.html,
"newton"_newton.html,

1
doc/src/Commands_category.txt
View File

@ -116,6 +116,7 @@ Actions:
"minimize"_minimize.html,
"neb"_neb.html,
"neb_spin"_neb_spin.html,
"prd"_prd.html,
"rerun"_rerun.html,
"run"_run.html,

1
doc/src/Commands_fix.txt
View File

@ -107,6 +107,7 @@ OPT.
"mvv/edpd"_fix_mvv_dpd.html,
"mvv/tdpd"_fix_mvv_dpd.html,
"neb"_fix_neb.html,
"neb_spin"_fix_neb_spin.html,
"nph (ko)"_fix_nh.html,
"nph/asphere (o)"_fix_nph_asphere.html,
"nph/body"_fix_nph_body.html,

BIN
doc/src/Eqs/neb_spin_angle.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 9.4 KiB

15
doc/src/Eqs/neb_spin_angle.tex Normal file
View File

@ -0,0 +1,15 @@
\documentclass[preview]{standalone}
\usepackage{varwidth}
\usepackage[utf8x]{inputenc}
\usepackage{amsmath, amssymb, graphics, setspace}
\begin{document}
\begin{varwidth}{50in}
\begin{equation}
\omega_i^{\nu} =
(\nu - 1) \Delta \omega_i
{\rm ~~and~~} \Delta \omega_i = \frac{\omega_i}{Q-1}
, \nonumber
\end{equation}
\end{varwidth}
\end{document}

BIN
doc/src/Eqs/neb_spin_k.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 8.2 KiB

16
doc/src/Eqs/neb_spin_k.tex Normal file
View File

@ -0,0 +1,16 @@
\documentclass[preview]{standalone}
\usepackage{varwidth}
\usepackage[utf8x]{inputenc}
\usepackage{amsmath, amssymb, graphics, setspace}
\begin{document}
\begin{varwidth}{50in}
\begin{equation}
\vec{k}_i =
\frac{\vec{m}_i^I \times \vec{m}_i^F}{\left|\vec{m}_i^I
\times \vec{m}_i^F\right|}
%&{\rm ~if~}& \vec{m}_i^I \times \vec{m}_i^F
, \nonumber
\end{equation}
\end{varwidth}
\end{document}

BIN
doc/src/Eqs/neb_spin_rodrigues_formula.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 20 KiB

16
doc/src/Eqs/neb_spin_rodrigues_formula.tex Normal file
View File

@ -0,0 +1,16 @@
\documentclass[preview]{standalone}
\usepackage{varwidth}
\usepackage[utf8x]{inputenc}
\usepackage{amsmath, amssymb, graphics, setspace}
\begin{document}
\begin{varwidth}{50in}
\begin{equation}
\vec{m}_i^{\nu} = \vec{m}_i^{I} \cos(\omega_i^{\nu})
+ (\vec{k}_i \times \vec{m}_i^{I}) \sin(\omega_i^{\nu})
+ (1.0-\cos(\omega_i^{\nu})) \vec{k}_i (\vec{k}_i\cdot
\vec{m}_i^{I})
, \nonumber
\end{equation}
\end{varwidth}
\end{document}

BIN
doc/src/Eqs/pair_mdf-6.jpg
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 2.4 KiB

After

Width:  |  Height:  |  Size: 2.5 KiB

4
doc/src/Eqs/pair_mdf-6.tex
View File

@ -1,9 +1,9 @@
\documentclass[12pt]{article}
\pagestyle{empty}
\begin{document}
$$
E(r) = \frac{A}{r^{12}} - \frac{A}{r^{6}}
E(r) = \frac{A}{r^{12}} - \frac{B}{r^{6}}
$$
\end{document}

1
doc/src/Howto_replica.txt
View File

@ -17,6 +17,7 @@ periodically.
These are the relevant commands:
"neb"_neb.html for nudged elastic band calculations
"neb_spin"_neb_spin.html for magnetic nudged elastic band calculations
"prd"_prd.html for parallel replica dynamics
"tad"_tad.html for temperature accelerated dynamics
"temper"_temper.html for parallel tempering

23
doc/src/Howto_spins.txt
View File

@ -10,7 +10,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
Magnetic spins :h3
The magnetic spin simulations are enabled by the SPIN package, whose
implementation is detailed in "Tranchida"_#Tranchida7.
implementation is detailed in "Tranchida"_#Tranchida.
The model represents the simulation of atomic magnetic spins coupled
to lattice vibrations. The dynamics of those magnetic spins can be used
@ -36,13 +36,28 @@ A Langevin thermostat can be applied to those magnetic spins using
"fix langevin/spin"_fix_langevin_spin.html. Typically, this thermostat
can be coupled to another Langevin thermostat applied to the atoms
using "fix langevin"_fix_langevin.html in order to simulate
thermostatted spin-lattice system.
thermostatted spin-lattice systems.
The magnetic Gilbert damping can also be applied using "fix
langevin/spin"_fix_langevin_spin.html. It allows to either dissipate
the thermal energy of the Langevin thermostat, or to perform a
relaxation of the magnetic configuration toward an equilibrium state.
The command "fix setforce/spin"_fix_setforce.html allows to set the
components of the magnetic precession vectors (while erasing and
replacing the previously computed magnetic precession vectors on
the atom).
This command can be used to freeze the magnetic moment of certain
atoms in the simulation by zeroing their precession vector.
The command "fix nve/spin"_fix_nve_spin.html can be used to
perform a symplectic integration of the combined dynamics of spins
and atomic motions.
The minimization style "min/spin"_min_spin.html can be applied
to the spins to perform a minimization of the spin configuration.
All the computed magnetic properties can be output by two main
commands. The first one is "compute spin"_compute_spin.html, that
enables to evaluate magnetic averaged quantities, such as the total
@ -54,6 +69,6 @@ magnetic spin, or the magnetic force acting on this spin.
:line
:link(Tranchida7)
:link(Tranchida)
[(Tranchida)] Tranchida, Plimpton, Thibaudeau and Thompson,
arXiv preprint arXiv:1801.10233, (2018).
Journal of Computational Physics, 372, 406-425, (2018).

4
doc/src/Manual.txt
View File

@ -1,7 +1,7 @@
<!-- HTML_ONLY -->
<HEAD>
<TITLE>LAMMPS Users Manual</TITLE>
<META NAME="docnumber" CONTENT="29 Mar 2019 version">
<META NAME="docnumber" CONTENT="30 Apr 2019 version">
<META NAME="author" CONTENT="http://lammps.sandia.gov - Sandia National Laboratories">
<META NAME="copyright" CONTENT="Copyright (2003) Sandia Corporation. This software and manual is distributed under the GNU General Public License.">
</HEAD>
@ -21,7 +21,7 @@
:line
LAMMPS Documentation :c,h1
29 Mar 2019 version :c,h2
30 Apr 2019 version :c,h2
"What is a LAMMPS version?"_Manual_version.html

BIN
doc/src/PDF/colvars-refman-lammps.pdf
View File

Binary file not shown.

1
doc/src/Packages_details.txt
View File

@ -918,6 +918,7 @@ src/SPIN: filenames -> commands
"fix nve/spin"_fix_nve_spin.html
"fix precession/spin"_fix_precession_spin.html
"compute spin"_compute_spin.html
"neb/spin"_neb_spin.html
examples/SPIN :ul
:line

61
doc/src/Speed_kokkos.txt
View File

@ -111,16 +111,10 @@ Makefile.kokkos_mpi_only) will give better performance than the OpenMP
back end (i.e. Makefile.kokkos_omp) because some of the overhead to make
the code thread-safe is removed.
NOTE: The default for the "package kokkos"_package.html command is to
use "full" neighbor lists and set the Newton flag to "off" for both
pairwise and bonded interactions. However, when running on CPUs, it
will typically be faster to use "half" neighbor lists and set the
Newton flag to "on", just as is the case for non-accelerated pair
styles. It can also be faster to use non-threaded communication. Use
the "-pk kokkos" "command-line switch"_Run_options.html to change the
default "package kokkos"_package.html options. See its doc page for
details and default settings. Experimenting with its options can
provide a speed-up for specific calculations. For example:
NOTE: Use the "-pk kokkos" "command-line switch"_Run_options.html to
change the default "package kokkos"_package.html options. See its doc
page for details and default settings. Experimenting with its options
can provide a speed-up for specific calculations. For example:
mpirun -np 16 lmp_kokkos_mpi_only -k on -sf kk -pk kokkos newton on neigh half comm no -in in.lj # Newton on, Half neighbor list, non-threaded comm :pre
@ -190,19 +184,18 @@ tasks/node. The "-k on t Nt" command-line switch sets the number of
threads/task as Nt. The product of these two values should be N, i.e.
256 or 264.
NOTE: The default for the "package kokkos"_package.html command is to
use "full" neighbor lists and set the Newton flag to "off" for both
pairwise and bonded interactions. When running on KNL, this will
typically be best for pair-wise potentials. For many-body potentials,
using "half" neighbor lists and setting the Newton flag to "on" may be
faster. It can also be faster to use non-threaded communication. Use
the "-pk kokkos" "command-line switch"_Run_options.html to change the
default "package kokkos"_package.html options. See its doc page for
details and default settings. Experimenting with its options can
provide a speed-up for specific calculations. For example:
NOTE: The default for the "package kokkos"_package.html command when
running on KNL is to use "half" neighbor lists and set the Newton flag
to "on" for both pairwise and bonded interactions. This will typically
be best for many-body potentials. For simpler pair-wise potentials, it
may be faster to use a "full" neighbor list with Newton flag to "off".
Use the "-pk kokkos" "command-line switch"_Run_options.html to change
the default "package kokkos"_package.html options. See its doc page for
details and default settings. Experimenting with its options can provide
a speed-up for specific calculations. For example:
mpirun -np 64 lmp_kokkos_phi -k on t 4 -sf kk -pk kokkos comm no -in in.lj # Newton off, full neighbor list, non-threaded comm
mpirun -np 64 lmp_kokkos_phi -k on t 4 -sf kk -pk kokkos newton on neigh half comm no -in in.reax # Newton on, half neighbor list, non-threaded comm :pre
mpirun -np 64 lmp_kokkos_phi -k on t 4 -sf kk -pk kokkos comm host -in in.reax # Newton on, half neighbor list, threaded comm
mpirun -np 64 lmp_kokkos_phi -k on t 4 -sf kk -pk kokkos newton off neigh full comm no -in in.lj # Newton off, full neighbor list, non-threaded comm :pre
NOTE: MPI tasks and threads should be bound to cores as described
above for CPUs.
@ -236,19 +229,19 @@ one or more nodes, each with two GPUs:
mpirun -np 2 lmp_kokkos_cuda_openmpi -k on g 2 -sf kk -in in.lj # 1 node, 2 MPI tasks/node, 2 GPUs/node
mpirun -np 32 -ppn 2 lmp_kokkos_cuda_openmpi -k on g 2 -sf kk -in in.lj # 16 nodes, 2 MPI tasks/node, 2 GPUs/node (32 GPUs total) :pre
NOTE: The default for the "package kokkos"_package.html command is to
use "full" neighbor lists and set the Newton flag to "off" for both
pairwise and bonded interactions, along with threaded communication.
When running on Maxwell or Kepler GPUs, this will typically be
best. For Pascal GPUs, using "half" neighbor lists and setting the
Newton flag to "on" may be faster. For many pair styles, setting the
neighbor binsize equal to the ghost atom cutoff will give speedup.
Use the "-pk kokkos" "command-line switch"_Run_options.html to change
the default "package kokkos"_package.html options. See its doc page
for details and default settings. Experimenting with its options can
provide a speed-up for specific calculations. For example:
NOTE: The default for the "package kokkos"_package.html command when
running on GPUs is to use "full" neighbor lists and set the Newton flag
to "off" for both pairwise and bonded interactions, along with threaded
communication. When running on Maxwell or Kepler GPUs, this will
typically be best. For Pascal GPUs, using "half" neighbor lists and
setting the Newton flag to "on" may be faster. For many pair styles,
setting the neighbor binsize equal to twice the CPU default value will
give speedup, which is the default when running on GPUs. Use the "-pk
kokkos" "command-line switch"_Run_options.html to change the default
"package kokkos"_package.html options. See its doc page for details and
default settings. Experimenting with its options can provide a speed-up
for specific calculations. For example:
mpirun -np 2 lmp_kokkos_cuda_openmpi -k on g 2 -sf kk -pk kokkos binsize 2.8 -in in.lj # Set binsize = neighbor ghost cutoff
mpirun -np 2 lmp_kokkos_cuda_openmpi -k on g 2 -sf kk -pk kokkos newton on neigh half binsize 2.8 -in in.lj # Newton on, half neighbor list, set binsize = neighbor ghost cutoff :pre
NOTE: For good performance of the KOKKOS package on GPUs, you must

1
doc/src/commands_list.txt
View File

@ -67,6 +67,7 @@ Commands :h1
minimize
molecule
neb
neb_spin
neigh_modify
neighbor
newton

10
doc/src/fix_colvars.txt
View File

@ -98,6 +98,16 @@ fix to add the energy change from the biasing force added by the fix
to the system's potential energy as part of "thermodynamic
output"_thermo_style.html.
The {fix_modify configfile <config file>} option allows to add settings
from an additional config file to the colvars module. This option can
only be used, after the system has been initialized with a "run"_run.html
command.
The {fix_modify config <quoted string>} option allows to add settings
from inline strings. Those have to fit on a single line when enclosed
in a pair of double quotes ("), or can span multiple lines when bracketed
by a pair of triple double quotes (""", like python embedded documentation).
This fix computes a global scalar which can be accessed by various
"output commands"_Howto_output.html. The scalar is the cumulative
energy change due to this fix. The scalar value calculated by this

2
doc/src/fix_langevin_spin.txt
View File

@ -99,4 +99,4 @@ integration fix (e.g. {fix nve/spin}).
:link(Tranchida2)
[(Tranchida)] Tranchida, Plimpton, Thibaudeau and Thompson,
Journal of Computational Physics, (2018).
Journal of Computational Physics, 372, 406-425, (2018).

6
doc/src/fix_neb.txt
View File

@ -97,7 +97,7 @@ Note that in this case the specified {Kspring} is in force/distance
units.
With a value of {ideal}, the spring force is computed as suggested in
"(WeinenE)"_#WeinenE :
"(WeinanE)"_#WeinanE :
Fnudge_parallel = -{Kspring} * (RD-RDideal) / (2 * meanDist) :pre
@ -224,8 +224,8 @@ specified (no inter-replica force on the end replicas).
[(Henkelman2)] Henkelman, Uberuaga, Jonsson, J Chem Phys, 113,
9901-9904 (2000).
:link(WeinenE)
[(WeinenE)] E, Ren, Vanden-Eijnden, Phys Rev B, 66, 052301 (2002).
:link(WeinanE)
[(WeinanE)] E, Ren, Vanden-Eijnden, Phys Rev B, 66, 052301 (2002).
:link(Jonsson)
[(Jonsson)] Jonsson, Mills and Jacobsen, in Classical and Quantum

76
doc/src/fix_neb_spin.txt Normal file
View File

@ -0,0 +1,76 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
fix neb/spin command :h3
[Syntax:]
fix ID group-ID neb/spin Kspring :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
neb/spin = style name of this fix command :l
Kspring = spring constant for parallel nudging force
(force/distance units or force units, see parallel keyword) :pre,ule
[Examples:]
fix 1 active neb/spin 1.0
[Description:]
Add nudging forces to spins in the group for a multi-replica
simulation run via the "neb/spin"_neb_spin.html command to perform a
geodesic nudged elastic band (GNEB) calculation for finding the
transition state.
Hi-level explanations of GNEB are given with the
"neb/spin"_neb_spin.html command and on the
"Howto replica"_Howto_replica.html doc page.
The fix neb/spin command must be used with the "neb/spin" command and
defines how inter-replica nudging forces are computed. A GNEB
calculation is divided in two stages. In the first stage n replicas
are relaxed toward a MEP until convergence. In the second stage, the
climbing image scheme is enabled, so that the replica having the highest
energy relaxes toward the saddle point (i.e. the point of highest energy
along the MEP), and a second relaxation is performed.
The nudging forces are calculated as explained in
"(BessarabB)"_#BessarabB).
See this reference for more explanation about their expression.
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various "output commands"_Howto_output.html.
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command.
The forces due to this fix are imposed during an energy minimization,
as invoked by the "minimize"_minimize.html command via the
"neb/spin"_neb_spin.html command.
[Restrictions:]
This command can only be used if LAMMPS was built with the SPIN
package. See the "Build package"_Build_package.html doc
page for more info.
[Related commands:]
"neb_spin"_neb_spin.html
[Default:]
none
:line
:link(BessarabB)
[(BessarabB)] Bessarab, Uzdin, Jonsson, Comp Phys Comm, 196,
335-347 (2015).

2
doc/src/fix_nve_spin.txt
View File

@ -73,4 +73,4 @@ instead of "array" is also valid.
:link(Tranchida1)
[(Tranchida)] Tranchida, Plimpton, Thibaudeau and Thompson,
Journal of Computational Physics, (2018).
Journal of Computational Physics, 372, 406-425, (2018).

2
doc/src/fix_precession_spin.txt
View File

@ -31,7 +31,7 @@ fix 1 all precession/spin zeeman 0.1 0.0 0.0 1.0 anisotropy 0.001 0.0 0.0 1.0 :p
[Description:]
Impose a force torque to each magnetic spin in the group.
This fix applies a precession torque to each magnetic spin in the group.
Style {zeeman} is used for the simulation of the interaction
between the magnetic spins in the defined group and an external

17
doc/src/fix_print.txt
View File

@ -14,7 +14,7 @@ fix ID group-ID print N string keyword value ... :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
print = style name of this fix command :l
N = print every N steps :l
N = print every N steps; N can be a variable (see below) :l
string = text string to print with optional variable names :l
zero or more keyword/value pairs may be appended :l
keyword = {file} or {append} or {screen} or {title} :l
@ -40,6 +40,21 @@ If it contains variables it must be enclosed in double quotes to
insure they are not evaluated when the input script line is read, but
will instead be evaluated each time the string is printed.
Instead of a numeric value, N can be specified as an "equal-style
variable"_variable.html, which should be specified as v_name, where
name is the variable name. In this case, the variable is evaluated at
the beginning of a run to determine the [next] timestep at which the
string will be written out. On that timestep, the variable will be
evaluated again to determine the next timestep, etc.
Thus the variable should return timestep values. See the stagger()
and logfreq() and stride() math functions for "equal-style
variables"_variable.html, as examples of useful functions to use in
this context. For example, the following commands will print output at
timesteps 10,20,30,100,200,300,1000,2000,etc:
variable s equal logfreq(10,3,10)
fix extra all print v_s "Coords of marker atom = $x $y $z" :pre
The specified group-ID is ignored by this fix.
See the "variable"_variable.html command for a description of {equal}

20
doc/src/fix_setforce.txt
View File

@ -8,6 +8,7 @@
fix setforce command :h3
fix setforce/kk command :h3
fix setforce/spin command :h3
[Syntax:]
@ -27,6 +28,7 @@ keyword = {region} :l
fix freeze indenter setforce 0.0 0.0 0.0
fix 2 edge setforce NULL 0.0 0.0
fix 1 edge setforce/spin 0.0 0.0 0.0
fix 2 edge setforce NULL 0.0 v_oscillate :pre
[Description:]
@ -65,6 +67,19 @@ to it.
:line
Style {spin} suffix sets the components of the magnetic precession
vectors instead of the mechanical forces. This also erases all
previously computed magnetic precession vectors on the atom, though
additional magnetic fixes could add new forces.
This command can be used to freeze the magnetic moment of certain
atoms in the simulation by zeroing their precession vector.
All options defined above remain valid, they just apply to the magnetic
precession vectors instead of the forces.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
@ -117,7 +132,10 @@ forces to any value besides zero when performing a minimization. Use
the "fix addforce"_fix_addforce.html command if you want to apply a
non-zero force to atoms during a minimization.
[Restrictions:] none
[Restrictions:]
The fix {setforce/spin} only makes sense when LAMMPS was built with the
SPIN package.
[Related commands:]

22
doc/src/fix_wall_gran.txt
View File

@ -17,13 +17,13 @@ wall/gran = style name of this fix command :l
fstyle = style of force interactions between particles and wall :l
possible choices: hooke, hooke/history, hertz/history, granular :pre
fstyle_params = parameters associated with force interaction style :l
For {hooke}, {hooke/history}, and {hertz/history}, {fstyle_params} are:
Kn = elastic constant for normal particle repulsion (force/distance units or pressure units - see discussion below)
Kt = elastic constant for tangential contact (force/distance units or pressure units - see discussion below)
gamma_n = damping coefficient for collisions in normal direction (1/time units or 1/time-distance units - see discussion below)
gamma_t = damping coefficient for collisions in tangential direction (1/time units or 1/time-distance units - see discussion below)
xmu = static yield criterion (unitless value between 0.0 and 1.0e4)
dampflag = 0 or 1 if tangential damping force is excluded or included :pre
For {hooke}, {hooke/history}, and {hertz/history}, {fstyle_params} are:
Kn = elastic constant for normal particle repulsion (force/distance units or pressure units - see discussion below)
Kt = elastic constant for tangential contact (force/distance units or pressure units - see discussion below)
gamma_n = damping coefficient for collisions in normal direction (1/time units or 1/time-distance units - see discussion below)
gamma_t = damping coefficient for collisions in tangential direction (1/time units or 1/time-distance units - see discussion below)
xmu = static yield criterion (unitless value between 0.0 and 1.0e4)
dampflag = 0 or 1 if tangential damping force is excluded or included :pre
For {granular}, {fstyle_params} are set using the same syntax as for the {pair_coeff} command of "pair_style granular"_pair_granular.html :pre
wallstyle = {xplane} or {yplane} or {zplane} or {zcylinder} :l
args = list of arguments for a particular style :l
@ -46,10 +46,10 @@ keyword = {wiggle} or {shear} :l
fix 1 all wall/gran hooke 200000.0 NULL 50.0 NULL 0.5 0 xplane -10.0 10.0
fix 1 all wall/gran hooke/history 200000.0 NULL 50.0 NULL 0.5 0 zplane 0.0 NULL
fix 2 all wall/gran hooke 100000.0 20000.0 50.0 30.0 0.5 1 zcylinder 15.0 wiggle z 3.0 2.0
fix 3 all wall/gran granular hooke 1000.0 50.0 tangential linear_nohistory 1.0 0.4 zplane 0.0 NULL
fix 4 all wall/gran granular jkr 1000.0 50.0 0.3 5.0 tangential mindlin 800.0 1.0 0.5 rolling sds 500.0 200.0 0.5 twisting marshall zcylinder 15.0 wiggle z 3.0 2.0
fix 5 all wall/gran granular dmt 1000.0 50.0 0.3 10.0 tangential mindlin 800.0 0.5 0.1 roll sds 500.0 200.0 0.1 twisting marshall zplane 0.0 NULL :pre
fix 2 all wall/gran hooke 100000.0 20000.0 50.0 30.0 0.5 1 zcylinder 15.0 wiggle z 3.0 2.0
fix 3 all wall/gran/region granular hooke 1000.0 50.0 tangential linear_nohistory 1.0 0.4 damping velocity region myBox
fix 4 all wall/gran/region granular jkr 1e5 1500.0 0.3 10.0 tangential mindlin NULL 1.0 0.5 rolling sds 500.0 200.0 0.5 twisting marshall region myCone
fix 5 all wall/gran/region granular dmt 1e5 0.2 0.3 10.0 tangential mindlin NULL 1.0 0.5 rolling sds 500.0 200.0 0.5 twisting marshall damping tsuji region myCone :pre
[Description:]

22
doc/src/fix_wall_gran_region.txt
View File

@ -17,23 +17,23 @@ wall/region = style name of this fix command :l
fstyle = style of force interactions between particles and wall :l
possible choices: hooke, hooke/history, hertz/history, granular :pre
fstyle_params = parameters associated with force interaction style :l
For {hooke}, {hooke/history}, and {hertz/history}, {fstyle_params} are:
Kn = elastic constant for normal particle repulsion (force/distance units or pressure units - see discussion below)
Kt = elastic constant for tangential contact (force/distance units or pressure units - see discussion below)
gamma_n = damping coefficient for collisions in normal direction (1/time units or 1/time-distance units - see discussion below)
gamma_t = damping coefficient for collisions in tangential direction (1/time units or 1/time-distance units - see discussion below)
xmu = static yield criterion (unitless value between 0.0 and 1.0e4)
dampflag = 0 or 1 if tangential damping force is excluded or included :pre
For {hooke}, {hooke/history}, and {hertz/history}, {fstyle_params} are:
Kn = elastic constant for normal particle repulsion (force/distance units or pressure units - see discussion below)
Kt = elastic constant for tangential contact (force/distance units or pressure units - see discussion below)
gamma_n = damping coefficient for collisions in normal direction (1/time units or 1/time-distance units - see discussion below)
gamma_t = damping coefficient for collisions in tangential direction (1/time units or 1/time-distance units - see discussion below)
xmu = static yield criterion (unitless value between 0.0 and 1.0e4)
dampflag = 0 or 1 if tangential damping force is excluded or included :pre
For {granular}, {fstyle_params} are set using the same syntax as for the {pair_coeff} command of "pair_style granular"_pair_granular.html :pre
wallstyle = region (see "fix wall/gran"_fix_wall_gran.html for options for other kinds of walls) :l
region-ID = region whose boundary will act as wall :l,ule
[Examples:]
fix wall all wall/gran/region hooke/history 1000.0 200.0 200.0 100.0 0.5 1 region myCone
fix 3 all wall/gran/region granular hooke 1000.0 50.0 tangential linear_nohistory 1.0 0.4 region myBox
fix 4 all wall/gran/region granular jkr 1000.0 50.0 tangential linear_history 800.0 1.0 0.5 rolling sds 500.0 200.0 0.5 twisting marshall region myCone
fix 5 all wall/gran/region granular dmt 1000.0 50.0 0.3 10.0 tangential linear_history 800.0 0.5 0.1 roll sds 500.0 200.0 0.1 twisting marshall region myCone :pre
fix wall all wall/gran/region hooke/history 1000.0 200.0 200.0 100.0 0.5 1 region myCone
fix 3 all wall/gran/region granular hooke 1000.0 50.0 tangential linear_nohistory 1.0 0.4 damping velocity region myBox
fix 4 all wall/gran/region granular jkr 1e5 1500.0 0.3 10.0 tangential mindlin NULL 1.0 0.5 rolling sds 500.0 200.0 0.5 twisting marshall region myCone
fix 5 all wall/gran/region granular dmt 1e5 0.2 0.3 10.0 tangential mindlin NULL 1.0 0.5 rolling sds 500.0 200.0 0.5 twisting marshall damping tsuji region myCone :pre
[Description:]

1
doc/src/fixes.txt
View File

@ -84,6 +84,7 @@ Fixes :h1
fix_msst
fix_mvv_dpd
fix_neb
fix_neb_spin
fix_nh
fix_nh_eff
fix_nh_uef

2
doc/src/lammps.book
View File

@ -179,6 +179,7 @@ min_spin.html
minimize.html
molecule.html
neb.html
neb_spin.html
neigh_modify.html
neighbor.html
newton.html
@ -309,6 +310,7 @@ fix_mscg.html
fix_msst.html
fix_mvv_dpd.html
fix_neb.html
fix_neb_spin.html
fix_nh.html
fix_nh_eff.html
fix_nph_asphere.html

375
doc/src/neb_spin.txt Normal file
View File

@ -0,0 +1,375 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Commands_all.html)
:line
neb command :h3
[Syntax:]
neb/spin etol ttol N1 N2 Nevery file-style arg keyword :pre
etol = stopping tolerance for energy (energy units) :ulb,l
ttol = stopping tolerance for torque ( units) :l
N1 = max # of iterations (timesteps) to run initial NEB :l
N2 = max # of iterations (timesteps) to run barrier-climbing NEB :l
Nevery = print replica energies and reaction coordinates every this many timesteps :l
file-style = {final} or {each} or {none} :l
{final} arg = filename
filename = file with initial coords for final replica
coords for intermediate replicas are linearly interpolated
between first and last replica
{each} arg = filename
filename = unique filename for each replica (except first)
with its initial coords
{none} arg = no argument all replicas assumed to already have
their initial coords :pre
keyword = {verbose}
:ule
[Examples:]
neb/spin 0.1 0.0 1000 500 50 final coords.final
neb/spin 0.0 0.001 1000 500 50 each coords.initial.$i
neb/spin 0.0 0.001 1000 500 50 none verbose :pre
[Description:]
Perform a geodesic nudged elastic band (GNEB) calculation using multiple
replicas of a system. Two or more replicas must be used; the first
and last are the end points of the transition path.
GNEB is a method for finding both the spin configurations and height
of the energy barrier associated with a transition state, e.g.
spins to perform a collective rotation from one energy basin to
another.
The implementation in LAMMPS follows the discussion in the
following paper: "(BessarabA)"_#BessarabA.
Each replica runs on a partition of one or more processors. Processor
partitions are defined at run-time using the "-partition command-line
switch"_Run_options.html. Note that if you have MPI installed, you
can run a multi-replica simulation with more replicas (partitions)
than you have physical processors, e.g you can run a 10-replica
simulation on just one or two processors. You will simply not get the
performance speed-up you would see with one or more physical
processors per replica. See the "Howto replica"_Howto_replica.html
doc page for further discussion.
NOTE: As explained below, a GNEB calculation performs a damped dynamics
minimization across all the replicas. The "spin"_min_spin.html
style minimizer has to be defined in your input script.
When a GNEB calculation is performed, it is assumed that each replica
is running the same system, though LAMMPS does not check for this.
I.e. the simulation domain, the number of magnetic atoms, the
interaction potentials, and the starting configuration when the neb
command is issued should be the same for every replica.
In a GNEB calculation each replica is connected to other replicas by
inter-replica nudging forces. These forces are imposed by the "fix
neb/spin"_fix_neb_spin.html command, which must be used in conjunction
with the neb command.
The group used to define the fix neb/spin command defines the
GNEB magnetic atoms which are the only ones that inter-replica springs
are applied to.
If the group does not include all magnetic atoms, then non-GNEB
magnetic atoms have no inter-replica springs and the torques they feel
and their precession motion is computed in the usual way due only
to other magnetic atoms within their replica.
Conceptually, the non-GNEB atoms provide a background force field for
the GNEB atoms.
Their magnetic spins can be allowed to evolve during the GNEB
minimization procedure.
The initial spin configuration for each of the replicas can be
specified in different manners via the {file-style} setting, as
discussed below. Only atomic spins whose initial coordinates should
differ from the current configuration need to be specified.
Conceptually, the initial and final configurations for the first
replica should be states on either side of an energy barrier.
As explained below, the initial configurations of intermediate
replicas can be spin coordinates interpolated in a linear fashion
between the first and last replicas. This is often adequate for
simple transitions. For more complex transitions, it may lead to slow
convergence or even bad results if the minimum energy path (MEP, see
below) of states over the barrier cannot be correctly converged to
from such an initial path. In this case, you will want to generate
initial states for the intermediate replicas that are geometrically
closer to the MEP and read them in.
:line
For a {file-style} setting of {final}, a filename is specified which
contains atomic and spin coordinates for zero or more atoms, in the
format described below.
For each atom that appears in the file, the new coordinates are
assigned to that atom in the final replica. Each intermediate replica
also assigns a new spin to that atom in an interpolated manner.
This is done by using the current direction of the spin at the starting
point and the read-in direction as the final point.
The "angular distance" between them is calculated, and the new direction
is assigned to be a fraction of the angular distance.
NOTE: The "angular distance" between the starting and final point is
evaluated in the geodesic sense, as described in
"(BessarabA)"_#BessarabA.
NOTE: The angular interpolation between the starting and final point
is achieved using Rodrigues formula:
:c,image(Eqs/neb_spin_rodrigues_formula.jpg)
where m_i^I is the initial spin configuration for the spin i,
omega_i^nu is a rotation angle defined as:
:c,image(Eqs/neb_spin_angle.jpg)
with nu the image number, Q the total number of images, and
omega_i the total rotation between the initial and final spins.
k_i defines a rotation axis such as:
:c,image(Eqs/neb_spin_k.jpg)
if the initial and final spins are not aligned.
If the initial and final spins are aligned, then their cross
product is null, and the expression above does not apply.
If they point toward the same direction, the intermediate images
conserve the same orientation.
If the initial and final spins are aligned, but point toward
opposite directions, an arbitrary rotation vector belonging to
the plane perpendicular to initial and final spins is chosen.
In this case, a warning message is displayed.
For a {file-style} setting of {each}, a filename is specified which is
assumed to be unique to each replica.
See the "neb"_neb.html documentation page for more information about this
option.
For a {file-style} setting of {none}, no filename is specified. Each
replica is assumed to already be in its initial configuration at the
time the neb command is issued. This allows each replica to define
its own configuration by reading a replica-specific data or restart or
dump file, via the "read_data"_read_data.html,
"read_restart"_read_restart.html, or "read_dump"_read_dump.html
commands. The replica-specific names of these files can be specified
as in the discussion above for the {each} file-style. Also see the
section below for how a NEB calculation can produce restart files, so
that a long calculation can be restarted if needed.
NOTE: None of the {file-style} settings change the initial
configuration of any atom in the first replica. The first replica
must thus be in the correct initial configuration at the time the neb
command is issued.
:line
A NEB calculation proceeds in two stages, each of which is a
minimization procedure, performed via damped dynamics. To enable
this, you must first define a damped spin dynamics
"min_style"_min_style.html, using the {spin} style (see
"min_spin"_min_spin.html for more information).
The other styles cannot be used, since they relax the lattice
degrees of freedom instead of the spins.
The minimizer tolerances for energy and force are set by {etol} and
{ttol}, the same as for the "minimize"_minimize.html command.
A non-zero {etol} means that the GNEB calculation will terminate if the
energy criterion is met by every replica. The energies being compared
to {etol} do not include any contribution from the inter-replica
nudging forces, since these are non-conservative. A non-zero {ttol}
means that the GNEB calculation will terminate if the torque criterion
is met by every replica. The torques being compared to {ttol} include
the inter-replica nudging forces.
The maximum number of iterations in each stage is set by {N1} and
{N2}. These are effectively timestep counts since each iteration of
damped dynamics is like a single timestep in a dynamics
"run"_run.html. During both stages, the potential energy of each
replica and its normalized distance along the reaction path (reaction
coordinate RD) will be printed to the screen and log file every
{Nevery} timesteps. The RD is 0 and 1 for the first and last replica.
For intermediate replicas, it is the cumulative angular distance
(normalized by the total cumulative angular distance) between adjacent
replicas, where "distance" is defined as the length of the 3N-vector of
the geodesic distances in spin coordinates, with N the number of
GNEB spins involved (see equation (13) in "(BessarabA)"_#BessarabA).
These outputs allow you to monitor NEB's progress in
finding a good energy barrier. {N1} and {N2} must both be multiples
of {Nevery}.
In the first stage of GNEB, the set of replicas should converge toward
a minimum energy path (MEP) of conformational states that transition
over a barrier. The MEP for a transition is defined as a sequence of
3N-dimensional spin states, each of which has a potential energy
gradient parallel to the MEP itself.
The configuration of highest energy along a MEP corresponds to a saddle
point. The replica states will also be roughly equally spaced along
the MEP due to the inter-replica nudging force added by the
"fix neb"_fix_neb.html command.
In the second stage of GNEB, the replica with the highest energy is
selected and the inter-replica forces on it are converted to a force
that drives its spin coordinates to the top or saddle point of the
barrier, via the barrier-climbing calculation described in
"(BessarabA)"_#BessarabA. As before, the other replicas rearrange
themselves along the MEP so as to be roughly equally spaced.
When both stages are complete, if the GNEB calculation was successful,
the configurations of the replicas should be along (close to) the MEP
and the replica with the highest energy should be a spin
configuration at (close to) the saddle point of the transition. The
potential energies for the set of replicas represents the energy
profile of the transition along the MEP.
:line
An atom map must be defined which it is not by default for "atom_style
atomic"_atom_style.html problems. The "atom_modify
map"_atom_modify.html command can be used to do this.
An initial value can be defined for the timestep. Although, the {spin}
minimization algorithm is an adaptive timestep methodology, so that
this timestep is likely to evolve during the calculation.
The minimizers in LAMMPS operate on all spins in your system, even
non-GNEB atoms, as defined above.
:line
Each file read by the neb/spin command containing spin coordinates used
to initialize one or more replicas must be formatted as follows.
The file can be ASCII text or a gzipped text file (detected by a .gz
suffix). The file can contain initial blank lines or comment lines
starting with "#" which are ignored. The first non-blank, non-comment
line should list N = the number of lines to follow. The N successive
lines contain the following information:
ID1 g1 x1 y1 z1 sx1 sy1 sz1
ID2 g2 x2 y2 z2 sx2 sy2 sz2
...
IDN gN yN zN sxN syN szN :pre
The fields are the atom ID, the norm of the associated magnetic spin,
followed by the {x,y,z} coordinates and the {sx,sy,sz} spin coordinates.
The lines can be listed in any order. Additional trailing information on
the line is OK, such as a comment.
Note that for a typical GNEB calculation you do not need to specify
initial spin coordinates for very many atoms to produce differing starting
and final replicas whose intermediate replicas will converge to the
energy barrier. Typically only new spin coordinates for atoms
geometrically near the barrier need be specified.
Also note there is no requirement that the atoms in the file
correspond to the GNEB atoms in the group defined by the "fix
neb"_fix_neb.html command. Not every GNEB atom need be in the file,
and non-GNEB atoms can be listed in the file.
:line
Four kinds of output can be generated during a GNEB calculation: energy
barrier statistics, thermodynamic output by each replica, dump files,
and restart files.
When running with multiple partitions (each of which is a replica in
this case), the print-out to the screen and master log.lammps file
contains a line of output, printed once every {Nevery} timesteps. It
contains the timestep, the maximum torque per replica, the maximum
torque per atom (in any replica), potential gradients in the initial,
final, and climbing replicas, the forward and backward energy
barriers, the total reaction coordinate (RDT), and the normalized
reaction coordinate and potential energy of each replica.
The "maximum torque per replica" is the two-norm of the
3N-length vector given by the cross product of a spin by its
precession vector omega, in each replica, maximized across replicas,
which is what the {ttol} setting is checking against. In this case, N is
all the atoms in each replica. The "maximum torque per atom" is the
maximum torque component of any atom in any replica. The potential
gradients are the two-norm of the 3N-length magnetic precession vector
solely due to the interaction potential i.e. without adding in
inter-replica forces, and projected along the path tangent (as detailed
in Appendix D of "(BessarabA)"_#BessarabA).
The "reaction coordinate" (RD) for each replica is the two-norm of the
3N-length vector of geodesic distances between its spins and the preceding
replica's spins (see equation (13) of "(BessarabA)"_#BessarabA), added to
the RD of the preceding replica. The RD of the first replica RD1 = 0.0;
the RD of the final replica RDN = RDT, the total reaction coordinate.
The normalized RDs are divided by RDT, so that they form a monotonically
increasing sequence from zero to one. When computing RD, N only includes
the spins being operated on by the fix neb/spin command.
The forward (reverse) energy barrier is the potential energy of the
highest replica minus the energy of the first (last) replica.
Supplementary information for all replicas can be printed out to the
screen and master log.lammps file by adding the verbose keyword. This
information include the following.
The "GradVidottan" are the projections of the potential gradient for
the replica i on its tangent vector (as detailed in Appendix D of
"(BessarabA)"_#BessarabA).
The "DNi" are the non normalized geodesic distances (see equation (13)
of "(BessarabA)"_#BessarabA), between a replica i and the next replica
i+1. For the last replica, this distance is not defined and a "NAN"
value is the corresponding output.
When a NEB calculation does not converge properly, the supplementary
information can help understanding what is going wrong.
When running on multiple partitions, LAMMPS produces additional log
files for each partition, e.g. log.lammps.0, log.lammps.1, etc. For a
GNEB calculation, these contain the thermodynamic output for each
replica.
If "dump"_dump.html commands in the input script define a filename
that includes a {universe} or {uloop} style "variable"_variable.html,
then one dump file (per dump command) will be created for each
replica. At the end of the GNEB calculation, the final snapshot in
each file will contain the sequence of snapshots that transition the
system over the energy barrier. Earlier snapshots will show the
convergence of the replicas to the MEP.
Likewise, "restart"_restart.html filenames can be specified with a
{universe} or {uloop} style "variable"_variable.html, to generate
restart files for each replica. These may be useful if the GNEB
calculation fails to converge properly to the MEP, and you wish to
restart the calculation from an intermediate point with altered
parameters.
A c file script in provided in the tool/spin/interpolate_gneb
directory, that interpolates the MEP given the information provided
by the verbose output option (as detailed in Appendix D of
"(BessarabA)"_#BessarabA).
:line
[Restrictions:]
This command can only be used if LAMMPS was built with the SPIN
package. See the "Build package"_Build_package.html doc
page for more info.
:line
[Related commands:]
"min/spin"_min_spin.html, "fix neb/spin"_fix_neb_spin.html
[Default:]
none
:line
:link(BessarabA)
[(BessarabA)] Bessarab, Uzdin, Jonsson, Comp Phys Comm, 196,
335-347 (2015).

192
doc/src/package.txt
View File

@ -64,7 +64,7 @@ args = arguments specific to the style :l
{no_affinity} values = none
{kokkos} args = keyword value ...
zero or more keyword/value pairs may be appended
keywords = {neigh} or {neigh/qeq} or {newton} or {binsize} or {comm} or {comm/exchange} or {comm/forward} or {comm/reverse}
keywords = {neigh} or {neigh/qeq} or {newton} or {binsize} or {comm} or {comm/exchange} or {comm/forward} or {comm/reverse} or {gpu/direct}
{neigh} value = {full} or {half}
full = full neighbor list
half = half neighbor list built in thread-safe manner
@ -72,7 +72,7 @@ args = arguments specific to the style :l
full = full neighbor list
half = half neighbor list built in thread-safe manner
{newton} = {off} or {on}
off = set Newton pairwise and bonded flags off (default)
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)
@ -422,101 +422,103 @@ processes/threads used for LAMMPS.
:line
The {kokkos} style invokes settings associated with the use of the
KOKKOS package.
The {kokkos} style invokes settings associated with the use of the
KOKKOS package.
All of the settings are optional keyword/value pairs. Each has a
default value as listed below.
All of the settings are optional keyword/value pairs. Each has a default
value as listed below.
The {neigh} keyword determines how neighbor lists are built. A value
of {half} uses a thread-safe variant of half-neighbor lists,
the same as used by most pair styles in LAMMPS.
The {neigh} keyword determines how neighbor lists are built. A value of
{half} uses a thread-safe variant of half-neighbor lists, the same as
used by most pair styles in LAMMPS, which is the default when running on
CPUs (i.e. the Kokkos CUDA back end is not enabled).
A value of {full} uses a full neighbor lists and is the default. This
performs twice as much computation as the {half} option, however that
is often a win because it is thread-safe and doesn't require atomic
operations in the calculation of pair forces. For that reason, {full}
is the default setting. However, when running in MPI-only mode with 1
thread per MPI task, {half} neighbor lists will typically be faster,
just as it is for non-accelerated pair styles. Similarly, the {neigh/qeq}
keyword determines how neighbor lists are built for "fix qeq/reax/kk"_fix_qeq_reax.html.
If not explicitly set, the value of {neigh/qeq} will match {neigh}.
A value of {full} uses a full neighbor lists and is the default when
running on GPUs. This performs twice as much computation as the {half}
option, however that is often a win because it is thread-safe and
doesn't require atomic operations in the calculation of pair forces. For
that reason, {full} is the default setting for GPUs. However, when
running on CPUs, a {half} neighbor list is the default because it are
often faster, just as it is for non-accelerated pair styles. Similarly,
the {neigh/qeq} keyword determines how neighbor lists are built for "fix
qeq/reax/kk"_fix_qeq_reax.html. If not explicitly set, the value of
{neigh/qeq} will match {neigh}.
The {newton} keyword sets the Newton flags for pairwise and bonded
interactions to {off} or {on}, the same as the "newton"_newton.html
command allows. The default is {off} because this will almost always
give better performance for the KOKKOS package. This means more
computation is done, but less communication. However, when running in
MPI-only mode with 1 thread per MPI task, a value of {on} will
typically be faster, just as it is for non-accelerated pair styles.
The {newton} keyword sets the Newton flags for pairwise and bonded
interactions to {off} or {on}, the same as the "newton"_newton.html
command allows. The default for GPUs is {off} because this will almost
always give better performance for the KOKKOS package. This means more
computation is done, but less communication. However, when running on
CPUs a value of {on} is the default since it can often be faster, just
as it is for non-accelerated pair styles
The {binsize} keyword sets the size of bins used to bin atoms in
neighbor list builds. The same value can be set by the "neigh_modify
binsize"_neigh_modify.html command. Making it an option in the
package kokkos command allows it to be set from the command line. The
default value is 0.0, which means the LAMMPS default will be used,
which is bins = 1/2 the size of the pairwise cutoff + neighbor skin
distance. This is fine when neighbor lists are built on the CPU. For
GPU builds, a 2x larger binsize equal to the pairwise cutoff +
neighbor skin, is often faster, which can be set by this keyword.
Note that if you use a longer-than-usual pairwise cutoff, e.g. to
allow for a smaller fraction of KSpace work with a "long-range
Coulombic solver"_kspace_style.html because the GPU is faster at
performing pairwise interactions, then this rule of thumb may give too
large a binsize.
The {binsize} keyword sets the size of bins used to bin atoms in
neighbor list builds. The same value can be set by the "neigh_modify
binsize"_neigh_modify.html command. Making it an option in the package
kokkos command allows it to be set from the command line. The default
value for CPUs is 0.0, which means the LAMMPS default will be used,
which is bins = 1/2 the size of the pairwise cutoff + neighbor skin
distance. This is fine when neighbor lists are built on the CPU. For GPU
builds, a 2x larger binsize equal to the pairwise cutoff + neighbor skin
is often faster, which is the default. Note that if you use a
longer-than-usual pairwise cutoff, e.g. to allow for a smaller fraction
of KSpace work with a "long-range Coulombic solver"_kspace_style.html
because the GPU is faster at performing pairwise interactions, then this
rule of thumb may give too large a binsize and the default should be
overridden with a smaller value.
The {comm} and {comm/exchange} and {comm/forward} and {comm/reverse} keywords determine
whether the host or device performs the packing and unpacking of data
when communicating per-atom data between processors. "Exchange"
communication happens only on timesteps that neighbor lists are
rebuilt. The data is only for atoms that migrate to new processors.
"Forward" communication happens every timestep. "Reverse" communication
happens every timestep if the {newton} option is on. The data is for atom
coordinates and any other atom properties that needs to be updated for
ghost atoms owned by each processor.
The {comm} and {comm/exchange} and {comm/forward} and {comm/reverse}
keywords determine whether the host or device performs the packing and
unpacking of data when communicating per-atom data between processors.
"Exchange" communication happens only on timesteps that neighbor lists
are rebuilt. The data is only for atoms that migrate to new processors.
"Forward" communication happens every timestep. "Reverse" communication
happens every timestep if the {newton} option is on. The data is for
atom coordinates and any other atom properties that needs to be updated
for ghost atoms owned by each processor.
The {comm} keyword is simply a short-cut to set the same value
for both the {comm/exchange} and {comm/forward} and {comm/reverse} keywords.
The {comm} keyword is simply a short-cut to set the same value for both
the {comm/exchange} and {comm/forward} and {comm/reverse} keywords.
The value options for all 3 keywords are {no} or {host} or {device}.
A value of {no} means to use the standard non-KOKKOS method of
packing/unpacking data for the communication. A value of {host} means
to use the host, typically a multi-core CPU, and perform the
packing/unpacking in parallel with threads. A value of {device}
means to use the device, typically a GPU, to perform the
packing/unpacking operation.
The value options for all 3 keywords are {no} or {host} or {device}. A
value of {no} means to use the standard non-KOKKOS method of
packing/unpacking data for the communication. A value of {host} means to
use the host, typically a multi-core CPU, and perform the
packing/unpacking in parallel with threads. A value of {device} means to
use the device, typically a GPU, to perform the packing/unpacking
operation.
The optimal choice for these keywords depends on the input script and
the hardware used. The {no} value is useful for verifying that the
Kokkos-based {host} and {device} values are working correctly.
It may also be the fastest choice when using Kokkos styles in
MPI-only mode (i.e. with a thread count of 1).
The optimal choice for these keywords depends on the input script and
the hardware used. The {no} value is useful for verifying that the
Kokkos-based {host} and {device} values are working correctly. It is the
default when running on CPUs since it is usually the fastest.
When running on CPUs or Xeon Phi, the {host} and {device} values work
identically. When using GPUs, the {device} value will typically be
optimal if all of your styles used in your input script are supported
by the KOKKOS package. In this case data can stay on the GPU for many
timesteps without being moved between the host and GPU, if you use the
{device} value. This requires that your MPI is able to access GPU
memory directly. Currently that is true for OpenMPI 1.8 (or later
versions), Mvapich2 1.9 (or later), and CrayMPI. If your script uses
styles (e.g. fixes) which are not yet supported by the KOKKOS package,
then data has to be move between the host and device anyway, so it is
typically faster to let the host handle communication, by using the
{host} value. Using {host} instead of {no} will enable use of
multiple threads to pack/unpack communicated data.
When running on CPUs or Xeon Phi, the {host} and {device} values work
identically. When using GPUs, the {device} value is the default since it
will typically be optimal if all of your styles used in your input
script are supported by the KOKKOS package. In this case data can stay
on the GPU for many timesteps without being moved between the host and
GPU, if you use the {device} value. This requires that your MPI is able
to access GPU memory directly. Currently that is true for OpenMPI 1.8
(or later versions), Mvapich2 1.9 (or later), and CrayMPI. If your
script uses styles (e.g. fixes) which are not yet supported by the
KOKKOS package, then data has to be move between the host and device
anyway, so it is typically faster to let the host handle communication,
by using the {host} value. Using {host} instead of {no} will enable use
of multiple threads to pack/unpack communicated data.
The {gpu/direct} keyword chooses whether GPU-direct will be used. When
this keyword is set to {on}, buffers in GPU memory are passed directly
through MPI send/receive calls. This reduces overhead of first copying
the data to the host CPU. However GPU-direct is not supported on all
systems, which can lead to segmentation faults and would require
using a value of {off}. If LAMMPS can safely detect that GPU-direct is
not available (currently only possible with OpenMPI v2.0.0 or later),
then the {gpu/direct} keyword is automatically set to {off} by default.
When the {gpu/direct} keyword is set to {off} while any of the {comm}
keywords are set to {device}, the value for these {comm} keywords will
be automatically changed to {host}.
The {gpu/direct} keyword chooses whether GPU-direct will be used. When
this keyword is set to {on}, buffers in GPU memory are passed directly
through MPI send/receive calls. This reduces overhead of first copying
the data to the host CPU. However GPU-direct is not supported on all
systems, which can lead to segmentation faults and would require using a
value of {off}. If LAMMPS can safely detect that GPU-direct is not
available (currently only possible with OpenMPI v2.0.0 or later), then
the {gpu/direct} keyword is automatically set to {off} by default. When
the {gpu/direct} keyword is set to {off} while any of the {comm}
keywords are set to {device}, the value for these {comm} keywords will
be automatically changed to {host}. This setting has no effect if not
running on GPUs.
:line
@ -623,14 +625,16 @@ not used, you must invoke the package intel command in your input
script or or via the "-pk intel" "command-line
switch"_Run_options.html.
For the KOKKOS package, the option defaults neigh = full, neigh/qeq =
full, newton = off, binsize = 0.0, and comm = device, gpu/direct = on.
When LAMMPS can safely detect, that GPU-direct is not available, the
default value of gpu/direct becomes "off".
These settings are made automatically by the required "-k on"
"command-line switch"_Run_options.html. You can change them by
using the package kokkos command in your input script or via the
"-pk kokkos command-line switch"_Run_options.html.
For the KOKKOS package, the option defaults for GPUs are neigh = full,
neigh/qeq = full, newton = off, binsize for GPUs = 2x LAMMPS default
value, comm = device, gpu/direct = on. When LAMMPS can safely detect
that GPU-direct is not available, the default value of gpu/direct
becomes "off". For CPUs or Xeon Phis, the option defaults are neigh =
half, neigh/qeq = half, newton = on, binsize = 0.0, and comm = no. These
settings are made automatically by the required "-k on" "command-line
switch"_Run_options.html. You can change them by using the package
kokkos command in your input script or via the "-pk kokkos command-line
switch"_Run_options.html.
For the OMP package, the default is Nthreads = 0 and the option
defaults are neigh = yes. These settings are made automatically if

17
doc/src/pair_airebo.txt
View File

@ -36,7 +36,7 @@ pair_style airebo/morse 3.0
pair_coeff * * ../potentials/CH.airebo-m H C :pre
pair_style rebo
pair_coeff * * ../potentials/CH.airebo H C :pre
pair_coeff * * ../potentials/CH.rebo H C :pre
[Description:]
@ -57,7 +57,8 @@ The {rebo} pair style computes the Reactive Empirical Bond Order (REBO)
Potential of "(Brenner)"_#Brenner. Note that this is the so-called
2nd generation REBO from 2002, not the original REBO from 1990.
As discussed below, 2nd generation REBO is closely related to the
initial AIREBO; it is just a subset of the potential energy terms.
initial AIREBO; it is just a subset of the potential energy terms
with a few slightly different parameters
The AIREBO potential consists of three terms:
@ -113,12 +114,12 @@ various dihedral angle preferences in hydrocarbon configurations.
:line
Only a single pair_coeff command is used with the {airebo}, {airebo}
or {rebo} style which specifies an AIREBO or AIREBO-M potential file
with parameters for C and H. Note that the {rebo} style in LAMMPS
uses the same AIREBO-formatted potential file. These are mapped to
LAMMPS atom types by specifying N additional arguments after the
filename in the pair_coeff command, where N is the number of LAMMPS
atom types:
or {rebo} style which specifies an AIREBO, REBO, or AIREBO-M potential
file with parameters for C and H. Note that as of LAMMPS version
15 May 2019 the {rebo} style in LAMMPS uses its own potential
file (CH.rebo). These are mapped to LAMMPS atom types by specifying
N additional arguments after the filename in the pair_coeff command,
where N is the number of LAMMPS atom types:
filename
N element names = mapping of AIREBO elements to atom types :ul

78
doc/src/pair_granular.txt
View File

@ -24,22 +24,24 @@ cutoff = global cutoff (optional). See discussion below. :ul
[Examples:]
pair_style granular
pair_coeff * * hooke 1000.0 50.0 tangential linear_nohistory 1.0 0.4 :pre
pair_coeff * * hooke 1000.0 50.0 tangential linear_nohistory 1.0 0.4 damping mass_velocity :pre
pair_style granular
pair_coeff * * hertz 1000.0 50.0 tangential mindlin NULL 1.0 0.4 :pre
pair_coeff * * hooke 1000.0 50.0 tangential linear_history 500.0 1.0 0.4 damping mass_velocity :pre
pair_style granular
pair_coeff * * hertz/material 1e8 0.3 tangential mindlin_rescale NULL 1.0 0.4 damping tsuji :pre
pair_coeff * * hertz 1000.0 50.0 tangential mindlin 1000.0 1.0 0.4 :pre
pair_style granular
pair_coeff 1 1 jkr 1000.0 50.0 tangential mindlin 800.0 1.0 0.5 rolling sds 500.0 200.0 0.5 twisting marshall
pair_coeff 2 2 hertz 200.0 20.0 tangential linear_history 300.0 1.0 0.1 rolling sds 200.0 100.0 0.1 twisting marshall :pre
pair_coeff * * hertz/material 1e8 0.3 0.3 tangential mindlin_rescale NULL 1.0 0.4 damping tsuji :pre
pair_style granular
pair_coeff 1 1 hertz 1000.0 50.0 tangential mindlin 800.0 0.5 0.5 rolling sds 500.0 200.0 0.5 twisting marshall
pair_coeff 2 2 dmt 1000.0 50.0 0.3 10.0 tangential mindlin 800.0 0.5 0.1 roll sds 500.0 200.0 0.1 twisting marshall
pair_coeff 1 2 dmt 1000.0 50.0 0.3 10.0 tangential mindlin 800.0 0.5 0.1 roll sds 500.0 200.0 0.1 twisting marshall :pre
pair_coeff 1 * jkr 1000.0 500.0 0.3 10 tangential mindlin 800.0 1.0 0.5 rolling sds 500.0 200.0 0.5 twisting marshall
pair_coeff 2 2 hertz 200.0 100.0 tangential linear_history 300.0 1.0 0.1 rolling sds 200.0 100.0 0.1 twisting marshall :pre
pair_style granular
pair_coeff 1 1 dmt 1000.0 50.0 0.3 0.0 tangential mindlin NULL 0.5 0.5 rolling sds 500.0 200.0 0.5 twisting marshall
pair_coeff 2 2 dmt 1000.0 50.0 0.3 10.0 tangential mindlin NULL 0.5 0.1 rolling sds 500.0 200.0 0.1 twisting marshall :pre
[Description:]
@ -57,18 +59,18 @@ global, but can be set to different values for different combinations
of particle types, as determined by the "pair_coeff"_pair_coeff.html
command. If the contact model choice is the same for two particle
types, the mixing for the cross-coefficients can be carried out
automatically. This is shown in the second example, where model
automatically. This is shown in the last example, where model
choices are the same for type 1 - type 1 as for type 2 - type2
interactions, but coefficients are different. In this case, the
coefficients for type 2 - type interactions can be determined from
mixed coefficients for type 1 - type 2 interactions can be determined from
mixing rules discussed below. For additional flexibility,
coefficients as well as model forms can vary between particle types,
as shown in the third example: type 1- type 1 interactions are based
on a Hertzian normal contact model and 2-2 interactions are based on a
DMT cohesive model (see below). In that example, 1-1 and 2-2
interactions have different model forms, in which case mixing of
as shown in the fourth example: type 1 - type 1 interactions are based
on a Johnson-Kendall-Roberts normal contact model and 2-2 interactions
are based on a DMT cohesive model (see below). In that example, 1-1
and 2-2 interactions have different model forms, in which case mixing of
coefficients cannot be determined, so 1-2 interactions must be
explicitly defined via the {pair_coeff 1 2} command, otherwise an
explicitly defined via the {pair_coeff 1 *} command, otherwise an
error would result.
:line
@ -189,6 +191,7 @@ other settings, potentially also the twisting damping). The options
for the damping model currently supported are:
{velocity}
{mass_velocity}
{viscoelastic}
{tsuji} :ol
@ -199,11 +202,23 @@ For {damping velocity}, the normal damping is simply equal to the
user-specified damping coefficient in the {normal} model:
\begin\{equation\}
\eta_n = \eta_\{n0\}\
\eta_n = \eta_\{n0\}
\end\{equation\}
Here, \(\gamma_n\) is the damping coefficient specified for the normal
contact model, in units of {mass}/{time},
Here, \(\eta_\{n0\}\) is the damping coefficient specified for the normal
contact model, in units of {mass}/{time}.
For {damping mass_velocity}, the normal damping is given by:
\begin\{equation\}
\eta_n = \eta_\{n0\} m_\{eff\}
\end\{equation\}
Here, \(\eta_\{n0\}\) is the damping coefficient specified for the normal
contact model, in units of {mass}/{time} and
\(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/*}.
The {damping viscoelastic} model is based on the viscoelastic
treatment of "(Brilliantov et al)"_#Brill1996, where the normal
@ -213,11 +228,10 @@ damping is given by:
\eta_n = \eta_\{n0\}\ a m_\{eff\}
\end\{equation\}
Here, \(m_\{eff\} = m_i m_j/(m_i + m_j)\) is the effective mass, {a}
is the contact radius, given by \(a =\sqrt\{R\delta\}\) for all models
except {jkr}, for which it is given implicitly according to \(delta =
a^2/R - 2\sqrt\{\pi \gamma a/E\}\). In this case, \eta_\{n0\}\ is in
units of 1/({time}*{distance}).
Here, {a} is the contact radius, given by \(a =\sqrt\{R\delta\}\)
for all models except {jkr}, for which it is given implicitly according
to \(\delta = a^2/R - 2\sqrt\{\pi \gamma a/E\}\). For {damping viscoelastic},
\(\eta_\{n0\}\) is in units of 1/({time}*{distance}).
The {tsuji} model is based on the work of "(Tsuji et
al)"_#Tsuji1992. Here, the damping coefficient specified as part of
@ -564,6 +578,20 @@ Finally, the twisting torque on each particle is given by:
:line
The {granular} pair style can reproduce the behavior of the
{pair gran/*} styles with the appropriate settings (some very
minor differences can be expected due to corrections in
displacement history frame-of-reference, and the application
of the torque at the center of the contact rather than
at each particle). The first example above
is equivalent to {pair gran/hooke 1000.0 NULL 50.0 50.0 0.4 1}.
The second example is equivalent to
{pair gran/hooke/history 1000.0 500.0 50.0 50.0 0.4 1}.
The third example is equivalent to
{pair gran/hertz/history 1000.0 500.0 50.0 50.0 0.4 1}.
:line
LAMMPS automatically sets pairwise cutoff values for {pair_style
granular} based on particle radii (and in the case of {jkr} pull-off
distances). In the vast majority of situations, this is adequate.
@ -619,7 +647,7 @@ interactions is set to \(\mu_1\), and friction coefficient for type
2-type 2 interactions is set to \(\mu_2\), the friction coefficient
for type1-type2 interactions is computed as \(\sqrt\{\mu_1\mu_2\}\)
(unless explicitly specified to a different value by a {pair_coeff 1 2
...} command. The exception to this is elastic modulus, only
...} command). The exception to this is elastic modulus, only
applicable to {hertz/material}, {dmt} and {jkr} normal contact
models. In that case, the effective elastic modulus is computed as:
@ -706,7 +734,7 @@ For the {pair_coeff} settings: {damping viscoelastic}, {rolling none},
J. M., & Poschel, T. (1996). Model for collisions in granular
gases. Physical review E, 53(5), 5382.
:link(Tsuji1992)
:link(Tsuji1992)
[(Tsuji et al, 1992)] Tsuji, Y., Tanaka, T., & Ishida,
T. (1992). Lagrangian numerical simulation of plug flow of
cohesionless particles in a horizontal pipe. Powder technology, 71(3),

68
doc/src/pair_mdf.txt
View File

@ -30,16 +30,16 @@ args = list of arguments for a particular style :l
[Examples:]
pair_style lj/mdf 2.5 3.0
pair_coeff * * 1 1
pair_coeff 1 1 1 1.1 2.8 3.0 3.2 :pre
pair_coeff * * 1.0 1.0
pair_coeff 1 1 1.1 2.8 3.0 3.2 :pre
pair_style buck 2.5 3.0
pair_coeff * * 100.0 1.5 200.0
pair_coeff * * 100.0 1.5 200.0 3.0 3.5 :pre
pair_style lennard/mdf 2.5 3.0
pair_coeff * * 1 1
pair_coeff 1 1 1 1.1 2.8 3.0 3.2 :pre
pair_coeff * * 1.0 1.0
pair_coeff 1 1 1021760.3664 2120.317338 3.0 3.2 :pre
[Description:]
@ -69,11 +69,12 @@ standard 12-6 Lennard-Jones written in the epsilon/sigma form:
:c,image(Eqs/pair_mdf-4.jpg)
The following coefficients must be defined for each pair of atoms
types via the pair_coeff command as in the examples above, or in the
data file or restart files read by the "read_data"_read_data.html or
"read_restart commands"_read_restart.html, or by mixing as described
below:
Either the first two or all of the following coefficients must be
defined for each pair of atoms types via the pair_coeff command as
in the examples above, or in the data file read by the
"read_data"_read_data.html. The two cutoffs default to the global
values and epsilon and sigma can also be determined by mixing as
described below:
epsilon (energy units)
sigma (distance units)
@ -83,7 +84,9 @@ r_{cut} (distance units) :ul
:line
For the {buck/mdf} pair_style, the potential energy, {E(r)}, is the
standard Buckingham potential:
standard Buckingham potential with three required coefficients.
The two cutoffs can be omitted and default to the corresponding
global values:
:c,image(Eqs/pair_mdf-5.jpg)
@ -91,19 +94,20 @@ A (energy units)
\rho (distance units)
C (energy-distance^6 units)
r_m (distance units)
r_{cut}$ (distance units) :ul
r_{cut} (distance units) :ul
:line
For the {lennard/mdf} pair_style, the potential energy, {E(r)}, is the
standard 12-6 Lennard-Jones written in the $A/B$ form:
standard 12-6 Lennard-Jones written in the A/B form:
:c,image(Eqs/pair_mdf-6.jpg)
The following coefficients must be defined for each pair of atoms
types via the pair_coeff command as in the examples above, or in the
data file or restart files read by the read_data or read_restart
commands, or by mixing as described below:
data file read by the read_data commands, or by mixing as described below.
The two cutoffs default to their global values and must be either both
given or both left out:
A (energy-distance^12 units)
B (energy-distance^6 units)
@ -115,33 +119,23 @@ r_{cut} (distance units) :ul
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance for all of the lj/cut pair styles can be mixed.
and cutoff distances for the lj/mdf pair style can be mixed.
The default mix value is {geometric}. See the "pair_modify" command
for details.
for details. The other two pair styles buck/mdf and lennard/mdf do not
support mixing, so all I,J pairs of coefficients must be specified
explicitly.
All of the {lj/cut} pair styles support the
"pair_modify"_pair_modify.html shift option for the energy of the
Lennard-Jones portion of the pair interaction.
None of the lj/mdf, buck/mdf, or lennard/mdf pair styles supports
the "pair_modify"_pair_modify.html shift option or long-range
tail corrections to pressure and energy.
The {lj/cut/coul/long} and {lj/cut/tip4p/long} pair styles support the
"pair_modify"_pair_modify.html table option since they can tabulate
the short-range portion of the long-range Coulombic interaction.
These styles write their information to "binary restart
files"_restart.html, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.
All of the {lj/cut} pair styles support the
"pair_modify"_pair_modify.html tail option for adding a long-range
tail correction to the energy and pressure for the Lennard-Jones
portion of the pair interaction.
All of the {lj/cut} pair styles write their information to "binary
restart files"_restart.html, so pair_style and pair_coeff commands do
not need to be specified in an input script that reads a restart file.
The {lj/cut} and {lj/cut/coul/long} pair styles support the use of the
{inner}, {middle}, and {outer} keywords of the "run_style
respa"_run_style.html command, meaning the pairwise forces can be
partitioned by distance at different levels of the rRESPA hierarchy.
The other styles only support the {pair} keyword of run_style respa.
See the "run_style"_run_style.html command for details.
These styles can only be used via the {pair} keyword of the "run_style
respa"_run_style.html command. They do not support the {inner},
{middle}, {outer} keywords.
:line

2
doc/src/pair_spin_dmi.txt
View File

@ -88,4 +88,4 @@ package"_Build_package.html doc page for more info.
Physical Review B, 88(18), 184422. (2013).
:link(Tranchida5)
[(Tranchida)] Tranchida, Plimpton, Thibaudeau and Thompson,
Journal of Computational Physics, (2018).
Journal of Computational Physics, 372, 406-425, (2018).

2
doc/src/pair_spin_exchange.txt
View File

@ -95,4 +95,4 @@ package"_Build_package.html doc page for more info.
:link(Tranchida3)
[(Tranchida)] Tranchida, Plimpton, Thibaudeau and Thompson,
Journal of Computational Physics, (2018).
Journal of Computational Physics, 372, 406-425, (2018).

2
doc/src/pair_spin_magelec.txt
View File

@ -70,4 +70,4 @@ package"_Build_package.html doc page for more info.
:link(Tranchida4)
[(Tranchida)] Tranchida, Plimpton, Thibaudeau, and Thompson,
Journal of Computational Physics, (2018).
Journal of Computational Physics, 372, 406-425, (2018).

2
doc/src/pair_spin_neel.txt
View File

@ -80,4 +80,4 @@ package"_Build_package.html doc page for more info.
:link(Tranchida6)
[(Tranchida)] Tranchida, Plimpton, Thibaudeau and Thompson,
Journal of Computational Physics, (2018).
Journal of Computational Physics, 372, 406-425, (2018).

8
doc/src/write_coeff.txt
View File

@ -26,11 +26,9 @@ coefficients in a way, that it can be read by LAMMPS with the
option of "write_data"_write_data.html this can be used to move
the Coeffs sections from a data file into a separate file.
NOTE: The write_coeff command is not yet fully implemented in two
respects. First, some pair styles do not yet write their coefficient
information into the coeff file. This means you will need to specify
that information in your input script that reads the data file, via
the "pair_coeff"_pair_coeff.html command.
NOTE: The write_coeff command is not yet fully implemented as
some pair styles do not output their coefficient information.
This means you will need to add/copy this information manually.
:line