documentation whitespace cleanup
This commit is contained in:
Axel Kohlmeyer
@ -50,7 +50,7 @@ Code Coverage and Testing :h4,link(testing)
|
||||
|
||||
We do extensive regression testing of the LAMMPS code base on a continuous
|
||||
basis. Some of the logic to do this has been added to the CMake build so
|
||||
developers can run the tests directly on their workstation.
|
||||
developers can run the tests directly on their workstation.
|
||||
|
||||
NOTE: this is incomplete and only represents a small subset of tests that we run
|
||||
|
||||
|
||||
@ -43,19 +43,19 @@ 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 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
|
||||
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.
|
||||
to the spins to perform a minimization of the spin configuration.
|
||||
|
||||
|
||||
All the computed magnetic properties can be output by two main
|
||||
|
||||
@ -46,14 +46,14 @@ software version 7.5 or later must be installed on your system. See
|
||||
the discussion for the "GPU package"_Speed_gpu.html for details of how
|
||||
to check and do this.
|
||||
|
||||
NOTE: Kokkos with CUDA currently implicitly assumes that the MPI library
|
||||
is CUDA-aware. This is not always the case, especially when using
|
||||
pre-compiled MPI libraries provided by a Linux distribution. This is not
|
||||
a problem when using only a single GPU with a single MPI rank. When
|
||||
running with multiple MPI ranks, you may see segmentation faults without
|
||||
CUDA-aware MPI support. These can be avoided by adding the flags "-pk
|
||||
kokkos cuda/aware off"_Run_options.html to the LAMMPS command line or by
|
||||
using the command "package kokkos cuda/aware off"_package.html in the
|
||||
NOTE: Kokkos with CUDA currently implicitly assumes that the MPI library
|
||||
is CUDA-aware. This is not always the case, especially when using
|
||||
pre-compiled MPI libraries provided by a Linux distribution. This is not
|
||||
a problem when using only a single GPU with a single MPI rank. When
|
||||
running with multiple MPI ranks, you may see segmentation faults without
|
||||
CUDA-aware MPI support. These can be avoided by adding the flags "-pk
|
||||
kokkos cuda/aware off"_Run_options.html to the LAMMPS command line or by
|
||||
using the command "package kokkos cuda/aware off"_package.html in the
|
||||
input file.
|
||||
|
||||
[Building LAMMPS with the KOKKOS package:]
|
||||
@ -110,10 +110,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: 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
|
||||
|
||||
@ -183,15 +183,15 @@ 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 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:
|
||||
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 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
|
||||
@ -206,19 +206,19 @@ supports.
|
||||
|
||||
[Running on GPUs:]
|
||||
|
||||
Use the "-k" "command-line switch"_Run_options.html to specify the
|
||||
number of GPUs per node. Typically the -np setting of the mpirun command
|
||||
should set the number of MPI tasks/node to be equal to the number of
|
||||
physical GPUs on the node. You can assign multiple MPI tasks to the same
|
||||
GPU with the KOKKOS package, but this is usually only faster if some
|
||||
portions of the input script have not been ported to use Kokkos. In this
|
||||
case, also packing/unpacking communication buffers on the host may give
|
||||
speedup (see the KOKKOS "package"_package.html command). Using CUDA MPS
|
||||
Use the "-k" "command-line switch"_Run_options.html to specify the
|
||||
number of GPUs per node. Typically the -np setting of the mpirun command
|
||||
should set the number of MPI tasks/node to be equal to the number of
|
||||
physical GPUs on the node. You can assign multiple MPI tasks to the same
|
||||
GPU with the KOKKOS package, but this is usually only faster if some
|
||||
portions of the input script have not been ported to use Kokkos. In this
|
||||
case, also packing/unpacking communication buffers on the host may give
|
||||
speedup (see the KOKKOS "package"_package.html command). Using CUDA MPS
|
||||
is recommended in this scenario.
|
||||
|
||||
Using a CUDA-aware MPI library is highly recommended. CUDA-aware MPI use can be
|
||||
avoided by using "-pk kokkos cuda/aware no"_package.html. As above for
|
||||
multi-core CPUs (and no GPU), if N is the number of physical cores/node,
|
||||
Using a CUDA-aware MPI library is highly recommended. CUDA-aware MPI use can be
|
||||
avoided by using "-pk kokkos cuda/aware no"_package.html. As above for
|
||||
multi-core CPUs (and no GPU), if N is the number of physical cores/node,
|
||||
then the number of MPI tasks/node should not exceed N.
|
||||
|
||||
-k on g Ng :pre
|
||||
@ -229,18 +229,18 @@ 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 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:
|
||||
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 newton on neigh half binsize 2.8 -in in.lj # Newton on, half neighbor list, set binsize = neighbor ghost cutoff :pre
|
||||
|
||||
|
||||
@ -515,13 +515,13 @@ Ernst Mach Institute in Germany (georg.ganzenmueller at emi.fhg.de).
|
||||
spin tool :h4,link(spin)
|
||||
|
||||
The spin sub-directory contains a C file interpolate.c which can
|
||||
be compiled and used to perform a cubic polynomial interpolation of
|
||||
be compiled and used to perform a cubic polynomial interpolation of
|
||||
the MEP following a GNEB calculation.
|
||||
|
||||
See the README file in tools/spin/interpolate_gneb for more details.
|
||||
|
||||
This tool was written by the SPIN package author, Julien
|
||||
Tranchida at Sandia National Labs (jtranch at sandia.gov, and by Aleksei
|
||||
Tranchida at Sandia National Labs (jtranch at sandia.gov, and by Aleksei
|
||||
Ivanov, at University of Iceland (ali5 at hi.is).
|
||||
|
||||
:line
|
||||
|
||||
@ -244,7 +244,7 @@ compute"_Commands_compute.html doc page are followed by one or more of
|
||||
"plasticity/atom"_compute_plasticity_atom.html - Peridynamic plasticity for each atom
|
||||
"pressure"_compute_pressure.html - total pressure and pressure tensor
|
||||
"pressure/cylinder"_compute_pressure_cylinder.html - pressure tensor in cylindrical coordinates
|
||||
"pressure/uef"_compute_pressure_uef.html - pressure tensor in the reference frame of an applied flow field
|
||||
"pressure/uef"_compute_pressure_uef.html - pressure tensor in the reference frame of an applied flow field
|
||||
"property/atom"_compute_property_atom.html - convert atom attributes to per-atom vectors/arrays
|
||||
"property/chunk"_compute_property_chunk.html - extract various per-chunk attributes
|
||||
"property/local"_compute_property_local.html - convert local attributes to localvectors/arrays
|
||||
@ -284,7 +284,7 @@ compute"_Commands_compute.html doc page are followed by one or more of
|
||||
"stress/mop"_compute_stress_mop.html - normal components of the local stress tensor using the method of planes
|
||||
"stress/mop/profile"_compute_stress_mop.html - profile of the normal components of the local stress tensor using the method of planes
|
||||
"stress/tally"_compute_tally.html -
|
||||
"tdpd/cc/atom"_compute_tdpd_cc_atom.html - per-atom chemical concentration of a specified species for each tDPD particle
|
||||
"tdpd/cc/atom"_compute_tdpd_cc_atom.html - per-atom chemical concentration of a specified species for each tDPD particle
|
||||
"temp"_compute_temp.html - temperature of group of atoms
|
||||
"temp/asphere"_compute_temp_asphere.html - temperature of aspherical particles
|
||||
"temp/body"_compute_temp_body.html - temperature of body particles
|
||||
|
||||
@ -47,7 +47,7 @@ neighboring atoms, unless selected by type, type range, or group option,
|
||||
are included in the coordination number tally.
|
||||
|
||||
The optional {group} keyword allows to specify from which group atoms
|
||||
contribute to the coordination number. Default setting is group 'all'.
|
||||
contribute to the coordination number. Default setting is group 'all'.
|
||||
|
||||
The {typeN} keywords allow specification of which atom types
|
||||
contribute to each coordination number. One coordination number is
|
||||
|
||||
@ -34,7 +34,7 @@ compute 2 all hma 1 u cv :pre
|
||||
|
||||
Define a computation that calculates the properties of a solid (potential
|
||||
energy, pressure or heat capacity), using the harmonically-mapped averaging
|
||||
(HMA) method.
|
||||
(HMA) method.
|
||||
This command yields much higher precision than the equivalent compute commands
|
||||
("compute pe"_compute_pe.html, "compute pressure"_compute_pressure.html, etc.)
|
||||
commands during a canonical simulation of an atomic crystal. Specifically,
|
||||
@ -52,7 +52,7 @@ restricted to simulations in the NVT ensemble. While this compute may be
|
||||
used with any potential in LAMMPS, it will provide inaccurate results
|
||||
for potentials that do not go to 0 at the truncation distance;
|
||||
"pair_lj_smooth_linear"_pair_lj_smooth_linear.html and Ewald summation should
|
||||
work fine, while "pair_lj"_pair_lj.html will perform poorly unless
|
||||
work fine, while "pair_lj"_pair_lj.html will perform poorly unless
|
||||
the potential is shifted (via "pair_modify"_pair_modify.html shift) or the cutoff is large. Furthermore, computation of the heat capacity with
|
||||
this compute is restricted to those that implement the single_hessian method
|
||||
in Pair. Implementing single_hessian in additional pair styles is simple.
|
||||
@ -64,8 +64,8 @@ the list of pair styles that currently implement pair_hessian:
|
||||
:ule
|
||||
|
||||
In this method, the analytically known harmonic behavior of a crystal is removed from the traditional ensemble
|
||||
averages, which leads to an accurate and precise measurement of the anharmonic contributions without contamination
|
||||
by noise produced by the already-known harmonic behavior.
|
||||
averages, which leads to an accurate and precise measurement of the anharmonic contributions without contamination
|
||||
by noise produced by the already-known harmonic behavior.
|
||||
A detailed description of this method can be found in ("Moustafa"_#hma-Moustafa). The potential energy is computed by the formula:
|
||||
|
||||
\begin\{equation\}
|
||||
@ -74,9 +74,9 @@ A detailed description of this method can be found in ("Moustafa"_#hma-Moustafa)
|
||||
|
||||
where \(N\) is the number of atoms in the system, \(k_B\) is Boltzmann's
|
||||
constant, \(T\) is the temperature, \(d\) is the
|
||||
dimensionality of the system (2 or 3 for 2d/3d), \(F\bullet\Delta r\) is the sum of dot products of the
|
||||
atomic force vectors and displacement (from lattice sites) vectors, and \(U\) is the sum of
|
||||
pair, bond, angle, dihedral, improper, kspace (long-range), and fix energies.
|
||||
dimensionality of the system (2 or 3 for 2d/3d), \(F\bullet\Delta r\) is the sum of dot products of the
|
||||
atomic force vectors and displacement (from lattice sites) vectors, and \(U\) is the sum of
|
||||
pair, bond, angle, dihedral, improper, kspace (long-range), and fix energies.
|
||||
|
||||
The pressure is computed by the formula:
|
||||
|
||||
@ -118,30 +118,30 @@ When using this keyword, the compute must be first active (it must be included
|
||||
via a "thermo_style custom"_thermo_style.html command) while the atoms are
|
||||
still at their lattice sites (before equilibration).
|
||||
|
||||
The temp-ID specified with compute hma command should be same as the fix-ID of Nose-Hoover ("fix nvt"_fix_nh.html) or
|
||||
Berendsen ("fix temp/berendsen"_fix_temp_berendsen.html) thermostat used for the simulation. While using this command, Langevin thermostat
|
||||
("fix langevin"_fix_langevin.html)
|
||||
should be avoided as its extra forces interfere with the HMA implementation.
|
||||
The temp-ID specified with compute hma command should be same as the fix-ID of Nose-Hoover ("fix nvt"_fix_nh.html) or
|
||||
Berendsen ("fix temp/berendsen"_fix_temp_berendsen.html) thermostat used for the simulation. While using this command, Langevin thermostat
|
||||
("fix langevin"_fix_langevin.html)
|
||||
should be avoided as its extra forces interfere with the HMA implementation.
|
||||
|
||||
|
||||
|
||||
NOTE: Compute hma command should be used right after the energy minimization, when the atoms are at their lattice sites.
|
||||
|
||||
NOTE: Compute hma command should be used right after the energy minimization, when the atoms are at their lattice sites.
|
||||
The simulation should not be started before this command has been used in the input script.
|
||||
|
||||
|
||||
The following example illustrates the placement of this command in the input script:
|
||||
|
||||
|
||||
min_style cg
|
||||
minimize 1e-35 1e-15 50000 500000
|
||||
min_style cg
|
||||
minimize 1e-35 1e-15 50000 500000
|
||||
compute 1 all hma thermostatid u
|
||||
fix thermostatid all nvt temp 600.0 600.0 100.0 :pre
|
||||
fix thermostatid all nvt temp 600.0 600.0 100.0 :pre
|
||||
|
||||
|
||||
|
||||
NOTE: Compute hma should be used when the atoms of the solid do not diffuse. Diffusion will reduce the precision in the potential energy computation.
|
||||
|
||||
|
||||
|
||||
NOTE: The "fix_modify energy yes"_fix_modify.html command must also be specified if a fix is to contribute potential energy to this command.
|
||||
|
||||
An example input script that uses this compute is included in
|
||||
@ -180,5 +180,5 @@ this compute.
|
||||
:line
|
||||
|
||||
:link(hma-Moustafa)
|
||||
[(Moustafa)] Sabry G. Moustafa, Andrew J. Schultz, and David A. Kofke, {Very fast averaging of thermal properties of crystals by molecular simulation},
|
||||
[(Moustafa)] Sabry G. Moustafa, Andrew J. Schultz, and David A. Kofke, {Very fast averaging of thermal properties of crystals by molecular simulation},
|
||||
"Phys. Rev. E \[92\], 043303 (2015)"_https://link.aps.org/doi/10.1103/PhysRevE.92.043303
|
||||
|
||||
@ -76,14 +76,14 @@ parameters up to {Q}12 for a range of commonly encountered
|
||||
high-symmetry structures are given in Table I of "Mickel et
|
||||
al."_#Mickel, and these can be reproduced with this compute
|
||||
|
||||
The optional keyword {wl} will output the third-order invariants {Wl}
|
||||
The optional keyword {wl} will output the third-order invariants {Wl}
|
||||
(see Eq. 1.4 in "Steinhardt"_#Steinhardt) for the same degrees as
|
||||
for the {Ql} parameters. For the FCC crystal with {nnn} =12,
|
||||
{W}4 = -sqrt(14/143).(49/4096)/Pi^1.5 = -0.0006722136...
|
||||
|
||||
The optional keyword {wl/hat} will output the normalized third-order
|
||||
invariants {Wlhat} (see Eq. 2.2 in "Steinhardt"_#Steinhardt)
|
||||
for the same degrees as for the {Ql} parameters. For the FCC crystal
|
||||
The optional keyword {wl/hat} will output the normalized third-order
|
||||
invariants {Wlhat} (see Eq. 2.2 in "Steinhardt"_#Steinhardt)
|
||||
for the same degrees as for the {Ql} parameters. For the FCC crystal
|
||||
with {nnn} =12, {W}4hat = -7/3*sqrt(2/429) = -0.159317...The numerical
|
||||
values of {Wlhat} for a range of commonly encountered high-symmetry
|
||||
structures are given in Table I of "Steinhardt"_#Steinhardt, and these
|
||||
@ -127,9 +127,9 @@ range 0 <= {Ql} <= 1.
|
||||
If the keyword {wl} is set to yes, then the {Wl} values for each
|
||||
atom will be added to the output array, which are real numbers.
|
||||
|
||||
If the keyword {wl/hat} is set to yes, then the {Wl_hat}
|
||||
If the keyword {wl/hat} is set to yes, then the {Wl_hat}
|
||||
values for each atom will be added to the output array, which are real numbers.
|
||||
|
||||
|
||||
If the keyword {components} is set, then the real and imaginary parts
|
||||
of each component of (normalized) {Ybar_lm} will be added to the
|
||||
output array in the following order: Re({Ybar_-m}) Im({Ybar_-m})
|
||||
|
||||
@ -196,7 +196,7 @@ for j1 in range(0,twojmax+1):
|
||||
if (j>=j1): print j1/2.,j2/2.,j/2. :pre
|
||||
|
||||
NOTE: the {diagonal} keyword allowing other possible choices
|
||||
for the number of bispectrum components was removed in 2019,
|
||||
for the number of bispectrum components was removed in 2019,
|
||||
since all potentials use the value of 3, corresponding to the
|
||||
above set of bispectrum components.
|
||||
|
||||
|
||||
@ -40,14 +40,14 @@ The simplest way to output the results of the compute spin calculation
|
||||
is to define some of the quantities as variables, and to use the thermo and
|
||||
thermo_style commands, for example:
|
||||
|
||||
compute out_mag all spin :pre
|
||||
compute out_mag all spin :pre
|
||||
|
||||
variable mag_z equal c_out_mag\[3\]
|
||||
variable mag_norm equal c_out_mag\[4\]
|
||||
variable temp_mag equal c_out_mag\[6\] :pre
|
||||
variable mag_z equal c_out_mag\[3\]
|
||||
variable mag_norm equal c_out_mag\[4\]
|
||||
variable temp_mag equal c_out_mag\[6\] :pre
|
||||
|
||||
thermo 10
|
||||
thermo_style custom step v_mag_z v_mag_norm v_temp_mag :pre
|
||||
thermo 10
|
||||
thermo_style custom step v_mag_z v_mag_norm v_temp_mag :pre
|
||||
|
||||
This series of commands evaluates the total magnetization along z, the norm of
|
||||
the total magnetization, and the magnetic temperature. Three variables are
|
||||
|
||||
@ -52,4 +52,4 @@ provided by Pair's single_hessian.
|
||||
|
||||
[Default:]
|
||||
|
||||
The default settings are file = "dynmat.dyn", binary = no
|
||||
The default settings are file = "dynmat.dyn", binary = no
|
||||
|
||||
@ -221,7 +221,7 @@ accelerated styles exist.
|
||||
"heat"_fix_heat.html - add/subtract momentum-conserving heat
|
||||
"hyper/global"_fix_hyper_global.html - global hyperdynamics
|
||||
"hyper/local"_fix_hyper_local.html - local hyperdynamics
|
||||
"imd"_fix_imd.html - implements the “Interactive MD” (IMD) protocol
|
||||
"imd"_fix_imd.html - implements the “Interactive MD” (IMD) protocol
|
||||
"indent"_fix_indent.html - impose force due to an indenter
|
||||
"ipi"_fix_ipi.html - enable LAMMPS to run as a client for i-PI path-integral simulations
|
||||
"langevin"_fix_langevin.html - Langevin temperature control
|
||||
@ -327,7 +327,7 @@ accelerated styles exist.
|
||||
"rigid/nvt/small"_fix_rigid.html - constrain many small clusters of atoms to move as a rigid body with NVT integration
|
||||
"rigid/small"_fix_rigid.html - constrain many small clusters of atoms to move as a rigid body with NVE integration
|
||||
"rx"_fix_rx.html -
|
||||
"saed/vtk"_fix_saed_vtk.html -
|
||||
"saed/vtk"_fix_saed_vtk.html -
|
||||
"setforce"_fix_setforce.html - set the force on each atom
|
||||
"shake"_fix_shake.html - SHAKE constraints on bonds and/or angles
|
||||
"shardlow"_fix_shardlow.html - integration of DPD equations of motion using the Shardlow splitting
|
||||
|
||||
@ -31,7 +31,6 @@ cvar = name of control variable :l
|
||||
|
||||
[Examples:]
|
||||
|
||||
|
||||
fix 1 all controller 100 1.0 0.5 0.0 0.0 c_thermo_temp 1.5 tcontrol
|
||||
fix 1 all controller 100 0.2 0.5 0 100.0 v_pxxwall 1.01325 xwall
|
||||
fix 1 all controller 10000 0.2 0.5 0 2000 v_avpe -3.785 tcontrol :pre
|
||||
|
||||
@ -24,18 +24,18 @@ 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
|
||||
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
|
||||
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
|
||||
|
||||
@ -21,7 +21,7 @@ style = {zeeman} or {anisotropy} or {cubic} :l
|
||||
{anisotropy} args = K x y z
|
||||
K = intensity of the magnetic anisotropy (in eV)
|
||||
x y z = vector direction of the anisotropy :pre
|
||||
{cubic} args = K1 K2c n1x n1y n1x n2x n2y n2z n3x n3y n3z
|
||||
{cubic} args = K1 K2c n1x n1y n1x n2x n2y n2z n3x n3y n3z
|
||||
K1 and K2c = intensity of the magnetic anisotropy (in eV)
|
||||
n1x to n3z = three direction vectors of the cubic anisotropy :pre
|
||||
:ule
|
||||
@ -55,24 +55,24 @@ with n defining the direction of the anisotropy, and K (in eV) its intensity.
|
||||
If K>0, an easy axis is defined, and if K<0, an easy plane is defined.
|
||||
|
||||
Style {cubic} is used to simulate a cubic anisotropy, with three
|
||||
possible easy axis for the magnetic spins in the defined group:
|
||||
possible easy axis for the magnetic spins in the defined group:
|
||||
|
||||
:c,image(Eqs/fix_spin_cubic.jpg)
|
||||
|
||||
with K1 and K2c (in eV) the intensity coefficients and
|
||||
with K1 and K2c (in eV) the intensity coefficients and
|
||||
n1, n2 and n3 defining the three anisotropic directions
|
||||
defined by the command (from n1x to n3z).
|
||||
For n1 = (100), n2 = (010), and n3 = (001), K1 < 0 defines an
|
||||
defined by the command (from n1x to n3z).
|
||||
For n1 = (100), n2 = (010), and n3 = (001), K1 < 0 defines an
|
||||
iron type anisotropy (easy axis along the (001)-type cube
|
||||
edges), and K1 > 0 defines a nickel type anisotropy (easy axis
|
||||
along the (111)-type cube diagonals).
|
||||
along the (111)-type cube diagonals).
|
||||
K2^c > 0 also defines easy axis along the (111)-type cube
|
||||
diagonals.
|
||||
See chapter 2 of "(Skomski)"_#Skomski1 for more details on cubic
|
||||
anisotropies.
|
||||
|
||||
In all cases, the choice of (x y z) only imposes the vector
|
||||
directions for the forces. Only the direction of the vector is
|
||||
directions for the forces. Only the direction of the vector is
|
||||
important; it's length is ignored (the entered vectors are
|
||||
normalized).
|
||||
|
||||
|
||||
@ -44,7 +44,7 @@ fix 1 rods rigid/meso molecule
|
||||
fix 1 spheres rigid/meso single force 1 off off on
|
||||
fix 1 particles rigid/meso molecule force 1*5 off off off force 6*10 off off on
|
||||
fix 2 spheres rigid/meso group 3 sphere1 sphere2 sphere3 torque * off off off :pre
|
||||
|
||||
|
||||
[Description:]
|
||||
|
||||
Treat one or more sets of mesoscopic SPH/SDPD particles as independent
|
||||
|
||||
@ -67,15 +67,15 @@ 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
|
||||
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.
|
||||
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
|
||||
All options defined above remain valid, they just apply to the magnetic
|
||||
precession vectors instead of the forces.
|
||||
|
||||
:line
|
||||
@ -132,7 +132,7 @@ 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:]
|
||||
[Restrictions:]
|
||||
|
||||
The fix {setforce/spin} only makes sense when LAMMPS was built with the
|
||||
SPIN package.
|
||||
|
||||
@ -116,10 +116,10 @@ used without a cutoff, i.e. they become full long-range potentials.
|
||||
The {ewald/disp} style can also be used with point-dipoles, see
|
||||
"(Toukmaji)"_#Toukmaji.
|
||||
|
||||
The {ewald/dipole} style adds long-range standard Ewald summations
|
||||
The {ewald/dipole} style adds long-range standard Ewald summations
|
||||
for dipole-dipole interactions, see "(Toukmaji)"_#Toukmaji.
|
||||
|
||||
The {ewald/dipole/spin} style adds long-range standard Ewald
|
||||
The {ewald/dipole/spin} style adds long-range standard Ewald
|
||||
summations for magnetic dipole-dipole interactions between
|
||||
magnetic spins.
|
||||
|
||||
@ -142,11 +142,11 @@ The optional {smallq} argument defines the cutoff for the absolute
|
||||
charge value which determines whether a particle is considered charged
|
||||
or not. Its default value is 1.0e-5.
|
||||
|
||||
The {pppm/dipole} style invokes a particle-particle particle-mesh solver
|
||||
The {pppm/dipole} style invokes a particle-particle particle-mesh solver
|
||||
for dipole-dipole interactions, following the method of "(Cerda)"_#Cerda2008.
|
||||
|
||||
The {pppm/dipole/spin} style invokes a particle-particle particle-mesh solver
|
||||
for magnetic dipole-dipole interactions between magnetic spins.
|
||||
The {pppm/dipole/spin} style invokes a particle-particle particle-mesh solver
|
||||
for magnetic dipole-dipole interactions between magnetic spins.
|
||||
|
||||
The {pppm/tip4p} style is identical to the {pppm} style except that it
|
||||
adds a charge at the massless 4th site in each TIP4P water molecule.
|
||||
|
||||
@ -17,7 +17,7 @@ keyword = {dmax} or {line} or {alpha_damp} or {discrete_factor}
|
||||
{dmax} value = max
|
||||
max = maximum distance for line search to move (distance units)
|
||||
{line} value = {backtrack} or {quadratic} or {forcezero}
|
||||
backtrack,quadratic,forcezero = style of linesearch to use
|
||||
backtrack,quadratic,forcezero = style of linesearch to use
|
||||
{alpha_damp} value = damping
|
||||
damping = fictitious Gilbert damping for spin minimization (adim)
|
||||
{discrete_factor} value = factor
|
||||
@ -70,14 +70,14 @@ that difference may be smaller than machine epsilon even if atoms
|
||||
could move in the gradient direction to reduce forces further.
|
||||
|
||||
Keywords {alpha_damp} and {discrete_factor} only make sense when
|
||||
a "min_spin"_min_spin.html command is declared.
|
||||
a "min_spin"_min_spin.html command is declared.
|
||||
Keyword {alpha_damp} defines an analog of a magnetic Gilbert
|
||||
damping. It defines a relaxation rate toward an equilibrium for
|
||||
a given magnetic system.
|
||||
a given magnetic system.
|
||||
Keyword {discrete_factor} defines a discretization factor for the
|
||||
adaptive timestep used in the {spin} minimization.
|
||||
adaptive timestep used in the {spin} minimization.
|
||||
See "min_spin"_min_spin.html for more information about those
|
||||
quantities.
|
||||
quantities.
|
||||
Default values are {alpha_damp} = 1.0 and {discrete_factor} = 10.0.
|
||||
|
||||
[Restrictions:] none
|
||||
|
||||
@ -13,7 +13,7 @@ min_style spin :pre
|
||||
|
||||
[Examples:]
|
||||
|
||||
min_style spin :pre
|
||||
min_style spin :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
@ -27,36 +27,36 @@ timestep, according to:
|
||||
|
||||
with lambda a damping coefficient (similar to a Gilbert
|
||||
damping).
|
||||
Lambda can be defined by setting the {alpha_damp} keyword with the
|
||||
"min_modify"_min_modify.html command.
|
||||
Lambda can be defined by setting the {alpha_damp} keyword with the
|
||||
"min_modify"_min_modify.html command.
|
||||
|
||||
The minimization procedure solves this equation using an
|
||||
adaptive timestep. The value of this timestep is defined
|
||||
by the largest precession frequency that has to be solved in the
|
||||
adaptive timestep. The value of this timestep is defined
|
||||
by the largest precession frequency that has to be solved in the
|
||||
system:
|
||||
|
||||
:c,image(Eqs/min_spin_timestep.jpg)
|
||||
|
||||
with {|omega|_{max}} the norm of the largest precession frequency
|
||||
in the system (across all processes, and across all replicas if a
|
||||
spin/neb calculation is performed).
|
||||
spin/neb calculation is performed).
|
||||
|
||||
Kappa defines a discretization factor {discrete_factor} for the
|
||||
definition of this timestep.
|
||||
Kappa defines a discretization factor {discrete_factor} for the
|
||||
definition of this timestep.
|
||||
{discrete_factor} can be defined with the "min_modify"_min_modify.html
|
||||
command.
|
||||
|
||||
NOTE: The {spin} style replaces the force tolerance by a torque
|
||||
tolerance. See "minimize"_minimize.html for more explanation.
|
||||
tolerance. See "minimize"_minimize.html for more explanation.
|
||||
|
||||
[Restrictions:]
|
||||
[Restrictions:]
|
||||
|
||||
This minimization procedure is only applied to spin degrees of
|
||||
freedom for a frozen lattice configuration.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"min_style"_min_style.html, "minimize"_minimize.html,
|
||||
"min_style"_min_style.html, "minimize"_minimize.html,
|
||||
"min_modify"_min_modify.html
|
||||
|
||||
[Default:]
|
||||
|
||||
@ -62,7 +62,7 @@ the velocity non-parallel to the current force vector. The velocity
|
||||
of each atom is initialized to 0.0 by this style, at the beginning of
|
||||
a minimization.
|
||||
|
||||
Style {spin} is a damped spin dynamics with an adaptive
|
||||
Style {spin} is a damped spin dynamics with an adaptive
|
||||
timestep.
|
||||
See the "min/spin"_min_spin.html doc page for more information.
|
||||
|
||||
@ -74,10 +74,10 @@ defined via the "timestep"_timestep.html command. Often they will
|
||||
converge more quickly if you use a timestep about 10x larger than you
|
||||
would normally use for dynamics simulations.
|
||||
|
||||
NOTE: The {quickmin}, {fire}, {hftn}, and {cg/kk} styles do not yet
|
||||
support the use of the "fix box/relax"_fix_box_relax.html command or
|
||||
minimizations involving the electron radius in "eFF"_pair_eff.html
|
||||
models.
|
||||
NOTE: The {quickmin}, {fire}, {hftn}, and {cg/kk} styles do not yet
|
||||
support the use of the "fix box/relax"_fix_box_relax.html command or
|
||||
minimizations involving the electron radius in "eFF"_pair_eff.html
|
||||
models.
|
||||
|
||||
:line
|
||||
|
||||
|
||||
@ -106,9 +106,9 @@ the number of total force evaluations exceeds {maxeval} :ul
|
||||
|
||||
NOTE: the "minimization style"_min_style.html {spin} replaces
|
||||
the force tolerance {ftol} by a torque tolerance.
|
||||
The minimization procedure stops if the 2-norm (length) of the
|
||||
global torque vector (defined as the cross product between the
|
||||
spins and their precession vectors omega) is less than {ftol},
|
||||
The minimization procedure stops if the 2-norm (length) of the
|
||||
global torque vector (defined as the cross product between the
|
||||
spins and their precession vectors omega) is less than {ftol},
|
||||
or if any of the other criteria are met.
|
||||
|
||||
NOTE: You can also use the "fix halt"_fix_halt.html command to specify
|
||||
|
||||
@ -45,7 +45,7 @@ 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.
|
||||
another.
|
||||
The implementation in LAMMPS follows the discussion in the
|
||||
following paper: "(BessarabA)"_#BessarabA.
|
||||
|
||||
@ -61,33 +61,33 @@ 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.
|
||||
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
|
||||
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.
|
||||
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.
|
||||
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
|
||||
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
|
||||
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
|
||||
@ -106,21 +106,21 @@ 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
|
||||
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 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
|
||||
NOTE: The angular interpolation between the starting and final point
|
||||
is achieved using Rodrigues formula:
|
||||
|
||||
:c,image(Eqs/neb_spin_rodrigues_formula.jpg)
|
||||
@ -130,7 +130,7 @@ 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
|
||||
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:
|
||||
|
||||
@ -139,16 +139,16 @@ k_i defines a rotation axis such as:
|
||||
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
|
||||
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.
|
||||
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
|
||||
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
|
||||
@ -173,7 +173,7 @@ 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).
|
||||
"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.
|
||||
|
||||
@ -195,9 +195,9 @@ damped dynamics is like a single timestep in a dynamics
|
||||
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
|
||||
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
|
||||
@ -207,11 +207,11 @@ 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
|
||||
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
|
||||
@ -234,12 +234,12 @@ 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.
|
||||
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.
|
||||
non-GNEB atoms, as defined above.
|
||||
|
||||
:line
|
||||
|
||||
@ -257,7 +257,7 @@ 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,
|
||||
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.
|
||||
@ -290,22 +290,22 @@ 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,
|
||||
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
|
||||
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
|
||||
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
|
||||
@ -313,17 +313,17 @@ 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
|
||||
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
|
||||
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.
|
||||
value is the corresponding output.
|
||||
|
||||
When a NEB calculation does not converge properly, the supplementary
|
||||
information can help understanding what is going wrong.
|
||||
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
|
||||
@ -346,9 +346,9 @@ 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
|
||||
directory, that interpolates the MEP given the information provided
|
||||
by the verbose output option (as detailed in Appendix D of
|
||||
"(BessarabA)"_#BessarabA).
|
||||
"(BessarabA)"_#BessarabA).
|
||||
|
||||
:line
|
||||
|
||||
|
||||
@ -423,115 +423,115 @@ 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, which is the default when running on
|
||||
CPUs (i.e. the Kokkos CUDA back end is not enabled).
|
||||
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 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
|
||||
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}.
|
||||
|
||||
If the {neigh/thread} keyword is set to {off}, then the KOKKOS package
|
||||
threads only over atoms. However, for small systems, this may not expose
|
||||
enough parallelism to keep a GPU busy. When this keyword is set to {on},
|
||||
the KOKKOS package threads over both atoms and neighbors of atoms. When
|
||||
using {neigh/thread} {on}, a full neighbor list must also be used. Using
|
||||
{neigh/thread} {on} may be slower for large systems, so this this option
|
||||
is turned on by default only when there are 16K atoms or less owned by
|
||||
an MPI rank and when using a full neighbor list. Not all KOKKOS-enabled
|
||||
potentials support this keyword yet, and only thread over atoms. Many
|
||||
simple pair-wise potentials such as Lennard-Jones do support threading
|
||||
If the {neigh/thread} keyword is set to {off}, then the KOKKOS package
|
||||
threads only over atoms. However, for small systems, this may not expose
|
||||
enough parallelism to keep a GPU busy. When this keyword is set to {on},
|
||||
the KOKKOS package threads over both atoms and neighbors of atoms. When
|
||||
using {neigh/thread} {on}, a full neighbor list must also be used. Using
|
||||
{neigh/thread} {on} may be slower for large systems, so this this option
|
||||
is turned on by default only when there are 16K atoms or less owned by
|
||||
an MPI rank and when using a full neighbor list. Not all KOKKOS-enabled
|
||||
potentials support this keyword yet, and only thread over atoms. Many
|
||||
simple pair-wise potentials such as Lennard-Jones do support threading
|
||||
over both atoms and neighbors.
|
||||
|
||||
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 {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 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 {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
|
||||
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} 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
|
||||
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 is the
|
||||
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 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. 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 small systems on a GPU,
|
||||
performing the exchange pack/unpack on the host CPU can give speedup
|
||||
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. 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 small systems on a GPU,
|
||||
performing the exchange pack/unpack on the host CPU can give speedup
|
||||
since it reduces the number of CUDA kernel launches.
|
||||
|
||||
The {cuda/aware} keyword chooses whether CUDA-aware MPI 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 CUDA-aware MPI 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 CUDA-aware MPI is not
|
||||
available (currently only possible with OpenMPI v2.0.0 or later), then
|
||||
the {cuda/aware} keyword is automatically set to {off} by default. When
|
||||
the {cuda/aware} 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. CUDA-aware MPI is available for OpenMPI 1.8 (or later
|
||||
The {cuda/aware} keyword chooses whether CUDA-aware MPI 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 CUDA-aware MPI 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 CUDA-aware MPI is not
|
||||
available (currently only possible with OpenMPI v2.0.0 or later), then
|
||||
the {cuda/aware} keyword is automatically set to {off} by default. When
|
||||
the {cuda/aware} 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. CUDA-aware MPI is available for OpenMPI 1.8 (or later
|
||||
versions), Mvapich2 1.9 (or later) when the "MV2_USE_CUDA" environment
|
||||
variable is set to "1", CrayMPI, and IBM Spectrum MPI when the "-gpu"
|
||||
flag is used.
|
||||
@ -641,16 +641,16 @@ not used, you must invoke the package intel command in your input
|
||||
script or via the "-pk intel" "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, cuda/aware = on. When LAMMPS can safely detect
|
||||
that CUDA-aware MPI is not available, the default value of cuda/aware
|
||||
becomes "off". For CPUs or Xeon Phis, the option defaults are neigh =
|
||||
half, neigh/qeq = half, newton = on, binsize = 0.0, and comm = no. The
|
||||
option neigh/thread = on when there are 16K atoms or less on an MPI
|
||||
rank, otherwise it is "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
|
||||
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, cuda/aware = on. When LAMMPS can safely detect
|
||||
that CUDA-aware MPI is not available, the default value of cuda/aware
|
||||
becomes "off". For CPUs or Xeon Phis, the option defaults are neigh =
|
||||
half, neigh/qeq = half, newton = on, binsize = 0.0, and comm = no. The
|
||||
option neigh/thread = on when there are 16K atoms or less on an MPI
|
||||
rank, otherwise it is "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 OMP package, the default is Nthreads = 0 and the option
|
||||
|
||||
@ -20,8 +20,8 @@ If the {preset} keyword is given, no others are needed.
|
||||
Otherwise, all are mandatory except for {neigh}.
|
||||
The {neigh} keyword is always optional. :l
|
||||
{preset} arg = {2011} or {2015} = which set of predefined parameters to use
|
||||
2011 = use the potential parameters from "(Tainter 2011)"_#Tainter2011
|
||||
2015 = use the potential parameters from "(Tainter 2015)"_#Tainter2015
|
||||
2011 = use the potential parameters from "(Tainter 2011)"_#Tainter2011
|
||||
2015 = use the potential parameters from "(Tainter 2015)"_#Tainter2015
|
||||
{Ea} arg = three-body energy for type A hydrogen bonding interactions (energy units)
|
||||
{Eb} arg = three-body energy for type B hydrogen bonding interactions (energy units)
|
||||
{Ec} arg = three-body energy for type C hydrogen bonding interactions (energy units)
|
||||
|
||||
@ -790,4 +790,4 @@ alternative contact force models during inelastic collisions. Powder
|
||||
Technology, 233, 30-46.
|
||||
|
||||
:link(WaltonPC)
|
||||
[(Otis R. Walton)] Walton, O.R., Personal Communication
|
||||
[(Otis R. Walton)] Walton, O.R., Personal Communication
|
||||
|
||||
@ -43,8 +43,8 @@ when the tapper function is turned off. The formula of taper function
|
||||
can be found in pair style "ilp/graphene/hbn"_pair_ilp_graphene_hbn.html.
|
||||
|
||||
NOTE: This potential (ILP) is intended for interlayer interactions between two
|
||||
different layers of graphene. To perform a realistic simulation, this potential
|
||||
must be used in combination with intralayer potential, such as
|
||||
different layers of graphene. To perform a realistic simulation, this potential
|
||||
must be used in combination with intralayer potential, such as
|
||||
"AIREBO"_pair_airebo.html or "Tersoff"_pair_tersoff.html potential.
|
||||
To keep the intralayer properties unaffected, the interlayer interaction
|
||||
within the same layers should be avoided. Hence, each atom has to have a layer
|
||||
|
||||
@ -68,7 +68,7 @@ gamma (distance) :ul
|
||||
|
||||
[Mixing, shift, table, tail correction, restart, rRESPA info]:
|
||||
|
||||
Mixing rules are fixed for this style as defined above.
|
||||
Mixing rules are fixed for this style as defined above.
|
||||
|
||||
Shifting the potential energy is not necessary because the switching
|
||||
function ensures that the potential is zero at the cut-off.
|
||||
|
||||
@ -27,8 +27,8 @@ args = list of arguments for these particular styles :ul
|
||||
{oxdna2/stk} args = seq T xi kappa 6.0 0.4 0.9 0.32 0.6 1.3 0 0.8 0.9 0 0.95 0.9 0 0.95 2.0 0.65 2.0 0.65
|
||||
seq = seqav (for average sequence stacking strength) or seqdep (for sequence-dependent stacking strength)
|
||||
T = temperature (oxDNA units, 0.1 = 300 K)
|
||||
xi = temperature-independent coefficient in stacking strength
|
||||
kappa = coefficient of linear temperature dependence in stacking strength
|
||||
xi = temperature-independent coefficient in stacking strength
|
||||
kappa = coefficient of linear temperature dependence in stacking strength
|
||||
{oxdna2/hbond} args = seq eps 8.0 0.4 0.75 0.34 0.7 1.5 0 0.7 1.5 0 0.7 1.5 0 0.7 0.46 3.141592653589793 0.7 4.0 1.5707963267948966 0.45 4.0 1.5707963267948966 0.45
|
||||
seq = seqav (for average sequence base-pairing strength) or seqdep (for sequence-dependent base-pairing strength)
|
||||
eps = 1.0678 (between base pairs A-T and C-G) or 0 (all other pairs)
|
||||
|
||||
@ -50,7 +50,7 @@ the SNAP potential files themselves.
|
||||
Only a single pair_coeff command is used with the {snap} style which
|
||||
specifies a SNAP coefficient file followed by a SNAP parameter file
|
||||
and then N additional arguments specifying the mapping of SNAP
|
||||
elements to LAMMPS atom types, where N is the number of
|
||||
elements to LAMMPS atom types, where N is the number of
|
||||
LAMMPS atom types:
|
||||
|
||||
SNAP coefficient file
|
||||
@ -79,7 +79,7 @@ The name of the SNAP coefficient file usually ends in the
|
||||
".snapcoeff" extension. It may contain coefficients
|
||||
for many SNAP elements. The only requirement is that it
|
||||
contain at least those element names appearing in the
|
||||
LAMMPS mapping list.
|
||||
LAMMPS mapping list.
|
||||
The name of the SNAP parameter file usually ends in the ".snapparam"
|
||||
extension. It contains a small number
|
||||
of parameters that define the overall form of the SNAP potential.
|
||||
|
||||
@ -11,7 +11,7 @@ pair_style spin/dipole/long command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
pair_style spin/dipole/cut cutoff
|
||||
pair_style spin/dipole/cut cutoff
|
||||
pair_style spin/dipole/long cutoff :pre
|
||||
|
||||
cutoff = global cutoff for magnetic dipole energy and forces
|
||||
@ -21,7 +21,7 @@ cutoff = global cutoff for magnetic dipole energy and forces
|
||||
[Examples:]
|
||||
|
||||
pair_style spin/dipole/cut 10.0
|
||||
pair_coeff * * 10.0
|
||||
pair_coeff * * 10.0
|
||||
pair_coeff 2 3 8.0 :pre
|
||||
|
||||
pair_style spin/dipole/long 9.0
|
||||
@ -32,24 +32,24 @@ pair_coeff 2 3 1.0 1.0 2.5 4.0 :pre
|
||||
[Description:]
|
||||
|
||||
Style {spin/dipole/cut} computes a short-range dipole-dipole
|
||||
interaction between pairs of magnetic particles that each
|
||||
have a magnetic spin.
|
||||
interaction between pairs of magnetic particles that each
|
||||
have a magnetic spin.
|
||||
The magnetic dipole-dipole interactions are computed by the
|
||||
following formulas for the magnetic energy, magnetic precession
|
||||
following formulas for the magnetic energy, magnetic precession
|
||||
vector omega and mechanical force between particles I and J.
|
||||
|
||||
:c,image(Eqs/pair_spin_dipole.jpg)
|
||||
|
||||
where si and sj are the spin on two magnetic particles,
|
||||
r is their separation distance, and the vector e = (Ri - Rj)/|Ri - Rj|
|
||||
is the direction vector between the two particles.
|
||||
where si and sj are the spin on two magnetic particles,
|
||||
r is their separation distance, and the vector e = (Ri - Rj)/|Ri - Rj|
|
||||
is the direction vector between the two particles.
|
||||
|
||||
Style {spin/dipole/long} computes long-range magnetic dipole-dipole
|
||||
interaction.
|
||||
A "kspace_style"_kspace_style.html must be defined to
|
||||
use this pair style. Currently, "kspace_style
|
||||
use this pair style. Currently, "kspace_style
|
||||
ewald/dipole/spin"_kspace_style.html and "kspace_style
|
||||
pppm/dipole/spin"_kspace_style.html support long-range magnetic
|
||||
pppm/dipole/spin"_kspace_style.html support long-range magnetic
|
||||
dipole-dipole interactions.
|
||||
|
||||
:line
|
||||
@ -68,8 +68,8 @@ to be specified in an input script that reads a restart file.
|
||||
[Restrictions:]
|
||||
|
||||
The {spin/dipole/cut} and {spin/dipole/long} styles are part of
|
||||
the SPIN package. They are only enabled if LAMMPS was built with that
|
||||
package. See the "Build package"_Build_package.html doc page for more
|
||||
the SPIN package. They are only enabled if LAMMPS was built with that
|
||||
package. See the "Build package"_Build_package.html doc page for more
|
||||
info.
|
||||
|
||||
Using dipole/spin pair styles with {electron} "units"_units.html is not
|
||||
|
||||
@ -15,11 +15,11 @@ pair_style spin/dmi cutoff :pre
|
||||
cutoff = global cutoff pair (distance in metal units) :ulb,l
|
||||
|
||||
:ule
|
||||
|
||||
|
||||
[Examples:]
|
||||
|
||||
pair_style spin/dmi 4.0
|
||||
pair_coeff * * dmi 2.6 0.001 1.0 0.0 0.0
|
||||
pair_coeff * * dmi 2.6 0.001 1.0 0.0 0.0
|
||||
pair_coeff 1 2 dmi 4.0 0.00109 0.0 0.0 1.0 :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
@ -15,7 +15,7 @@ pair_style spin/neel cutoff :pre
|
||||
cutoff = global cutoff pair (distance in metal units) :ulb,l
|
||||
|
||||
:ule
|
||||
|
||||
|
||||
[Examples:]
|
||||
|
||||
pair_style spin/neel 4.0
|
||||
|
||||
Reference in New Issue
Block a user