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

Merge branch 'master' into stochasticwall

Browse Source
This commit is contained in:
Axel Kohlmeyer
2019-09-24 12:08:38 -04:00
parent 12ffa868b3 aa2b885783
commit a3e255b314
182 changed files with 17036 additions and 86554 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
doc/src/Build_basics.txt
View File

@ -51,7 +51,7 @@ Serial build (see src/MAKE/Makefile.serial):
MPI_INC = -I../STUBS
MPI_PATH = -L../STUBS
MPI_LIB = -lmpi_stubs :pre
MPI_LIB = -lmpi_stubs :pre
For a parallel build, if MPI is installed on your system in the usual
place (e.g. under /usr/local), you do not need to specify the 3
@ -183,17 +183,17 @@ want.
Parallel build (see src/MAKE/Makefile.mpi):
CC = mpicxx
CCFLAGS = -g -O3
LINK = mpicxx
LINKFLAGS = -g -O :pre
CC = mpicxx
CCFLAGS = -g -O3
LINK = mpicxx
LINKFLAGS = -g -O :pre
Serial build (see src/MAKE/Makefile.serial):
CC = g++
CCFLAGS = -g -O3
LINK = g++
LINKFLAGS = -g -O :pre
CC = g++
CCFLAGS = -g -O3
LINK = g++
LINKFLAGS = -g -O :pre
The "compiler/linker settings" section of a Makefile.machine lists
compiler and linker settings for your C++ compiler, including

2
doc/src/Build_development.txt
View File

@ -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

12
doc/src/Build_extras.txt
View File

@ -302,7 +302,7 @@ files.
KOKKOS_ABSOLUTE_PATH = $(shell cd $(KOKKOS_PATH); pwd)
export OMPI_CXX = $(KOKKOS_ABSOLUTE_PATH)/config/nvcc_wrapper
CC = mpicxx :pre
CC = mpicxx :pre
:line
@ -802,7 +802,7 @@ dir, using a command like these, which simply invoke the
lib/h5md/Install.py script with the specified args:
make lib-h5md # print help message
make lib-hm5d args="-m h5cc" # build with h5cc compiler :pre
make lib-h5md args="-m h5cc" # build with h5cc compiler :pre
The build should produce two files: lib/h5md/libch5md.a and
lib/h5md/Makefile.lammps. The latter is copied from an existing
@ -849,15 +849,15 @@ additional information.
For CPUs:
OPTFLAGS = -xHost -O2 -fp-model fast=2 -no-prec-div -qoverride-limits -qopt-zmm-usage=high
CCFLAGS = -g -qopenmp -DLAMMPS_MEMALIGN=64 -no-offload -fno-alias -ansi-alias -restrict $(OPTFLAGS)
LINKFLAGS = -g -qopenmp $(OPTFLAGS)
CCFLAGS = -g -qopenmp -DLAMMPS_MEMALIGN=64 -no-offload -fno-alias -ansi-alias -restrict $(OPTFLAGS)
LINKFLAGS = -g -qopenmp $(OPTFLAGS)
LIB = -ltbbmalloc :pre
For KNLs:
OPTFLAGS = -xMIC-AVX512 -O2 -fp-model fast=2 -no-prec-div -qoverride-limits
CCFLAGS = -g -qopenmp -DLAMMPS_MEMALIGN=64 -no-offload -fno-alias -ansi-alias -restrict $(OPTFLAGS)
LINKFLAGS = -g -qopenmp $(OPTFLAGS)
CCFLAGS = -g -qopenmp -DLAMMPS_MEMALIGN=64 -no-offload -fno-alias -ansi-alias -restrict $(OPTFLAGS)
LINKFLAGS = -g -qopenmp $(OPTFLAGS)
LIB = -ltbbmalloc :pre
:line

23
doc/src/Build_settings.txt
View File

@ -12,6 +12,7 @@ Optional build settings :h3
LAMMPS can be built with several optional settings. Each sub-section
explain how to do this for building both with CMake and make.
"C++11 standard compliance test"_#cxx11 when building all of LAMMPS
"FFT library"_#fft for use with the "kspace_style pppm"_kspace_style.html command
"Size of LAMMPS data types"_#size
"Read or write compressed files"_#gzip
@ -23,6 +24,28 @@ explain how to do this for building both with CMake and make.
:line
C++11 standard compliance test :h4,link(cxx11)
The LAMMPS developers plan to transition to make the C++11 standard the
minimum requirement for compiling LAMMPS. Currently this only applies to
some packages like KOKKOS while the rest aims to be compatible with the C++98
standard. Most currently used compilers are compatible with C++11; some need
to set extra flags to switch. To determine the impact of requiring C++11,
we have added a simple compliance test to the source code, that will cause
the compilation to abort, if C++11 compliance is not available or enabled.
To bypass this check, you need to change a setting in the makefile or
when calling CMake.
[CMake variable]:
-D DISABLE_CXX11_REQUIREMENT=yes
[Makefile.machine setting]:
LMP_INC = -DLAMMPS_CXX98
:line
FFT library :h4,link(fft)
When the KSPACE package is included in a LAMMPS build, the

2
doc/src/Commands_bond.txt
View File

@ -108,7 +108,7 @@ OPT.
"class2 (ko)"_dihedral_class2.html,
"cosine/shift/exp (o)"_dihedral_cosine_shift_exp.html,
"fourier (io)"_dihedral_fourier.html,
"harmonic (io)"_dihedral_harmonic.html,
"harmonic (iko)"_dihedral_harmonic.html,
"helix (o)"_dihedral_helix.html,
"multi/harmonic (o)"_dihedral_multi_harmonic.html,
"nharmonic (o)"_dihedral_nharmonic.html,

1
doc/src/Commands_pair.txt
View File

@ -166,6 +166,7 @@ OPT.
"lj/smooth/linear (o)"_pair_lj_smooth_linear.html,
"lj/switch3/coulgauss/long"_pair_lj_switch3_coulgauss.html,
"lj96/cut (go)"_pair_lj96.html,
"local/density"_pair_local_density.html,
"lubricate (o)"_pair_lubricate.html,
"lubricate/poly (o)"_pair_lubricate.html,
"lubricateU"_pair_lubricateU.html,

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 3.0 KiB

11
doc/src/Eqs/pair_local_density_energy.tex Normal file
View File

@ -0,0 +1,11 @@
\documentclass[12pt]{article}
\begin{document}
$$
U_{LD} = \sum_i F(\rho_i)
$$
\end{document}
~

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 7.8 KiB

9
doc/src/Eqs/pair_local_density_energy_implement.tex Normal file
View File

@ -0,0 +1,9 @@
\documentclass[12pt]{article}
\begin{document}
$$
U_{LD} = \sum_k U_{LD}^{(k)} = \sum_i \left[ \sum_k a_\alpha^{(k)} F^{(k)} \left(\rho_i^{(k)}\right) \right]
$$
\end{document}

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 3.4 KiB

9
doc/src/Eqs/pair_local_density_energy_multi.tex Normal file
View File

@ -0,0 +1,9 @@
\documentclass[12pt]{article}
\begin{document}
$$
U_{LD} = \sum_i a_\alpha F(\rho_i)
$$
\end{document}

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 8.8 KiB

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

@ -0,0 +1,16 @@
\documentclass[12pt]{article}
\usepackage[utf8]{inputenc}
\usepackage{amsmath}
\usepackage{amsfonts}
\begin{document}
\[
\varphi(r) =
\begin{cases}
1 & r \le R_1 \\
c_0 + c_2r^2 + c_4r^4 + c_6r^6 & r \in (R_1, R_2) \\
0 & r \ge R_2
\end{cases}
\]
\end{document}

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 3.0 KiB

10
doc/src/Eqs/pair_local_density_ld.tex Normal file
View File

@ -0,0 +1,10 @@
\documentclass[12pt]{article}
\begin{document}
$$
\rho_i = \sum_{j \neq i} \varphi(r_{ij})
$$
\end{document}

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 4.2 KiB

10
doc/src/Eqs/pair_local_density_ld_implement.tex Normal file
View File

@ -0,0 +1,10 @@
\documentstyle[12pt]{article}
\begin{document}
$$
\rho_i^{(k)} = \sum_j b_\beta^{(k)} \varphi^{(k)} (r_{ij})
$$
\end{document}

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

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 3.4 KiB

10
doc/src/Eqs/pair_local_density_ld_multi.tex Normal file
View File

@ -0,0 +1,10 @@
\documentclass[12pt]{article}
\begin{document}
$$
\rho_i = \sum_{j \neq i} b_\beta \varphi(r_{ij})
$$
\end{document}

16
doc/src/Howto_spins.txt
View File

@ -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

4
doc/src/Manual.txt
View File

@ -1,7 +1,7 @@
<!-- HTML_ONLY -->
<HEAD>
<TITLE>LAMMPS Users Manual</TITLE>
<META NAME="docnumber" CONTENT="7 Aug 2019 version">
<META NAME="docnumber" CONTENT="19 Sep 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
7 Aug 2019 version :c,h2
19 Sep 2019 version :c,h2
"What is a LAMMPS version?"_Manual_version.html

88
doc/src/Speed_kokkos.txt
View File

@ -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

23
doc/src/Tools.txt
View File

@ -76,9 +76,10 @@ Post-processing tools :h3
"pymol_asphere"_#pymol,
"python"_#pythontools,
"reax"_#reax_tool,
"replica"_#replica,
"smd"_#smd,
"spin"_#spin,
"xmgrace"_#xmgrace :tb(c=6,ea=c,a=l)
"xmgrace"_#xmgrace :tb(c=6,ea=c,a=l)
Miscellaneous tools :h3
@ -485,6 +486,21 @@ README for more info on Pizza.py and how to use these scripts.
:line
replica tool :h4,link(replica)
The tools/replica directory contains the reorder_remd_traj python script which
can be used to reorder the replica trajectories (resulting from the use of the
temper command) according to temperature. This will produce discontinuous
trajectories with all frames at the same temperature in each trajectory.
Additional options can be used to calculate the canonical configurational
log-weight for each frame at each temperature using the pymbar package. See
the README.md file for further details. Try out the peptide example provided.
This tool was written by (and is maintained by) Tanmoy Sanyal,
while at the Shell lab at UC Santa Barbara. (tanmoy dot 7989 at gmail.com)
:line
reax tool :h4,link(reax_tool)
The reax sub-directory contains stand-alone codes that can
@ -515,13 +531,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
@ -549,3 +565,4 @@ simulation.
See the README file for details.
These files were provided by Vikas Varshney (vv0210 at gmail.com)

4
doc/src/compute.txt
View File

@ -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

2
doc/src/compute_coord_atom.txt
View File

@ -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

36
doc/src/compute_hma.txt
View File

@ -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

12
doc/src/compute_orientorder_atom.txt
View File

@ -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})

19
doc/src/compute_pair_local.txt
View File

@ -64,6 +64,23 @@ which calculate the tangential force between two particles and return
its components and magnitude acting on atom I for N = 1,2,3,4. See
individual pair styles for details.
When using {pN} with pair style {hybrid}, the output will be the Nth
quantity from the sub-style that computes the pairwise interaction
(based on atom types). If that sub-style does not define a {pN},
the output will be 0.0. The maximum allowed N is the maximum number
of quantities provided by any sub-style.
When using {pN} with pair style {hybrid/overlay} the quantities
from all sub-styles that provide them are concatenated together
into one long list. For example, if there are 3 sub-styles and
2 of them have additional output (with 3 and 4 quantities,
respectively), then 7 values ({p1} up to {p7}) are defined.
The values {p1} to {p3} refer to quantities defined by the first
of the two sub-styles. Values {p4} to {p7} refer to quantities
from the second of the two sub-styles. If the referenced {pN}
is not computed for the specific pairwise interaction (based on
atom types), then the output will be 0.0.
The value {dist} will be in distance "units"_units.html. The value
{eng} will be in energy "units"_units.html. The values {force}, {fx},
{fy}, and {fz} will be in force "units"_units.html. The values {pN}
@ -126,7 +143,7 @@ options.
The output for {dist} will be in distance "units"_units.html. The
output for {eng} will be in energy "units"_units.html. The output for
{force}, {fx}, {fy}, and {fz} will be in force "units"_units.html.
The outpur for {pN} will be in whatever units the pair style defines.
The output for {pN} will be in whatever units the pair style defines.
[Restrictions:] none

2
doc/src/compute_sna_atom.txt
View File

@ -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.

12
doc/src/compute_spin.txt
View File

@ -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

1
doc/src/dihedral_harmonic.txt
View File

@ -8,6 +8,7 @@
dihedral_style harmonic command :h3
dihedral_style harmonic/intel command :h3
dihedral_style harmonic/kk command :h3
dihedral_style harmonic/omp command :h3
[Syntax:]

3
doc/src/dump.txt
View File

@ -21,7 +21,8 @@ dump ID group-ID style N file args :pre
ID = user-assigned name for the dump :ulb,l
group-ID = ID of the group of atoms to be dumped :l
style = {atom} or {atom/gz} or {atom/mpiio} or {cfg} or {cfg/gz} or {cfg/mpiio} or {custom} or {custom/gz} or {custom/mpiio} or {dcd} or {h5md} or {image} or {local} or {molfile} or {movie} or {netcdf} or {netcdf/mpiio} or {vtk} or {xtc} or {xyz} or {xyz/gz} or {xyz/mpiio} :l
style = {atom} or {atom/gz} or {atom/mpiio} or {cfg} or {cfg/gz} or
{cfg/mpiio} or {custom} or {custom/gz} or {custom/mpiio} or {dcd} or {h5md} or {image} or {local} or {local/gz} or {molfile} or {movie} or {netcdf} or {netcdf/mpiio} or {vtk} or {xtc} or {xyz} or {xyz/gz} or {xyz/mpiio} :l
N = dump every this many timesteps :l
file = name of file to write dump info to :l
args = list of arguments for a particular style :l

17
doc/src/dump_modify.txt
View File

@ -50,6 +50,7 @@ keyword = {append} or {at} or {buffer} or {delay} or {element} or {every} or {fi
{sfactor} arg = coordinate scaling factor (> 0.0)
{thermo} arg = {yes} or {no}
{tfactor} arg = time scaling factor (> 0.0)
{units} arg = {yes} or {no}
{sort} arg = {off} or {id} or N or -N
off = no sorting of per-atom lines within a snapshot
id = sort per-atom lines by atom ID
@ -620,6 +621,21 @@ threshold criterion is met. Otherwise it is not met.
:line
The {units} keyword only applies to the dump {atom}, {custom}, and
{local} styles (and their COMPRESS package versions {atom/gz},
{custom/gz} and {local/gz}). If set to {yes}, each individual dump
file will contain two extra lines at the very beginning with:
ITEM: UNITS
\<units style\> :pre
This will output the current selected "units"_units.html style
to the dump file and thus allows visualization and post-processing
tools to determine the choice of units of the data in the dump file.
The default setting is {no}.
:line
The {unwrap} keyword only applies to the dump {dcd} and {xtc} styles.
If set to {yes}, coordinates will be written "unwrapped" by the image
flags for each atom. Unwrapped means that if the atom has passed through
@ -924,6 +940,7 @@ scale = yes
sort = off for dump styles {atom}, {custom}, {cfg}, and {local}
sort = id for dump styles {dcd}, {xtc}, and {xyz}
thresh = none
units = no
unwrap = no :ul
acolor = * red/green/blue/yellow/aqua/cyan

2
doc/src/dynamical_matrix.txt
View File

@ -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

4
doc/src/fix.txt
View File

@ -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

54
doc/src/fix_bond_react.txt
View File

@ -186,20 +186,25 @@ reacting atoms.
Some atoms in the pre-reacted template that are not reacting may have
missing topology with respect to the simulation. For example, the
pre-reacted template may contain an atom that would connect to the
rest of a long polymer chain. These are referred to as edge atoms, and
are also specified in the map file. When the pre-reaction template
contains edge atoms, not all atoms, bonds, charges, etc. specified in
the reaction templates will be updated. Specifically, topology that
involves only atoms that are 'too near' to template edges will not be
updated. The definition of 'too near the edge' depends on which
interactions are defined in the simulation. If the simulation has
defined dihedrals, atoms within two bonds of edge atoms are considered
'too near the edge.' If the simulation defines angles, but not
dihedrals, atoms within one bond of edge atoms are considered 'too
near the edge.' If just bonds are defined, only edge atoms are
pre-reacted template may contain an atom that, in the simulation, is
currently connected to the rest of a long polymer chain. These are
referred to as edge atoms, and are also specified in the map file. All
pre-reaction template atoms should be linked to a bonding atom, via at
least one path that does not involve edge atoms. When the pre-reaction
template contains edge atoms, not all atoms, bonds, charges, etc.
specified in the reaction templates will be updated. Specifically,
topology that involves only atoms that are 'too near' to template
edges will not be updated. The definition of 'too near the edge'
depends on which interactions are defined in the simulation. If the
simulation has defined dihedrals, atoms within two bonds of edge atoms
are considered 'too near the edge.' If the simulation defines angles,
but not dihedrals, atoms within one bond of edge atoms are considered
'too near the edge.' If just bonds are defined, only edge atoms are
considered 'too near the edge.'
NOTE: Small molecules, i.e. ones that have all their atoms contained
within the reaction templates, never have edge atoms.
Note that some care must be taken when a building a molecule template
for a given simulation. All atom types in the pre-reacted template
must be the same as those of a potential reaction site in the
@ -392,10 +397,11 @@ local command.
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html, aside from internally-created per-atom
properties. None of the "fix_modify"_fix_modify.html options are
relevant to this fix.
Cumulative reaction counts for each reaction are written to "binary
restart files"_restart.html. These values are associated with the
reaction name (react-ID). Additionally, internally-created per-atom
properties are stored to allow for smooth restarts. None of the
"fix_modify"_fix_modify.html options are relevant to this fix.
This fix computes one statistic for each {react} argument that it
stores in a global vector, of length 'number of react arguments', that
@ -406,8 +412,8 @@ These is 1 quantity for each react argument:
(1) cumulative # of reactions occurred :ul
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command. This fix is not invoked during "energy
No parameter of this fix can be used with the {start/stop} keywords
of the "run"_run.html command. This fix is not invoked during "energy
minimization"_minimize.html.
When fix bond/react is 'unfixed,' all internally-created groups are
@ -417,18 +423,20 @@ all other fixes that use any group created by fix bond/react.
[Restrictions:]
This fix is part of the USER-MISC package. It is only enabled if
LAMMPS was built with that package. See the "Build
package"_Build_package.html doc page for more info.
LAMMPS was built with that package. See the
"Build package"_Build_package.html doc page for more info.
[Related commands:]
"fix bond/create"_fix_bond_create.html, "fix
bond/break"_fix_bond_break.html, "fix bond/swap"_fix_bond_swap.html,
"fix bond/create"_fix_bond_create.html,
"fix bond/break"_fix_bond_break.html,
"fix bond/swap"_fix_bond_swap.html,
"dump local"_dump.html, "special_bonds"_special_bonds.html
[Default:]
The option defaults are stabilization = no, prob = 1.0, stabilize_steps = 60, update_edges = none
The option defaults are stabilization = no, prob = 1.0, stabilize_steps = 60,
update_edges = none
:line

1
doc/src/fix_controller.txt
View File

@ -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

22
doc/src/fix_neb_spin.txt
View File

@ -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

14
doc/src/fix_precession_spin.txt
View File

@ -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).

2
doc/src/fix_rigid_meso.txt
View File

@ -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

14
doc/src/fix_setforce.txt
View File

@ -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.

16
doc/src/improper_fourier.txt
View File

@ -16,7 +16,7 @@ improper_style fourier :pre
[Examples:]
improper_style fourier
improper_coeff 1 100.0 180.0 :pre
improper_coeff 1 100.0 0.0 1.0 0.5 1 :pre
[Description:]
@ -24,12 +24,12 @@ The {fourier} improper style uses the following potential:
:c,image(Eqs/improper_fourier.jpg)
where K is the force constant and omega is the angle between the IL
axis and the IJK plane:
where K is the force constant, C0, C1, C2 are dimensionless coefficients,
and omega is the angle between the IL axis and the IJK plane:
:c,image(JPG/umbrella.jpg)
If all parameter (see bellow) is not zero, the all the three possible angles will taken in account.
If all parameter (see below) is not zero, the all the three possible angles will taken in account.
The following coefficients must be defined for each improper type via
the "improper_coeff"_improper_coeff.html command as in the example
@ -38,10 +38,10 @@ above, or in the data file or restart files read by the
commands:
K (energy)
C0 (real)
C1 (real)
C2 (real)
all (integer >= 0) :ul
C0 (unitless)
C1 (unitless)
C2 (unitless)
all (0 or 1, optional) :ul
:line

10
doc/src/kspace_style.txt
View File

@ -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.

1
doc/src/lammps.book
View File

@ -612,6 +612,7 @@ pair_lj_smooth.html
pair_lj_smooth_linear.html
pair_fep_soft.html
pair_lj_switch3_coulgauss.html
pair_local_density.html
pair_lubricate.html
pair_lubricateU.html
pair_mdf.html

10
doc/src/min_modify.txt
View File

@ -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

22
doc/src/min_spin.txt
View File

@ -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:]

10
doc/src/min_style.txt
View File

@ -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

6
doc/src/minimize.txt
View File

@ -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

128
doc/src/neb_spin.txt
View File

@ -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

200
doc/src/package.txt
View File

@ -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

4
doc/src/pair_e3b.txt
View File

@ -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)

2
doc/src/pair_granular.txt
View File

@ -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

4
doc/src/pair_kolmogorov_crespi_full.txt
View File

@ -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

207
doc/src/pair_local_density.txt Normal file
View File

@ -0,0 +1,207 @@
"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
pair_style local/density command :h3
[Syntax:]
pair_style style arg :pre
style = {local/density}
arg = name of file containing tabulated values of local density and the potential :ul
[Examples:]
pair_style local/density benzene_water.localdensity.table :pre
pair_style hybrid/overlay table spline 500 local/density
pair_coeff * * local/density benzene_water.localdensity.table :pre
[Description:]
The local density (LD) potential is a mean-field manybody potential, and, in some
sense,a generalization of embedded atom models (EAM). The name "local density
potential" arises from the fact that it assigns an energy to an atom depending
on the number of neighboring atoms of given type around it within a predefined
spherical volume (i.e., within a cutoff). The bottom-up coarse-graining (CG)
literature suggests that such potentials can be widely useful in capturing
effective multibody forces in a computationally efficient manner so as to
improve the quality of CG models of implicit solvation"(Sanyal1)"_#Sanyal1 and
phase-segregation in liquid mixtures"(Sanyal2)"_#Sanyal2, and provide guidelines
to determine the extent of manybody correlations present in a CG
model."(Rosenberger)"_#Rosenberger The LD potential in LAMMPS is primarily
intended to be used as a corrective potential over traditional pair potentials
in bottom-up CG models, i.e., as a hybrid pair style with
other explicit pair interaction terms (e.g., table spline, Lennard Jones, etc.).
Because the LD potential is not a pair potential per se, it is implemented
simply as a single auxiliary file with all specifications that will be read
upon initialization.
NOTE: Thus when used as the only interaction in the system, there is no
corresponding pair_coeff command and when used with other pair styles using the
hybrid/overlay option, the corresponding pair_coeff command must be supplied
* * as placeholders for the atom types.
:line
[System with a single CG atom type:]
A system of a single atom type (e.g., LJ argon) with a single local density (LD)
potential would have an energy given by:
:c,image(Eqs/pair_local_density_energy.jpg)
where rho_i is the LD at atom i and F(rho) is similar in spirit to the
embedding function used in EAM potentials. The LD at atom i is given by the sum
:c,image(Eqs/pair_local_density_ld.jpg)
where phi is an indicator function that is one at r=0 and zero beyond a cutoff
distance R2. The choice of the functional form of phi is somewhat arbitrary,
but the following piecewise cubic function has proven sufficiently general:
"(Sanyal1)"_#Sanyal1, "(Sanyal2)"_#Sanyal2 "(Rosenberger)"_#Rosenberger
:c,image(Eqs/pair_local_density_indicator_func.jpg)
The constants {c} are chosen so that the indicator function smoothly
interpolates between 1 and 0 between the distances R1 and R2, which are
called the inner and outer cutoffs, respectively. Thus phi satisfies
phi(R1) = 1, phi(R2) = dphi/dr @ (r=R1) = dphi/dr @ (r=R2) = 0. The embedding
function F(rho) may or may not have a closed-form expression. To maintain
generality, it is practically represented with a spline-interpolated table
over a predetermined range of rho. Outside of that range it simply adopts zero
values at the endpoints.
It can be shown that the total force between two atoms due to the LD potential
takes the form of a pair force, which motivates its designation as a LAMMPS
pair style. Please see "(Sanyal1)"_#Sanyal1 for details of the derivation.
:line
[Systems with arbitrary numbers of atom types:]
The potential is easily generalized to systems involving multiple atom types:
:c,image(Eqs/pair_local_density_energy_multi.jpg)
with the LD expressed as
:c,image(Eqs/pair_local_density_ld_multi.jpg)
where alpha gives the type of atom i, beta the type of atom j, and the
coefficients a and b filter for atom types as specified by the user. a is
called the central atom filter as it determines to which atoms the
potential applies; a_alpha = 1 if the LD potential applies to atom type alpha
else zero. On the other hand, b is called the neighbor atom filter because it
specifies which atom types to use in the calculation of the LD; b_beta = 1 if
atom type beta contributes to the LD and zero otherwise.
NOTE: Note that the potentials need not be symmetric with respect to atom types,
which is the reason for two distinct sets of coefficients a and b. An atom type
may contribute to the LD but not the potential, or to the potential but not the
LD. Such decisions are made by the user and should (ideally) be motivated on
physical grounds for the problem at hand.
:line
[General form for implementation in LAMMPS:]
Of course, a system with many atom types may have many different possible LD
potentials, each with their own atom type filters, cutoffs, and embedding
functions. The most general form of this potential as implemented in the
pair_style local/density is:
:c,image(Eqs/pair_local_density_energy_implement.jpg)
where, k is an index that spans the (arbitrary) number of applied LD potentials
N_LD. Each LD is calculated as before with:
:c,image(Eqs/pair_local_density_ld_implement.jpg)
The superscript on the indicator function phi simply indicates that it is
associated with specific values of the cutoff distances R1(k) and R2(k). In
summary, there may be N_LD distinct LD potentials. With each potential type (k),
one must specify:
the inner and outer cutoffs as R1 and R2
the central type filter a(k), where k = 1,2,...N_LD
the neighbor type filter b(k), where k = 1,2,...N_LD
the LD potential function F(k)(rho), typically as a table that is later spline-interpolated :ul
:line
[Tabulated input file format:]
Line 1: comment or blank (ignored)
Line 2: comment or blank (ignored)
Line 3: N_LD N_rho (# of LD potentials and # of tabulated values, single space separated)
Line 4: blank (ignored)
Line 5: R1(k) R2(k) (lower and upper cutoffs, single space separated)
Line 6: central-types (central atom types, single space separated)
Line 7: neighbor-types (neighbor atom types single space separated)
Line 8: rho_min rho_max drho (min, max and diff. in tabulated rho values, single space separated)
Line 9: F(k)(rho_min + 0.drho)
Line 10: F(k)(rho_min + 1.drho)
Line 11: F(k)(rho_min + 2.drho)
...
Line 9+N_rho: F(k)(rho_min + N_rho . drho)
Line 10+N_rho: blank (ignored) :pre
Block 2 :pre
Block 3 :pre
Block N_LD :pre
Lines 5 to 9+N_rho constitute the first block. Thus the input file is separated
(by blank lines) into N_LD blocks each representing a separate LD potential and
each specifying its own upper and lower cutoffs, central and neighbor atoms,
and potential. In general, blank lines anywhere are ignored.
:line
[Mixing, shift, table, tail correction, restart, info]:
This pair style does not support automatic mixing. For atom type pairs alpha,
beta and alpha != beta, even if LD potentials of type (alpha, alpha) and
(beta, beta) are provided, you will need to explicitly provide LD potential
types (alpha, beta) and (beta, alpha) if need be (Here, the notation (alpha,
beta) means that alpha is the central atom to which the LD potential is applied
and beta is the neighbor atom which contributes to the LD potential on alpha).
This pair style does not support the "pair_modify"_pair_modify.html
shift, table, and tail options.
The local/density pair style does not write its information to "binary restart
files"_restart.html, since it is stored in tabulated potential files.
Thus, you need to re-specify the pair_style and pair_coeff commands in
an input script that reads a restart file.
:line
[Restrictions:]
The local/density pair style is a part of the USER-MISC package. It is only
enabled if LAMMPS was built with that package. See the "Build
package"_Build_package.html doc page for more info.
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
:line
:link(Sanyal1)
[(Sanyal1)] Sanyal and Shell, Journal of Chemical Physics, 2016, 145 (3), 034109.
:link(Sanyal2)
[(Sanyal2)] Sanyal and Shell, Journal of Physical Chemistry B, 122 (21), 5678-5693.
:link(Rosenberger)
[(Rosenberger)] Rosenberger, Sanyal, Shell and van der Vegt, Journal of Chemical Physics, 2019, 151 (4), 044111.

2
doc/src/pair_mm3_switch3_coulgauss.txt
View File

@ -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.

4
doc/src/pair_oxdna2.txt
View File

@ -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)

4
doc/src/pair_snap.txt
View File

@ -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.

24
doc/src/pair_spin_dipole.txt
View File

@ -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

4
doc/src/pair_spin_dmi.txt
View File

@ -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:]

2
doc/src/pair_spin_neel.txt
View File

@ -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

1
doc/src/pair_style.txt
View File

@ -228,6 +228,7 @@ accelerated styles exist.
"lj/smooth/linear"_pair_lj_smooth_linear.html - linear smoothed LJ potential
"lj/switch3/coulgauss"_pair_lj_switch3_coulgauss - smoothed LJ vdW potential with Gaussian electrostatics
"lj96/cut"_pair_lj96.html - Lennard-Jones 9/6 potential
"local/density"_pair_local_density.html - generalized basic local density potential
"lubricate"_pair_lubricate.html - hydrodynamic lubrication forces
"lubricate/poly"_pair_lubricate.html - hydrodynamic lubrication forces with polydispersity
"lubricateU"_pair_lubricateU.html - hydrodynamic lubrication forces for Fast Lubrication Dynamics

1
doc/src/pairs.txt
View File

@ -66,6 +66,7 @@ Pair Styles :h1
pair_lj_smooth
pair_lj_smooth_linear
pair_lj_switch3_coulgauss
pair_local_density
pair_lubricate
pair_lubricateU
pair_mdf

8
doc/src/temper.txt
View File

@ -110,7 +110,13 @@ the information from the log.lammps file. E.g. you could produce one
dump file with snapshots at 300K (from all replicas), another with
snapshots at 310K, etc. Note that these new dump files will not
contain "continuous trajectories" for individual atoms, because two
successive snapshots (in time) may be from different replicas.
successive snapshots (in time) may be from different replicas. The
reorder_remd_traj python script can do the reordering for you
(and additionally also calculated configurational log-weights of
trajectory snapshots in the canonical ensemble). The script can be found
in the tools/replica directory while instructions on how to use it is
available in doc/Tools (in brief) and as a README file in tools/replica
(in detail).
The last argument {index} in the temper command is optional and is
used when restarting a tempering run from a set of restart files (one