diff --git a/bench/FERMI/README b/bench/FERMI/README
index db3f527bd..b66e56077 100644
--- a/bench/FERMI/README
+++ b/bench/FERMI/README
@@ -1,103 +1,51 @@
These are input scripts used to run versions of several of the
-benchmarks in the top-level bench directory using the GPU and
-USER-CUDA accelerator packages. The results of running these scripts
-on two different machines (a desktop with 2 Tesla GPUs and the ORNL
-Titan supercomputer) are shown on the "GPU (Fermi)" section of the
-Benchmark page of the LAMMPS WWW site: lammps.sandia.gov/bench.
+benchmarks in the top-level bench directory using the GPU accelerator
+package. The results of running these scripts on two different machines
+(a desktop with 2 Tesla GPUs and the ORNL Titan supercomputer) are shown
+on the "GPU (Fermi)" section of the Benchmark page of the LAMMPS WWW
+site: lammps.sandia.gov/bench.
Examples are shown below of how to run these scripts. This assumes
-you have built 3 executables with both the GPU and USER-CUDA packages
+you have built 3 executables with the GPU package
installed, e.g.
lmp_linux_single
lmp_linux_mixed
lmp_linux_double
-The precision (single, mixed, double) refers to the GPU and USER-CUDA
-package precision. See the README files in the lib/gpu and lib/cuda
-directories for instructions on how to build the packages with
-different precisions. The GPU and USER-CUDA sub-sections of the
-doc/Section_accelerate.html file also describes this process.
-
-Make.py -d ~/lammps -j 16 -p #all orig -m linux -o cpu -a exe
-Make.py -d ~/lammps -j 16 -p #all opt orig -m linux -o opt -a exe
-Make.py -d ~/lammps -j 16 -p #all omp orig -m linux -o omp -a exe
-Make.py -d ~/lammps -j 16 -p #all gpu orig -m linux \
- -gpu mode=double arch=20 -o gpu_double -a libs exe
-Make.py -d ~/lammps -j 16 -p #all gpu orig -m linux \
- -gpu mode=mixed arch=20 -o gpu_mixed -a libs exe
-Make.py -d ~/lammps -j 16 -p #all gpu orig -m linux \
- -gpu mode=single arch=20 -o gpu_single -a libs exe
-Make.py -d ~/lammps -j 16 -p #all cuda orig -m linux \
- -cuda mode=double arch=20 -o cuda_double -a libs exe
-Make.py -d ~/lammps -j 16 -p #all cuda orig -m linux \
- -cuda mode=mixed arch=20 -o cuda_mixed -a libs exe
-Make.py -d ~/lammps -j 16 -p #all cuda orig -m linux \
- -cuda mode=single arch=20 -o cuda_single -a libs exe
-Make.py -d ~/lammps -j 16 -p #all intel orig -m linux -o intel_cpu -a exe
-Make.py -d ~/lammps -j 16 -p #all kokkos orig -m linux -o kokkos_omp -a exe
-Make.py -d ~/lammps -j 16 -p #all kokkos orig -kokkos cuda arch=20 \
- -m cuda -o kokkos_cuda -a exe
-
-Make.py -d ~/lammps -j 16 -p #all opt omp gpu cuda intel kokkos orig \
- -gpu mode=double arch=20 -cuda mode=double arch=20 -m linux \
- -o all -a libs exe
-
-Make.py -d ~/lammps -j 16 -p #all opt omp gpu cuda intel kokkos orig \
- -kokkos cuda arch=20 -gpu mode=double arch=20 \
- -cuda mode=double arch=20 -m cuda -o all_cuda -a libs exe
-
------------------------------------------------------------------------
-To run on just CPUs (without using the GPU or USER-CUDA styles),
+To run on just CPUs (without using the GPU styles),
do something like the following:
mpirun -np 1 lmp_linux_double -v x 8 -v y 8 -v z 8 -v t 100 < in.lj
mpirun -np 12 lmp_linux_double -v x 16 -v y 16 -v z 16 -v t 100 < in.eam
The "xyz" settings determine the problem size. The "t" setting
determines the number of timesteps.
These mpirun commands run on a single node. To run on multiple
nodes, scale up the "-np" setting.
------------------------------------------------------------------------
To run with the GPU package, do something like the following:
mpirun -np 12 lmp_linux_single -sf gpu -v x 32 -v y 32 -v z 64 -v t 100 < in.lj
mpirun -np 8 lmp_linux_mixed -sf gpu -pk gpu 2 -v x 32 -v y 32 -v z 64 -v t 100 < in.eam
The "xyz" settings determine the problem size. The "t" setting
determines the number of timesteps. The "np" setting determines how
many MPI tasks (per node) the problem will run on. The numeric
argument to the "-pk" setting is the number of GPUs (per node); 1 GPU
is the default. Note that you can use more MPI tasks than GPUs (per
node) with the GPU package.
These mpirun commands run on a single node. To run on multiple nodes,
scale up the "-np" setting, and control the number of MPI tasks per
node via a "-ppn" setting.
------------------------------------------------------------------------
-To run with the USER-CUDA package, do something like the following:
-
-mpirun -np 1 lmp_linux_single -c on -sf cuda -v x 16 -v y 16 -v z 16 -v t 100 < in.lj
-mpirun -np 2 lmp_linux_double -c on -sf cuda -pk cuda 2 -v x 32 -v y 64 -v z 64 -v t 100 < in.eam
-
-The "xyz" settings determine the problem size. The "t" setting
-determines the number of timesteps. The "np" setting determines how
-many MPI tasks (per node) the problem will run on. The numeric
-argument to the "-pk" setting is the number of GPUs (per node); 1 GPU
-is the default. Note that the number of MPI tasks must equal the
-number of GPUs (both per node) with the USER-CUDA package.
-
-These mpirun commands run on a single node. To run on multiple nodes,
-scale up the "-np" setting, and control the number of MPI tasks per
-node via a "-ppn" setting.
-
-------------------------------------------------------------------------
-
If the script has "titan" in its name, it was run on the Titan
supercomputer at ORNL.
diff --git a/bench/README b/bench/README
index 85d71cbb5..0806fcded 100644
--- a/bench/README
+++ b/bench/README
@@ -1,127 +1,111 @@
LAMMPS benchmark problems
This directory contains 5 benchmark problems which are discussed in
the Benchmark section of the LAMMPS documentation, and on the
Benchmark page of the LAMMPS WWW site (lammps.sandia.gov/bench).
This directory also has several sub-directories:
FERMI benchmark scripts for desktop machine with Fermi GPUs (Tesla)
KEPLER benchmark scripts for GPU cluster with Kepler GPUs
POTENTIALS benchmarks scripts for various potentials in LAMMPS
The results for all of these benchmarks are displayed and discussed on
the Benchmark page of the LAMMPS WWW site: lammps.sandia.gov/bench.
The remainder of this file refers to the 5 problems in the top-level
of this directory and how to run them on CPUs, either in serial or
parallel. The sub-directories have their own README files which you
should refer to before running those scripts.
----------------------------------------------------------------------
Each of the 5 problems has 32,000 atoms and runs for 100 timesteps.
Each can be run as a serial benchmark (on one processor) or in
parallel. In parallel, each benchmark can be run as a fixed-size or
scaled-size problem. For fixed-size benchmarking, the same 32K atom
problem is run on various numbers of processors. For scaled-size
benchmarking, the model size is increased with the number of
processors. E.g. on 8 processors, a 256K-atom problem is run; on 1024
processors, a 32-million atom problem is run, etc.
A few sample log file outputs on different machines and different
numbers of processors are included in this directory to compare your
answers to. E.g. a log file like log.date.chain.lmp.scaled.foo.P is
for a scaled-size version of the Chain benchmark, run on P processors
of machine "foo" with the dated version of LAMMPS. Note that the Eam
and Lj benchmarks may not give identical answers on different machines
because of the "velocity loop geom" option that assigns velocities
based on atom coordinates - see the discussion in the documentation
for the velocity command for details.
The CPU time (in seconds) for the run is in the "Loop time" line
of the log files, e.g.
Loop time of 3.89418 on 8 procs for 100 steps with 32000 atoms
Timing results for these problems run on various machines are listed
on the Benchmarks page of the LAMMPS WWW Site.
----------------------------------------------------------------------
These are the 5 benchmark problems:
LJ = atomic fluid, Lennard-Jones potential with 2.5 sigma cutoff (55
neighbors per atom), NVE integration
Chain = bead-spring polymer melt of 100-mer chains, FENE bonds and LJ
pairwise interactions with a 2^(1/6) sigma cutoff (5 neighbors per
atom), NVE integration
EAM = metallic solid, Cu EAM potential with 4.95 Angstrom cutoff (45
neighbors per atom), NVE integration
Chute = granular chute flow, frictional history potential with 1.1
sigma cutoff (7 neighbors per atom), NVE integration
Rhodo = rhodopsin protein in solvated lipid bilayer, CHARMM force
field with a 10 Angstrom LJ cutoff (440 neighbors per atom),
particle-particle particle-mesh (PPPM) for long-range Coulombics, NPT
integration
----------------------------------------------------------------------
-Here is a src/Make.py command which will perform a parallel build of a
-LAMMPS executable "lmp_mpi" with all the packages needed by all the
-examples. This assumes you have an MPI installed on your machine so
-that "mpicxx" can be used as the wrapper compiler. It also assumes
-you have an Intel compiler to use as the base compiler. You can leave
-off the "-cc mpi wrap=icc" switch if that is not the case. You can
-also leave off the "-fft fftw3" switch if you do not have the FFTW
-(v3) installed as an FFT package, in which case the default KISS FFT
-library will be used.
-
-cd src
-Make.py -j 16 -p none molecule manybody kspace granular rigid orig \
- -cc mpi wrap=icc -fft fftw3 -a file mpi
-
-----------------------------------------------------------------------
-
Here is how to run each problem, assuming the LAMMPS executable is
named lmp_mpi, and you are using the mpirun command to launch parallel
runs:
Serial (one processor runs):
-lmp_mpi < in.lj
-lmp_mpi < in.chain
-lmp_mpi < in.eam
-lmp_mpi < in.chute
-lmp_mpi < in.rhodo
+lmp_mpi -in in.lj
+lmp_mpi -in in.chain
+lmp_mpi -in in.eam
+lmp_mpi -in in.chute
+lmp_mpi -in in.rhodo
Parallel fixed-size runs (on 8 procs in this case):
-mpirun -np 8 lmp_mpi < in.lj
-mpirun -np 8 lmp_mpi < in.chain
-mpirun -np 8 lmp_mpi < in.eam
-mpirun -np 8 lmp_mpi < in.chute
-mpirun -np 8 lmp_mpi < in.rhodo
+mpirun -np 8 lmp_mpi -in in.lj
+mpirun -np 8 lmp_mpi -in in.chain
+mpirun -np 8 lmp_mpi -in in.eam
+mpirun -np 8 lmp_mpi -in in.chute
+mpirun -np 8 lmp_mpi -in in.rhodo
Parallel scaled-size runs (on 16 procs in this case):
-mpirun -np 16 lmp_mpi -var x 2 -var y 2 -var z 4 < in.lj
-mpirun -np 16 lmp_mpi -var x 2 -var y 2 -var z 4 < in.chain.scaled
-mpirun -np 16 lmp_mpi -var x 2 -var y 2 -var z 4 < in.eam
-mpirun -np 16 lmp_mpi -var x 4 -var y 4 < in.chute.scaled
-mpirun -np 16 lmp_mpi -var x 2 -var y 2 -var z 4 < in.rhodo.scaled
+mpirun -np 16 lmp_mpi -var x 2 -var y 2 -var z 4 -in in.lj
+mpirun -np 16 lmp_mpi -var x 2 -var y 2 -var z 4 -in in.chain.scaled
+mpirun -np 16 lmp_mpi -var x 2 -var y 2 -var z 4 -in in.eam
+mpirun -np 16 lmp_mpi -var x 4 -var y 4 -in in.chute.scaled
+mpirun -np 16 lmp_mpi -var x 2 -var y 2 -var z 4 -in in.rhodo.scaled
For each of the scaled-size runs you must set 3 variables as -var
command line switches. The variables x,y,z are used in the input
scripts to scale up the problem size in each dimension. Imagine the P
processors arrayed as a 3d grid, so that P = Px * Py * Pz. For P =
16, you might use Px = 2, Py = 2, Pz = 4. To scale up equally in all
dimensions you roughly want Px = Py = Pz. Using the var switches, set
x = Px, y = Py, and z = Pz.
For Chute runs, you must have Pz = 1. Therefore P = Px * Py and you
only need to set variables x and y.
diff --git a/doc/src/Manual.txt b/doc/src/Manual.txt
index 36391731d..359aa19ed 100644
--- a/doc/src/Manual.txt
+++ b/doc/src/Manual.txt
@@ -1,339 +1,338 @@
LAMMPS Users Manual
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
LAMMPS Documentation :c,h3
6 Jul 2017 version :c,h4
Version info: :h4
The LAMMPS "version" is the date when it was released, such as 1 May
2010. LAMMPS is updated continuously. Whenever we fix a bug or add a
feature, we release it immediately, and post a notice on "this page of
the WWW site"_bug. Every 2-4 months one of the incremental releases
is subjected to more thorough testing and labeled as a {stable} version.
Each dated copy of LAMMPS contains all the
features and bug-fixes up to and including that version date. The
version date is printed to the screen and logfile every time you run
LAMMPS. It is also in the file src/version.h and in the LAMMPS
directory name created when you unpack a tarball, and at the top of
the first page of the manual (this page).
If you browse the HTML doc pages on the LAMMPS WWW site, they always
describe the most current [development] version of LAMMPS. :ulb,l
If you browse the HTML doc pages included in your tarball, they
describe the version you have. :l
The "PDF file"_Manual.pdf on the WWW site or in the tarball is updated
about once per month. This is because it is large, and we don't want
it to be part of every patch. :l
There is also a "Developer.pdf"_Developer.pdf file in the doc
directory, which describes the internal structure and algorithms of
LAMMPS. :l
:ule
LAMMPS stands for Large-scale Atomic/Molecular Massively Parallel
Simulator.
LAMMPS is a classical molecular dynamics simulation code designed to
run efficiently on parallel computers. It was developed at Sandia
National Laboratories, a US Department of Energy facility, with
funding from the DOE. It is an open-source code, distributed freely
under the terms of the GNU Public License (GPL).
The current core group of LAMMPS developers is at Sandia National
Labs and Temple University:
"Steve Plimpton"_sjp, sjplimp at sandia.gov :ulb,l
Aidan Thompson, athomps at sandia.gov :l
Stan Moore, stamoor at sandia.gov :l
"Axel Kohlmeyer"_ako, akohlmey at gmail.com :l
:ule
Past core developers include Paul Crozier, Ray Shan and Mark Stevens,
all at Sandia. The [LAMMPS home page] at
"http://lammps.sandia.gov"_http://lammps.sandia.gov has more information
about the code and its uses. Interaction with external LAMMPS developers,
bug reports and feature requests are mainly coordinated through the
"LAMMPS project on GitHub."_https://github.com/lammps/lammps
The lammps.org domain, currently hosting "public continuous integration
testing"_https://ci.lammps.org/job/lammps/ and "precompiled Linux
RPM and Windows installer packages"_http://rpm.lammps.org is located
at Temple University and managed by Richard Berger,
richard.berger at temple.edu.
:link(bug,http://lammps.sandia.gov/bug.html)
:link(sjp,http://www.sandia.gov/~sjplimp)
:link(ako,http://goo.gl/1wk0)
:line
The LAMMPS documentation is organized into the following sections. If
you find errors or omissions in this manual or have suggestions for
useful information to add, please send an email to the developers so
we can improve the LAMMPS documentation.
Once you are familiar with LAMMPS, you may want to bookmark "this
page"_Section_commands.html#comm at Section_commands.html#comm since
it gives quick access to documentation for all LAMMPS commands.
"PDF file"_Manual.pdf of the entire manual, generated by
"htmldoc"_http://freecode.com/projects/htmldoc
"Introduction"_Section_intro.html :olb,l
1.1 "What is LAMMPS"_intro_1 :ulb,b
1.2 "LAMMPS features"_intro_2 :b
1.3 "LAMMPS non-features"_intro_3 :b
1.4 "Open source distribution"_intro_4 :b
1.5 "Acknowledgments and citations"_intro_5 :ule,b
"Getting started"_Section_start.html :l
2.1 "What's in the LAMMPS distribution"_start_1 :ulb,b
2.2 "Making LAMMPS"_start_2 :b
2.3 "Making LAMMPS with optional packages"_start_3 :b
2.4 "Building LAMMPS as a library"_start_4 :b
2.5 "Running LAMMPS"_start_5 :b
2.6 "Command-line options"_start_6 :b
2.7 "Screen output"_start_7 :b
2.8 "Tips for users of previous versions"_start_8 :ule,b
"Commands"_Section_commands.html :l
3.1 "LAMMPS input script"_cmd_1 :ulb,b
3.2 "Parsing rules"_cmd_2 :b
3.3 "Input script structure"_cmd_3 :b
3.4 "Commands listed by category"_cmd_4 :b
3.5 "Commands listed alphabetically"_cmd_5 :ule,b
"Packages"_Section_packages.html :l
4.1 "Standard packages"_pkg_1 :ulb,b
4.2 "User packages"_pkg_2 :ule,b
"Accelerating LAMMPS performance"_Section_accelerate.html :l
5.1 "Measuring performance"_acc_1 :ulb,b
5.2 "Algorithms and code options to boost performace"_acc_2 :b
5.3 "Accelerator packages with optimized styles"_acc_3 :b
5.3.1 "GPU package"_accelerate_gpu.html :ulb,b
5.3.2 "USER-INTEL package"_accelerate_intel.html :b
5.3.3 "KOKKOS package"_accelerate_kokkos.html :b
5.3.4 "USER-OMP package"_accelerate_omp.html :b
5.3.5 "OPT package"_accelerate_opt.html :ule,b
5.4 "Comparison of various accelerator packages"_acc_4 :ule,b
"How-to discussions"_Section_howto.html :l
6.1 "Restarting a simulation"_howto_1 :ulb,b
6.2 "2d simulations"_howto_2 :b
6.3 "CHARMM and AMBER force fields"_howto_3 :b
6.4 "Running multiple simulations from one input script"_howto_4 :b
6.5 "Multi-replica simulations"_howto_5 :b
6.6 "Granular models"_howto_6 :b
6.7 "TIP3P water model"_howto_7 :b
6.8 "TIP4P water model"_howto_8 :b
6.9 "SPC water model"_howto_9 :b
6.10 "Coupling LAMMPS to other codes"_howto_10 :b
6.11 "Visualizing LAMMPS snapshots"_howto_11 :b
6.12 "Triclinic (non-orthogonal) simulation boxes"_howto_12 :b
6.13 "NEMD simulations"_howto_13 :b
6.14 "Finite-size spherical and aspherical particles"_howto_14 :b
6.15 "Output from LAMMPS (thermo, dumps, computes, fixes, variables)"_howto_15 :b
6.16 "Thermostatting, barostatting, and compute temperature"_howto_16 :b
6.17 "Walls"_howto_17 :b
6.18 "Elastic constants"_howto_18 :b
6.19 "Library interface to LAMMPS"_howto_19 :b
6.20 "Calculating thermal conductivity"_howto_20 :b
6.21 "Calculating viscosity"_howto_21 :b
6.22 "Calculating a diffusion coefficient"_howto_22 :b
6.23 "Using chunks to calculate system properties"_howto_23 :b
6.24 "Setting parameters for pppm/disp"_howto_24 :b
6.25 "Polarizable models"_howto_25 :b
6.26 "Adiabatic core/shell model"_howto_26 :b
6.27 "Drude induced dipoles"_howto_27 :ule,b
"Example problems"_Section_example.html :l
"Performance & scalability"_Section_perf.html :l
"Additional tools"_Section_tools.html :l
"Modifying & extending LAMMPS"_Section_modify.html :l
10.1 "Atom styles"_mod_1 :ulb,b
10.2 "Bond, angle, dihedral, improper potentials"_mod_2 :b
10.3 "Compute styles"_mod_3 :b
10.4 "Dump styles"_mod_4 :b
10.5 "Dump custom output options"_mod_5 :b
10.6 "Fix styles"_mod_6 :b
10.7 "Input script commands"_mod_7 :b
10.8 "Kspace computations"_mod_8 :b
10.9 "Minimization styles"_mod_9 :b
10.10 "Pairwise potentials"_mod_10 :b
10.11 "Region styles"_mod_11 :b
10.12 "Body styles"_mod_12 :b
10.13 "Thermodynamic output options"_mod_13 :b
10.14 "Variable options"_mod_14 :b
10.15 "Submitting new features for inclusion in LAMMPS"_mod_15 :ule,b
"Python interface"_Section_python.html :l
11.1 "Overview of running LAMMPS from Python"_py_1 :ulb,b
11.2 "Overview of using Python from a LAMMPS script"_py_2 :b
11.3 "Building LAMMPS as a shared library"_py_3 :b
11.4 "Installing the Python wrapper into Python"_py_4 :b
11.5 "Extending Python with MPI to run in parallel"_py_5 :b
11.6 "Testing the Python-LAMMPS interface"_py_6 :b
11.7 "Using LAMMPS from Python"_py_7 :b
11.8 "Example Python scripts that use LAMMPS"_py_8 :ule,b
"Errors"_Section_errors.html :l
12.1 "Common problems"_err_1 :ulb,b
12.2 "Reporting bugs"_err_2 :b
12.3 "Error & warning messages"_err_3 :ule,b
"Future and history"_Section_history.html :l
13.1 "Coming attractions"_hist_1 :ulb,b
13.2 "Past versions"_hist_2 :ule,b
:ole
:link(intro_1,Section_intro.html#intro_1)
:link(intro_2,Section_intro.html#intro_2)
:link(intro_3,Section_intro.html#intro_3)
:link(intro_4,Section_intro.html#intro_4)
:link(intro_5,Section_intro.html#intro_5)
:link(start_1,Section_start.html#start_1)
:link(start_2,Section_start.html#start_2)
:link(start_3,Section_start.html#start_3)
:link(start_4,Section_start.html#start_4)
:link(start_5,Section_start.html#start_5)
:link(start_6,Section_start.html#start_6)
:link(start_7,Section_start.html#start_7)
:link(start_8,Section_start.html#start_8)
-:link(start_9,Section_start.html#start_9)
:link(cmd_1,Section_commands.html#cmd_1)
:link(cmd_2,Section_commands.html#cmd_2)
:link(cmd_3,Section_commands.html#cmd_3)
:link(cmd_4,Section_commands.html#cmd_4)
:link(cmd_5,Section_commands.html#cmd_5)
:link(pkg_1,Section_packages.html#pkg_1)
:link(pkg_2,Section_packages.html#pkg_2)
:link(acc_1,Section_accelerate.html#acc_1)
:link(acc_2,Section_accelerate.html#acc_2)
:link(acc_3,Section_accelerate.html#acc_3)
:link(acc_4,Section_accelerate.html#acc_4)
:link(howto_1,Section_howto.html#howto_1)
:link(howto_2,Section_howto.html#howto_2)
:link(howto_3,Section_howto.html#howto_3)
:link(howto_4,Section_howto.html#howto_4)
:link(howto_5,Section_howto.html#howto_5)
:link(howto_6,Section_howto.html#howto_6)
:link(howto_7,Section_howto.html#howto_7)
:link(howto_8,Section_howto.html#howto_8)
:link(howto_9,Section_howto.html#howto_9)
:link(howto_10,Section_howto.html#howto_10)
:link(howto_11,Section_howto.html#howto_11)
:link(howto_12,Section_howto.html#howto_12)
:link(howto_13,Section_howto.html#howto_13)
:link(howto_14,Section_howto.html#howto_14)
:link(howto_15,Section_howto.html#howto_15)
:link(howto_16,Section_howto.html#howto_16)
:link(howto_17,Section_howto.html#howto_17)
:link(howto_18,Section_howto.html#howto_18)
:link(howto_19,Section_howto.html#howto_19)
:link(howto_20,Section_howto.html#howto_20)
:link(howto_21,Section_howto.html#howto_21)
:link(howto_22,Section_howto.html#howto_22)
:link(howto_23,Section_howto.html#howto_23)
:link(howto_24,Section_howto.html#howto_24)
:link(howto_25,Section_howto.html#howto_25)
:link(howto_26,Section_howto.html#howto_26)
:link(howto_27,Section_howto.html#howto_27)
:link(mod_1,Section_modify.html#mod_1)
:link(mod_2,Section_modify.html#mod_2)
:link(mod_3,Section_modify.html#mod_3)
:link(mod_4,Section_modify.html#mod_4)
:link(mod_5,Section_modify.html#mod_5)
:link(mod_6,Section_modify.html#mod_6)
:link(mod_7,Section_modify.html#mod_7)
:link(mod_8,Section_modify.html#mod_8)
:link(mod_9,Section_modify.html#mod_9)
:link(mod_10,Section_modify.html#mod_10)
:link(mod_11,Section_modify.html#mod_11)
:link(mod_12,Section_modify.html#mod_12)
:link(mod_13,Section_modify.html#mod_13)
:link(mod_14,Section_modify.html#mod_14)
:link(mod_15,Section_modify.html#mod_15)
:link(py_1,Section_python.html#py_1)
:link(py_2,Section_python.html#py_2)
:link(py_3,Section_python.html#py_3)
:link(py_4,Section_python.html#py_4)
:link(py_5,Section_python.html#py_5)
:link(py_6,Section_python.html#py_6)
:link(err_1,Section_errors.html#err_1)
:link(err_2,Section_errors.html#err_2)
:link(err_3,Section_errors.html#err_3)
:link(hist_1,Section_history.html#hist_1)
:link(hist_2,Section_history.html#hist_2)
diff --git a/doc/src/Section_accelerate.txt b/doc/src/Section_accelerate.txt
index 64b80c1a5..881235888 100644
--- a/doc/src/Section_accelerate.txt
+++ b/doc/src/Section_accelerate.txt
@@ -1,391 +1,391 @@
"Previous Section"_Section_packages.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
Section"_Section_howto.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
5. Accelerating LAMMPS performance :h3
This section describes various methods for improving LAMMPS
performance for different classes of problems running on different
kinds of machines.
There are two thrusts to the discussion that follows. The
first is using code options that implement alternate algorithms
that can speed-up a simulation. The second is to use one
of the several accelerator packages provided with LAMMPS that
contain code optimized for certain kinds of hardware, including
multi-core CPUs, GPUs, and Intel Xeon Phi coprocessors.
5.1 "Measuring performance"_#acc_1 :ulb,l
5.2 "Algorithms and code options to boost performace"_#acc_2 :l
5.3 "Accelerator packages with optimized styles"_#acc_3 :l
5.3.1 "GPU package"_accelerate_gpu.html :l
5.3.2 "USER-INTEL package"_accelerate_intel.html :l
5.3.3 "KOKKOS package"_accelerate_kokkos.html :l
5.3.4 "USER-OMP package"_accelerate_omp.html :l
5.3.5 "OPT package"_accelerate_opt.html :l
5.4 "Comparison of various accelerator packages"_#acc_4 :l
:ule
The "Benchmark page"_http://lammps.sandia.gov/bench.html of the LAMMPS
web site gives performance results for the various accelerator
packages discussed in Section 5.2, for several of the standard LAMMPS
benchmark problems, as a function of problem size and number of
compute nodes, on different hardware platforms.
:line
:line
5.1 Measuring performance :h4,link(acc_1)
Before trying to make your simulation run faster, you should
understand how it currently performs and where the bottlenecks are.
The best way to do this is run the your system (actual number of
atoms) for a modest number of timesteps (say 100 steps) on several
different processor counts, including a single processor if possible.
Do this for an equilibrium version of your system, so that the
100-step timings are representative of a much longer run. There is
typically no need to run for 1000s of timesteps to get accurate
timings; you can simply extrapolate from short runs.
For the set of runs, look at the timing data printed to the screen and
log file at the end of each LAMMPS run. "This
-section"_Section_start.html#start_8 of the manual has an overview.
+section"_Section_start.html#start_7 of the manual has an overview.
Running on one (or a few processors) should give a good estimate of
the serial performance and what portions of the timestep are taking
the most time. Running the same problem on a few different processor
counts should give an estimate of parallel scalability. I.e. if the
simulation runs 16x faster on 16 processors, its 100% parallel
efficient; if it runs 8x faster on 16 processors, it's 50% efficient.
The most important data to look at in the timing info is the timing
breakdown and relative percentages. For example, trying different
options for speeding up the long-range solvers will have little impact
if they only consume 10% of the run time. If the pairwise time is
dominating, you may want to look at GPU or OMP versions of the pair
style, as discussed below. Comparing how the percentages change as
you increase the processor count gives you a sense of how different
operations within the timestep are scaling. Note that if you are
running with a Kspace solver, there is additional output on the
breakdown of the Kspace time. For PPPM, this includes the fraction
spent on FFTs, which can be communication intensive.
Another important detail in the timing info are the histograms of
atoms counts and neighbor counts. If these vary widely across
processors, you have a load-imbalance issue. This often results in
inaccurate relative timing data, because processors have to wait when
communication occurs for other processors to catch up. Thus the
reported times for "Communication" or "Other" may be higher than they
really are, due to load-imbalance. If this is an issue, you can
uncomment the MPI_Barrier() lines in src/timer.cpp, and recompile
LAMMPS, to obtain synchronized timings.
:line
5.2 General strategies :h4,link(acc_2)
NOTE: this section 5.2 is still a work in progress
Here is a list of general ideas for improving simulation performance.
Most of them are only applicable to certain models and certain
bottlenecks in the current performance, so let the timing data you
generate be your guide. It is hard, if not impossible, to predict how
much difference these options will make, since it is a function of
problem size, number of processors used, and your machine. There is
no substitute for identifying performance bottlenecks, and trying out
various options.
rRESPA
2-FFT PPPM
Staggered PPPM
single vs double PPPM
partial charge PPPM
verlet/split run style
processor command for proc layout and numa layout
load-balancing: balance and fix balance :ul
2-FFT PPPM, also called {analytic differentiation} or {ad} PPPM, uses
2 FFTs instead of the 4 FFTs used by the default {ik differentiation}
PPPM. However, 2-FFT PPPM also requires a slightly larger mesh size to
achieve the same accuracy as 4-FFT PPPM. For problems where the FFT
cost is the performance bottleneck (typically large problems running
on many processors), 2-FFT PPPM may be faster than 4-FFT PPPM.
Staggered PPPM performs calculations using two different meshes, one
shifted slightly with respect to the other. This can reduce force
aliasing errors and increase the accuracy of the method, but also
doubles the amount of work required. For high relative accuracy, using
staggered PPPM allows one to half the mesh size in each dimension as
compared to regular PPPM, which can give around a 4x speedup in the
kspace time. However, for low relative accuracy, using staggered PPPM
gives little benefit and can be up to 2x slower in the kspace
time. For example, the rhodopsin benchmark was run on a single
processor, and results for kspace time vs. relative accuracy for the
different methods are shown in the figure below. For this system,
staggered PPPM (using ik differentiation) becomes useful when using a
relative accuracy of slightly greater than 1e-5 and above.
:c,image(JPG/rhodo_staggered.jpg)
NOTE: Using staggered PPPM may not give the same increase in accuracy
of energy and pressure as it does in forces, so some caution must be
used if energy and/or pressure are quantities of interest, such as
when using a barostat.
:line
5.3 Packages with optimized styles :h4,link(acc_3)
Accelerated versions of various "pair_style"_pair_style.html,
"fixes"_fix.html, "computes"_compute.html, and other commands have
been added to LAMMPS, which will typically run faster than the
standard non-accelerated versions. Some require appropriate hardware
to be present on your system, e.g. GPUs or Intel Xeon Phi
coprocessors.
All of these commands are in packages provided with LAMMPS. An
overview of packages is give in "Section
packages"_Section_packages.html.
These are the accelerator packages
currently in LAMMPS, either as standard or user packages:
"GPU Package"_accelerate_gpu.html : for NVIDIA GPUs as well as OpenCL support
"USER-INTEL Package"_accelerate_intel.html : for Intel CPUs and Intel Xeon Phi
"KOKKOS Package"_accelerate_kokkos.html : for Nvidia GPUs, Intel Xeon Phi, and OpenMP threading
"USER-OMP Package"_accelerate_omp.html : for OpenMP threading and generic CPU optimizations
"OPT Package"_accelerate_opt.html : generic CPU optimizations :tb(s=:)
Inverting this list, LAMMPS currently has acceleration support for
three kinds of hardware, via the listed packages:
Many-core CPUs : "USER-INTEL"_accelerate_intel.html, "KOKKOS"_accelerate_kokkos.html, "USER-OMP"_accelerate_omp.html, "OPT"_accelerate_opt.html packages
NVIDIA GPUs : "GPU"_accelerate_gpu.html, "KOKKOS"_accelerate_kokkos.html packages
Intel Phi : "USER-INTEL"_accelerate_intel.html, "KOKKOS"_accelerate_kokkos.html packages :tb(s=:)
Which package is fastest for your hardware may depend on the size
problem you are running and what commands (accelerated and
non-accelerated) are invoked by your input script. While these doc
pages include performance guidelines, there is no substitute for
trying out the different packages appropriate to your hardware.
Any accelerated style has the same name as the corresponding standard
style, except that a suffix is appended. Otherwise, the syntax for
the command that uses the style is identical, their functionality is
the same, and the numerical results it produces should also be the
same, except for precision and round-off effects.
For example, all of these styles are accelerated variants of the
Lennard-Jones "pair_style lj/cut"_pair_lj.html:
"pair_style lj/cut/gpu"_pair_lj.html
"pair_style lj/cut/intel"_pair_lj.html
"pair_style lj/cut/kk"_pair_lj.html
"pair_style lj/cut/omp"_pair_lj.html
"pair_style lj/cut/opt"_pair_lj.html :ul
To see what accelerate styles are currently available, see
"Section 3.5"_Section_commands.html#cmd_5 of the manual. The
doc pages for individual commands (e.g. "pair lj/cut"_pair_lj.html or
"fix nve"_fix_nve.html) also list any accelerated variants available
for that style.
To use an accelerator package in LAMMPS, and one or more of the styles
it provides, follow these general steps. Details vary from package to
package and are explained in the individual accelerator doc pages,
listed above:
build the accelerator library |
only for GPU package |
install the accelerator package |
make yes-opt, make yes-user-intel, etc |
add compile/link flags to Makefile.machine in src/MAKE |
only for USER-INTEL, KOKKOS, USER-OMP, OPT packages |
re-build LAMMPS |
make machine |
prepare and test a regular LAMMPS simulation |
lmp_machine -in in.script; mpirun -np 32 lmp_machine -in in.script |
-enable specific accelerator support via '-k on' "command-line switch"_Section_start.html#start_7, |
+enable specific accelerator support via '-k on' "command-line switch"_Section_start.html#start_6, |
only needed for KOKKOS package |
-set any needed options for the package via "-pk" "command-line switch"_Section_start.html#start_7 or "package"_package.html command, |
+set any needed options for the package via "-pk" "command-line switch"_Section_start.html#start_6 or "package"_package.html command, |
only if defaults need to be changed |
-use accelerated styles in your input via "-sf" "command-line switch"_Section_start.html#start_7 or "suffix"_suffix.html command | lmp_machine -in in.script -sf gpu
+use accelerated styles in your input via "-sf" "command-line switch"_Section_start.html#start_6 or "suffix"_suffix.html command | lmp_machine -in in.script -sf gpu
:tb(c=2,s=|)
Note that the first 4 steps can be done as a single command, using the
src/Make.py tool. This tool is discussed in "Section
-2.4"_Section_start.html#start_4 of the manual, and its use is
+4"_Section_packages.html of the manual, and its use is
illustrated in the individual accelerator sections. Typically these
steps only need to be done once, to create an executable that uses one
or more accelerator packages.
The last 4 steps can all be done from the command-line when LAMMPS is
launched, without changing your input script, as illustrated in the
individual accelerator sections. Or you can add
"package"_package.html and "suffix"_suffix.html commands to your input
script.
NOTE: With a few exceptions, you can build a single LAMMPS executable
with all its accelerator packages installed. Note however that the
USER-INTEL and KOKKOS packages require you to choose one of their
hardware options when building for a specific platform. I.e. CPU or
Phi option for the USER-INTEL package. Or the OpenMP, Cuda, or Phi
option for the KOKKOS package.
These are the exceptions. You cannot build a single executable with:
both the USER-INTEL Phi and KOKKOS Phi options
the USER-INTEL Phi or Kokkos Phi option, and the GPU package :ul
See the examples/accelerate/README and make.list files for sample
Make.py commands that build LAMMPS with any or all of the accelerator
packages. As an example, here is a command that builds with all the
GPU related packages installed (GPU, KOKKOS with Cuda), including
settings to build the needed auxiliary GPU libraries for Kepler GPUs:
Make.py -j 16 -p omp gpu kokkos -cc nvcc wrap=mpi \
-gpu mode=double arch=35 -kokkos cuda arch=35 lib-all file mpi :pre
The examples/accelerate directory also has input scripts that can be
used with all of the accelerator packages. See its README file for
details.
Likewise, the bench directory has FERMI and KEPLER and PHI
sub-directories with Make.py commands and input scripts for using all
the accelerator packages on various machines. See the README files in
those dirs.
As mentioned above, the "Benchmark
page"_http://lammps.sandia.gov/bench.html of the LAMMPS web site gives
performance results for the various accelerator packages for several
of the standard LAMMPS benchmark problems, as a function of problem
size and number of compute nodes, on different hardware platforms.
Here is a brief summary of what the various packages provide. Details
are in the individual accelerator sections.
Styles with a "gpu" suffix are part of the GPU package, and can be run
on NVIDIA GPUs. The speed-up on a GPU depends on a variety of
factors, discussed in the accelerator sections. :ulb,l
Styles with an "intel" suffix are part of the USER-INTEL
package. These styles support vectorized single and mixed precision
calculations, in addition to full double precision. In extreme cases,
this can provide speedups over 3.5x on CPUs. The package also
supports acceleration in "offload" mode to Intel(R) Xeon Phi(TM)
coprocessors. This can result in additional speedup over 2x depending
on the hardware configuration. :l
Styles with a "kk" suffix are part of the KOKKOS package, and can be
run using OpenMP on multicore CPUs, on an NVIDIA GPU, or on an Intel
Xeon Phi in "native" mode. The speed-up depends on a variety of
factors, as discussed on the KOKKOS accelerator page. :l
Styles with an "omp" suffix are part of the USER-OMP package and allow
a pair-style to be run in multi-threaded mode using OpenMP. This can
be useful on nodes with high-core counts when using less MPI processes
than cores is advantageous, e.g. when running with PPPM so that FFTs
are run on fewer MPI processors or when the many MPI tasks would
overload the available bandwidth for communication. :l
Styles with an "opt" suffix are part of the OPT package and typically
speed-up the pairwise calculations of your simulation by 5-25% on a
CPU. :l
:ule
The individual accelerator package doc pages explain:
what hardware and software the accelerated package requires
how to build LAMMPS with the accelerated package
how to run with the accelerated package either via command-line switches or modifying the input script
speed-ups to expect
guidelines for best performance
restrictions :ul
:line
5.4 Comparison of various accelerator packages :h4,link(acc_4)
NOTE: this section still needs to be re-worked with additional KOKKOS
and USER-INTEL information.
The next section compares and contrasts the various accelerator
options, since there are multiple ways to perform OpenMP threading,
run on GPUs, and run on Intel Xeon Phi coprocessors.
All 3 of these packages accelerate a LAMMPS calculation using NVIDIA
hardware, but they do it in different ways.
As a consequence, for a particular simulation on specific hardware,
one package may be faster than the other. We give guidelines below,
but the best way to determine which package is faster for your input
script is to try both of them on your machine. See the benchmarking
section below for examples where this has been done.
[Guidelines for using each package optimally:]
The GPU package allows you to assign multiple CPUs (cores) to a single
GPU (a common configuration for "hybrid" nodes that contain multicore
CPU(s) and GPU(s)) and works effectively in this mode. :ulb,l
The GPU package moves per-atom data (coordinates, forces)
back-and-forth between the CPU and GPU every timestep. The
KOKKOS/CUDA package only does this on timesteps when a CPU calculation
is required (e.g. to invoke a fix or compute that is non-GPU-ized).
Hence, if you can formulate your input script to only use GPU-ized
fixes and computes, and avoid doing I/O too often (thermo output, dump
file snapshots, restart files), then the data transfer cost of the
KOKKOS/CUDA package can be very low, causing it to run faster than the
GPU package. :l
The GPU package is often faster than the KOKKOS/CUDA package, if the
number of atoms per GPU is smaller. The crossover point, in terms of
atoms/GPU at which the KOKKOS/CUDA package becomes faster depends
strongly on the pair style. For example, for a simple Lennard Jones
system the crossover (in single precision) is often about 50K-100K
atoms per GPU. When performing double precision calculations the
crossover point can be significantly smaller. :l
Both packages compute bonded interactions (bonds, angles, etc) on the
CPU. If the GPU package is running with several MPI processes
assigned to one GPU, the cost of computing the bonded interactions is
spread across more CPUs and hence the GPU package can run faster. :l
When using the GPU package with multiple CPUs assigned to one GPU, its
performance depends to some extent on high bandwidth between the CPUs
and the GPU. Hence its performance is affected if full 16 PCIe lanes
are not available for each GPU. In HPC environments this can be the
case if S2050/70 servers are used, where two devices generally share
one PCIe 2.0 16x slot. Also many multi-GPU mainboards do not provide
full 16 lanes to each of the PCIe 2.0 16x slots. :l
:ule
[Differences between the two packages:]
The GPU package accelerates only pair force, neighbor list, and PPPM
calculations. :ulb,l
The GPU package requires neighbor lists to be built on the CPU when using
exclusion lists, hybrid pair styles, or a triclinic simulation box. :l
:ule
diff --git a/doc/src/Section_errors.txt b/doc/src/Section_errors.txt
index 40e61a248..408c01d52 100644
--- a/doc/src/Section_errors.txt
+++ b/doc/src/Section_errors.txt
@@ -1,11939 +1,11939 @@
"Previous Section"_Section_python.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
Section"_Section_history.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
12. Errors :h3
This section describes the errors you can encounter when using LAMMPS,
either conceptually, or as printed out by the program.
12.1 "Common problems"_#err_1
12.2 "Reporting bugs"_#err_2
12.3 "Error & warning messages"_#err_3 :all(b)
:line
:line
12.1 Common problems :link(err_1),h4
If two LAMMPS runs do not produce the exact same answer on different
machines or different numbers of processors, this is typically not a
bug. In theory you should get identical answers on any number of
processors and on any machine. In practice, numerical round-off can
cause slight differences and eventual divergence of molecular dynamics
phase space trajectories within a few 100s or few 1000s of timesteps.
However, the statistical properties of the two runs (e.g. average
energy or temperature) should still be the same.
If the "velocity"_velocity.html command is used to set initial atom
velocities, a particular atom can be assigned a different velocity
when the problem is run on a different number of processors or on
different machines. If this happens, the phase space trajectories of
the two simulations will rapidly diverge. See the discussion of the
{loop} option in the "velocity"_velocity.html command for details and
options that avoid this issue.
Similarly, the "create_atoms"_create_atoms.html command generates a
lattice of atoms. For the same physical system, the ordering and
numbering of atoms by atom ID may be different depending on the number
of processors.
Some commands use random number generators which may be setup to
produce different random number streams on each processor and hence
will produce different effects when run on different numbers of
processors. A commonly-used example is the "fix
langevin"_fix_langevin.html command for thermostatting.
A LAMMPS simulation typically has two stages, setup and run. Most
LAMMPS errors are detected at setup time; others like a bond
stretching too far may not occur until the middle of a run.
LAMMPS tries to flag errors and print informative error messages so
you can fix the problem. For most errors it will also print the last
input script command that it was processing. Of course, LAMMPS cannot
figure out your physics or numerical mistakes, like choosing too big a
timestep, specifying erroneous force field coefficients, or putting 2
atoms on top of each other! If you run into errors that LAMMPS
doesn't catch that you think it should flag, please send an email to
the "developers"_http://lammps.sandia.gov/authors.html.
If you get an error message about an invalid command in your input
script, you can determine what command is causing the problem by
looking in the log.lammps file or using the "echo command"_echo.html
to see it on the screen. If you get an error like "Invalid ...
style", with ... being fix, compute, pair, etc, it means that you
mistyped the style name or that the command is part of an optional
package which was not compiled into your executable. The list of
available styles in your executable can be listed by using "the -h
-command-line argument"_Section_start.html#start_7. The installation
+command-line argument"_Section_start.html#start_6. The installation
and compilation of optional packages is explained in the "installation
instructions"_Section_start.html#start_3.
For a given command, LAMMPS expects certain arguments in a specified
order. If you mess this up, LAMMPS will often flag the error, but it
may also simply read a bogus argument and assign a value that is
valid, but not what you wanted. E.g. trying to read the string "abc"
as an integer value of 0. Careful reading of the associated doc page
for the command should allow you to fix these problems. In most cases,
where LAMMPS expects to read a number, either integer or floating point,
it performs a stringent test on whether the provided input actually
is an integer or floating-point number, respectively, and reject the
input with an error message (for instance, when an integer is required,
but a floating-point number 1.0 is provided):
ERROR: Expected integer parameter in input script or data file :pre
Some commands allow for using variable references in place of numeric
constants so that the value can be evaluated and may change over the
course of a run. This is typically done with the syntax {v_name} for a
parameter, where name is the name of the variable. On the other hand,
immediate variable expansion with the syntax ${name} is performed while
reading the input and before parsing commands,
NOTE: Using a variable reference (i.e. {v_name}) is only allowed if
the documentation of the corresponding command explicitly says it is.
Generally, LAMMPS will print a message to the screen and logfile and
exit gracefully when it encounters a fatal error. Sometimes it will
print a WARNING to the screen and logfile and continue on; you can
decide if the WARNING is important or not. A WARNING message that is
generated in the middle of a run is only printed to the screen, not to
the logfile, to avoid cluttering up thermodynamic output. If LAMMPS
crashes or hangs without spitting out an error message first then it
could be a bug (see "this section"_#err_2) or one of the following
cases:
LAMMPS runs in the available memory a processor allows to be
allocated. Most reasonable MD runs are compute limited, not memory
limited, so this shouldn't be a bottleneck on most platforms. Almost
all large memory allocations in the code are done via C-style malloc's
which will generate an error message if you run out of memory.
Smaller chunks of memory are allocated via C++ "new" statements. If
you are unlucky you could run out of memory just when one of these
small requests is made, in which case the code will crash or hang (in
parallel), since LAMMPS doesn't trap on those errors.
Illegal arithmetic can cause LAMMPS to run slow or crash. This is
typically due to invalid physics and numerics that your simulation is
computing. If you see wild thermodynamic values or NaN values in your
LAMMPS output, something is wrong with your simulation. If you
suspect this is happening, it is a good idea to print out
thermodynamic info frequently (e.g. every timestep) via the
"thermo"_thermo.html so you can monitor what is happening.
Visualizing the atom movement is also a good idea to insure your model
is behaving as you expect.
In parallel, one way LAMMPS can hang is due to how different MPI
implementations handle buffering of messages. If the code hangs
without an error message, it may be that you need to specify an MPI
setting or two (usually via an environment variable) to enable
buffering or boost the sizes of messages that can be buffered.
:line
12.2 Reporting bugs :link(err_2),h4
If you are confident that you have found a bug in LAMMPS, follow these
steps.
Check the "New features and bug
fixes"_http://lammps.sandia.gov/bug.html section of the "LAMMPS WWW
site"_lws to see if the bug has already been reported or fixed or the
"Unfixed bug"_http://lammps.sandia.gov/unbug.html to see if a fix is
pending.
Check the "mailing list"_http://lammps.sandia.gov/mail.html
to see if it has been discussed before.
If not, send an email to the mailing list describing the problem with
any ideas you have as to what is causing it or where in the code the
problem might be. The developers will ask for more info if needed,
such as an input script or data files.
The most useful thing you can do to help us fix the bug is to isolate
the problem. Run it on the smallest number of atoms and fewest number
of processors and with the simplest input script that reproduces the
bug and try to identify what command or combination of commands is
causing the problem.
As a last resort, you can send an email directly to the
"developers"_http://lammps.sandia.gov/authors.html.
:line
12.3 Error & warning messages :h4,link(err_3)
These are two alphabetic lists of the "ERROR"_#error and
"WARNING"_#warn messages LAMMPS prints out and the reason why. If the
explanation here is not sufficient, the documentation for the
offending command may help.
Error and warning messages also list the source file and line number
where the error was generated. For example, this message
ERROR: Illegal velocity command (velocity.cpp:78)
means that line #78 in the file src/velocity.cpp generated the error.
Looking in the source code may help you figure out what went wrong.
Note that error messages from "user-contributed
packages"_Section_start.html#start_3 are not listed here. If such an
error occurs and is not self-explanatory, you'll need to look in the
source code or contact the author of the package.
Errors: :h4,link(error)
:dlb
{1-3 bond count is inconsistent} :dt
An inconsistency was detected when computing the number of 1-3
neighbors for each atom. This likely means something is wrong with
the bond topologies you have defined. :dd
{1-4 bond count is inconsistent} :dt
An inconsistency was detected when computing the number of 1-4
neighbors for each atom. This likely means something is wrong with
the bond topologies you have defined. :dd
{Accelerator sharing is not currently supported on system} :dt
Multiple MPI processes cannot share the accelerator on your
system. For NVIDIA GPUs, see the nvidia-smi command to change this
setting. :dd
{All angle coeffs are not set} :dt
All angle coefficients must be set in the data file or by the
angle_coeff command before running a simulation. :dd
{All atom IDs = 0 but atom_modify id = yes} :dt
Self-explanatory. :dd
{All atoms of a swapped type must have same charge.} :dt
Self-explanatory. :dd
{All atoms of a swapped type must have the same charge.} :dt
Self-explanatory. :dd
{All bond coeffs are not set} :dt
All bond coefficients must be set in the data file or by the
bond_coeff command before running a simulation. :dd
{All dihedral coeffs are not set} :dt
All dihedral coefficients must be set in the data file or by the
dihedral_coeff command before running a simulation. :dd
{All improper coeffs are not set} :dt
All improper coefficients must be set in the data file or by the
improper_coeff command before running a simulation. :dd
{All masses are not set} :dt
For atom styles that define masses for each atom type, all masses must
be set in the data file or by the mass command before running a
simulation. They must also be set before using the velocity
command. :dd
{All mol IDs should be set for fix gcmc group atoms} :dt
The molecule flag is on, yet not all molecule ids in the fix group
have been set to non-zero positive values by the user. This is an
error since all atoms in the fix gcmc group are eligible for deletion,
rotation, and translation and therefore must have valid molecule ids. :dd
{All pair coeffs are not set} :dt
All pair coefficients must be set in the data file or by the
pair_coeff command before running a simulation. :dd
{All read_dump x,y,z fields must be specified for scaled, triclinic coords} :dt
For triclinic boxes and scaled coordinates you must specify all 3 of
the x,y,z fields, else LAMMPS cannot reconstruct the unscaled
coordinates. :dd
{All universe/uloop variables must have same # of values} :dt
Self-explanatory. :dd
{All variables in next command must be same style} :dt
Self-explanatory. :dd
{Angle atom missing in delete_bonds} :dt
The delete_bonds command cannot find one or more atoms in a particular
angle on a particular processor. The pairwise cutoff is too short or
the atoms are too far apart to make a valid angle. :dd
{Angle atom missing in set command} :dt
The set command cannot find one or more atoms in a particular angle on
a particular processor. The pairwise cutoff is too short or the atoms
are too far apart to make a valid angle. :dd
{Angle atoms %d %d %d missing on proc %d at step %ld} :dt
One or more of 3 atoms needed to compute a particular angle are
missing on this processor. Typically this is because the pairwise
cutoff is set too short or the angle has blown apart and an atom is
too far away. :dd
{Angle atoms missing on proc %d at step %ld} :dt
One or more of 3 atoms needed to compute a particular angle are
missing on this processor. Typically this is because the pairwise
cutoff is set too short or the angle has blown apart and an atom is
too far away. :dd
{Angle coeff for hybrid has invalid style} :dt
Angle style hybrid uses another angle style as one of its
coefficients. The angle style used in the angle_coeff command or read
from a restart file is not recognized. :dd
{Angle coeffs are not set} :dt
No angle coefficients have been assigned in the data file or via the
angle_coeff command. :dd
{Angle extent > half of periodic box length} :dt
This error was detected by the neigh_modify check yes setting. It is
an error because the angle atoms are so far apart it is ambiguous how
it should be defined. :dd
{Angle potential must be defined for SHAKE} :dt
When shaking angles, an angle_style potential must be used. :dd
{Angle style hybrid cannot have hybrid as an argument} :dt
Self-explanatory. :dd
{Angle style hybrid cannot have none as an argument} :dt
Self-explanatory. :dd
{Angle style hybrid cannot use same angle style twice} :dt
Self-explanatory. :dd
{Angle table must range from 0 to 180 degrees} :dt
Self-explanatory. :dd
{Angle table parameters did not set N} :dt
List of angle table parameters must include N setting. :dd
{Angle_coeff command before angle_style is defined} :dt
Coefficients cannot be set in the data file or via the angle_coeff
command until an angle_style has been assigned. :dd
{Angle_coeff command before simulation box is defined} :dt
The angle_coeff command cannot be used before a read_data,
read_restart, or create_box command. :dd
{Angle_coeff command when no angles allowed} :dt
The chosen atom style does not allow for angles to be defined. :dd
{Angle_style command when no angles allowed} :dt
The chosen atom style does not allow for angles to be defined. :dd
{Angles assigned incorrectly} :dt
Angles read in from the data file were not assigned correctly to
atoms. This means there is something invalid about the topology
definitions. :dd
{Angles defined but no angle types} :dt
The data file header lists angles but no angle types. :dd
{Append boundary must be shrink/minimum} :dt
The boundary style of the face where atoms are added
must be of type m (shrink/minimum). :dd
{Arccos of invalid value in variable formula} :dt
Argument of arccos() must be between -1 and 1. :dd
{Arcsin of invalid value in variable formula} :dt
Argument of arcsin() must be between -1 and 1. :dd
{Assigning body parameters to non-body atom} :dt
Self-explanatory. :dd
{Assigning ellipsoid parameters to non-ellipsoid atom} :dt
Self-explanatory. :dd
{Assigning line parameters to non-line atom} :dt
Self-explanatory. :dd
{Assigning quat to non-body atom} :dt
Self-explanatory. :dd
{Assigning tri parameters to non-tri atom} :dt
Self-explanatory. :dd
{At least one atom of each swapped type must be present to define charges.} :dt
Self-explanatory. :dd
{Atom IDs must be consecutive for velocity create loop all} :dt
Self-explanatory. :dd
{Atom IDs must be used for molecular systems} :dt
Atom IDs are used to identify and find partner atoms in bonds. :dd
{Atom count changed in fix neb} :dt
This is not allowed in a NEB calculation. :dd
{Atom count is inconsistent, cannot write data file} :dt
The sum of atoms across processors does not equal the global number
of atoms. Probably some atoms have been lost. :dd
{Atom count is inconsistent, cannot write restart file} :dt
Sum of atoms across processors does not equal initial total count.
This is probably because you have lost some atoms. :dd
{Atom in too many rigid bodies - boost MAXBODY} :dt
Fix poems has a parameter MAXBODY (in fix_poems.cpp) which determines
the maximum number of rigid bodies a single atom can belong to (i.e. a
multibody joint). The bodies you have defined exceed this limit. :dd
{Atom sort did not operate correctly} :dt
This is an internal LAMMPS error. Please report it to the
developers. :dd
{Atom sorting has bin size = 0.0} :dt
The neighbor cutoff is being used as the bin size, but it is zero.
Thus you must explicitly list a bin size in the atom_modify sort
command or turn off sorting. :dd
{Atom style hybrid cannot have hybrid as an argument} :dt
Self-explanatory. :dd
{Atom style hybrid cannot use same atom style twice} :dt
Self-explanatory. :dd
{Atom style template molecule must have atom types} :dt
The defined molecule(s) does not specify atom types. :dd
{Atom style was redefined after using fix property/atom} :dt
This is not allowed. :dd
{Atom type must be zero in fix gcmc mol command} :dt
Self-explanatory. :dd
{Atom vector in equal-style variable formula} :dt
Atom vectors generate one value per atom which is not allowed
in an equal-style variable. :dd
{Atom-style variable in equal-style variable formula} :dt
Atom-style variables generate one value per atom which is not allowed
in an equal-style variable. :dd
{Atom_modify id command after simulation box is defined} :dt
The atom_modify id command cannot be used after a read_data,
read_restart, or create_box command. :dd
{Atom_modify map command after simulation box is defined} :dt
The atom_modify map command cannot be used after a read_data,
read_restart, or create_box command. :dd
{Atom_modify sort and first options cannot be used together} :dt
Self-explanatory. :dd
{Atom_style command after simulation box is defined} :dt
The atom_style command cannot be used after a read_data,
read_restart, or create_box command. :dd
{Atom_style line can only be used in 2d simulations} :dt
Self-explanatory. :dd
{Atom_style tri can only be used in 3d simulations} :dt
Self-explanatory. :dd
{Atomfile variable could not read values} :dt
Check the file assigned to the variable. :dd
{Atomfile variable in equal-style variable formula} :dt
Self-explanatory. :dd
{Atomfile-style variable in equal-style variable formula} :dt
Self-explanatory. :dd
{Attempt to pop empty stack in fix box/relax} :dt
Internal LAMMPS error. Please report it to the developers. :dd
{Attempt to push beyond stack limit in fix box/relax} :dt
Internal LAMMPS error. Please report it to the developers. :dd
{Attempting to rescale a 0.0 temperature} :dt
Cannot rescale a temperature that is already 0.0. :dd
{Bad FENE bond} :dt
Two atoms in a FENE bond have become so far apart that the bond cannot
be computed. :dd
{Bad TIP4P angle type for PPPM/TIP4P} :dt
Specified angle type is not valid. :dd
{Bad TIP4P angle type for PPPMDisp/TIP4P} :dt
Specified angle type is not valid. :dd
{Bad TIP4P bond type for PPPM/TIP4P} :dt
Specified bond type is not valid. :dd
{Bad TIP4P bond type for PPPMDisp/TIP4P} :dt
Specified bond type is not valid. :dd
{Bad fix ID in fix append/atoms command} :dt
The value of the fix_id for keyword spatial must start with 'f_'. :dd
{Bad grid of processors} :dt
The 3d grid of processors defined by the processors command does not
match the number of processors LAMMPS is being run on. :dd
{Bad kspace_modify kmax/ewald parameter} :dt
Kspace_modify values for the kmax/ewald keyword must be integers > 0 :dd
{Bad kspace_modify slab parameter} :dt
Kspace_modify value for the slab/volume keyword must be >= 2.0. :dd
{Bad matrix inversion in mldivide3} :dt
This error should not occur unless the matrix is badly formed. :dd
{Bad principal moments} :dt
Fix rigid did not compute the principal moments of inertia of a rigid
group of atoms correctly. :dd
{Bad quadratic solve for particle/line collision} :dt
This is an internal error. It should normally not occur. :dd
{Bad quadratic solve for particle/tri collision} :dt
This is an internal error. It should normally not occur. :dd
{Bad real space Coulomb cutoff in fix tune/kspace} :dt
Fix tune/kspace tried to find the optimal real space Coulomb cutoff using
the Newton-Rhaphson method, but found a non-positive or NaN cutoff :dd
{Balance command before simulation box is defined} :dt
The balance command cannot be used before a read_data, read_restart,
or create_box command. :dd
{Balance produced bad splits} :dt
This should not occur. It means two or more cutting plane locations
are on top of each other or out of order. Report the problem to the
developers. :dd
{Balance rcb cannot be used with comm_style brick} :dt
Comm_style tiled must be used instead. :dd
{Balance shift string is invalid} :dt
The string can only contain the characters "x", "y", or "z". :dd
{Bias compute does not calculate a velocity bias} :dt
The specified compute must compute a bias for temperature. :dd
{Bias compute does not calculate temperature} :dt
The specified compute must compute temperature. :dd
{Bias compute group does not match compute group} :dt
The specified compute must operate on the same group as the parent
compute. :dd
{Big particle in fix srd cannot be point particle} :dt
Big particles must be extended spheriods or ellipsoids. :dd
{Bigint setting in lmptype.h is invalid} :dt
Size of bigint is less than size of tagint. :dd
{Bigint setting in lmptype.h is not compatible} :dt
Format of bigint stored in restart file is not consistent with LAMMPS
version you are running. See the settings in src/lmptype.h :dd
{Bitmapped lookup tables require int/float be same size} :dt
Cannot use pair tables on this machine, because of word sizes. Use
the pair_modify command with table 0 instead. :dd
{Bitmapped table in file does not match requested table} :dt
Setting for bitmapped table in pair_coeff command must match table
in file exactly. :dd
{Bitmapped table is incorrect length in table file} :dt
Number of table entries is not a correct power of 2. :dd
{Bond and angle potentials must be defined for TIP4P} :dt
Cannot use TIP4P pair potential unless bond and angle potentials
are defined. :dd
{Bond atom missing in box size check} :dt
The 2nd atoms needed to compute a particular bond is missing on this
processor. Typically this is because the pairwise cutoff is set too
short or the bond has blown apart and an atom is too far away. :dd
{Bond atom missing in delete_bonds} :dt
The delete_bonds command cannot find one or more atoms in a particular
bond on a particular processor. The pairwise cutoff is too short or
the atoms are too far apart to make a valid bond. :dd
{Bond atom missing in image check} :dt
The 2nd atom in a particular bond is missing on this processor.
Typically this is because the pairwise cutoff is set too short or the
bond has blown apart and an atom is too far away. :dd
{Bond atom missing in set command} :dt
The set command cannot find one or more atoms in a particular bond on
a particular processor. The pairwise cutoff is too short or the atoms
are too far apart to make a valid bond. :dd
{Bond atoms %d %d missing on proc %d at step %ld} :dt
The 2nd atom needed to compute a particular bond is missing on this
processor. Typically this is because the pairwise cutoff is set too
short or the bond has blown apart and an atom is too far away. :dd
{Bond atoms missing on proc %d at step %ld} :dt
The 2nd atom needed to compute a particular bond is missing on this
processor. Typically this is because the pairwise cutoff is set too
short or the bond has blown apart and an atom is too far away. :dd
{Bond coeff for hybrid has invalid style} :dt
Bond style hybrid uses another bond style as one of its coefficients.
The bond style used in the bond_coeff command or read from a restart
file is not recognized. :dd
{Bond coeffs are not set} :dt
No bond coefficients have been assigned in the data file or via the
bond_coeff command. :dd
{Bond extent > half of periodic box length} :dt
This error was detected by the neigh_modify check yes setting. It is
an error because the bond atoms are so far apart it is ambiguous how
it should be defined. :dd
{Bond potential must be defined for SHAKE} :dt
Cannot use fix shake unless bond potential is defined. :dd
{Bond style hybrid cannot have hybrid as an argument} :dt
Self-explanatory. :dd
{Bond style hybrid cannot have none as an argument} :dt
Self-explanatory. :dd
{Bond style hybrid cannot use same bond style twice} :dt
Self-explanatory. :dd
{Bond style quartic cannot be used with 3,4-body interactions} :dt
No angle, dihedral, or improper styles can be defined when using
bond style quartic. :dd
{Bond style quartic cannot be used with atom style template} :dt
This bond style can change the bond topology which is not
allowed with this atom style. :dd
{Bond style quartic requires special_bonds = 1,1,1} :dt
This is a restriction of the current bond quartic implementation. :dd
{Bond table parameters did not set N} :dt
List of bond table parameters must include N setting. :dd
{Bond table values are not increasing} :dt
The values in the tabulated file must be monotonically increasing. :dd
{BondAngle coeff for hybrid angle has invalid format} :dt
No "ba" field should appear in data file entry. :dd
{BondBond coeff for hybrid angle has invalid format} :dt
No "bb" field should appear in data file entry. :dd
{Bond_coeff command before bond_style is defined} :dt
Coefficients cannot be set in the data file or via the bond_coeff
command until an bond_style has been assigned. :dd
{Bond_coeff command before simulation box is defined} :dt
The bond_coeff command cannot be used before a read_data,
read_restart, or create_box command. :dd
{Bond_coeff command when no bonds allowed} :dt
The chosen atom style does not allow for bonds to be defined. :dd
{Bond_style command when no bonds allowed} :dt
The chosen atom style does not allow for bonds to be defined. :dd
{Bonds assigned incorrectly} :dt
Bonds read in from the data file were not assigned correctly to atoms.
This means there is something invalid about the topology definitions. :dd
{Bonds defined but no bond types} :dt
The data file header lists bonds but no bond types. :dd
{Both restart files must use % or neither} :dt
Self-explanatory. :dd
{Both restart files must use MPI-IO or neither} :dt
Self-explanatory. :dd
{Both sides of boundary must be periodic} :dt
Cannot specify a boundary as periodic only on the lo or hi side. Must
be periodic on both sides. :dd
{Boundary command after simulation box is defined} :dt
The boundary command cannot be used after a read_data, read_restart,
or create_box command. :dd
{Box bounds are invalid} :dt
The box boundaries specified in the read_data file are invalid. The
lo value must be less than the hi value for all 3 dimensions. :dd
{Box command after simulation box is defined} :dt
The box command cannot be used after a read_data, read_restart, or
create_box command. :dd
{CPU neighbor lists must be used for ellipsoid/sphere mix.} :dt
When using Gay-Berne or RE-squared pair styles with both ellipsoidal and
spherical particles, the neighbor list must be built on the CPU :dd
{Can not specify Pxy/Pxz/Pyz in fix box/relax with non-triclinic box} :dt
Only triclinic boxes can be used with off-diagonal pressure components.
See the region prism command for details. :dd
{Can not specify Pxy/Pxz/Pyz in fix nvt/npt/nph with non-triclinic box} :dt
Only triclinic boxes can be used with off-diagonal pressure components.
See the region prism command for details. :dd
{Can only use -plog with multiple partitions} :dt
Self-explanatory. See doc page discussion of command-line switches. :dd
{Can only use -pscreen with multiple partitions} :dt
Self-explanatory. See doc page discussion of command-line switches. :dd
{Can only use Kokkos supported regions with Kokkos package} :dt
Self-explanatory. :dd
{Can only use NEB with 1-processor replicas} :dt
This is current restriction for NEB as implemented in LAMMPS. :dd
{Can only use TAD with 1-processor replicas for NEB} :dt
This is current restriction for NEB as implemented in LAMMPS. :dd
{Cannot (yet) do analytic differentiation with pppm/gpu} :dt
This is a current restriction of this command. :dd
{Cannot (yet) request ghost atoms with Kokkos half neighbor list} :dt
This feature is not yet supported. :dd
{Cannot (yet) use 'electron' units with dipoles} :dt
This feature is not yet supported. :dd
{Cannot (yet) use Ewald with triclinic box and slab correction} :dt
This feature is not yet supported. :dd
{Cannot (yet) use K-space slab correction with compute group/group for triclinic systems} :dt
This option is not yet supported. :dd
{Cannot (yet) use MSM with 2d simulation} :dt
This feature is not yet supported. :dd
{Cannot (yet) use PPPM with triclinic box and TIP4P} :dt
This feature is not yet supported. :dd
{Cannot (yet) use PPPM with triclinic box and kspace_modify diff ad} :dt
This feature is not yet supported. :dd
{Cannot (yet) use PPPM with triclinic box and slab correction} :dt
This feature is not yet supported. :dd
{Cannot (yet) use kspace slab correction with long-range dipoles and non-neutral systems or per-atom energy} :dt
This feature is not yet supported. :dd
{Cannot (yet) use kspace_modify diff ad with compute group/group} :dt
This option is not yet supported. :dd
{Cannot (yet) use kspace_style pppm/stagger with triclinic systems} :dt
This feature is not yet supported. :dd
{Cannot (yet) use molecular templates with Kokkos} :dt
Self-explanatory. :dd
{Cannot (yet) use respa with Kokkos} :dt
Self-explanatory. :dd
{Cannot (yet) use rigid bodies with fix deform and Kokkos} :dt
Self-explanatory. :dd
{Cannot (yet) use rigid bodies with fix nh and Kokkos} :dt
Self-explanatory. :dd
{Cannot (yet) use single precision with MSM (remove -DFFT_SINGLE from Makefile and recompile)} :dt
Single precision cannot be used with MSM. :dd
{Cannot add atoms to fix move variable} :dt
Atoms can not be added afterwards to this fix option. :dd
{Cannot append atoms to a triclinic box} :dt
The simulation box must be defined with edges aligned with the
Cartesian axes. :dd
{Cannot balance in z dimension for 2d simulation} :dt
Self-explanatory. :dd
{Cannot change box ortho/triclinic with certain fixes defined} :dt
This is because those fixes store the shape of the box. You need to
use unfix to discard the fix, change the box, then redefine a new
fix. :dd
{Cannot change box ortho/triclinic with dumps defined} :dt
This is because some dumps store the shape of the box. You need to
use undump to discard the dump, change the box, then redefine a new
dump. :dd
{Cannot change box tilt factors for orthogonal box} :dt
Cannot use tilt factors unless the simulation box is non-orthogonal. :dd
{Cannot change box to orthogonal when tilt is non-zero} :dt
Self-explanatory. :dd
{Cannot change box z boundary to nonperiodic for a 2d simulation} :dt
Self-explanatory. :dd
{Cannot change dump_modify every for dump dcd} :dt
The frequency of writing dump dcd snapshots cannot be changed. :dd
{Cannot change dump_modify every for dump xtc} :dt
The frequency of writing dump xtc snapshots cannot be changed. :dd
{Cannot change timestep once fix srd is setup} :dt
This is because various SRD properties depend on the timestep
size. :dd
{Cannot change timestep with fix pour} :dt
This is because fix pour pre-computes the time delay for particles to
fall out of the insertion volume due to gravity. :dd
{Cannot change to comm_style brick from tiled layout} :dt
Self-explanatory. :dd
{Cannot change_box after reading restart file with per-atom info} :dt
This is because the restart file info cannot be migrated with the
atoms. You can get around this by performing a 0-timestep run which
will assign the restart file info to actual atoms. :dd
{Cannot change_box in xz or yz for 2d simulation} :dt
Self-explanatory. :dd
{Cannot change_box in z dimension for 2d simulation} :dt
Self-explanatory. :dd
{Cannot clear group all} :dt
This operation is not allowed. :dd
{Cannot close restart file - MPI error: %s} :dt
This error was generated by MPI when reading/writing an MPI-IO restart
file. :dd
{Cannot compute initial g_ewald_disp} :dt
LAMMPS failed to compute an initial guess for the PPPM_disp g_ewald_6
factor that partitions the computation between real space and k-space
for Dispersion interactions. :dd
{Cannot create an atom map unless atoms have IDs} :dt
The simulation requires a mapping from global atom IDs to local atoms,
but the atoms that have been defined have no IDs. :dd
{Cannot create atoms with undefined lattice} :dt
Must use the lattice command before using the create_atoms
command. :dd
{Cannot create/grow a vector/array of pointers for %s} :dt
LAMMPS code is making an illegal call to the templated memory
allocaters, to create a vector or array of pointers. :dd
{Cannot create_atoms after reading restart file with per-atom info} :dt
The per-atom info was stored to be used when by a fix that you may
re-define. If you add atoms before re-defining the fix, then there
will not be a correct amount of per-atom info. :dd
{Cannot create_box after simulation box is defined} :dt
A simulation box can only be defined once. :dd
{Cannot currently use pair reax with pair hybrid} :dt
This is not yet supported. :dd
{Cannot currently use pppm/gpu with fix balance.} :dt
Self-explanatory. :dd
{Cannot delete group all} :dt
Self-explanatory. :dd
{Cannot delete group currently used by a compute} :dt
Self-explanatory. :dd
{Cannot delete group currently used by a dump} :dt
Self-explanatory. :dd
{Cannot delete group currently used by a fix} :dt
Self-explanatory. :dd
{Cannot delete group currently used by atom_modify first} :dt
Self-explanatory. :dd
{Cannot delete_atoms bond yes for non-molecular systems} :dt
Self-explanatory. :dd
{Cannot displace_atoms after reading restart file with per-atom info} :dt
This is because the restart file info cannot be migrated with the
atoms. You can get around this by performing a 0-timestep run which
will assign the restart file info to actual atoms. :dd
{Cannot do GCMC on atoms in atom_modify first group} :dt
This is a restriction due to the way atoms are organized in a list to
enable the atom_modify first command. :dd
{Cannot do atom/swap on atoms in atom_modify first group} :dt
This is a restriction due to the way atoms are organized in a list to
enable the atom_modify first command. :dd
{Cannot dump sort on atom IDs with no atom IDs defined} :dt
Self-explanatory. :dd
{Cannot dump sort when multiple dump files are written} :dt
In this mode, each processor dumps its atoms to a file, so
no sorting is allowed. :dd
{Cannot embed Python when also extending Python with LAMMPS} :dt
When running LAMMPS via Python through the LAMMPS library interface
you cannot also user the input script python command. :dd
{Cannot evaporate atoms in atom_modify first group} :dt
This is a restriction due to the way atoms are organized in
a list to enable the atom_modify first command. :dd
{Cannot find create_bonds group ID} :dt
Self-explanatory. :dd
{Cannot find delete_bonds group ID} :dt
Group ID used in the delete_bonds command does not exist. :dd
{Cannot find specified group ID for core particles} :dt
Self-explanatory. :dd
{Cannot find specified group ID for shell particles} :dt
Self-explanatory. :dd
{Cannot have both pair_modify shift and tail set to yes} :dt
These 2 options are contradictory. :dd
{Cannot intersect groups using a dynamic group} :dt
This operation is not allowed. :dd
{Cannot mix molecular and molecule template atom styles} :dt
Self-explanatory. :dd
{Cannot open -reorder file} :dt
Self-explanatory. :dd
{Cannot open ADP potential file %s} :dt
The specified ADP potential file cannot be opened. Check that the
path and name are correct. :dd
{Cannot open AIREBO potential file %s} :dt
The specified AIREBO potential file cannot be opened. Check that the
path and name are correct. :dd
{Cannot open BOP potential file %s} :dt
The specified BOP potential file cannot be opened. Check that the
path and name are correct. :dd
{Cannot open COMB potential file %s} :dt
The specified COMB potential file cannot be opened. Check that the
path and name are correct. :dd
{Cannot open COMB3 lib.comb3 file} :dt
The COMB3 library file cannot be opened. Check that the path and name
are correct. :dd
{Cannot open COMB3 potential file %s} :dt
The specified COMB3 potential file cannot be opened. Check that the
path and name are correct. :dd
{Cannot open EAM potential file %s} :dt
The specified EAM potential file cannot be opened. Check that the
path and name are correct. :dd
{Cannot open EIM potential file %s} :dt
The specified EIM potential file cannot be opened. Check that the
path and name are correct. :dd
{Cannot open LCBOP potential file %s} :dt
The specified LCBOP potential file cannot be opened. Check that the
path and name are correct. :dd
{Cannot open MEAM potential file %s} :dt
The specified MEAM potential file cannot be opened. Check that the
path and name are correct. :dd
{Cannot open SNAP coefficient file %s} :dt
The specified SNAP coefficient file cannot be opened. Check that the
path and name are correct. :dd
{Cannot open SNAP parameter file %s} :dt
The specified SNAP parameter file cannot be opened. Check that the
path and name are correct. :dd
{Cannot open Stillinger-Weber potential file %s} :dt
The specified SW potential file cannot be opened. Check that the path
and name are correct. :dd
{Cannot open Tersoff potential file %s} :dt
The specified potential file cannot be opened. Check that the path
and name are correct. :dd
{Cannot open Vashishta potential file %s} :dt
The specified Vashishta potential file cannot be opened. Check that the path
and name are correct. :dd
{Cannot open balance output file} :dt
Self-explanatory. :dd
{Cannot open coul/streitz potential file %s} :dt
The specified coul/streitz potential file cannot be opened. Check
that the path and name are correct. :dd
{Cannot open custom file} :dt
Self-explanatory. :dd
{Cannot open data file %s} :dt
The specified file cannot be opened. Check that the path and name are
correct. :dd
{Cannot open dir to search for restart file} :dt
Using a "*" in the name of the restart file will open the current
directory to search for matching file names. :dd
{Cannot open dump file} :dt
Self-explanatory. :dd
{Cannot open dump file %s} :dt
The output file for the dump command cannot be opened. Check that the
path and name are correct. :dd
{Cannot open file %s} :dt
The specified file cannot be opened. Check that the path and name are
correct. If the file is a compressed file, also check that the gzip
executable can be found and run. :dd
{Cannot open file variable file %s} :dt
The specified file cannot be opened. Check that the path and name are
correct. :dd
{Cannot open fix ave/chunk file %s} :dt
The specified file cannot be opened. Check that the path and name are
correct. :dd
{Cannot open fix ave/correlate file %s} :dt
The specified file cannot be opened. Check that the path and name are
correct. :dd
{Cannot open fix ave/histo file %s} :dt
The specified file cannot be opened. Check that the path and name are
correct. :dd
{Cannot open fix ave/spatial file %s} :dt
The specified file cannot be opened. Check that the path and name are
correct. :dd
{Cannot open fix ave/time file %s} :dt
The specified file cannot be opened. Check that the path and name are
correct. :dd
{Cannot open fix balance output file} :dt
Self-explanatory. :dd
{Cannot open fix poems file %s} :dt
The specified file cannot be opened. Check that the path and name are
correct. :dd
{Cannot open fix print file %s} :dt
The output file generated by the fix print command cannot be opened :dd
{Cannot open fix qeq parameter file %s} :dt
The specified file cannot be opened. Check that the path and name are
correct. :dd
{Cannot open fix qeq/comb file %s} :dt
The output file for the fix qeq/combs command cannot be opened.
Check that the path and name are correct. :dd
{Cannot open fix reax/bonds file %s} :dt
The output file for the fix reax/bonds command cannot be opened.
Check that the path and name are correct. :dd
{Cannot open fix rigid infile %s} :dt
The specified file cannot be opened. Check that the path and name are
correct. :dd
{Cannot open fix rigid restart file %s} :dt
The specified file cannot be opened. Check that the path and name are
correct. :dd
{Cannot open fix rigid/small infile %s} :dt
The specified file cannot be opened. Check that the path and name are
correct. :dd
{Cannot open fix tmd file %s} :dt
The output file for the fix tmd command cannot be opened. Check that
the path and name are correct. :dd
{Cannot open fix ttm file %s} :dt
The output file for the fix ttm command cannot be opened. Check that
the path and name are correct. :dd
{Cannot open gzipped file} :dt
LAMMPS was compiled without support for reading and writing gzipped
files through a pipeline to the gzip program with -DLAMMPS_GZIP. :dd
{Cannot open input script %s} :dt
Self-explanatory. :dd
{Cannot open log.cite file} :dt
This file is created when you use some LAMMPS features, to indicate
what paper you should cite on behalf of those who implemented
the feature. Check that you have write privileges into the directory
you are running in. :dd
{Cannot open log.lammps for writing} :dt
The default LAMMPS log file cannot be opened. Check that the
directory you are running in allows for files to be created. :dd
{Cannot open logfile} :dt
The LAMMPS log file named in a command-line argument cannot be opened.
Check that the path and name are correct. :dd
{Cannot open logfile %s} :dt
The LAMMPS log file specified in the input script cannot be opened.
Check that the path and name are correct. :dd
{Cannot open molecule file %s} :dt
The specified file cannot be opened. Check that the path and name are
correct. :dd
{Cannot open nb3b/harmonic potential file %s} :dt
The specified potential file cannot be opened. Check that the path
and name are correct. :dd
{Cannot open pair_write file} :dt
The specified output file for pair energies and forces cannot be
opened. Check that the path and name are correct. :dd
{Cannot open polymorphic potential file %s} :dt
The specified polymorphic potential file cannot be opened. Check that
the path and name are correct. :dd
{Cannot open print file %s} :dt
Self-explanatory. :dd
{Cannot open processors output file} :dt
Self-explanatory. :dd
{Cannot open restart file %s} :dt
Self-explanatory. :dd
{Cannot open restart file for reading - MPI error: %s} :dt
This error was generated by MPI when reading/writing an MPI-IO restart
file. :dd
{Cannot open restart file for writing - MPI error: %s} :dt
This error was generated by MPI when reading/writing an MPI-IO restart
file. :dd
{Cannot open screen file} :dt
The screen file specified as a command-line argument cannot be
opened. Check that the directory you are running in allows for files
to be created. :dd
{Cannot open temporary file for world counter.} :dt
Self-explanatory. :dd
{Cannot open universe log file} :dt
For a multi-partition run, the master log file cannot be opened.
Check that the directory you are running in allows for files to be
created. :dd
{Cannot open universe screen file} :dt
For a multi-partition run, the master screen file cannot be opened.
Check that the directory you are running in allows for files to be
created. :dd
{Cannot read from restart file - MPI error: %s} :dt
This error was generated by MPI when reading/writing an MPI-IO restart
file. :dd
{Cannot read_data without add keyword after simulation box is defined} :dt
Self-explanatory. :dd
{Cannot read_restart after simulation box is defined} :dt
The read_restart command cannot be used after a read_data,
read_restart, or create_box command. :dd
{Cannot redefine variable as a different style} :dt
An equal-style variable can be re-defined but only if it was
originally an equal-style variable. :dd
{Cannot replicate 2d simulation in z dimension} :dt
The replicate command cannot replicate a 2d simulation in the z
dimension. :dd
{Cannot replicate with fixes that store atom quantities} :dt
Either fixes are defined that create and store atom-based vectors or a
restart file was read which included atom-based vectors for fixes.
The replicate command cannot duplicate that information for new atoms.
You should use the replicate command before fixes are applied to the
system. :dd
{Cannot reset timestep with a dynamic region defined} :dt
Dynamic regions (see the region command) have a time dependence.
Thus you cannot change the timestep when one or more of these
are defined. :dd
{Cannot reset timestep with a time-dependent fix defined} :dt
You cannot reset the timestep when a fix that keeps track of elapsed
time is in place. :dd
{Cannot run 2d simulation with nonperiodic Z dimension} :dt
Use the boundary command to make the z dimension periodic in order to
run a 2d simulation. :dd
{Cannot set bond topology types for atom style template} :dt
The bond, angle, etc types cannot be changed for this atom style since
they are static settings in the molecule template files. :dd
{Cannot set both respa pair and inner/middle/outer} :dt
In the rRESPA integrator, you must compute pairwise potentials either
all together (pair), or in pieces (inner/middle/outer). You can't do
both. :dd
{Cannot set cutoff/multi before simulation box is defined} :dt
Self-explanatory. :dd
{Cannot set dpd/theta for this atom style} :dt
Self-explanatory. :dd
{Cannot set dump_modify flush for dump xtc} :dt
Self-explanatory. :dd
{Cannot set mass for this atom style} :dt
This atom style does not support mass settings for each atom type.
Instead they are defined on a per-atom basis in the data file. :dd
{Cannot set meso/cv for this atom style} :dt
Self-explanatory. :dd
{Cannot set meso/e for this atom style} :dt
Self-explanatory. :dd
{Cannot set meso/rho for this atom style} :dt
Self-explanatory. :dd
{Cannot set non-zero image flag for non-periodic dimension} :dt
Self-explanatory. :dd
{Cannot set non-zero z velocity for 2d simulation} :dt
Self-explanatory. :dd
{Cannot set quaternion for atom that has none} :dt
Self-explanatory. :dd
{Cannot set quaternion with xy components for 2d system} :dt
Self-explanatory. :dd
{Cannot set respa hybrid and any of pair/inner/middle/outer} :dt
In the rRESPA integrator, you must compute pairwise potentials either
all together (pair), with different cutoff regions (inner/middle/outer),
or per hybrid sub-style (hybrid). You cannot mix those. :dd
{Cannot set respa middle without inner/outer} :dt
In the rRESPA integrator, you must define both a inner and outer
setting in order to use a middle setting. :dd
{Cannot set restart file size - MPI error: %s} :dt
This error was generated by MPI when reading/writing an MPI-IO restart
file. :dd
{Cannot set smd/contact/radius for this atom style} :dt
Self-explanatory. :dd
{Cannot set smd/mass/density for this atom style} :dt
Self-explanatory. :dd
{Cannot set temperature for fix rigid/nph} :dt
The temp keyword cannot be specified. :dd
{Cannot set theta for atom that is not a line} :dt
Self-explanatory. :dd
{Cannot set this attribute for this atom style} :dt
The attribute being set does not exist for the defined atom style. :dd
{Cannot set variable z velocity for 2d simulation} :dt
Self-explanatory. :dd
{Cannot skew triclinic box in z for 2d simulation} :dt
Self-explanatory. :dd
{Cannot subtract groups using a dynamic group} :dt
This operation is not allowed. :dd
{Cannot union groups using a dynamic group} :dt
This operation is not allowed. :dd
{Cannot use -cuda on and -kokkos on together} :dt
This is not allowed since both packages can use GPUs. :dd
{Cannot use -cuda on without USER-CUDA installed} :dt
The USER-CUDA package must be installed via "make yes-user-cuda"
before LAMMPS is built. :dd
{Cannot use -kokkos on without KOKKOS installed} :dt
Self-explanatory. :dd
{Cannot use -reorder after -partition} :dt
Self-explanatory. See doc page discussion of command-line switches. :dd
{Cannot use Ewald with 2d simulation} :dt
The kspace style ewald cannot be used in 2d simulations. You can use
2d Ewald in a 3d simulation; see the kspace_modify command. :dd
{Cannot use Ewald/disp solver on system with no charge, dipole, or LJ particles} :dt
No atoms in system have a non-zero charge or dipole, or are LJ
particles. Change charges/dipoles or change options of the kspace
solver/pair style. :dd
{Cannot use EwaldDisp with 2d simulation} :dt
This is a current restriction of this command. :dd
{Cannot use GPU package with USER-CUDA package enabled} :dt
You cannot use both the GPU and USER-CUDA packages
together. Use one or the other. :dd
{Cannot use Kokkos pair style with rRESPA inner/middle} :dt
Self-explanatory. :dd
{Cannot use NEB unless atom map exists} :dt
Use the atom_modify command to create an atom map. :dd
{Cannot use NEB with a single replica} :dt
Self-explanatory. :dd
{Cannot use NEB with atom_modify sort enabled} :dt
This is current restriction for NEB implemented in LAMMPS. :dd
{Cannot use PPPM with 2d simulation} :dt
The kspace style pppm cannot be used in 2d simulations. You can use
2d PPPM in a 3d simulation; see the kspace_modify command. :dd
{Cannot use PPPMDisp with 2d simulation} :dt
The kspace style pppm/disp cannot be used in 2d simulations. You can
use 2d pppm/disp in a 3d simulation; see the kspace_modify command. :dd
{Cannot use PRD with a changing box} :dt
The current box dimensions are not copied between replicas :dd
{Cannot use PRD with a time-dependent fix defined} :dt
PRD alters the timestep in ways that will mess up these fixes. :dd
{Cannot use PRD with a time-dependent region defined} :dt
PRD alters the timestep in ways that will mess up these regions. :dd
{Cannot use PRD with atom_modify sort enabled} :dt
This is a current restriction of PRD. You must turn off sorting,
which is enabled by default, via the atom_modify command. :dd
{Cannot use PRD with multi-processor replicas unless atom map exists} :dt
Use the atom_modify command to create an atom map. :dd
{Cannot use TAD unless atom map exists for NEB} :dt
See atom_modify map command to set this. :dd
{Cannot use TAD with a single replica for NEB} :dt
NEB requires multiple replicas. :dd
{Cannot use TAD with atom_modify sort enabled for NEB} :dt
This is a current restriction of NEB. :dd
{Cannot use a damped dynamics min style with fix box/relax} :dt
This is a current restriction in LAMMPS. Use another minimizer
style. :dd
{Cannot use a damped dynamics min style with per-atom DOF} :dt
This is a current restriction in LAMMPS. Use another minimizer
style. :dd
{Cannot use append/atoms in periodic dimension} :dt
The boundary style of the face where atoms are added can not be of
type p (periodic). :dd
{Cannot use atomfile-style variable unless atom map exists} :dt
Self-explanatory. See the atom_modify command to create a map. :dd
{Cannot use both com and bias with compute temp/chunk} :dt
Self-explanatory. :dd
{Cannot use chosen neighbor list style with buck/coul/cut/kk} :dt
Self-explanatory. :dd
{Cannot use chosen neighbor list style with buck/coul/long/kk} :dt
Self-explanatory. :dd
{Cannot use chosen neighbor list style with buck/kk} :dt
That style is not supported by Kokkos. :dd
{Cannot use chosen neighbor list style with coul/cut/kk} :dt
That style is not supported by Kokkos. :dd
{Cannot use chosen neighbor list style with coul/debye/kk} :dt
Self-explanatory. :dd
{Cannot use chosen neighbor list style with coul/dsf/kk} :dt
That style is not supported by Kokkos. :dd
{Cannot use chosen neighbor list style with coul/wolf/kk} :dt
That style is not supported by Kokkos. :dd
{Cannot use chosen neighbor list style with lj/charmm/coul/charmm/implicit/kk} :dt
Self-explanatory. :dd
{Cannot use chosen neighbor list style with lj/charmm/coul/charmm/kk} :dt
Self-explanatory. :dd
{Cannot use chosen neighbor list style with lj/charmm/coul/long/kk} :dt
Self-explanatory. :dd
{Cannot use chosen neighbor list style with lj/class2/coul/cut/kk} :dt
Self-explanatory. :dd
{Cannot use chosen neighbor list style with lj/class2/coul/long/kk} :dt
Self-explanatory. :dd
{Cannot use chosen neighbor list style with lj/class2/kk} :dt
Self-explanatory. :dd
{Cannot use chosen neighbor list style with lj/cut/coul/cut/kk} :dt
That style is not supported by Kokkos. :dd
{Cannot use chosen neighbor list style with lj/cut/coul/debye/kk} :dt
Self-explanatory. :dd
{Cannot use chosen neighbor list style with lj/cut/coul/long/kk} :dt
That style is not supported by Kokkos. :dd
{Cannot use chosen neighbor list style with lj/cut/kk} :dt
That style is not supported by Kokkos. :dd
{Cannot use chosen neighbor list style with lj/expand/kk} :dt
Self-explanatory. :dd
{Cannot use chosen neighbor list style with lj/gromacs/coul/gromacs/kk} :dt
Self-explanatory. :dd
{Cannot use chosen neighbor list style with lj/gromacs/kk} :dt
Self-explanatory. :dd
{Cannot use chosen neighbor list style with lj/sdk/kk} :dt
That style is not supported by Kokkos. :dd
{Cannot use chosen neighbor list style with pair eam/kk} :dt
That style is not supported by Kokkos. :dd
{Cannot use chosen neighbor list style with pair eam/kk/alloy} :dt
Self-explanatory. :dd
{Cannot use chosen neighbor list style with pair eam/kk/fs} :dt
Self-explanatory. :dd
{Cannot use chosen neighbor list style with pair sw/kk} :dt
Self-explanatory. :dd
{Cannot use chosen neighbor list style with tersoff/kk} :dt
Self-explanatory. :dd
{Cannot use chosen neighbor list style with tersoff/zbl/kk} :dt
Self-explanatory. :dd
{Cannot use compute chunk/atom bin z for 2d model} :dt
Self-explanatory. :dd
{Cannot use compute cluster/atom unless atoms have IDs} :dt
Atom IDs are used to identify clusters. :dd
{Cannot use create_atoms rotate unless single style} :dt
Self-explanatory. :dd
{Cannot use create_bonds unless atoms have IDs} :dt
This command requires a mapping from global atom IDs to local atoms,
but the atoms that have been defined have no IDs. :dd
{Cannot use create_bonds with non-molecular system} :dt
Self-explanatory. :dd
{Cannot use cwiggle in variable formula between runs} :dt
This is a function of elapsed time. :dd
{Cannot use delete_atoms bond yes with atom_style template} :dt
This is because the bonds for that atom style are hardwired in the
molecule template. :dd
{Cannot use delete_atoms unless atoms have IDs} :dt
Your atoms do not have IDs, so the delete_atoms command cannot be
used. :dd
{Cannot use delete_bonds with non-molecular system} :dt
Your choice of atom style does not have bonds. :dd
{Cannot use dump_modify fileper without % in dump file name} :dt
Self-explanatory. :dd
{Cannot use dump_modify nfile without % in dump file name} :dt
Self-explanatory. :dd
{Cannot use dynamic group with fix adapt atom} :dt
This is not yet supported. :dd
{Cannot use fix TMD unless atom map exists} :dt
Using this fix requires the ability to lookup an atom index, which is
provided by an atom map. An atom map does not exist (by default) for
non-molecular problems. Using the atom_modify map command will force
an atom map to be created. :dd
{Cannot use fix ave/spatial z for 2 dimensional model} :dt
Self-explanatory. :dd
{Cannot use fix bond/break with non-molecular systems} :dt
Only systems with bonds that can be changed can be used. Atom_style
template does not qualify. :dd
{Cannot use fix bond/create with non-molecular systems} :dt
Only systems with bonds that can be changed can be used. Atom_style
template does not qualify. :dd
{Cannot use fix bond/swap with non-molecular systems} :dt
Only systems with bonds that can be changed can be used. Atom_style
template does not qualify. :dd
{Cannot use fix box/relax on a 2nd non-periodic dimension} :dt
When specifying an off-diagonal pressure component, the 2nd of the two
dimensions must be periodic. E.g. if the xy component is specified,
then the y dimension must be periodic. :dd
{Cannot use fix box/relax on a non-periodic dimension} :dt
When specifying a diagonal pressure component, the dimension must be
periodic. :dd
{Cannot use fix box/relax with both relaxation and scaling on a tilt factor} :dt
When specifying scaling on a tilt factor component, that component can not
also be controlled by the barostat. E.g. if scalexy yes is specified and
also keyword tri or xy, this is wrong. :dd
{Cannot use fix box/relax with tilt factor scaling on a 2nd non-periodic dimension} :dt
When specifying scaling on a tilt factor component, the 2nd of the two
dimensions must be periodic. E.g. if the xy component is specified,
then the y dimension must be periodic. :dd
{Cannot use fix deform on a shrink-wrapped boundary} :dt
The x, y, z options cannot be applied to shrink-wrapped
dimensions. :dd
{Cannot use fix deform tilt on a shrink-wrapped 2nd dim} :dt
This is because the shrink-wrapping will change the value
of the strain implied by the tilt factor. :dd
{Cannot use fix deform trate on a box with zero tilt} :dt
The trate style alters the current strain. :dd
{Cannot use fix deposit rigid and not molecule} :dt
Self-explanatory. :dd
{Cannot use fix deposit rigid and shake} :dt
These two attributes are conflicting. :dd
{Cannot use fix deposit shake and not molecule} :dt
Self-explanatory. :dd
{Cannot use fix enforce2d with 3d simulation} :dt
Self-explanatory. :dd
{Cannot use fix gcmc in a 2d simulation} :dt
Fix gcmc is set up to run in 3d only. No 2d simulations with fix gcmc
are allowed. :dd
{Cannot use fix gcmc shake and not molecule} :dt
Self-explanatory. :dd
{Cannot use fix msst without per-type mass defined} :dt
Self-explanatory. :dd
{Cannot use fix npt and fix deform on same component of stress tensor} :dt
This would be changing the same box dimension twice. :dd
{Cannot use fix nvt/npt/nph on a 2nd non-periodic dimension} :dt
When specifying an off-diagonal pressure component, the 2nd of the two
dimensions must be periodic. E.g. if the xy component is specified,
then the y dimension must be periodic. :dd
{Cannot use fix nvt/npt/nph on a non-periodic dimension} :dt
When specifying a diagonal pressure component, the dimension must be
periodic. :dd
{Cannot use fix nvt/npt/nph with both xy dynamics and xy scaling} :dt
Self-explanatory. :dd
{Cannot use fix nvt/npt/nph with both xz dynamics and xz scaling} :dt
Self-explanatory. :dd
{Cannot use fix nvt/npt/nph with both yz dynamics and yz scaling} :dt
Self-explanatory. :dd
{Cannot use fix nvt/npt/nph with xy scaling when y is non-periodic dimension} :dt
The 2nd dimension in the barostatted tilt factor must be periodic. :dd
{Cannot use fix nvt/npt/nph with xz scaling when z is non-periodic dimension} :dt
The 2nd dimension in the barostatted tilt factor must be periodic. :dd
{Cannot use fix nvt/npt/nph with yz scaling when z is non-periodic dimension} :dt
The 2nd dimension in the barostatted tilt factor must be periodic. :dd
{Cannot use fix pour rigid and not molecule} :dt
Self-explanatory. :dd
{Cannot use fix pour rigid and shake} :dt
These two attributes are conflicting. :dd
{Cannot use fix pour shake and not molecule} :dt
Self-explanatory. :dd
{Cannot use fix pour with triclinic box} :dt
This option is not yet supported. :dd
{Cannot use fix press/berendsen and fix deform on same component of stress tensor} :dt
These commands both change the box size/shape, so you cannot use both
together. :dd
{Cannot use fix press/berendsen on a non-periodic dimension} :dt
Self-explanatory. :dd
{Cannot use fix press/berendsen with triclinic box} :dt
Self-explanatory. :dd
{Cannot use fix reax/bonds without pair_style reax} :dt
Self-explanatory. :dd
{Cannot use fix rigid npt/nph and fix deform on same component of stress tensor} :dt
This would be changing the same box dimension twice. :dd
{Cannot use fix rigid npt/nph on a non-periodic dimension} :dt
When specifying a diagonal pressure component, the dimension must be
periodic. :dd
{Cannot use fix rigid/small npt/nph on a non-periodic dimension} :dt
When specifying a diagonal pressure component, the dimension must be
periodic. :dd
{Cannot use fix shake with non-molecular system} :dt
Your choice of atom style does not have bonds. :dd
{Cannot use fix ttm with 2d simulation} :dt
This is a current restriction of this fix due to the grid it creates. :dd
{Cannot use fix ttm with triclinic box} :dt
This is a current restriction of this fix due to the grid it creates. :dd
{Cannot use fix tune/kspace without a kspace style} :dt
Self-explanatory. :dd
{Cannot use fix tune/kspace without a pair style} :dt
This fix (tune/kspace) can only be used when a pair style has been specified. :dd
{Cannot use fix wall in periodic dimension} :dt
Self-explanatory. :dd
{Cannot use fix wall zlo/zhi for a 2d simulation} :dt
Self-explanatory. :dd
{Cannot use fix wall/reflect in periodic dimension} :dt
Self-explanatory. :dd
{Cannot use fix wall/reflect zlo/zhi for a 2d simulation} :dt
Self-explanatory. :dd
{Cannot use fix wall/srd in periodic dimension} :dt
Self-explanatory. :dd
{Cannot use fix wall/srd more than once} :dt
Nor is their a need to since multiple walls can be specified
in one command. :dd
{Cannot use fix wall/srd without fix srd} :dt
Self-explanatory. :dd
{Cannot use fix wall/srd zlo/zhi for a 2d simulation} :dt
Self-explanatory. :dd
{Cannot use fix_deposit unless atoms have IDs} :dt
Self-explanatory. :dd
{Cannot use fix_pour unless atoms have IDs} :dt
Self-explanatory. :dd
{Cannot use include command within an if command} :dt
Self-explanatory. :dd
{Cannot use lines with fix srd unless overlap is set} :dt
This is because line segments are connected to each other. :dd
{Cannot use multiple fix wall commands with pair brownian} :dt
Self-explanatory. :dd
{Cannot use multiple fix wall commands with pair lubricate} :dt
Self-explanatory. :dd
{Cannot use multiple fix wall commands with pair lubricate/poly} :dt
Self-explanatory. :dd
{Cannot use multiple fix wall commands with pair lubricateU} :dt
Self-explanatory. :dd
{Cannot use neigh_modify exclude with GPU neighbor builds} :dt
This is a current limitation of the GPU implementation
in LAMMPS. :dd
{Cannot use neighbor bins - box size << cutoff} :dt
Too many neighbor bins will be created. This typically happens when
the simulation box is very small in some dimension, compared to the
neighbor cutoff. Use the "nsq" style instead of "bin" style. :dd
{Cannot use newton pair with beck/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with born/coul/long/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with born/coul/wolf/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with born/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with buck/coul/cut/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with buck/coul/long/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with buck/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with colloid/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with coul/cut/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with coul/debye/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with coul/dsf/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with coul/long/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with dipole/cut/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with dipole/sf/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with dpd/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with dpd/tstat/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with eam/alloy/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with eam/fs/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with eam/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with gauss/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with gayberne/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with lj/charmm/coul/long/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with lj/class2/coul/long/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with lj/class2/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with lj/cubic/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with lj/cut/coul/cut/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with lj/cut/coul/debye/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with lj/cut/coul/dsf/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with lj/cut/coul/long/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with lj/cut/coul/msm/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with lj/cut/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with lj/expand/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with lj/gromacs/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with lj/sdk/coul/long/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with lj/sdk/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with lj96/cut/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with mie/cut/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with morse/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with resquared/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with soft/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with table/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with yukawa/colloid/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with yukawa/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use newton pair with zbl/gpu pair style} :dt
Self-explanatory. :dd
{Cannot use non-zero forces in an energy minimization} :dt
Fix setforce cannot be used in this manner. Use fix addforce
instead. :dd
{Cannot use nonperiodic boundares with fix ttm} :dt
This fix requires a fully periodic simulation box. :dd
{Cannot use nonperiodic boundaries with Ewald} :dt
For kspace style ewald, all 3 dimensions must have periodic boundaries
unless you use the kspace_modify command to define a 2d slab with a
non-periodic z dimension. :dd
{Cannot use nonperiodic boundaries with EwaldDisp} :dt
For kspace style ewald/disp, all 3 dimensions must have periodic
boundaries unless you use the kspace_modify command to define a 2d
slab with a non-periodic z dimension. :dd
{Cannot use nonperiodic boundaries with PPPM} :dt
For kspace style pppm, all 3 dimensions must have periodic boundaries
unless you use the kspace_modify command to define a 2d slab with a
non-periodic z dimension. :dd
{Cannot use nonperiodic boundaries with PPPMDisp} :dt
For kspace style pppm/disp, all 3 dimensions must have periodic
boundaries unless you use the kspace_modify command to define a 2d
slab with a non-periodic z dimension. :dd
{Cannot use order greater than 8 with pppm/gpu.} :dt
Self-explanatory. :dd
{Cannot use package gpu neigh yes with triclinic box} :dt
This is a current restriction in LAMMPS. :dd
{Cannot use pair hybrid with GPU neighbor list builds} :dt
Neighbor list builds must be done on the CPU for this pair style. :dd
{Cannot use pair tail corrections with 2d simulations} :dt
The correction factors are only currently defined for 3d systems. :dd
{Cannot use processors part command without using partitions} :dt
See the command-line -partition switch. :dd
{Cannot use ramp in variable formula between runs} :dt
This is because the ramp() function is time dependent. :dd
{Cannot use read_data add before simulation box is defined} :dt
Self-explanatory. :dd
{Cannot use read_data extra with add flag} :dt
Self-explanatory. :dd
{Cannot use read_data offset without add flag} :dt
Self-explanatory. :dd
{Cannot use read_data shift without add flag} :dt
Self-explanatory. :dd
{Cannot use region INF or EDGE when box does not exist} :dt
Regions that extend to the box boundaries can only be used after the
create_box command has been used. :dd
{Cannot use set atom with no atom IDs defined} :dt
Atom IDs are not defined, so they cannot be used to identify an atom. :dd
{Cannot use set mol with no molecule IDs defined} :dt
Self-explanatory. :dd
{Cannot use swiggle in variable formula between runs} :dt
This is a function of elapsed time. :dd
{Cannot use tris with fix srd unless overlap is set} :dt
This is because triangles are connected to each other. :dd
{Cannot use variable energy with constant efield in fix efield} :dt
LAMMPS computes the energy itself when the E-field is constant. :dd
{Cannot use variable energy with constant force in fix addforce} :dt
This is because for constant force, LAMMPS can compute the change
in energy directly. :dd
{Cannot use variable every setting for dump dcd} :dt
The format of DCD dump files requires snapshots be output
at a constant frequency. :dd
{Cannot use variable every setting for dump xtc} :dt
The format of this file requires snapshots at regular intervals. :dd
{Cannot use vdisplace in variable formula between runs} :dt
This is a function of elapsed time. :dd
{Cannot use velocity bias command without temp keyword} :dt
Self-explanatory. :dd
{Cannot use velocity create loop all unless atoms have IDs} :dt
Atoms in the simulation to do not have IDs, so this style
of velocity creation cannot be performed. :dd
{Cannot use wall in periodic dimension} :dt
Self-explanatory. :dd
{Cannot use write_restart fileper without % in restart file name} :dt
Self-explanatory. :dd
{Cannot use write_restart nfile without % in restart file name} :dt
Self-explanatory. :dd
{Cannot wiggle and shear fix wall/gran} :dt
Cannot specify both options at the same time. :dd
{Cannot write to restart file - MPI error: %s} :dt
This error was generated by MPI when reading/writing an MPI-IO restart
file. :dd
{Cannot yet use KSpace solver with grid with comm style tiled} :dt
This is current restriction in LAMMPS. :dd
{Cannot yet use comm_style tiled with multi-mode comm} :dt
Self-explanatory. :dd
{Cannot yet use comm_style tiled with triclinic box} :dt
Self-explanatory. :dd
{Cannot yet use compute tally with Kokkos} :dt
This feature is not yet supported. :dd
{Cannot yet use fix bond/break with this improper style} :dt
This is a current restriction in LAMMPS. :dd
{Cannot yet use fix bond/create with this improper style} :dt
This is a current restriction in LAMMPS. :dd
{Cannot yet use minimize with Kokkos} :dt
This feature is not yet supported. :dd
{Cannot yet use pair hybrid with Kokkos} :dt
This feature is not yet supported. :dd
{Cannot zero Langevin force of 0 atoms} :dt
The group has zero atoms, so you cannot request its force
be zeroed. :dd
{Cannot zero gld force for zero atoms} :dt
There are no atoms currently in the group. :dd
{Cannot zero momentum of no atoms} :dt
Self-explanatory. :dd
{Change_box command before simulation box is defined} :dt
Self-explanatory. :dd
{Change_box volume used incorrectly} :dt
The "dim volume" option must be used immediately following one or two
settings for "dim1 ..." (and optionally "dim2 ...") and must be for a
different dimension, i.e. dim != dim1 and dim != dim2. :dd
{Chunk/atom compute does not exist for compute angmom/chunk} :dt
Self-explanatory. :dd
{Chunk/atom compute does not exist for compute com/chunk} :dt
Self-explanatory. :dd
{Chunk/atom compute does not exist for compute gyration/chunk} :dt
Self-explanatory. :dd
{Chunk/atom compute does not exist for compute inertia/chunk} :dt
Self-explanatory. :dd
{Chunk/atom compute does not exist for compute msd/chunk} :dt
Self-explanatory. :dd
{Chunk/atom compute does not exist for compute omega/chunk} :dt
Self-explanatory. :dd
{Chunk/atom compute does not exist for compute property/chunk} :dt
Self-explanatory. :dd
{Chunk/atom compute does not exist for compute temp/chunk} :dt
Self-explanatory. :dd
{Chunk/atom compute does not exist for compute torque/chunk} :dt
Self-explanatory. :dd
{Chunk/atom compute does not exist for compute vcm/chunk} :dt
Self-explanatory. :dd
{Chunk/atom compute does not exist for fix ave/chunk} :dt
Self-explanatory. :dd
{Comm tiled invalid index in box drop brick} :dt
Internal error check in comm_style tiled which should not occur.
Contact the developers. :dd
{Comm tiled mis-match in box drop brick} :dt
Internal error check in comm_style tiled which should not occur.
Contact the developers. :dd
{Comm_modify group != atom_modify first group} :dt
Self-explanatory. :dd
{Communication cutoff for comm_style tiled cannot exceed periodic box length} :dt
Self-explanatory. :dd
{Communication cutoff too small for SNAP micro load balancing} :dt
This can happen if you change the neighbor skin after your pair_style
command or if your box dimensions grow during a run. You can set the
cutoff explicitly via the comm_modify cutoff command. :dd
{Compute %s does not allow use of dynamic group} :dt
Dynamic groups have not yet been enabled for this compute. :dd
{Compute ID for compute chunk /atom does not exist} :dt
Self-explanatory. :dd
{Compute ID for compute chunk/atom does not exist} :dt
Self-explanatory. :dd
{Compute ID for compute reduce does not exist} :dt
Self-explanatory. :dd
{Compute ID for compute slice does not exist} :dt
Self-explanatory. :dd
{Compute ID for fix ave/atom does not exist} :dt
Self-explanatory. :dd
{Compute ID for fix ave/chunk does not exist} :dt
Self-explanatory. :dd
{Compute ID for fix ave/correlate does not exist} :dt
Self-explanatory. :dd
{Compute ID for fix ave/histo does not exist} :dt
Self-explanatory. :dd
{Compute ID for fix ave/spatial does not exist} :dt
Self-explanatory. :dd
{Compute ID for fix ave/time does not exist} :dt
Self-explanatory. :dd
{Compute ID for fix store/state does not exist} :dt
Self-explanatory. :dd
{Compute ID for fix vector does not exist} :dt
Self-explanatory. :dd
{Compute ID must be alphanumeric or underscore characters} :dt
Self-explanatory. :dd
{Compute angle/local used when angles are not allowed} :dt
The atom style does not support angles. :dd
{Compute angmom/chunk does not use chunk/atom compute} :dt
The style of the specified compute is not chunk/atom. :dd
{Compute body/local requires atom style body} :dt
Self-explanatory. :dd
{Compute bond/local used when bonds are not allowed} :dt
The atom style does not support bonds. :dd
{Compute centro/atom requires a pair style be defined} :dt
This is because the computation of the centro-symmetry values
uses a pairwise neighbor list. :dd
{Compute chunk/atom bin/cylinder radius is too large for periodic box} :dt
Radius cannot be bigger than 1/2 of a non-axis periodic dimension. :dd
{Compute chunk/atom bin/sphere radius is too large for periodic box} :dt
Radius cannot be bigger than 1/2 of any periodic dimension. :dd
{Compute chunk/atom compute array is accessed out-of-range} :dt
The index for the array is out of bounds. :dd
{Compute chunk/atom compute does not calculate a per-atom array} :dt
Self-explanatory. :dd
{Compute chunk/atom compute does not calculate a per-atom vector} :dt
Self-explanatory. :dd
{Compute chunk/atom compute does not calculate per-atom values} :dt
Self-explanatory. :dd
{Compute chunk/atom cylinder axis must be z for 2d} :dt
Self-explanatory. :dd
{Compute chunk/atom fix array is accessed out-of-range} :dt
the index for the array is out of bounds. :dd
{Compute chunk/atom fix does not calculate a per-atom array} :dt
Self-explanatory. :dd
{Compute chunk/atom fix does not calculate a per-atom vector} :dt
Self-explanatory. :dd
{Compute chunk/atom fix does not calculate per-atom values} :dt
Self-explanatory. :dd
{Compute chunk/atom for triclinic boxes requires units reduced} :dt
Self-explanatory. :dd
{Compute chunk/atom ids once but nchunk is not once} :dt
You cannot assign chunks IDs to atom permanently if the number of
chunks may change. :dd
{Compute chunk/atom molecule for non-molecular system} :dt
Self-explanatory. :dd
{Compute chunk/atom sphere z origin must be 0.0 for 2d} :dt
Self-explanatory. :dd
{Compute chunk/atom stores no IDs for compute property/chunk} :dt
It will only store IDs if its compress option is enabled. :dd
{Compute chunk/atom stores no coord1 for compute property/chunk} :dt
Only certain binning options for compute chunk/atom store coordinates. :dd
{Compute chunk/atom stores no coord2 for compute property/chunk} :dt
Only certain binning options for compute chunk/atom store coordinates. :dd
{Compute chunk/atom stores no coord3 for compute property/chunk} :dt
Only certain binning options for compute chunk/atom store coordinates. :dd
{Compute chunk/atom variable is not atom-style variable} :dt
Self-explanatory. :dd
{Compute chunk/atom without bins cannot use discard mixed} :dt
That discard option only applies to the binning styles. :dd
{Compute cluster/atom cutoff is longer than pairwise cutoff} :dt
Cannot identify clusters beyond cutoff. :dd
{Compute cluster/atom requires a pair style be defined} :dt
This is so that the pair style defines a cutoff distance which
is used to find clusters. :dd
{Compute cna/atom cutoff is longer than pairwise cutoff} :dt
Self-explanatory. :dd
{Compute cna/atom requires a pair style be defined} :dt
Self-explanatory. :dd
{Compute com/chunk does not use chunk/atom compute} :dt
The style of the specified compute is not chunk/atom. :dd
{Compute contact/atom requires a pair style be defined} :dt
Self-explanatory. :dd
{Compute contact/atom requires atom style sphere} :dt
Self-explanatory. :dd
{Compute coord/atom cutoff is longer than pairwise cutoff} :dt
Cannot compute coordination at distances longer than the pair cutoff,
since those atoms are not in the neighbor list. :dd
{Compute coord/atom requires a pair style be defined} :dt
Self-explanatory. :dd
{Compute damage/atom requires peridynamic potential} :dt
Damage is a Peridynamic-specific metric. It requires you
to be running a Peridynamics simulation. :dd
{Compute dihedral/local used when dihedrals are not allowed} :dt
The atom style does not support dihedrals. :dd
{Compute dilatation/atom cannot be used with this pair style} :dt
Self-explanatory. :dd
{Compute dilatation/atom requires Peridynamic pair style} :dt
Self-explanatory. :dd
{Compute does not allow an extra compute or fix to be reset} :dt
This is an internal LAMMPS error. Please report it to the
developers. :dd
{Compute erotate/asphere requires atom style ellipsoid or line or tri} :dt
Self-explanatory. :dd
{Compute erotate/asphere requires extended particles} :dt
This compute cannot be used with point particles. :dd
{Compute erotate/rigid with non-rigid fix-ID} :dt
Self-explanatory. :dd
{Compute erotate/sphere requires atom style sphere} :dt
Self-explanatory. :dd
{Compute erotate/sphere/atom requires atom style sphere} :dt
Self-explanatory. :dd
{Compute event/displace has invalid fix event assigned} :dt
This is an internal LAMMPS error. Please report it to the
developers. :dd
{Compute group/group group ID does not exist} :dt
Self-explanatory. :dd
{Compute gyration/chunk does not use chunk/atom compute} :dt
The style of the specified compute is not chunk/atom. :dd
{Compute heat/flux compute ID does not compute ke/atom} :dt
Self-explanatory. :dd
{Compute heat/flux compute ID does not compute pe/atom} :dt
Self-explanatory. :dd
{Compute heat/flux compute ID does not compute stress/atom} :dt
Self-explanatory. :dd
{Compute hexorder/atom cutoff is longer than pairwise cutoff} :dt
Cannot compute order parameter beyond cutoff. :dd
{Compute hexorder/atom requires a pair style be defined} :dt
Self-explanatory. :dd
{Compute improper/local used when impropers are not allowed} :dt
The atom style does not support impropers. :dd
{Compute inertia/chunk does not use chunk/atom compute} :dt
The style of the specified compute is not chunk/atom. :dd
{Compute ke/rigid with non-rigid fix-ID} :dt
Self-explanatory. :dd
{Compute msd/chunk does not use chunk/atom compute} :dt
The style of the specified compute is not chunk/atom. :dd
{Compute msd/chunk nchunk is not static} :dt
This is required because the MSD cannot be computed consistently if
the number of chunks is changing. Compute chunk/atom allows setting
nchunk to be static. :dd
{Compute nve/asphere requires atom style ellipsoid} :dt
Self-explanatory. :dd
{Compute nvt/nph/npt asphere requires atom style ellipsoid} :dt
Self-explanatory. :dd
{Compute nvt/nph/npt body requires atom style body} :dt
Self-explanatory. :dd
{Compute omega/chunk does not use chunk/atom compute} :dt
The style of the specified compute is not chunk/atom. :dd
{Compute orientorder/atom cutoff is longer than pairwise cutoff} :dt
Cannot compute order parameter beyond cutoff. :dd
{Compute orientorder/atom requires a pair style be defined} :dt
Self-explanatory. :dd
{Compute pair must use group all} :dt
Pair styles accumulate energy on all atoms. :dd
{Compute pe must use group all} :dt
Energies computed by potentials (pair, bond, etc) are computed on all
atoms. :dd
{Compute plasticity/atom cannot be used with this pair style} :dt
Self-explanatory. :dd
{Compute plasticity/atom requires Peridynamic pair style} :dt
Self-explanatory. :dd
{Compute pressure must use group all} :dt
Virial contributions computed by potentials (pair, bond, etc) are
computed on all atoms. :dd
{Compute pressure requires temperature ID to include kinetic energy} :dt
The keflag cannot be used unless a temperature compute is provided. :dd
{Compute pressure temperature ID does not compute temperature} :dt
The compute ID assigned to a pressure computation must compute
temperature. :dd
{Compute property/atom floating point vector does not exist} :dt
The command is accessing a vector added by the fix property/atom
command, that does not exist. :dd
{Compute property/atom for atom property that isn't allocated} :dt
Self-explanatory. :dd
{Compute property/atom integer vector does not exist} :dt
The command is accessing a vector added by the fix property/atom
command, that does not exist. :dd
{Compute property/chunk does not use chunk/atom compute} :dt
The style of the specified compute is not chunk/atom. :dd
{Compute property/local cannot use these inputs together} :dt
Only inputs that generate the same number of datums can be used
together. E.g. bond and angle quantities cannot be mixed. :dd
{Compute property/local does not (yet) work with atom_style template} :dt
Self-explanatory. :dd
{Compute property/local for property that isn't allocated} :dt
Self-explanatory. :dd
{Compute rdf requires a pair style be defined} :dt
Self-explanatory. :dd
{Compute reduce compute array is accessed out-of-range} :dt
An index for the array is out of bounds. :dd
{Compute reduce compute calculates global values} :dt
A compute that calculates peratom or local values is required. :dd
{Compute reduce compute does not calculate a local array} :dt
Self-explanatory. :dd
{Compute reduce compute does not calculate a local vector} :dt
Self-explanatory. :dd
{Compute reduce compute does not calculate a per-atom array} :dt
Self-explanatory. :dd
{Compute reduce compute does not calculate a per-atom vector} :dt
Self-explanatory. :dd
{Compute reduce fix array is accessed out-of-range} :dt
An index for the array is out of bounds. :dd
{Compute reduce fix calculates global values} :dt
A fix that calculates peratom or local values is required. :dd
{Compute reduce fix does not calculate a local array} :dt
Self-explanatory. :dd
{Compute reduce fix does not calculate a local vector} :dt
Self-explanatory. :dd
{Compute reduce fix does not calculate a per-atom array} :dt
Self-explanatory. :dd
{Compute reduce fix does not calculate a per-atom vector} :dt
Self-explanatory. :dd
{Compute reduce replace requires min or max mode} :dt
Self-explanatory. :dd
{Compute reduce variable is not atom-style variable} :dt
Self-explanatory. :dd
{Compute slice compute array is accessed out-of-range} :dt
An index for the array is out of bounds. :dd
{Compute slice compute does not calculate a global array} :dt
Self-explanatory. :dd
{Compute slice compute does not calculate a global vector} :dt
Self-explanatory. :dd
{Compute slice compute does not calculate global vector or array} :dt
Self-explanatory. :dd
{Compute slice compute vector is accessed out-of-range} :dt
The index for the vector is out of bounds. :dd
{Compute slice fix array is accessed out-of-range} :dt
An index for the array is out of bounds. :dd
{Compute slice fix does not calculate a global array} :dt
Self-explanatory. :dd
{Compute slice fix does not calculate a global vector} :dt
Self-explanatory. :dd
{Compute slice fix does not calculate global vector or array} :dt
Self-explanatory. :dd
{Compute slice fix vector is accessed out-of-range} :dt
The index for the vector is out of bounds. :dd
{Compute sna/atom cutoff is longer than pairwise cutoff} :dt
Self-explanatory. :dd
{Compute sna/atom requires a pair style be defined} :dt
Self-explanatory. :dd
{Compute snad/atom cutoff is longer than pairwise cutoff} :dt
Self-explanatory. :dd
{Compute snad/atom requires a pair style be defined} :dt
Self-explanatory. :dd
{Compute snav/atom cutoff is longer than pairwise cutoff} :dt
Self-explanatory. :dd
{Compute snav/atom requires a pair style be defined} :dt
Self-explanatory. :dd
{Compute stress/atom temperature ID does not compute temperature} :dt
The specified compute must compute temperature. :dd
{Compute temp/asphere requires atom style ellipsoid} :dt
Self-explanatory. :dd
{Compute temp/asphere requires extended particles} :dt
This compute cannot be used with point particles. :dd
{Compute temp/body requires atom style body} :dt
Self-explanatory. :dd
{Compute temp/body requires bodies} :dt
This compute can only be applied to body particles. :dd
{Compute temp/chunk does not use chunk/atom compute} :dt
The style of the specified compute is not chunk/atom. :dd
{Compute temp/cs requires ghost atoms store velocity} :dt
Use the comm_modify vel yes command to enable this. :dd
{Compute temp/cs used when bonds are not allowed} :dt
This compute only works on pairs of bonded particles. :dd
{Compute temp/partial cannot use vz for 2d systemx} :dt
Self-explanatory. :dd
{Compute temp/profile cannot bin z for 2d systems} :dt
Self-explanatory. :dd
{Compute temp/profile cannot use vz for 2d systemx} :dt
Self-explanatory. :dd
{Compute temp/sphere requires atom style sphere} :dt
Self-explanatory. :dd
{Compute ti kspace style does not exist} :dt
Self-explanatory. :dd
{Compute ti pair style does not exist} :dt
Self-explanatory. :dd
{Compute ti tail when pair style does not compute tail corrections} :dt
Self-explanatory. :dd
{Compute torque/chunk does not use chunk/atom compute} :dt
The style of the specified compute is not chunk/atom. :dd
{Compute used in dump between runs is not current} :dt
The compute was not invoked on the current timestep, therefore it
cannot be used in a dump between runs. :dd
{Compute used in variable between runs is not current} :dt
Computes cannot be invoked by a variable in between runs. Thus they
must have been evaluated on the last timestep of the previous run in
order for their value(s) to be accessed. See the doc page for the
variable command for more info. :dd
{Compute used in variable thermo keyword between runs is not current} :dt
Some thermo keywords rely on a compute to calculate their value(s).
Computes cannot be invoked by a variable in between runs. Thus they
must have been evaluated on the last timestep of the previous run in
order for their value(s) to be accessed. See the doc page for the
variable command for more info. :dd
{Compute vcm/chunk does not use chunk/atom compute} :dt
The style of the specified compute is not chunk/atom. :dd
{Computed temperature for fix temp/berendsen cannot be 0.0} :dt
Self-explanatory. :dd
{Computed temperature for fix temp/rescale cannot be 0.0} :dt
Cannot rescale the temperature to a new value if the current
temperature is 0.0. :dd
{Core/shell partner atom not found} :dt
Could not find one of the atoms in the bond pair. :dd
{Core/shell partners were not all found} :dt
Could not find or more atoms in the bond pairs. :dd
{Could not adjust g_ewald_6} :dt
The Newton-Raphson solver failed to converge to a good value for
g_ewald. This error should not occur for typical problems. Please
send an email to the developers. :dd
{Could not compute g_ewald} :dt
The Newton-Raphson solver failed to converge to a good value for
g_ewald. This error should not occur for typical problems. Please
send an email to the developers. :dd
{Could not compute grid size} :dt
The code is unable to compute a grid size consistent with the desired
accuracy. This error should not occur for typical problems. Please
send an email to the developers. :dd
{Could not compute grid size for Coulomb interaction} :dt
The code is unable to compute a grid size consistent with the desired
accuracy. This error should not occur for typical problems. Please
send an email to the developers. :dd
{Could not compute grid size for Dispersion} :dt
The code is unable to compute a grid size consistent with the desired
accuracy. This error should not occur for typical problems. Please
send an email to the developers. :dd
{Could not create 3d FFT plan} :dt
The FFT setup for the PPPM solver failed, typically due
to lack of memory. This is an unusual error. Check the
size of the FFT grid you are requesting. :dd
{Could not create 3d grid of processors} :dt
The specified constraints did not allow a Px by Py by Pz grid to be
created where Px * Py * Pz = P = total number of processors. :dd
{Could not create 3d remap plan} :dt
The FFT setup in pppm failed. :dd
{Could not create Python function arguments} :dt
This is an internal Python error, possibly because the number
of inputs to the function is too large. :dd
{Could not create numa grid of processors} :dt
The specified constraints did not allow this style of grid to be
created. Usually this is because the total processor count is not a
multiple of the cores/node or the user specified processor count is >
1 in one of the dimensions. :dd
{Could not create twolevel 3d grid of processors} :dt
The specified constraints did not allow this style of grid to be
created. :dd
{Could not evaluate Python function input variable} :dt
Self-explanatory. :dd
{Could not find Python function} :dt
The provided Python code was run successfully, but it not
define a callable function with the required name. :dd
{Could not find atom_modify first group ID} :dt
Self-explanatory. :dd
{Could not find change_box group ID} :dt
Group ID used in the change_box command does not exist. :dd
{Could not find compute ID for PRD} :dt
Self-explanatory. :dd
{Could not find compute ID for TAD} :dt
Self-explanatory. :dd
{Could not find compute ID for temperature bias} :dt
Self-explanatory. :dd
{Could not find compute ID to delete} :dt
Self-explanatory. :dd
{Could not find compute displace/atom fix ID} :dt
Self-explanatory. :dd
{Could not find compute event/displace fix ID} :dt
Self-explanatory. :dd
{Could not find compute group ID} :dt
Self-explanatory. :dd
{Could not find compute heat/flux compute ID} :dt
Self-explanatory. :dd
{Could not find compute msd fix ID} :dt
Self-explanatory. :dd
{Could not find compute msd/chunk fix ID} :dt
The compute creates an internal fix, which has been deleted. :dd
{Could not find compute pressure temperature ID} :dt
The compute ID for calculating temperature does not exist. :dd
{Could not find compute stress/atom temperature ID} :dt
Self-explanatory. :dd
{Could not find compute vacf fix ID} :dt
Self-explanatory. :dd
{Could not find compute/voronoi surface group ID} :dt
Self-explanatory. :dd
{Could not find compute_modify ID} :dt
Self-explanatory. :dd
{Could not find custom per-atom property ID} :dt
Self-explanatory. :dd
{Could not find delete_atoms group ID} :dt
Group ID used in the delete_atoms command does not exist. :dd
{Could not find delete_atoms region ID} :dt
Region ID used in the delete_atoms command does not exist. :dd
{Could not find displace_atoms group ID} :dt
Group ID used in the displace_atoms command does not exist. :dd
{Could not find dump custom compute ID} :dt
Self-explanatory. :dd
{Could not find dump custom fix ID} :dt
Self-explanatory. :dd
{Could not find dump custom variable name} :dt
Self-explanatory. :dd
{Could not find dump group ID} :dt
A group ID used in the dump command does not exist. :dd
{Could not find dump local compute ID} :dt
Self-explanatory. :dd
{Could not find dump local fix ID} :dt
Self-explanatory. :dd
{Could not find dump modify compute ID} :dt
Self-explanatory. :dd
{Could not find dump modify custom atom floating point property ID} :dt
Self-explanatory. :dd
{Could not find dump modify custom atom integer property ID} :dt
Self-explanatory. :dd
{Could not find dump modify fix ID} :dt
Self-explanatory. :dd
{Could not find dump modify variable name} :dt
Self-explanatory. :dd
{Could not find fix ID to delete} :dt
Self-explanatory. :dd
{Could not find fix adapt storage fix ID} :dt
This should not happen unless you explicitly deleted
a secondary fix that fix adapt created internally. :dd
{Could not find fix gcmc exclusion group ID} :dt
Self-explanatory. :dd
{Could not find fix gcmc rotation group ID} :dt
Self-explanatory. :dd
{Could not find fix group ID} :dt
A group ID used in the fix command does not exist. :dd
{Could not find fix msst compute ID} :dt
Self-explanatory. :dd
{Could not find fix poems group ID} :dt
A group ID used in the fix poems command does not exist. :dd
{Could not find fix recenter group ID} :dt
A group ID used in the fix recenter command does not exist. :dd
{Could not find fix rigid group ID} :dt
A group ID used in the fix rigid command does not exist. :dd
{Could not find fix srd group ID} :dt
Self-explanatory. :dd
{Could not find fix_modify ID} :dt
A fix ID used in the fix_modify command does not exist. :dd
{Could not find fix_modify pressure ID} :dt
The compute ID for computing pressure does not exist. :dd
{Could not find fix_modify temperature ID} :dt
The compute ID for computing temperature does not exist. :dd
{Could not find group clear group ID} :dt
Self-explanatory. :dd
{Could not find group delete group ID} :dt
Self-explanatory. :dd
{Could not find pair fix ID} :dt
A fix is created internally by the pair style to store shear
history information. You cannot delete it. :dd
{Could not find set group ID} :dt
Group ID specified in set command does not exist. :dd
{Could not find specified fix gcmc group ID} :dt
Self-explanatory. :dd
{Could not find thermo compute ID} :dt
Compute ID specified in thermo_style command does not exist. :dd
{Could not find thermo custom compute ID} :dt
The compute ID needed by thermo style custom to compute a requested
quantity does not exist. :dd
{Could not find thermo custom fix ID} :dt
The fix ID needed by thermo style custom to compute a requested
quantity does not exist. :dd
{Could not find thermo custom variable name} :dt
Self-explanatory. :dd
{Could not find thermo fix ID} :dt
Fix ID specified in thermo_style command does not exist. :dd
{Could not find thermo variable name} :dt
Self-explanatory. :dd
{Could not find thermo_modify pressure ID} :dt
The compute ID needed by thermo style custom to compute pressure does
not exist. :dd
{Could not find thermo_modify temperature ID} :dt
The compute ID needed by thermo style custom to compute temperature does
not exist. :dd
{Could not find undump ID} :dt
A dump ID used in the undump command does not exist. :dd
{Could not find velocity group ID} :dt
A group ID used in the velocity command does not exist. :dd
{Could not find velocity temperature ID} :dt
The compute ID needed by the velocity command to compute temperature
does not exist. :dd
{Could not find/initialize a specified accelerator device} :dt
Could not initialize at least one of the devices specified for the gpu
package :dd
{Could not grab element entry from EIM potential file} :dt
Self-explanatory :dd
{Could not grab global entry from EIM potential file} :dt
Self-explanatory. :dd
{Could not grab pair entry from EIM potential file} :dt
Self-explanatory. :dd
{Could not initialize embedded Python} :dt
The main module in Python was not accessible. :dd
{Could not open Python file} :dt
The specified file of Python code cannot be opened. Check that the
path and name are correct. :dd
{Could not process Python file} :dt
The Python code in the specified file was not run successfully by
Python, probably due to errors in the Python code. :dd
{Could not process Python string} :dt
The Python code in the here string was not run successfully by Python,
probably due to errors in the Python code. :dd
{Coulomb PPPMDisp order has been reduced below minorder} :dt
The default minimum order is 2. This can be reset by the
kspace_modify minorder command. :dd
{Coulomb cut not supported in pair_style buck/long/coul/coul} :dt
Must use long-range Coulombic interactions. :dd
{Coulomb cut not supported in pair_style lj/long/coul/long} :dt
Must use long-range Coulombic interactions. :dd
{Coulomb cut not supported in pair_style lj/long/tip4p/long} :dt
Must use long-range Coulombic interactions. :dd
{Coulomb cutoffs of pair hybrid sub-styles do not match} :dt
If using a Kspace solver, all Coulomb cutoffs of long pair styles must
be the same. :dd
{Coulombic cut not supported in pair_style lj/long/dipole/long} :dt
Must use long-range Coulombic interactions. :dd
{Cound not find dump_modify ID} :dt
Self-explanatory. :dd
{Create_atoms command before simulation box is defined} :dt
The create_atoms command cannot be used before a read_data,
read_restart, or create_box command. :dd
{Create_atoms molecule has atom IDs, but system does not} :dt
The atom_style id command can be used to force atom IDs to be stored. :dd
{Create_atoms molecule must have atom types} :dt
The defined molecule does not specify atom types. :dd
{Create_atoms molecule must have coordinates} :dt
The defined molecule does not specify coordinates. :dd
{Create_atoms region ID does not exist} :dt
A region ID used in the create_atoms command does not exist. :dd
{Create_bonds command before simulation box is defined} :dt
Self-explanatory. :dd
{Create_bonds command requires no kspace_style be defined} :dt
This is so that atom pairs that are already bonded to not appear
in the neighbor list. :dd
{Create_bonds command requires special_bonds 1-2 weights be 0.0} :dt
This is so that atom pairs that are already bonded to not appear in
the neighbor list. :dd
{Create_bonds max distance > neighbor cutoff} :dt
Can only create bonds for atom pairs that will be in neighbor list. :dd
{Create_bonds requires a pair style be defined} :dt
Self-explanatory. :dd
{Create_box region ID does not exist} :dt
Self-explanatory. :dd
{Create_box region does not support a bounding box} :dt
Not all regions represent bounded volumes. You cannot use
such a region with the create_box command. :dd
{Custom floating point vector for fix store/state does not exist} :dt
The command is accessing a vector added by the fix property/atom
command, that does not exist. :dd
{Custom integer vector for fix store/state does not exist} :dt
The command is accessing a vector added by the fix property/atom
command, that does not exist. :dd
{Custom per-atom property ID is not floating point} :dt
Self-explanatory. :dd
{Custom per-atom property ID is not integer} :dt
Self-explanatory. :dd
{Cut-offs missing in pair_style lj/long/dipole/long} :dt
Self-explanatory. :dd
{Cutoffs missing in pair_style buck/long/coul/long} :dt
Self-explanatory. :dd
{Cutoffs missing in pair_style lj/long/coul/long} :dt
Self-explanatory. :dd
{Cyclic loop in joint connections} :dt
Fix poems cannot (yet) work with coupled bodies whose joints connect
the bodies in a ring (or cycle). :dd
{Degenerate lattice primitive vectors} :dt
Invalid set of 3 lattice vectors for lattice command. :dd
{Delete region ID does not exist} :dt
Self-explanatory. :dd
{Delete_atoms command before simulation box is defined} :dt
The delete_atoms command cannot be used before a read_data,
read_restart, or create_box command. :dd
{Delete_atoms cutoff > max neighbor cutoff} :dt
Can only delete atoms in atom pairs that will be in neighbor list. :dd
{Delete_atoms mol yes requires atom attribute molecule} :dt
Cannot use this option with a non-molecular system. :dd
{Delete_atoms requires a pair style be defined} :dt
This is because atom deletion within a cutoff uses a pairwise
neighbor list. :dd
{Delete_bonds command before simulation box is defined} :dt
The delete_bonds command cannot be used before a read_data,
read_restart, or create_box command. :dd
{Delete_bonds command with no atoms existing} :dt
No atoms are yet defined so the delete_bonds command cannot be used. :dd
{Deposition region extends outside simulation box} :dt
Self-explanatory. :dd
{Did not assign all atoms correctly} :dt
Atoms read in from a data file were not assigned correctly to
processors. This is likely due to some atom coordinates being
outside a non-periodic simulation box. :dd
{Did not assign all restart atoms correctly} :dt
Atoms read in from the restart file were not assigned correctly to
processors. This is likely due to some atom coordinates being outside
a non-periodic simulation box. Normally this should not happen. You
may wish to use the "remap" option on the read_restart command to see
if this helps. :dd
{Did not find all elements in MEAM library file} :dt
The requested elements were not found in the MEAM file. :dd
{Did not find fix shake partner info} :dt
Could not find bond partners implied by fix shake command. This error
can be triggered if the delete_bonds command was used before fix
shake, and it removed bonds without resetting the 1-2, 1-3, 1-4
weighting list via the special keyword. :dd
{Did not find keyword in table file} :dt
Keyword used in pair_coeff command was not found in table file. :dd
{Did not set pressure for fix rigid/nph} :dt
The press keyword must be specified. :dd
{Did not set temp for fix rigid/nvt/small} :dt
Self-explanatory. :dd
{Did not set temp or press for fix rigid/npt/small} :dt
Self-explanatory. :dd
{Did not set temperature for fix rigid/nvt} :dt
The temp keyword must be specified. :dd
{Did not set temperature or pressure for fix rigid/npt} :dt
The temp and press keywords must be specified. :dd
{Dihedral atom missing in delete_bonds} :dt
The delete_bonds command cannot find one or more atoms in a particular
dihedral on a particular processor. The pairwise cutoff is too short
or the atoms are too far apart to make a valid dihedral. :dd
{Dihedral atom missing in set command} :dt
The set command cannot find one or more atoms in a particular dihedral
on a particular processor. The pairwise cutoff is too short or the
atoms are too far apart to make a valid dihedral. :dd
{Dihedral atoms %d %d %d %d missing on proc %d at step %ld} :dt
One or more of 4 atoms needed to compute a particular dihedral are
missing on this processor. Typically this is because the pairwise
cutoff is set too short or the dihedral has blown apart and an atom is
too far away. :dd
{Dihedral atoms missing on proc %d at step %ld} :dt
One or more of 4 atoms needed to compute a particular dihedral are
missing on this processor. Typically this is because the pairwise
cutoff is set too short or the dihedral has blown apart and an atom is
too far away. :dd
{Dihedral charmm is incompatible with Pair style} :dt
Dihedral style charmm must be used with a pair style charmm
in order for the 1-4 epsilon/sigma parameters to be defined. :dd
{Dihedral coeff for hybrid has invalid style} :dt
Dihedral style hybrid uses another dihedral style as one of its
coefficients. The dihedral style used in the dihedral_coeff command
or read from a restart file is not recognized. :dd
{Dihedral coeffs are not set} :dt
No dihedral coefficients have been assigned in the data file or via
the dihedral_coeff command. :dd
{Dihedral style hybrid cannot have hybrid as an argument} :dt
Self-explanatory. :dd
{Dihedral style hybrid cannot have none as an argument} :dt
Self-explanatory. :dd
{Dihedral style hybrid cannot use same dihedral style twice} :dt
Self-explanatory. :dd
{Dihedral/improper extent > half of periodic box length} :dt
This error was detected by the neigh_modify check yes setting. It is
an error because the dihedral atoms are so far apart it is ambiguous
how it should be defined. :dd
{Dihedral_coeff command before dihedral_style is defined} :dt
Coefficients cannot be set in the data file or via the dihedral_coeff
command until an dihedral_style has been assigned. :dd
{Dihedral_coeff command before simulation box is defined} :dt
The dihedral_coeff command cannot be used before a read_data,
read_restart, or create_box command. :dd
{Dihedral_coeff command when no dihedrals allowed} :dt
The chosen atom style does not allow for dihedrals to be defined. :dd
{Dihedral_style command when no dihedrals allowed} :dt
The chosen atom style does not allow for dihedrals to be defined. :dd
{Dihedrals assigned incorrectly} :dt
Dihedrals read in from the data file were not assigned correctly to
atoms. This means there is something invalid about the topology
definitions. :dd
{Dihedrals defined but no dihedral types} :dt
The data file header lists dihedrals but no dihedral types. :dd
{Dimension command after simulation box is defined} :dt
The dimension command cannot be used after a read_data,
read_restart, or create_box command. :dd
{Dispersion PPPMDisp order has been reduced below minorder} :dt
The default minimum order is 2. This can be reset by the
kspace_modify minorder command. :dd
{Displace_atoms command before simulation box is defined} :dt
The displace_atoms command cannot be used before a read_data,
read_restart, or create_box command. :dd
{Distance must be > 0 for compute event/displace} :dt
Self-explanatory. :dd
{Divide by 0 in influence function} :dt
This should not normally occur. It is likely a problem with your
model. :dd
{Divide by 0 in influence function of pair peri/lps} :dt
This should not normally occur. It is likely a problem with your
model. :dd
{Divide by 0 in variable formula} :dt
Self-explanatory. :dd
{Domain too large for neighbor bins} :dt
The domain has become extremely large so that neighbor bins cannot be
used. Most likely, one or more atoms have been blown out of the
simulation box to a great distance. :dd
{Double precision is not supported on this accelerator} :dt
Self-explanatory :dd
{Dump atom/gz only writes compressed files} :dt
The dump atom/gz output file name must have a .gz suffix. :dd
{Dump cfg arguments can not mix xs|ys|zs with xsu|ysu|zsu} :dt
Self-explanatory. :dd
{Dump cfg arguments must start with 'mass type xs ys zs' or 'mass type xsu ysu zsu'} :dt
This is a requirement of the CFG output format. See the dump cfg doc
page for more details. :dd
{Dump cfg requires one snapshot per file} :dt
Use the wildcard "*" character in the filename. :dd
{Dump cfg/gz only writes compressed files} :dt
The dump cfg/gz output file name must have a .gz suffix. :dd
{Dump custom and fix not computed at compatible times} :dt
The fix must produce per-atom quantities on timesteps that dump custom
needs them. :dd
{Dump custom compute does not calculate per-atom array} :dt
Self-explanatory. :dd
{Dump custom compute does not calculate per-atom vector} :dt
Self-explanatory. :dd
{Dump custom compute does not compute per-atom info} :dt
Self-explanatory. :dd
{Dump custom compute vector is accessed out-of-range} :dt
Self-explanatory. :dd
{Dump custom fix does not compute per-atom array} :dt
Self-explanatory. :dd
{Dump custom fix does not compute per-atom info} :dt
Self-explanatory. :dd
{Dump custom fix does not compute per-atom vector} :dt
Self-explanatory. :dd
{Dump custom fix vector is accessed out-of-range} :dt
Self-explanatory. :dd
{Dump custom variable is not atom-style variable} :dt
Only atom-style variables generate per-atom quantities, needed for
dump output. :dd
{Dump custom/gz only writes compressed files} :dt
The dump custom/gz output file name must have a .gz suffix. :dd
{Dump dcd of non-matching # of atoms} :dt
Every snapshot written by dump dcd must contain the same # of atoms. :dd
{Dump dcd requires sorting by atom ID} :dt
Use the dump_modify sort command to enable this. :dd
{Dump every variable returned a bad timestep} :dt
The variable must return a timestep greater than the current timestep. :dd
{Dump file MPI-IO output not allowed with % in filename} :dt
This is because a % signifies one file per processor and MPI-IO
creates one large file for all processors. :dd
{Dump file does not contain requested snapshot} :dt
Self-explanatory. :dd
{Dump file is incorrectly formatted} :dt
Self-explanatory. :dd
{Dump image body yes requires atom style body} :dt
Self-explanatory. :dd
{Dump image bond not allowed with no bond types} :dt
Self-explanatory. :dd
{Dump image cannot perform sorting} :dt
Self-explanatory. :dd
{Dump image line requires atom style line} :dt
Self-explanatory. :dd
{Dump image persp option is not yet supported} :dt
Self-explanatory. :dd
{Dump image requires one snapshot per file} :dt
Use a "*" in the filename. :dd
{Dump image tri requires atom style tri} :dt
Self-explanatory. :dd
{Dump local and fix not computed at compatible times} :dt
The fix must produce per-atom quantities on timesteps that dump local
needs them. :dd
{Dump local attributes contain no compute or fix} :dt
Self-explanatory. :dd
{Dump local cannot sort by atom ID} :dt
This is because dump local does not really dump per-atom info. :dd
{Dump local compute does not calculate local array} :dt
Self-explanatory. :dd
{Dump local compute does not calculate local vector} :dt
Self-explanatory. :dd
{Dump local compute does not compute local info} :dt
Self-explanatory. :dd
{Dump local compute vector is accessed out-of-range} :dt
Self-explanatory. :dd
{Dump local count is not consistent across input fields} :dt
Every column of output must be the same length. :dd
{Dump local fix does not compute local array} :dt
Self-explanatory. :dd
{Dump local fix does not compute local info} :dt
Self-explanatory. :dd
{Dump local fix does not compute local vector} :dt
Self-explanatory. :dd
{Dump local fix vector is accessed out-of-range} :dt
Self-explanatory. :dd
{Dump modify bcolor not allowed with no bond types} :dt
Self-explanatory. :dd
{Dump modify bdiam not allowed with no bond types} :dt
Self-explanatory. :dd
{Dump modify compute ID does not compute per-atom array} :dt
Self-explanatory. :dd
{Dump modify compute ID does not compute per-atom info} :dt
Self-explanatory. :dd
{Dump modify compute ID does not compute per-atom vector} :dt
Self-explanatory. :dd
{Dump modify compute ID vector is not large enough} :dt
Self-explanatory. :dd
{Dump modify element names do not match atom types} :dt
Number of element names must equal number of atom types. :dd
{Dump modify fix ID does not compute per-atom array} :dt
Self-explanatory. :dd
{Dump modify fix ID does not compute per-atom info} :dt
Self-explanatory. :dd
{Dump modify fix ID does not compute per-atom vector} :dt
Self-explanatory. :dd
{Dump modify fix ID vector is not large enough} :dt
Self-explanatory. :dd
{Dump modify variable is not atom-style variable} :dt
Self-explanatory. :dd
{Dump sort column is invalid} :dt
Self-explanatory. :dd
{Dump xtc requires sorting by atom ID} :dt
Use the dump_modify sort command to enable this. :dd
{Dump xyz/gz only writes compressed files} :dt
The dump xyz/gz output file name must have a .gz suffix. :dd
{Dump_modify buffer yes not allowed for this style} :dt
Self-explanatory. :dd
{Dump_modify format string is too short} :dt
There are more fields to be dumped in a line of output than your
format string specifies. :dd
{Dump_modify region ID does not exist} :dt
Self-explanatory. :dd
{Dumping an atom property that isn't allocated} :dt
The chosen atom style does not define the per-atom quantity being
dumped. :dd
{Duplicate atom IDs exist} :dt
Self-explanatory. :dd
{Duplicate fields in read_dump command} :dt
Self-explanatory. :dd
{Duplicate particle in PeriDynamic bond - simulation box is too small} :dt
This is likely because your box length is shorter than 2 times
the bond length. :dd
{Electronic temperature dropped below zero} :dt
Something has gone wrong with the fix ttm electron temperature model. :dd
{Element not defined in potential file} :dt
The specified element is not in the potential file. :dd
{Empty brackets in variable} :dt
There is no variable syntax that uses empty brackets. Check
the variable doc page. :dd
{Energy was not tallied on needed timestep} :dt
You are using a thermo keyword that requires potentials to
have tallied energy, but they didn't on this timestep. See the
variable doc page for ideas on how to make this work. :dd
{Epsilon or sigma reference not set by pair style in PPPMDisp} :dt
Self-explanatory. :dd
{Epsilon or sigma reference not set by pair style in ewald/n} :dt
The pair style is not providing the needed epsilon or sigma values. :dd
{Error in vdw spline: inner radius > outer radius} :dt
A pre-tabulated spline is invalid. Likely a problem with the
potential parameters. :dd
{Error writing averaged chunk data} :dt
Something in the output to the file triggered an error. :dd
{Error writing file header} :dt
Something in the output to the file triggered an error. :dd
{Error writing out correlation data} :dt
Something in the output to the file triggered an error. :dd
{Error writing out histogram data} :dt
Something in the output to the file triggered an error. :dd
{Error writing out time averaged data} :dt
Something in the output to the file triggered an error. :dd
{Failed to allocate %ld bytes for array %s} :dt
Your LAMMPS simulation has run out of memory. You need to run a
smaller simulation or on more processors. :dd
{Failed to open FFmpeg pipeline to file %s} :dt
The specified file cannot be opened. Check that the path and name are
correct and writable and that the FFmpeg executable can be found and run. :dd
{Failed to reallocate %ld bytes for array %s} :dt
Your LAMMPS simulation has run out of memory. You need to run a
smaller simulation or on more processors. :dd
{Fewer SRD bins than processors in some dimension} :dt
This is not allowed. Make your SRD bin size smaller. :dd
{File variable could not read value} :dt
Check the file assigned to the variable. :dd
{Final box dimension due to fix deform is < 0.0} :dt
Self-explanatory. :dd
{Fix %s does not allow use of dynamic group} :dt
Dynamic groups have not yet been enabled for this fix. :dd
{Fix ID for compute chunk/atom does not exist} :dt
Self-explanatory. :dd
{Fix ID for compute erotate/rigid does not exist} :dt
Self-explanatory. :dd
{Fix ID for compute ke/rigid does not exist} :dt
Self-explanatory. :dd
{Fix ID for compute reduce does not exist} :dt
Self-explanatory. :dd
{Fix ID for compute slice does not exist} :dt
Self-explanatory. :dd
{Fix ID for fix ave/atom does not exist} :dt
Self-explanatory. :dd
{Fix ID for fix ave/chunk does not exist} :dt
Self-explanatory. :dd
{Fix ID for fix ave/correlate does not exist} :dt
Self-explanatory. :dd
{Fix ID for fix ave/histo does not exist} :dt
Self-explanatory. :dd
{Fix ID for fix ave/spatial does not exist} :dt
Self-explanatory. :dd
{Fix ID for fix ave/time does not exist} :dt
Self-explanatory. :dd
{Fix ID for fix store/state does not exist} :dt
Self-explanatory :dd
{Fix ID for fix vector does not exist} :dt
Self-explanatory. :dd
{Fix ID for read_data does not exist} :dt
Self-explanatory. :dd
{Fix ID for velocity does not exist} :dt
Self-explanatory. :dd
{Fix ID must be alphanumeric or underscore characters} :dt
Self-explanatory. :dd
{Fix SRD: bad bin assignment for SRD advection} :dt
Something has gone wrong in your SRD model; try using more
conservative settings. :dd
{Fix SRD: bad search bin assignment} :dt
Something has gone wrong in your SRD model; try using more
conservative settings. :dd
{Fix SRD: bad stencil bin for big particle} :dt
Something has gone wrong in your SRD model; try using more
conservative settings. :dd
{Fix SRD: too many big particles in bin} :dt
Reset the ATOMPERBIN parameter at the top of fix_srd.cpp
to a larger value, and re-compile the code. :dd
{Fix SRD: too many walls in bin} :dt
This should not happen unless your system has been setup incorrectly. :dd
{Fix adapt interface to this pair style not supported} :dt
New coding for the pair style would need to be done. :dd
{Fix adapt kspace style does not exist} :dt
Self-explanatory. :dd
{Fix adapt pair style does not exist} :dt
Self-explanatory :dd
{Fix adapt pair style param not supported} :dt
The pair style does not know about the parameter you specified. :dd
{Fix adapt requires atom attribute charge} :dt
The atom style being used does not specify an atom charge. :dd
{Fix adapt requires atom attribute diameter} :dt
The atom style being used does not specify an atom diameter. :dd
{Fix adapt type pair range is not valid for pair hybrid sub-style} :dt
Self-explanatory. :dd
{Fix append/atoms requires a lattice be defined} :dt
Use the lattice command for this purpose. :dd
{Fix ave/atom compute array is accessed out-of-range} :dt
Self-explanatory. :dd
{Fix ave/atom compute does not calculate a per-atom array} :dt
Self-explanatory. :dd
{Fix ave/atom compute does not calculate a per-atom vector} :dt
A compute used by fix ave/atom must generate per-atom values. :dd
{Fix ave/atom compute does not calculate per-atom values} :dt
A compute used by fix ave/atom must generate per-atom values. :dd
{Fix ave/atom fix array is accessed out-of-range} :dt
Self-explanatory. :dd
{Fix ave/atom fix does not calculate a per-atom array} :dt
Self-explanatory. :dd
{Fix ave/atom fix does not calculate a per-atom vector} :dt
A fix used by fix ave/atom must generate per-atom values. :dd
{Fix ave/atom fix does not calculate per-atom values} :dt
A fix used by fix ave/atom must generate per-atom values. :dd
{Fix ave/atom variable is not atom-style variable} :dt
A variable used by fix ave/atom must generate per-atom values. :dd
{Fix ave/chunk compute does not calculate a per-atom array} :dt
Self-explanatory. :dd
{Fix ave/chunk compute does not calculate a per-atom vector} :dt
Self-explanatory. :dd
{Fix ave/chunk compute does not calculate per-atom values} :dt
Self-explanatory. :dd
{Fix ave/chunk compute vector is accessed out-of-range} :dt
Self-explanatory. :dd
{Fix ave/chunk does not use chunk/atom compute} :dt
The specified compute is not for a compute chunk/atom command. :dd
{Fix ave/chunk fix does not calculate a per-atom array} :dt
Self-explanatory. :dd
{Fix ave/chunk fix does not calculate a per-atom vector} :dt
Self-explanatory. :dd
{Fix ave/chunk fix does not calculate per-atom values} :dt
Self-explanatory. :dd
{Fix ave/chunk fix vector is accessed out-of-range} :dt
Self-explanatory. :dd
{Fix ave/chunk variable is not atom-style variable} :dt
Self-explanatory. :dd
{Fix ave/correlate compute does not calculate a scalar} :dt
Self-explanatory. :dd
{Fix ave/correlate compute does not calculate a vector} :dt
Self-explanatory. :dd
{Fix ave/correlate compute vector is accessed out-of-range} :dt
The index for the vector is out of bounds. :dd
{Fix ave/correlate fix does not calculate a scalar} :dt
Self-explanatory. :dd
{Fix ave/correlate fix does not calculate a vector} :dt
Self-explanatory. :dd
{Fix ave/correlate fix vector is accessed out-of-range} :dt
The index for the vector is out of bounds. :dd
{Fix ave/correlate variable is not equal-style variable} :dt
Self-explanatory. :dd
{Fix ave/histo cannot input local values in scalar mode} :dt
Self-explanatory. :dd
{Fix ave/histo cannot input per-atom values in scalar mode} :dt
Self-explanatory. :dd
{Fix ave/histo compute array is accessed out-of-range} :dt
Self-explanatory. :dd
{Fix ave/histo compute does not calculate a global array} :dt
Self-explanatory. :dd
{Fix ave/histo compute does not calculate a global scalar} :dt
Self-explanatory. :dd
{Fix ave/histo compute does not calculate a global vector} :dt
Self-explanatory. :dd
{Fix ave/histo compute does not calculate a local array} :dt
Self-explanatory. :dd
{Fix ave/histo compute does not calculate a local vector} :dt
Self-explanatory. :dd
{Fix ave/histo compute does not calculate a per-atom array} :dt
Self-explanatory. :dd
{Fix ave/histo compute does not calculate a per-atom vector} :dt
Self-explanatory. :dd
{Fix ave/histo compute does not calculate local values} :dt
Self-explanatory. :dd
{Fix ave/histo compute does not calculate per-atom values} :dt
Self-explanatory. :dd
{Fix ave/histo compute vector is accessed out-of-range} :dt
Self-explanatory. :dd
{Fix ave/histo fix array is accessed out-of-range} :dt
Self-explanatory. :dd
{Fix ave/histo fix does not calculate a global array} :dt
Self-explanatory. :dd
{Fix ave/histo fix does not calculate a global scalar} :dt
Self-explanatory. :dd
{Fix ave/histo fix does not calculate a global vector} :dt
Self-explanatory. :dd
{Fix ave/histo fix does not calculate a local array} :dt
Self-explanatory. :dd
{Fix ave/histo fix does not calculate a local vector} :dt
Self-explanatory. :dd
{Fix ave/histo fix does not calculate a per-atom array} :dt
Self-explanatory. :dd
{Fix ave/histo fix does not calculate a per-atom vector} :dt
Self-explanatory. :dd
{Fix ave/histo fix does not calculate local values} :dt
Self-explanatory. :dd
{Fix ave/histo fix does not calculate per-atom values} :dt
Self-explanatory. :dd
{Fix ave/histo fix vector is accessed out-of-range} :dt
Self-explanatory. :dd
{Fix ave/histo input is invalid compute} :dt
Self-explanatory. :dd
{Fix ave/histo input is invalid fix} :dt
Self-explanatory. :dd
{Fix ave/histo input is invalid variable} :dt
Self-explanatory. :dd
{Fix ave/histo inputs are not all global, peratom, or local} :dt
All inputs in a single fix ave/histo command must be of the
same style. :dd
{Fix ave/histo/weight value and weight vector lengths do not match} :dt
Self-explanatory. :dd
{Fix ave/spatial compute does not calculate a per-atom array} :dt
Self-explanatory. :dd
{Fix ave/spatial compute does not calculate a per-atom vector} :dt
A compute used by fix ave/spatial must generate per-atom values. :dd
{Fix ave/spatial compute does not calculate per-atom values} :dt
A compute used by fix ave/spatial must generate per-atom values. :dd
{Fix ave/spatial compute vector is accessed out-of-range} :dt
The index for the vector is out of bounds. :dd
{Fix ave/spatial fix does not calculate a per-atom array} :dt
Self-explanatory. :dd
{Fix ave/spatial fix does not calculate a per-atom vector} :dt
A fix used by fix ave/spatial must generate per-atom values. :dd
{Fix ave/spatial fix does not calculate per-atom values} :dt
A fix used by fix ave/spatial must generate per-atom values. :dd
{Fix ave/spatial fix vector is accessed out-of-range} :dt
The index for the vector is out of bounds. :dd
{Fix ave/spatial for triclinic boxes requires units reduced} :dt
Self-explanatory. :dd
{Fix ave/spatial settings invalid with changing box size} :dt
If the box size changes, only the units reduced option can be
used. :dd
{Fix ave/spatial variable is not atom-style variable} :dt
A variable used by fix ave/spatial must generate per-atom values. :dd
{Fix ave/time cannot set output array intensive/extensive from these inputs} :dt
One of more of the vector inputs has individual elements which are
flagged as intensive or extensive. Such an input cannot be flagged as
all intensive/extensive when turned into an array by fix ave/time. :dd
{Fix ave/time cannot use variable with vector mode} :dt
Variables produce scalar values. :dd
{Fix ave/time columns are inconsistent lengths} :dt
Self-explanatory. :dd
{Fix ave/time compute array is accessed out-of-range} :dt
An index for the array is out of bounds. :dd
{Fix ave/time compute does not calculate a scalar} :dt
Self-explanatory. :dd
{Fix ave/time compute does not calculate a vector} :dt
Self-explanatory. :dd
{Fix ave/time compute does not calculate an array} :dt
Self-explanatory. :dd
{Fix ave/time compute vector is accessed out-of-range} :dt
The index for the vector is out of bounds. :dd
{Fix ave/time fix array cannot be variable length} :dt
Self-explanatory. :dd
{Fix ave/time fix array is accessed out-of-range} :dt
An index for the array is out of bounds. :dd
{Fix ave/time fix does not calculate a scalar} :dt
Self-explanatory. :dd
{Fix ave/time fix does not calculate a vector} :dt
Self-explanatory. :dd
{Fix ave/time fix does not calculate an array} :dt
Self-explanatory. :dd
{Fix ave/time fix vector cannot be variable length} :dt
Self-explanatory. :dd
{Fix ave/time fix vector is accessed out-of-range} :dt
The index for the vector is out of bounds. :dd
{Fix ave/time variable is not equal-style variable} :dt
Self-explanatory. :dd
{Fix balance rcb cannot be used with comm_style brick} :dt
Comm_style tiled must be used instead. :dd
{Fix balance shift string is invalid} :dt
The string can only contain the characters "x", "y", or "z". :dd
{Fix bond/break needs ghost atoms from further away} :dt
This is because the fix needs to walk bonds to a certain distance to
acquire needed info, The comm_modify cutoff command can be used to
extend the communication range. :dd
{Fix bond/create angle type is invalid} :dt
Self-explanatory. :dd
{Fix bond/create cutoff is longer than pairwise cutoff} :dt
This is not allowed because bond creation is done using the
pairwise neighbor list. :dd
{Fix bond/create dihedral type is invalid} :dt
Self-explanatory. :dd
{Fix bond/create improper type is invalid} :dt
Self-explanatory. :dd
{Fix bond/create induced too many angles/dihedrals/impropers per atom} :dt
See the read_data command for info on using the "extra/angle/per/atom",
(or dihedral, improper) keywords to allow for additional
angles, dihedrals, and impropers to be formed. :dd
{Fix bond/create needs ghost atoms from further away} :dt
This is because the fix needs to walk bonds to a certain distance to
acquire needed info, The comm_modify cutoff command can be used to
extend the communication range. :dd
{Fix bond/swap cannot use dihedral or improper styles} :dt
These styles cannot be defined when using this fix. :dd
{Fix bond/swap requires pair and bond styles} :dt
Self-explanatory. :dd
{Fix bond/swap requires special_bonds = 0,1,1} :dt
Self-explanatory. :dd
{Fix box/relax generated negative box length} :dt
The pressure being applied is likely too large. Try applying
it incrementally, to build to the high pressure. :dd
{Fix command before simulation box is defined} :dt
The fix command cannot be used before a read_data, read_restart, or
create_box command. :dd
{Fix deform cannot use yz variable with xy} :dt
The yz setting cannot be a variable if xy deformation is also
specified. This is because LAMMPS cannot determine if the yz setting
will induce a box flip which would be invalid if xy is also changing. :dd
{Fix deform is changing yz too much with xy} :dt
When both yz and xy are changing, it induces changes in xz if the
box must flip from one tilt extreme to another. Thus it is not
allowed for yz to grow so much that a flip is induced. :dd
{Fix deform tilt factors require triclinic box} :dt
Cannot deform the tilt factors of a simulation box unless it
is a triclinic (non-orthogonal) box. :dd
{Fix deform volume setting is invalid} :dt
Cannot use volume style unless other dimensions are being controlled. :dd
{Fix deposit and fix rigid/small not using same molecule template ID} :dt
Self-explanatory. :dd
{Fix deposit and fix shake not using same molecule template ID} :dt
Self-explanatory. :dd
{Fix deposit molecule must have atom types} :dt
The defined molecule does not specify atom types. :dd
{Fix deposit molecule must have coordinates} :dt
The defined molecule does not specify coordinates. :dd
{Fix deposit molecule template ID must be same as atom_style template ID} :dt
When using atom_style template, you cannot deposit molecules that are
not in that template. :dd
{Fix deposit region cannot be dynamic} :dt
Only static regions can be used with fix deposit. :dd
{Fix deposit region does not support a bounding box} :dt
Not all regions represent bounded volumes. You cannot use
such a region with the fix deposit command. :dd
{Fix deposit shake fix does not exist} :dt
Self-explanatory. :dd
{Fix efield requires atom attribute q or mu} :dt
The atom style defined does not have this attribute. :dd
{Fix efield with dipoles cannot use atom-style variables} :dt
This option is not supported. :dd
{Fix evaporate molecule requires atom attribute molecule} :dt
The atom style being used does not define a molecule ID. :dd
{Fix external callback function not set} :dt
This must be done by an external program in order to use this fix. :dd
{Fix for fix ave/atom not computed at compatible time} :dt
Fixes generate their values on specific timesteps. Fix ave/atom is
requesting a value on a non-allowed timestep. :dd
{Fix for fix ave/chunk not computed at compatible time} :dt
Fixes generate their values on specific timesteps. Fix ave/chunk is
requesting a value on a non-allowed timestep. :dd
{Fix for fix ave/correlate not computed at compatible time} :dt
Fixes generate their values on specific timesteps. Fix ave/correlate
is requesting a value on a non-allowed timestep. :dd
{Fix for fix ave/histo not computed at compatible time} :dt
Fixes generate their values on specific timesteps. Fix ave/histo is
requesting a value on a non-allowed timestep. :dd
{Fix for fix ave/spatial not computed at compatible time} :dt
Fixes generate their values on specific timesteps. Fix ave/spatial is
requesting a value on a non-allowed timestep. :dd
{Fix for fix ave/time not computed at compatible time} :dt
Fixes generate their values on specific timesteps. Fix ave/time
is requesting a value on a non-allowed timestep. :dd
{Fix for fix store/state not computed at compatible time} :dt
Fixes generate their values on specific timesteps. Fix store/state
is requesting a value on a non-allowed timestep. :dd
{Fix for fix vector not computed at compatible time} :dt
Fixes generate their values on specific timesteps. Fix vector is
requesting a value on a non-allowed timestep. :dd
{Fix freeze requires atom attribute torque} :dt
The atom style defined does not have this attribute. :dd
{Fix gcmc and fix shake not using same molecule template ID} :dt
Self-explanatory. :dd
{Fix gcmc atom has charge, but atom style does not} :dt
Self-explanatory. :dd
{Fix gcmc cannot exchange individual atoms belonging to a molecule} :dt
This is an error since you should not delete only one atom of a
molecule. The user has specified atomic (non-molecular) gas
exchanges, but an atom belonging to a molecule could be deleted. :dd
{Fix gcmc does not (yet) work with atom_style template} :dt
Self-explanatory. :dd
{Fix gcmc molecule command requires that atoms have molecule attributes} :dt
Should not choose the gcmc molecule feature if no molecules are being
simulated. The general molecule flag is off, but gcmc's molecule flag
is on. :dd
{Fix gcmc molecule has charges, but atom style does not} :dt
Self-explanatory. :dd
{Fix gcmc molecule must have atom types} :dt
The defined molecule does not specify atom types. :dd
{Fix gcmc molecule must have coordinates} :dt
The defined molecule does not specify coordinates. :dd
{Fix gcmc molecule template ID must be same as atom_style template ID} :dt
When using atom_style template, you cannot insert molecules that are
not in that template. :dd
{Fix gcmc put atom outside box} :dt
This should not normally happen. Contact the developers. :dd
{Fix gcmc ran out of available atom IDs} :dt
See the setting for tagint in the src/lmptype.h file. :dd
{Fix gcmc ran out of available molecule IDs} :dt
See the setting for tagint in the src/lmptype.h file. :dd
{Fix gcmc region cannot be dynamic} :dt
Only static regions can be used with fix gcmc. :dd
{Fix gcmc region does not support a bounding box} :dt
Not all regions represent bounded volumes. You cannot use
such a region with the fix gcmc command. :dd
{Fix gcmc region extends outside simulation box} :dt
Self-explanatory. :dd
{Fix gcmc shake fix does not exist} :dt
Self-explanatory. :dd
{Fix gld c coefficients must be >= 0} :dt
Self-explanatory. :dd
{Fix gld needs more prony series coefficients} :dt
Self-explanatory. :dd
{Fix gld prony terms must be > 0} :dt
Self-explanatory. :dd
{Fix gld series type must be pprony for now} :dt
Self-explanatory. :dd
{Fix gld start temperature must be >= 0} :dt
Self-explanatory. :dd
{Fix gld stop temperature must be >= 0} :dt
Self-explanatory. :dd
{Fix gld tau coefficients must be > 0} :dt
Self-explanatory. :dd
{Fix heat group has no atoms} :dt
Self-explanatory. :dd
{Fix heat kinetic energy of an atom went negative} :dt
This will cause the velocity rescaling about to be performed by fix
heat to be invalid. :dd
{Fix heat kinetic energy went negative} :dt
This will cause the velocity rescaling about to be performed by fix
heat to be invalid. :dd
{Fix in variable not computed at compatible time} :dt
Fixes generate their values on specific timesteps. The variable is
requesting the values on a non-allowed timestep. :dd
{Fix langevin angmom is not yet implemented with kokkos} :dt
This option is not yet available. :dd
{Fix langevin angmom requires atom style ellipsoid} :dt
Self-explanatory. :dd
{Fix langevin angmom requires extended particles} :dt
This fix option cannot be used with point particles. :dd
{Fix langevin omega is not yet implemented with kokkos} :dt
This option is not yet available. :dd
{Fix langevin omega requires atom style sphere} :dt
Self-explanatory. :dd
{Fix langevin omega requires extended particles} :dt
One of the particles has radius 0.0. :dd
{Fix langevin period must be > 0.0} :dt
The time window for temperature relaxation must be > 0 :dd
{Fix langevin variable returned negative temperature} :dt
Self-explanatory. :dd
{Fix momentum group has no atoms} :dt
Self-explanatory. :dd
{Fix move cannot define z or vz variable for 2d problem} :dt
Self-explanatory. :dd
{Fix move cannot rotate aroung non z-axis for 2d problem} :dt
Self-explanatory. :dd
{Fix move cannot set linear z motion for 2d problem} :dt
Self-explanatory. :dd
{Fix move cannot set wiggle z motion for 2d problem} :dt
Self-explanatory. :dd
{Fix msst compute ID does not compute potential energy} :dt
Self-explanatory. :dd
{Fix msst compute ID does not compute pressure} :dt
Self-explanatory. :dd
{Fix msst compute ID does not compute temperature} :dt
Self-explanatory. :dd
{Fix msst requires a periodic box} :dt
Self-explanatory. :dd
{Fix msst tscale must satisfy 0 <= tscale < 1} :dt
Self-explanatory. :dd
{Fix npt/nph has tilted box too far in one step - periodic cell is too far from equilibrium state} :dt
Self-explanatory. The change in the box tilt is too extreme
on a short timescale. :dd
{Fix nve/asphere requires extended particles} :dt
This fix can only be used for particles with a shape setting. :dd
{Fix nve/asphere/noforce requires atom style ellipsoid} :dt
Self-explanatory. :dd
{Fix nve/asphere/noforce requires extended particles} :dt
One of the particles is not an ellipsoid. :dd
{Fix nve/body requires atom style body} :dt
Self-explanatory. :dd
{Fix nve/body requires bodies} :dt
This fix can only be used for particles that are bodies. :dd
{Fix nve/line can only be used for 2d simulations} :dt
Self-explanatory. :dd
{Fix nve/line requires atom style line} :dt
Self-explanatory. :dd
{Fix nve/line requires line particles} :dt
Self-explanatory. :dd
{Fix nve/sphere dipole requires atom attribute mu} :dt
An atom style with this attribute is needed. :dd
{Fix nve/sphere requires atom style sphere} :dt
Self-explanatory. :dd
{Fix nve/sphere requires extended particles} :dt
This fix can only be used for particles of a finite size. :dd
{Fix nve/tri can only be used for 3d simulations} :dt
Self-explanatory. :dd
{Fix nve/tri requires atom style tri} :dt
Self-explanatory. :dd
{Fix nve/tri requires tri particles} :dt
Self-explanatory. :dd
{Fix nvt/nph/npt asphere requires extended particles} :dt
The shape setting for a particle in the fix group has shape = 0.0,
which means it is a point particle. :dd
{Fix nvt/nph/npt body requires bodies} :dt
Self-explanatory. :dd
{Fix nvt/nph/npt sphere requires atom style sphere} :dt
Self-explanatory. :dd
{Fix nvt/npt/nph damping parameters must be > 0.0} :dt
Self-explanatory. :dd
{Fix nvt/npt/nph dilate group ID does not exist} :dt
Self-explanatory. :dd
{Fix nvt/sphere requires extended particles} :dt
This fix can only be used for particles of a finite size. :dd
{Fix orient/fcc file open failed} :dt
The fix orient/fcc command could not open a specified file. :dd
{Fix orient/fcc file read failed} :dt
The fix orient/fcc command could not read the needed parameters from a
specified file. :dd
{Fix orient/fcc found self twice} :dt
The neighbor lists used by fix orient/fcc are messed up. If this
error occurs, it is likely a bug, so send an email to the
"developers"_http://lammps.sandia.gov/authors.html. :dd
{Fix peri neigh does not exist} :dt
Somehow a fix that the pair style defines has been deleted. :dd
{Fix pour and fix rigid/small not using same molecule template ID} :dt
Self-explanatory. :dd
{Fix pour and fix shake not using same molecule template ID} :dt
Self-explanatory. :dd
{Fix pour insertion count per timestep is 0} :dt
Self-explanatory. :dd
{Fix pour molecule must have atom types} :dt
The defined molecule does not specify atom types. :dd
{Fix pour molecule must have coordinates} :dt
The defined molecule does not specify coordinates. :dd
{Fix pour molecule template ID must be same as atom style template ID} :dt
When using atom_style template, you cannot pour molecules that are
not in that template. :dd
{Fix pour polydisperse fractions do not sum to 1.0} :dt
Self-explanatory. :dd
{Fix pour region ID does not exist} :dt
Self-explanatory. :dd
{Fix pour region cannot be dynamic} :dt
Only static regions can be used with fix pour. :dd
{Fix pour region does not support a bounding box} :dt
Not all regions represent bounded volumes. You cannot use
such a region with the fix pour command. :dd
{Fix pour requires atom attributes radius, rmass} :dt
The atom style defined does not have these attributes. :dd
{Fix pour rigid fix does not exist} :dt
Self-explanatory. :dd
{Fix pour shake fix does not exist} :dt
Self-explanatory. :dd
{Fix press/berendsen damping parameters must be > 0.0} :dt
Self-explanatory. :dd
{Fix property/atom cannot specify mol twice} :dt
Self-explanatory. :dd
{Fix property/atom cannot specify q twice} :dt
Self-explanatory. :dd
{Fix property/atom mol when atom_style already has molecule attribute} :dt
Self-explanatory. :dd
{Fix property/atom q when atom_style already has charge attribute} :dt
Self-explanatory. :dd
{Fix property/atom vector name already exists} :dt
The name for an integer or floating-point vector must be unique. :dd
{Fix qeq has negative upper Taper radius cutoff} :dt
Self-explanatory. :dd
{Fix qeq/comb group has no atoms} :dt
Self-explanatory. :dd
{Fix qeq/comb requires atom attribute q} :dt
An atom style with charge must be used to perform charge equilibration. :dd
{Fix qeq/dynamic group has no atoms} :dt
Self-explanatory. :dd
{Fix qeq/dynamic requires atom attribute q} :dt
Self-explanatory. :dd
{Fix qeq/fire group has no atoms} :dt
Self-explanatory. :dd
{Fix qeq/fire requires atom attribute q} :dt
Self-explanatory. :dd
{Fix qeq/point group has no atoms} :dt
Self-explanatory. :dd
{Fix qeq/point has insufficient QEq matrix size} :dt
Occurs when number of neighbor atoms for an atom increased too much
during a run. Increase SAFE_ZONE and MIN_CAP in fix_qeq.h and
recompile. :dd
{Fix qeq/point requires atom attribute q} :dt
Self-explanatory. :dd
{Fix qeq/shielded group has no atoms} :dt
Self-explanatory. :dd
{Fix qeq/shielded has insufficient QEq matrix size} :dt
Occurs when number of neighbor atoms for an atom increased too much
during a run. Increase SAFE_ZONE and MIN_CAP in fix_qeq.h and
recompile. :dd
{Fix qeq/shielded requires atom attribute q} :dt
Self-explanatory. :dd
{Fix qeq/slater could not extract params from pair coul/streitz} :dt
This should not happen unless pair coul/streitz has been altered. :dd
{Fix qeq/slater group has no atoms} :dt
Self-explanatory. :dd
{Fix qeq/slater has insufficient QEq matrix size} :dt
Occurs when number of neighbor atoms for an atom increased too much
during a run. Increase SAFE_ZONE and MIN_CAP in fix_qeq.h and
recompile. :dd
{Fix qeq/slater requires atom attribute q} :dt
Self-explanatory. :dd
{Fix reax/bonds numbonds > nsbmax_most} :dt
The limit of the number of bonds expected by the ReaxFF force field
was exceeded. :dd
{Fix recenter group has no atoms} :dt
Self-explanatory. :dd
{Fix restrain requires an atom map, see atom_modify} :dt
Self-explanatory. :dd
{Fix rigid atom has non-zero image flag in a non-periodic dimension} :dt
Image flags for non-periodic dimensions should not be set. :dd
{Fix rigid file has no lines} :dt
Self-explanatory. :dd
{Fix rigid langevin period must be > 0.0} :dt
Self-explanatory. :dd
{Fix rigid molecule requires atom attribute molecule} :dt
Self-explanatory. :dd
{Fix rigid npt/nph dilate group ID does not exist} :dt
Self-explanatory. :dd
{Fix rigid npt/nph does not yet allow triclinic box} :dt
This is a current restriction in LAMMPS. :dd
{Fix rigid npt/nph period must be > 0.0} :dt
Self-explanatory. :dd
{Fix rigid npt/small t_chain should not be less than 1} :dt
Self-explanatory. :dd
{Fix rigid npt/small t_order must be 3 or 5} :dt
Self-explanatory. :dd
{Fix rigid nvt/npt/nph damping parameters must be > 0.0} :dt
Self-explanatory. :dd
{Fix rigid nvt/small t_chain should not be less than 1} :dt
Self-explanatory. :dd
{Fix rigid nvt/small t_iter should not be less than 1} :dt
Self-explanatory. :dd
{Fix rigid nvt/small t_order must be 3 or 5} :dt
Self-explanatory. :dd
{Fix rigid xy torque cannot be on for 2d simulation} :dt
Self-explanatory. :dd
{Fix rigid z force cannot be on for 2d simulation} :dt
Self-explanatory. :dd
{Fix rigid/npt period must be > 0.0} :dt
Self-explanatory. :dd
{Fix rigid/npt temperature order must be 3 or 5} :dt
Self-explanatory. :dd
{Fix rigid/npt/small period must be > 0.0} :dt
Self-explanatory. :dd
{Fix rigid/nvt period must be > 0.0} :dt
Self-explanatory. :dd
{Fix rigid/nvt temperature order must be 3 or 5} :dt
Self-explanatory. :dd
{Fix rigid/nvt/small period must be > 0.0} :dt
Self-explanatory. :dd
{Fix rigid/small atom has non-zero image flag in a non-periodic dimension} :dt
Image flags for non-periodic dimensions should not be set. :dd
{Fix rigid/small langevin period must be > 0.0} :dt
Self-explanatory. :dd
{Fix rigid/small molecule must have atom types} :dt
The defined molecule does not specify atom types. :dd
{Fix rigid/small molecule must have coordinates} :dt
The defined molecule does not specify coordinates. :dd
{Fix rigid/small npt/nph period must be > 0.0} :dt
Self-explanatory. :dd
{Fix rigid/small nvt/npt/nph damping parameters must be > 0.0} :dt
Self-explanatory. :dd
{Fix rigid/small nvt/npt/nph dilate group ID does not exist} :dt
Self-explanatory. :dd
{Fix rigid/small requires an atom map, see atom_modify} :dt
Self-explanatory. :dd
{Fix rigid/small requires atom attribute molecule} :dt
Self-explanatory. :dd
{Fix rigid: Bad principal moments} :dt
The principal moments of inertia computed for a rigid body
are not within the required tolerances. :dd
{Fix shake cannot be used with minimization} :dt
Cannot use fix shake while doing an energy minimization since
it turns off bonds that should contribute to the energy. :dd
{Fix shake molecule template must have shake info} :dt
The defined molecule does not specify SHAKE information. :dd
{Fix spring couple group ID does not exist} :dt
Self-explanatory. :dd
{Fix srd can only currently be used with comm_style brick} :dt
This is a current restriction in LAMMPS. :dd
{Fix srd lamda must be >= 0.6 of SRD grid size} :dt
This is a requirement for accuracy reasons. :dd
{Fix srd no-slip requires atom attribute torque} :dt
This is because the SRD collisions will impart torque to the solute
particles. :dd
{Fix srd requires SRD particles all have same mass} :dt
Self-explanatory. :dd
{Fix srd requires ghost atoms store velocity} :dt
Use the comm_modify vel yes command to enable this. :dd
{Fix srd requires newton pair on} :dt
Self-explanatory. :dd
{Fix store/state compute array is accessed out-of-range} :dt
Self-explanatory. :dd
{Fix store/state compute does not calculate a per-atom array} :dt
The compute calculates a per-atom vector. :dd
{Fix store/state compute does not calculate a per-atom vector} :dt
The compute calculates a per-atom vector. :dd
{Fix store/state compute does not calculate per-atom values} :dt
Computes that calculate global or local quantities cannot be used
with fix store/state. :dd
{Fix store/state fix array is accessed out-of-range} :dt
Self-explanatory. :dd
{Fix store/state fix does not calculate a per-atom array} :dt
The fix calculates a per-atom vector. :dd
{Fix store/state fix does not calculate a per-atom vector} :dt
The fix calculates a per-atom array. :dd
{Fix store/state fix does not calculate per-atom values} :dt
Fixes that calculate global or local quantities cannot be used with
fix store/state. :dd
{Fix store/state for atom property that isn't allocated} :dt
Self-explanatory. :dd
{Fix store/state variable is not atom-style variable} :dt
Only atom-style variables calculate per-atom quantities. :dd
{Fix temp/berendsen period must be > 0.0} :dt
Self-explanatory. :dd
{Fix temp/berendsen variable returned negative temperature} :dt
Self-explanatory. :dd
{Fix temp/csld is not compatible with fix rattle or fix shake} :dt
These two commands cannot currently be used together with fix temp/csld. :dd
{Fix temp/csld variable returned negative temperature} :dt
Self-explanatory. :dd
{Fix temp/csvr variable returned negative temperature} :dt
Self-explanatory. :dd
{Fix temp/rescale variable returned negative temperature} :dt
Self-explanatory. :dd
{Fix tfmc displacement length must be > 0} :dt
Self-explanatory. :dd
{Fix tfmc is not compatible with fix shake} :dt
These two commands cannot currently be used together. :dd
{Fix tfmc temperature must be > 0} :dt
Self-explanatory. :dd
{Fix thermal/conductivity swap value must be positive} :dt
Self-explanatory. :dd
{Fix tmd must come after integration fixes} :dt
Any fix tmd command must appear in the input script after all time
integration fixes (nve, nvt, npt). See the fix tmd documentation for
details. :dd
{Fix ttm electron temperatures must be > 0.0} :dt
Self-explanatory. :dd
{Fix ttm electronic_density must be > 0.0} :dt
Self-explanatory. :dd
{Fix ttm electronic_specific_heat must be > 0.0} :dt
Self-explanatory. :dd
{Fix ttm electronic_thermal_conductivity must be >= 0.0} :dt
Self-explanatory. :dd
{Fix ttm gamma_p must be > 0.0} :dt
Self-explanatory. :dd
{Fix ttm gamma_s must be >= 0.0} :dt
Self-explanatory. :dd
{Fix ttm number of nodes must be > 0} :dt
Self-explanatory. :dd
{Fix ttm v_0 must be >= 0.0} :dt
Self-explanatory. :dd
{Fix used in compute chunk/atom not computed at compatible time} :dt
The chunk/atom compute cannot query the output of the fix on a timestep
it is needed. :dd
{Fix used in compute reduce not computed at compatible time} :dt
Fixes generate their values on specific timesteps. Compute reduce is
requesting a value on a non-allowed timestep. :dd
{Fix used in compute slice not computed at compatible time} :dt
Fixes generate their values on specific timesteps. Compute slice is
requesting a value on a non-allowed timestep. :dd
{Fix vector cannot set output array intensive/extensive from these inputs} :dt
The inputs to the command have conflicting intensive/extensive attributes.
You need to use more than one fix vector command. :dd
{Fix vector compute does not calculate a scalar} :dt
Self-explanatory. :dd
{Fix vector compute does not calculate a vector} :dt
Self-explanatory. :dd
{Fix vector compute vector is accessed out-of-range} :dt
Self-explanatory. :dd
{Fix vector fix does not calculate a scalar} :dt
Self-explanatory. :dd
{Fix vector fix does not calculate a vector} :dt
Self-explanatory. :dd
{Fix vector fix vector is accessed out-of-range} :dt
Self-explanatory. :dd
{Fix vector variable is not equal-style variable} :dt
Self-explanatory. :dd
{Fix viscosity swap value must be positive} :dt
Self-explanatory. :dd
{Fix viscosity vtarget value must be positive} :dt
Self-explanatory. :dd
{Fix wall cutoff <= 0.0} :dt
Self-explanatory. :dd
{Fix wall/colloid requires atom style sphere} :dt
Self-explanatory. :dd
{Fix wall/colloid requires extended particles} :dt
One of the particles has radius 0.0. :dd
{Fix wall/gran is incompatible with Pair style} :dt
Must use a granular pair style to define the parameters needed for
this fix. :dd
{Fix wall/gran requires atom style sphere} :dt
Self-explanatory. :dd
{Fix wall/piston command only available at zlo} :dt
The face keyword must be zlo. :dd
{Fix wall/region colloid requires atom style sphere} :dt
Self-explanatory. :dd
{Fix wall/region colloid requires extended particles} :dt
One of the particles has radius 0.0. :dd
{Fix wall/region cutoff <= 0.0} :dt
Self-explanatory. :dd
{Fix_modify pressure ID does not compute pressure} :dt
The compute ID assigned to the fix must compute pressure. :dd
{Fix_modify temperature ID does not compute temperature} :dt
The compute ID assigned to the fix must compute temperature. :dd
{For triclinic deformation, specified target stress must be hydrostatic} :dt
Triclinic pressure control is allowed using the tri keyword, but
non-hydrostatic pressure control can not be used in this case. :dd
{Found no restart file matching pattern} :dt
When using a "*" in the restart file name, no matching file was found. :dd
{GPU library not compiled for this accelerator} :dt
Self-explanatory. :dd
{GPU package does not (yet) work with atom_style template} :dt
Self-explanatory. :dd
{GPU particle split must be set to 1 for this pair style.} :dt
For this pair style, you cannot run part of the force calculation on
the host. See the package command. :dd
{GPU split param must be positive for hybrid pair styles} :dt
See the package gpu command. :dd
{GPUs are requested but Kokkos has not been compiled for CUDA} :dt
Recompile Kokkos with CUDA support to use GPUs. :dd
{Ghost velocity forward comm not yet implemented with Kokkos} :dt
This is a current restriction. :dd
{Gmask function in equal-style variable formula} :dt
Gmask is per-atom operation. :dd
{Gravity changed since fix pour was created} :dt
The gravity vector defined by fix gravity must be static. :dd
{Gravity must point in -y to use with fix pour in 2d} :dt
Self-explanatory. :dd
{Gravity must point in -z to use with fix pour in 3d} :dt
Self-explanatory. :dd
{Grmask function in equal-style variable formula} :dt
Grmask is per-atom operation. :dd
{Group ID does not exist} :dt
A group ID used in the group command does not exist. :dd
{Group ID in variable formula does not exist} :dt
Self-explanatory. :dd
{Group all cannot be made dynamic} :dt
This operation is not allowed. :dd
{Group command before simulation box is defined} :dt
The group command cannot be used before a read_data, read_restart, or
create_box command. :dd
{Group dynamic cannot reference itself} :dt
Self-explanatory. :dd
{Group dynamic parent group cannot be dynamic} :dt
Self-explanatory. :dd
{Group dynamic parent group does not exist} :dt
Self-explanatory. :dd
{Group region ID does not exist} :dt
A region ID used in the group command does not exist. :dd
{If read_dump purges it cannot replace or trim} :dt
These operations are not compatible. See the read_dump doc
page for details. :dd
{Illegal ... command} :dt
Self-explanatory. Check the input script syntax and compare to the
documentation for the command. You can use -echo screen as a
command-line option when running LAMMPS to see the offending line. :dd
{Illegal COMB parameter} :dt
One or more of the coefficients defined in the potential file is
invalid. :dd
{Illegal COMB3 parameter} :dt
One or more of the coefficients defined in the potential file is
invalid. :dd
{Illegal Stillinger-Weber parameter} :dt
One or more of the coefficients defined in the potential file is
invalid. :dd
{Illegal Tersoff parameter} :dt
One or more of the coefficients defined in the potential file is
invalid. :dd
{Illegal Vashishta parameter} :dt
One or more of the coefficients defined in the potential file is
invalid. :dd
{Illegal compute voronoi/atom command (occupation and (surface or edges))} :dt
Self-explanatory. :dd
{Illegal coul/streitz parameter} :dt
One or more of the coefficients defined in the potential file is
invalid. :dd
{Illegal dump_modify sfactor value (must be > 0.0)} :dt
Self-explanatory. :dd
{Illegal dump_modify tfactor value (must be > 0.0)} :dt
Self-explanatory. :dd
{Illegal fix gcmc gas mass <= 0} :dt
The computed mass of the designated gas molecule or atom type was less
than or equal to zero. :dd
{Illegal fix tfmc random seed} :dt
Seeds can only be nonzero positive integers. :dd
{Illegal fix wall/piston velocity} :dt
The piston velocity must be positive. :dd
{Illegal integrate style} :dt
Self-explanatory. :dd
{Illegal nb3b/harmonic parameter} :dt
One or more of the coefficients defined in the potential file is
invalid. :dd
{Illegal number of angle table entries} :dt
There must be at least 2 table entries. :dd
{Illegal number of bond table entries} :dt
There must be at least 2 table entries. :dd
{Illegal number of pair table entries} :dt
There must be at least 2 table entries. :dd
{Illegal or unset periodicity in restart} :dt
This error should not normally occur unless the restart file is invalid. :dd
{Illegal range increment value} :dt
The increment must be >= 1. :dd
{Illegal simulation box} :dt
The lower bound of the simulation box is greater than the upper bound. :dd
{Illegal size double vector read requested} :dt
This error should not normally occur unless the restart file is invalid. :dd
{Illegal size integer vector read requested} :dt
This error should not normally occur unless the restart file is invalid. :dd
{Illegal size string or corrupt restart} :dt
This error should not normally occur unless the restart file is invalid. :dd
{Imageint setting in lmptype.h is invalid} :dt
Imageint must be as large or larger than smallint. :dd
{Imageint setting in lmptype.h is not compatible} :dt
Format of imageint stored in restart file is not consistent with
LAMMPS version you are running. See the settings in src/lmptype.h :dd
{Improper atom missing in delete_bonds} :dt
The delete_bonds command cannot find one or more atoms in a particular
improper on a particular processor. The pairwise cutoff is too short
or the atoms are too far apart to make a valid improper. :dd
{Improper atom missing in set command} :dt
The set command cannot find one or more atoms in a particular improper
on a particular processor. The pairwise cutoff is too short or the
atoms are too far apart to make a valid improper. :dd
{Improper atoms %d %d %d %d missing on proc %d at step %ld} :dt
One or more of 4 atoms needed to compute a particular improper are
missing on this processor. Typically this is because the pairwise
cutoff is set too short or the improper has blown apart and an atom is
too far away. :dd
{Improper atoms missing on proc %d at step %ld} :dt
One or more of 4 atoms needed to compute a particular improper are
missing on this processor. Typically this is because the pairwise
cutoff is set too short or the improper has blown apart and an atom is
too far away. :dd
{Improper coeff for hybrid has invalid style} :dt
Improper style hybrid uses another improper style as one of its
coefficients. The improper style used in the improper_coeff command
or read from a restart file is not recognized. :dd
{Improper coeffs are not set} :dt
No improper coefficients have been assigned in the data file or via
the improper_coeff command. :dd
{Improper style hybrid cannot have hybrid as an argument} :dt
Self-explanatory. :dd
{Improper style hybrid cannot have none as an argument} :dt
Self-explanatory. :dd
{Improper style hybrid cannot use same improper style twice} :dt
Self-explanatory. :dd
{Improper_coeff command before improper_style is defined} :dt
Coefficients cannot be set in the data file or via the improper_coeff
command until an improper_style has been assigned. :dd
{Improper_coeff command before simulation box is defined} :dt
The improper_coeff command cannot be used before a read_data,
read_restart, or create_box command. :dd
{Improper_coeff command when no impropers allowed} :dt
The chosen atom style does not allow for impropers to be defined. :dd
{Improper_style command when no impropers allowed} :dt
The chosen atom style does not allow for impropers to be defined. :dd
{Impropers assigned incorrectly} :dt
Impropers read in from the data file were not assigned correctly to
atoms. This means there is something invalid about the topology
definitions. :dd
{Impropers defined but no improper types} :dt
The data file header lists improper but no improper types. :dd
{Incomplete use of variables in create_atoms command} :dt
The var and set options must be used together. :dd
{Inconsistent iparam/jparam values in fix bond/create command} :dt
If itype and jtype are the same, then their maxbond and newtype
settings must also be the same. :dd
{Inconsistent line segment in data file} :dt
The end points of the line segment are not equal distances from the
center point which is the atom coordinate. :dd
{Inconsistent triangle in data file} :dt
The centroid of the triangle as defined by the corner points is not
the atom coordinate. :dd
{Inconsistent use of finite-size particles by molecule template molecules} :dt
Not all of the molecules define a radius for their constituent
particles. :dd
{Incorrect # of floating-point values in Bodies section of data file} :dt
See doc page for body style. :dd
{Incorrect # of integer values in Bodies section of data file} :dt
See doc page for body style. :dd
{Incorrect %s format in data file} :dt
A section of the data file being read by fix property/atom does
not have the correct number of values per line. :dd
{Incorrect SNAP parameter file} :dt
The file cannot be parsed correctly, check its internal syntax. :dd
{Incorrect args for angle coefficients} :dt
Self-explanatory. Check the input script or data file. :dd
{Incorrect args for bond coefficients} :dt
Self-explanatory. Check the input script or data file. :dd
{Incorrect args for dihedral coefficients} :dt
Self-explanatory. Check the input script or data file. :dd
{Incorrect args for improper coefficients} :dt
Self-explanatory. Check the input script or data file. :dd
{Incorrect args for pair coefficients} :dt
Self-explanatory. Check the input script or data file. :dd
{Incorrect args in pair_style command} :dt
Self-explanatory. :dd
{Incorrect atom format in data file} :dt
Number of values per atom line in the data file is not consistent with
the atom style. :dd
{Incorrect atom format in neb file} :dt
The number of fields per line is not what expected. :dd
{Incorrect bonus data format in data file} :dt
See the read_data doc page for a description of how various kinds of
bonus data must be formatted for certain atom styles. :dd
{Incorrect boundaries with slab Ewald} :dt
Must have periodic x,y dimensions and non-periodic z dimension to use
2d slab option with Ewald. :dd
{Incorrect boundaries with slab EwaldDisp} :dt
Must have periodic x,y dimensions and non-periodic z dimension to use
2d slab option with Ewald. :dd
{Incorrect boundaries with slab PPPM} :dt
Must have periodic x,y dimensions and non-periodic z dimension to use
2d slab option with PPPM. :dd
{Incorrect boundaries with slab PPPMDisp} :dt
Must have periodic x,y dimensions and non-periodic z dimension to use
2d slab option with pppm/disp. :dd
{Incorrect element names in ADP potential file} :dt
The element names in the ADP file do not match those requested. :dd
{Incorrect element names in EAM potential file} :dt
The element names in the EAM file do not match those requested. :dd
{Incorrect format in COMB potential file} :dt
Incorrect number of words per line in the potential file. :dd
{Incorrect format in COMB3 potential file} :dt
Incorrect number of words per line in the potential file. :dd
{Incorrect format in MEAM potential file} :dt
Incorrect number of words per line in the potential file. :dd
{Incorrect format in SNAP coefficient file} :dt
Incorrect number of words per line in the coefficient file. :dd
{Incorrect format in SNAP parameter file} :dt
Incorrect number of words per line in the parameter file. :dd
{Incorrect format in Stillinger-Weber potential file} :dt
Incorrect number of words per line in the potential file. :dd
{Incorrect format in TMD target file} :dt
Format of file read by fix tmd command is incorrect. :dd
{Incorrect format in Tersoff potential file} :dt
Incorrect number of words per line in the potential file. :dd
{Incorrect format in Vashishta potential file} :dt
Incorrect number of words per line in the potential file. :dd
{Incorrect format in coul/streitz potential file} :dt
Incorrect number of words per line in the potential file. :dd
{Incorrect format in nb3b/harmonic potential file} :dt
Incorrect number of words per line in the potential file. :dd
{Incorrect integer value in Bodies section of data file} :dt
See doc page for body style. :dd
{Incorrect multiplicity arg for dihedral coefficients} :dt
Self-explanatory. Check the input script or data file. :dd
{Incorrect number of elements in potential file} :dt
Self-explanatory. :dd
{Incorrect rigid body format in fix rigid file} :dt
The number of fields per line is not what expected. :dd
{Incorrect rigid body format in fix rigid/small file} :dt
The number of fields per line is not what expected. :dd
{Incorrect sign arg for dihedral coefficients} :dt
Self-explanatory. Check the input script or data file. :dd
{Incorrect table format check for element types} :dt
Self-explanatory. :dd
{Incorrect velocity format in data file} :dt
Each atom style defines a format for the Velocity section
of the data file. The read-in lines do not match. :dd
{Incorrect weight arg for dihedral coefficients} :dt
Self-explanatory. Check the input script or data file. :dd
{Index between variable brackets must be positive} :dt
Self-explanatory. :dd
{Indexed per-atom vector in variable formula without atom map} :dt
Accessing a value from an atom vector requires the ability to lookup
an atom index, which is provided by an atom map. An atom map does not
exist (by default) for non-molecular problems. Using the atom_modify
map command will force an atom map to be created. :dd
{Initial temperatures not all set in fix ttm} :dt
Self-explanatory. :dd
{Input line quote not followed by whitespace} :dt
An end quote must be followed by whitespace. :dd
{Insertion region extends outside simulation box} :dt
Self-explanatory. :dd
{Insufficient Jacobi rotations for POEMS body} :dt
Eigensolve for rigid body was not sufficiently accurate. :dd
{Insufficient Jacobi rotations for body nparticle} :dt
Eigensolve for rigid body was not sufficiently accurate. :dd
{Insufficient Jacobi rotations for rigid body} :dt
Eigensolve for rigid body was not sufficiently accurate. :dd
{Insufficient Jacobi rotations for rigid molecule} :dt
Eigensolve for rigid body was not sufficiently accurate. :dd
{Insufficient Jacobi rotations for triangle} :dt
The calculation of the inertia tensor of the triangle failed. This
should not happen if it is a reasonably shaped triangle. :dd
{Insufficient memory on accelerator} :dt
There is insufficient memory on one of the devices specified for the gpu
package :dd
{Internal error in atom_style body} :dt
This error should not occur. Contact the developers. :dd
{Invalid -reorder N value} :dt
Self-explanatory. :dd
{Invalid Angles section in molecule file} :dt
Self-explanatory. :dd
{Invalid Bonds section in molecule file} :dt
Self-explanatory. :dd
{Invalid Boolean syntax in if command} :dt
Self-explanatory. :dd
{Invalid Charges section in molecule file} :dt
Self-explanatory. :dd
{Invalid Coords section in molecule file} :dt
Self-explanatory. :dd
{Invalid Diameters section in molecule file} :dt
Self-explanatory. :dd
{Invalid Dihedrals section in molecule file} :dt
Self-explanatory. :dd
{Invalid Impropers section in molecule file} :dt
Self-explanatory. :dd
{Invalid Kokkos command-line args} :dt
Self-explanatory. See Section 2.7 of the manual for details. :dd
{Invalid LAMMPS restart file} :dt
The file does not appear to be a LAMMPS restart file since
it doesn't contain the correct magic string at the beginning. :dd
{Invalid Masses section in molecule file} :dt
Self-explanatory. :dd
{Invalid REAX atom type} :dt
There is a mis-match between LAMMPS atom types and the elements
listed in the ReaxFF force field file. :dd
{Invalid Special Bond Counts section in molecule file} :dt
Self-explanatory. :dd
{Invalid Types section in molecule file} :dt
Self-explanatory. :dd
{Invalid angle count in molecule file} :dt
Self-explanatory. :dd
{Invalid angle table length} :dt
Length must be 2 or greater. :dd
{Invalid angle type in Angles section of data file} :dt
Angle type must be positive integer and within range of specified angle
types. :dd
{Invalid angle type in Angles section of molecule file} :dt
Self-explanatory. :dd
{Invalid angle type index for fix shake} :dt
Self-explanatory. :dd
{Invalid args for non-hybrid pair coefficients} :dt
"NULL" is only supported in pair_coeff calls when using pair hybrid :dd
{Invalid argument to factorial %d} :dt
N must be >= 0 and <= 167, otherwise the factorial result is too
large. :dd
{Invalid atom ID in %s section of data file} :dt
An atom in a section of the data file being read by fix property/atom
has an invalid atom ID that is <= 0 or > the maximum existing atom ID. :dd
{Invalid atom ID in Angles section of data file} :dt
Atom IDs must be positive integers and within range of defined
atoms. :dd
{Invalid atom ID in Angles section of molecule file} :dt
Self-explanatory. :dd
{Invalid atom ID in Atoms section of data file} :dt
Atom IDs must be positive integers. :dd
{Invalid atom ID in Bodies section of data file} :dt
Atom IDs must be positive integers and within range of defined
atoms. :dd
{Invalid atom ID in Bonds section of data file} :dt
Atom IDs must be positive integers and within range of defined
atoms. :dd
{Invalid atom ID in Bonds section of molecule file} :dt
Self-explanatory. :dd
{Invalid atom ID in Bonus section of data file} :dt
Atom IDs must be positive integers and within range of defined
atoms. :dd
{Invalid atom ID in Dihedrals section of data file} :dt
Atom IDs must be positive integers and within range of defined
atoms. :dd
{Invalid atom ID in Impropers section of data file} :dt
Atom IDs must be positive integers and within range of defined
atoms. :dd
{Invalid atom ID in Velocities section of data file} :dt
Atom IDs must be positive integers and within range of defined
atoms. :dd
{Invalid atom ID in dihedrals section of molecule file} :dt
Self-explanatory. :dd
{Invalid atom ID in impropers section of molecule file} :dt
Self-explanatory. :dd
{Invalid atom ID in variable file} :dt
Self-explanatory. :dd
{Invalid atom IDs in neb file} :dt
An ID in the file was not found in the system. :dd
{Invalid atom diameter in molecule file} :dt
Diameters must be >= 0.0. :dd
{Invalid atom mass for fix shake} :dt
Mass specified in fix shake command must be > 0.0. :dd
{Invalid atom mass in molecule file} :dt
Masses must be > 0.0. :dd
{Invalid atom type in Atoms section of data file} :dt
Atom types must range from 1 to specified # of types. :dd
{Invalid atom type in create_atoms command} :dt
The create_box command specified the range of valid atom types.
An invalid type is being requested. :dd
{Invalid atom type in create_atoms mol command} :dt
The atom types in the defined molecule are added to the value
specified in the create_atoms command, as an offset. The final value
for each atom must be between 1 to N, where N is the number of atom
types. :dd
{Invalid atom type in fix atom/swap command} :dt
The atom type specified in the atom/swap command does not exist. :dd
{Invalid atom type in fix bond/create command} :dt
Self-explanatory. :dd
{Invalid atom type in fix deposit command} :dt
Self-explanatory. :dd
{Invalid atom type in fix deposit mol command} :dt
The atom types in the defined molecule are added to the value
specified in the create_atoms command, as an offset. The final value
for each atom must be between 1 to N, where N is the number of atom
types. :dd
{Invalid atom type in fix gcmc command} :dt
The atom type specified in the gcmc command does not exist. :dd
{Invalid atom type in fix pour command} :dt
Self-explanatory. :dd
{Invalid atom type in fix pour mol command} :dt
The atom types in the defined molecule are added to the value
specified in the create_atoms command, as an offset. The final value
for each atom must be between 1 to N, where N is the number of atom
types. :dd
{Invalid atom type in molecule file} :dt
Atom types must range from 1 to specified # of types. :dd
{Invalid atom type in neighbor exclusion list} :dt
Atom types must range from 1 to Ntypes inclusive. :dd
{Invalid atom type index for fix shake} :dt
Atom types must range from 1 to Ntypes inclusive. :dd
{Invalid atom types in pair_write command} :dt
Atom types must range from 1 to Ntypes inclusive. :dd
{Invalid atom vector in variable formula} :dt
The atom vector is not recognized. :dd
{Invalid atom_style body command} :dt
No body style argument was provided. :dd
{Invalid atom_style command} :dt
Self-explanatory. :dd
{Invalid attribute in dump custom command} :dt
Self-explanatory. :dd
{Invalid attribute in dump local command} :dt
Self-explanatory. :dd
{Invalid attribute in dump modify command} :dt
Self-explanatory. :dd
{Invalid basis setting in create_atoms command} :dt
The basis index must be between 1 to N where N is the number of basis
atoms in the lattice. The type index must be between 1 to N where N
is the number of atom types. :dd
{Invalid basis setting in fix append/atoms command} :dt
The basis index must be between 1 to N where N is the number of basis
atoms in the lattice. The type index must be between 1 to N where N
is the number of atom types. :dd
{Invalid bin bounds in compute chunk/atom} :dt
The lo/hi values are inconsistent. :dd
{Invalid bin bounds in fix ave/spatial} :dt
The lo/hi values are inconsistent. :dd
{Invalid body nparticle command} :dt
Arguments in atom-style command are not correct. :dd
{Invalid bond count in molecule file} :dt
Self-explanatory. :dd
{Invalid bond table length} :dt
Length must be 2 or greater. :dd
{Invalid bond type in Bonds section of data file} :dt
Bond type must be positive integer and within range of specified bond
types. :dd
{Invalid bond type in Bonds section of molecule file} :dt
Self-explanatory. :dd
{Invalid bond type in create_bonds command} :dt
Self-explanatory. :dd
{Invalid bond type in fix bond/break command} :dt
Self-explanatory. :dd
{Invalid bond type in fix bond/create command} :dt
Self-explanatory. :dd
{Invalid bond type index for fix shake} :dt
Self-explanatory. Check the fix shake command in the input script. :dd
{Invalid coeffs for this dihedral style} :dt
Cannot set class 2 coeffs in data file for this dihedral style. :dd
{Invalid color in dump_modify command} :dt
The specified color name was not in the list of recognized colors.
See the dump_modify doc page. :dd
{Invalid color map min/max values} :dt
The min/max values are not consistent with either each other or
with values in the color map. :dd
{Invalid command-line argument} :dt
One or more command-line arguments is invalid. Check the syntax of
the command you are using to launch LAMMPS. :dd
{Invalid compute ID in variable formula} :dt
The compute is not recognized. :dd
{Invalid create_atoms rotation vector for 2d model} :dt
The rotation vector can only have a z component. :dd
{Invalid custom OpenCL parameter string.} :dt
There are not enough or too many parameters in the custom string for package
GPU. :dd
{Invalid cutoff in comm_modify command} :dt
Specified cutoff must be >= 0.0. :dd
{Invalid cutoffs in pair_write command} :dt
Inner cutoff must be larger than 0.0 and less than outer cutoff. :dd
{Invalid d1 or d2 value for pair colloid coeff} :dt
Neither d1 or d2 can be < 0. :dd
{Invalid data file section: Angle Coeffs} :dt
Atom style does not allow angles. :dd
{Invalid data file section: AngleAngle Coeffs} :dt
Atom style does not allow impropers. :dd
{Invalid data file section: AngleAngleTorsion Coeffs} :dt
Atom style does not allow dihedrals. :dd
{Invalid data file section: AngleTorsion Coeffs} :dt
Atom style does not allow dihedrals. :dd
{Invalid data file section: Angles} :dt
Atom style does not allow angles. :dd
{Invalid data file section: Bodies} :dt
Atom style does not allow bodies. :dd
{Invalid data file section: Bond Coeffs} :dt
Atom style does not allow bonds. :dd
{Invalid data file section: BondAngle Coeffs} :dt
Atom style does not allow angles. :dd
{Invalid data file section: BondBond Coeffs} :dt
Atom style does not allow angles. :dd
{Invalid data file section: BondBond13 Coeffs} :dt
Atom style does not allow dihedrals. :dd
{Invalid data file section: Bonds} :dt
Atom style does not allow bonds. :dd
{Invalid data file section: Dihedral Coeffs} :dt
Atom style does not allow dihedrals. :dd
{Invalid data file section: Dihedrals} :dt
Atom style does not allow dihedrals. :dd
{Invalid data file section: Ellipsoids} :dt
Atom style does not allow ellipsoids. :dd
{Invalid data file section: EndBondTorsion Coeffs} :dt
Atom style does not allow dihedrals. :dd
{Invalid data file section: Improper Coeffs} :dt
Atom style does not allow impropers. :dd
{Invalid data file section: Impropers} :dt
Atom style does not allow impropers. :dd
{Invalid data file section: Lines} :dt
Atom style does not allow lines. :dd
{Invalid data file section: MiddleBondTorsion Coeffs} :dt
Atom style does not allow dihedrals. :dd
{Invalid data file section: Triangles} :dt
Atom style does not allow triangles. :dd
{Invalid delta_conf in tad command} :dt
The value must be between 0 and 1 inclusive. :dd
{Invalid density in Atoms section of data file} :dt
Density value cannot be <= 0.0. :dd
{Invalid density in set command} :dt
Density must be > 0.0. :dd
{Invalid diameter in set command} :dt
Self-explanatory. :dd
{Invalid dihedral count in molecule file} :dt
Self-explanatory. :dd
{Invalid dihedral type in Dihedrals section of data file} :dt
Dihedral type must be positive integer and within range of specified
dihedral types. :dd
{Invalid dihedral type in dihedrals section of molecule file} :dt
Self-explanatory. :dd
{Invalid dipole length in set command} :dt
Self-explanatory. :dd
{Invalid displace_atoms rotate axis for 2d} :dt
Axis must be in z direction. :dd
{Invalid dump dcd filename} :dt
Filenames used with the dump dcd style cannot be binary or compressed
or cause multiple files to be written. :dd
{Invalid dump frequency} :dt
Dump frequency must be 1 or greater. :dd
{Invalid dump image element name} :dt
The specified element name was not in the standard list of elements.
See the dump_modify doc page. :dd
{Invalid dump image filename} :dt
The file produced by dump image cannot be binary and must
be for a single processor. :dd
{Invalid dump image persp value} :dt
Persp value must be >= 0.0. :dd
{Invalid dump image theta value} :dt
Theta must be between 0.0 and 180.0 inclusive. :dd
{Invalid dump image zoom value} :dt
Zoom value must be > 0.0. :dd
{Invalid dump movie filename} :dt
The file produced by dump movie cannot be binary or compressed
and must be a single file for a single processor. :dd
{Invalid dump xtc filename} :dt
Filenames used with the dump xtc style cannot be binary or compressed
or cause multiple files to be written. :dd
{Invalid dump xyz filename} :dt
Filenames used with the dump xyz style cannot be binary or cause files
to be written by each processor. :dd
{Invalid dump_modify threshold operator} :dt
Operator keyword used for threshold specification in not recognized. :dd
{Invalid entry in -reorder file} :dt
Self-explanatory. :dd
{Invalid fix ID in variable formula} :dt
The fix is not recognized. :dd
{Invalid fix ave/time off column} :dt
Self-explanatory. :dd
{Invalid fix box/relax command for a 2d simulation} :dt
Fix box/relax styles involving the z dimension cannot be used in
a 2d simulation. :dd
{Invalid fix box/relax command pressure settings} :dt
If multiple dimensions are coupled, those dimensions must be specified. :dd
{Invalid fix box/relax pressure settings} :dt
Settings for coupled dimensions must be the same. :dd
{Invalid fix nvt/npt/nph command for a 2d simulation} :dt
Cannot control z dimension in a 2d model. :dd
{Invalid fix nvt/npt/nph command pressure settings} :dt
If multiple dimensions are coupled, those dimensions must be
specified. :dd
{Invalid fix nvt/npt/nph pressure settings} :dt
Settings for coupled dimensions must be the same. :dd
{Invalid fix press/berendsen for a 2d simulation} :dt
The z component of pressure cannot be controlled for a 2d model. :dd
{Invalid fix press/berendsen pressure settings} :dt
Settings for coupled dimensions must be the same. :dd
{Invalid fix qeq parameter file} :dt
Element index > number of atom types. :dd
{Invalid fix rigid npt/nph command for a 2d simulation} :dt
Cannot control z dimension in a 2d model. :dd
{Invalid fix rigid npt/nph command pressure settings} :dt
If multiple dimensions are coupled, those dimensions must be
specified. :dd
{Invalid fix rigid/small npt/nph command for a 2d simulation} :dt
Cannot control z dimension in a 2d model. :dd
{Invalid fix rigid/small npt/nph command pressure settings} :dt
If multiple dimensions are coupled, those dimensions must be
specified. :dd
{Invalid flag in force field section of restart file} :dt
Unrecognized entry in restart file. :dd
{Invalid flag in header section of restart file} :dt
Unrecognized entry in restart file. :dd
{Invalid flag in peratom section of restart file} :dt
The format of this section of the file is not correct. :dd
{Invalid flag in type arrays section of restart file} :dt
Unrecognized entry in restart file. :dd
{Invalid frequency in temper command} :dt
Nevery must be > 0. :dd
{Invalid group ID in neigh_modify command} :dt
A group ID used in the neigh_modify command does not exist. :dd
{Invalid group function in variable formula} :dt
Group function is not recognized. :dd
{Invalid group in comm_modify command} :dt
Self-explanatory. :dd
{Invalid image up vector} :dt
Up vector cannot be (0,0,0). :dd
{Invalid immediate variable} :dt
Syntax of immediate value is incorrect. :dd
{Invalid improper count in molecule file} :dt
Self-explanatory. :dd
{Invalid improper type in Impropers section of data file} :dt
Improper type must be positive integer and within range of specified
improper types. :dd
{Invalid improper type in impropers section of molecule file} :dt
Self-explanatory. :dd
{Invalid index for non-body particles in compute body/local command} :dt
Only indices 1,2,3 can be used for non-body particles. :dd
{Invalid index in compute body/local command} :dt
Self-explanatory. :dd
{Invalid is_active() function in variable formula} :dt
Self-explanatory. :dd
{Invalid is_available() function in variable formula} :dt
Self-explanatory. :dd
{Invalid is_defined() function in variable formula} :dt
Self-explanatory. :dd
{Invalid keyword in angle table parameters} :dt
Self-explanatory. :dd
{Invalid keyword in bond table parameters} :dt
Self-explanatory. :dd
{Invalid keyword in compute angle/local command} :dt
Self-explanatory. :dd
{Invalid keyword in compute bond/local command} :dt
Self-explanatory. :dd
{Invalid keyword in compute dihedral/local command} :dt
Self-explanatory. :dd
{Invalid keyword in compute improper/local command} :dt
Self-explanatory. :dd
{Invalid keyword in compute pair/local command} :dt
Self-explanatory. :dd
{Invalid keyword in compute property/atom command} :dt
Self-explanatory. :dd
{Invalid keyword in compute property/chunk command} :dt
Self-explanatory. :dd
{Invalid keyword in compute property/local command} :dt
Self-explanatory. :dd
{Invalid keyword in dump cfg command} :dt
Self-explanatory. :dd
{Invalid keyword in pair table parameters} :dt
Keyword used in list of table parameters is not recognized. :dd
{Invalid length in set command} :dt
Self-explanatory. :dd
{Invalid mass in set command} :dt
Self-explanatory. :dd
{Invalid mass line in data file} :dt
Self-explanatory. :dd
{Invalid mass value} :dt
Self-explanatory. :dd
{Invalid math function in variable formula} :dt
Self-explanatory. :dd
{Invalid math/group/special function in variable formula} :dt
Self-explanatory. :dd
{Invalid option in lattice command for non-custom style} :dt
Certain lattice keywords are not supported unless the
lattice style is "custom". :dd
{Invalid order of forces within respa levels} :dt
For respa, ordering of force computations within respa levels must
obey certain rules. E.g. bonds cannot be compute less frequently than
angles, pairwise forces cannot be computed less frequently than
kspace, etc. :dd
{Invalid pair table cutoff} :dt
Cutoffs in pair_coeff command are not valid with read-in pair table. :dd
{Invalid pair table length} :dt
Length of read-in pair table is invalid :dd
{Invalid param file for fix qeq/shielded} :dt
Invalid value of gamma. :dd
{Invalid param file for fix qeq/slater} :dt
Zeta value is 0.0. :dd
{Invalid partitions in processors part command} :dt
Valid partitions are numbered 1 to N and the sender and receiver
cannot be the same partition. :dd
{Invalid python command} :dt
Self-explanatory. Check the input script syntax and compare to the
documentation for the command. You can use -echo screen as a
command-line option when running LAMMPS to see the offending line. :dd
{Invalid radius in Atoms section of data file} :dt
Radius must be >= 0.0. :dd
{Invalid random number seed in fix ttm command} :dt
Random number seed must be > 0. :dd
{Invalid random number seed in set command} :dt
Random number seed must be > 0. :dd
{Invalid replace values in compute reduce} :dt
Self-explanatory. :dd
{Invalid rigid body ID in fix rigid file} :dt
The ID does not match the number of an existing ID of rigid bodies
that are defined by the fix rigid command. :dd
{Invalid rigid body ID in fix rigid/small file} :dt
The ID does not match the number of an existing ID of rigid bodies
that are defined by the fix rigid/small command. :dd
{Invalid run command N value} :dt
The number of timesteps must fit in a 32-bit integer. If you want to
run for more steps than this, perform multiple shorter runs. :dd
{Invalid run command start/stop value} :dt
Self-explanatory. :dd
{Invalid run command upto value} :dt
Self-explanatory. :dd
{Invalid seed for Marsaglia random # generator} :dt
The initial seed for this random number generator must be a positive
integer less than or equal to 900 million. :dd
{Invalid seed for Park random # generator} :dt
The initial seed for this random number generator must be a positive
integer. :dd
{Invalid shake angle type in molecule file} :dt
Self-explanatory. :dd
{Invalid shake atom in molecule file} :dt
Self-explanatory. :dd
{Invalid shake bond type in molecule file} :dt
Self-explanatory. :dd
{Invalid shake flag in molecule file} :dt
Self-explanatory. :dd
{Invalid shape in Ellipsoids section of data file} :dt
Self-explanatory. :dd
{Invalid shape in Triangles section of data file} :dt
Two or more of the triangle corners are duplicate points. :dd
{Invalid shape in set command} :dt
Self-explanatory. :dd
{Invalid shear direction for fix wall/gran} :dt
Self-explanatory. :dd
{Invalid special atom index in molecule file} :dt
Self-explanatory. :dd
{Invalid special function in variable formula} :dt
Self-explanatory. :dd
{Invalid style in pair_write command} :dt
Self-explanatory. Check the input script. :dd
{Invalid syntax in variable formula} :dt
Self-explanatory. :dd
{Invalid t_event in prd command} :dt
Self-explanatory. :dd
{Invalid t_event in tad command} :dt
The value must be greater than 0. :dd
{Invalid template atom in Atoms section of data file} :dt
The atom indices must be between 1 to N, where N is the number of
atoms in the template molecule the atom belongs to. :dd
{Invalid template index in Atoms section of data file} :dt
The template indices must be between 1 to N, where N is the number of
molecules in the template. :dd
{Invalid thermo keyword in variable formula} :dt
The keyword is not recognized. :dd
{Invalid threads_per_atom specified.} :dt
For 3-body potentials on the GPU, the threads_per_atom setting cannot be
greater than 4 for NVIDIA GPUs. :dd
{Invalid timestep reset for fix ave/atom} :dt
Resetting the timestep has invalidated the sequence of timesteps this
fix needs to process. :dd
{Invalid timestep reset for fix ave/chunk} :dt
Resetting the timestep has invalidated the sequence of timesteps this
fix needs to process. :dd
{Invalid timestep reset for fix ave/correlate} :dt
Resetting the timestep has invalidated the sequence of timesteps this
fix needs to process. :dd
{Invalid timestep reset for fix ave/histo} :dt
Resetting the timestep has invalidated the sequence of timesteps this
fix needs to process. :dd
{Invalid timestep reset for fix ave/spatial} :dt
Resetting the timestep has invalidated the sequence of timesteps this
fix needs to process. :dd
{Invalid timestep reset for fix ave/time} :dt
Resetting the timestep has invalidated the sequence of timesteps this
fix needs to process. :dd
{Invalid tmax in tad command} :dt
The value must be greater than 0.0. :dd
{Invalid type for mass set} :dt
Mass command must set a type from 1-N where N is the number of atom
types. :dd
{Invalid use of library file() function} :dt
This function is called thru the library interface. This
error should not occur. Contact the developers if it does. :dd
{Invalid value in set command} :dt
The value specified for the setting is invalid, likely because it is
too small or too large. :dd
{Invalid variable evaluation in variable formula} :dt
A variable used in a formula could not be evaluated. :dd
{Invalid variable in next command} :dt
Self-explanatory. :dd
{Invalid variable name} :dt
Variable name used in an input script line is invalid. :dd
{Invalid variable name in variable formula} :dt
Variable name is not recognized. :dd
{Invalid variable style in special function next} :dt
Only file-style or atomfile-style variables can be used with next(). :dd
{Invalid variable style with next command} :dt
Variable styles {equal} and {world} cannot be used in a next
command. :dd
{Invalid volume in set command} :dt
Volume must be > 0.0. :dd
{Invalid wiggle direction for fix wall/gran} :dt
Self-explanatory. :dd
{Invoked angle equil angle on angle style none} :dt
Self-explanatory. :dd
{Invoked angle single on angle style none} :dt
Self-explanatory. :dd
{Invoked bond equil distance on bond style none} :dt
Self-explanatory. :dd
{Invoked bond single on bond style none} :dt
Self-explanatory. :dd
{Invoked pair single on pair style none} :dt
A command (e.g. a dump) attempted to invoke the single() function on a
pair style none, which is illegal. You are probably attempting to
compute per-atom quantities with an undefined pair style. :dd
{Invoking coulombic in pair style lj/coul requires atom attribute q} :dt
The atom style defined does not have this attribute. :dd
{Invoking coulombic in pair style lj/long/dipole/long requires atom attribute q} :dt
The atom style defined does not have these attributes. :dd
{KIM neighbor iterator exceeded range} :dt
This should not happen. It likely indicates a bug
in the KIM implementation of the interatomic potential
where it is requesting neighbors incorrectly. :dd
{KOKKOS package does not yet support comm_style tiled} :dt
Self-explanatory. :dd
{KOKKOS package requires a kokkos enabled atom_style} :dt
Self-explanatory. :dd
{KSpace accuracy must be > 0} :dt
The kspace accuracy designated in the input must be greater than zero. :dd
{KSpace accuracy too large to estimate G vector} :dt
Reduce the accuracy request or specify gwald explicitly
via the kspace_modify command. :dd
{KSpace accuracy too low} :dt
Requested accuracy must be less than 1.0. :dd
{KSpace solver requires a pair style} :dt
No pair style is defined. :dd
{KSpace style does not yet support triclinic geometries} :dt
The specified kspace style does not allow for non-orthogonal
simulation boxes. :dd
{KSpace style has not yet been set} :dt
Cannot use kspace_modify command until a kspace style is set. :dd
{KSpace style is incompatible with Pair style} :dt
Setting a kspace style requires that a pair style with matching
long-range Coulombic or dispersion components be used. :dd
{Keyword %s in MEAM parameter file not recognized} :dt
Self-explanatory. :dd
{Kokkos has been compiled for CUDA but no GPUs are requested} :dt
One or more GPUs must be used when Kokkos is compiled for CUDA. :dd
{Kspace style does not support compute group/group} :dt
Self-explanatory. :dd
{Kspace style pppm/disp/tip4p requires newton on} :dt
Self-explanatory. :dd
{Kspace style pppm/tip4p requires newton on} :dt
Self-explanatory. :dd
{Kspace style requires atom attribute q} :dt
The atom style defined does not have these attributes. :dd
{Kspace_modify eigtol must be smaller than one} :dt
Self-explanatory. :dd
{LAMMPS is not built with Python embedded} :dt
This is done by including the PYTHON package before LAMMPS is built.
This is required to use python-style variables. :dd
{LAMMPS unit_style lj not supported by KIM models} :dt
Self-explanatory. Check the input script or data file. :dd
{LJ6 off not supported in pair_style buck/long/coul/long} :dt
Self-explanatory. :dd
{Label wasn't found in input script} :dt
Self-explanatory. :dd
{Lattice orient vectors are not orthogonal} :dt
The three specified lattice orientation vectors must be mutually
orthogonal. :dd
{Lattice orient vectors are not right-handed} :dt
The three specified lattice orientation vectors must create a
right-handed coordinate system such that a1 cross a2 = a3. :dd
{Lattice primitive vectors are collinear} :dt
The specified lattice primitive vectors do not for a unit cell with
non-zero volume. :dd
{Lattice settings are not compatible with 2d simulation} :dt
One or more of the specified lattice vectors has a non-zero z
component. :dd
{Lattice spacings are invalid} :dt
Each x,y,z spacing must be > 0. :dd
{Lattice style incompatible with simulation dimension} :dt
2d simulation can use sq, sq2, or hex lattice. 3d simulation can use
sc, bcc, or fcc lattice. :dd
{Log of zero/negative value in variable formula} :dt
Self-explanatory. :dd
{Lost atoms via balance: original %ld current %ld} :dt
This should not occur. Report the problem to the developers. :dd
{Lost atoms: original %ld current %ld} :dt
Lost atoms are checked for each time thermo output is done. See the
thermo_modify lost command for options. Lost atoms usually indicate
bad dynamics, e.g. atoms have been blown far out of the simulation
box, or moved further than one processor's sub-domain away before
reneighboring. :dd
{MEAM library error %d} :dt
A call to the MEAM Fortran library returned an error. :dd
{MPI_LMP_BIGINT and bigint in lmptype.h are not compatible} :dt
The size of the MPI datatype does not match the size of a bigint. :dd
{MPI_LMP_TAGINT and tagint in lmptype.h are not compatible} :dt
The size of the MPI datatype does not match the size of a tagint. :dd
{MSM can only currently be used with comm_style brick} :dt
This is a current restriction in LAMMPS. :dd
{MSM grid is too large} :dt
The global MSM grid is larger than OFFSET in one or more dimensions.
OFFSET is currently set to 16384. You likely need to decrease the
requested accuracy. :dd
{MSM order must be 4, 6, 8, or 10} :dt
This is a limitation of the MSM implementation in LAMMPS:
the MSM order can only be 4, 6, 8, or 10. :dd
{Mass command before simulation box is defined} :dt
The mass command cannot be used before a read_data, read_restart, or
create_box command. :dd
{Matrix factorization to split dispersion coefficients failed} :dt
This should not normally happen. Contact the developers. :dd
{Min_style command before simulation box is defined} :dt
The min_style command cannot be used before a read_data, read_restart,
or create_box command. :dd
{Minimization could not find thermo_pe compute} :dt
This compute is created by the thermo command. It must have been
explicitly deleted by a uncompute command. :dd
{Minimize command before simulation box is defined} :dt
The minimize command cannot be used before a read_data, read_restart,
or create_box command. :dd
{Mismatched brackets in variable} :dt
Self-explanatory. :dd
{Mismatched compute in variable formula} :dt
A compute is referenced incorrectly or a compute that produces per-atom
values is used in an equal-style variable formula. :dd
{Mismatched fix in variable formula} :dt
A fix is referenced incorrectly or a fix that produces per-atom
values is used in an equal-style variable formula. :dd
{Mismatched variable in variable formula} :dt
A variable is referenced incorrectly or an atom-style variable that
produces per-atom values is used in an equal-style variable
formula. :dd
{Modulo 0 in variable formula} :dt
Self-explanatory. :dd
{Molecule IDs too large for compute chunk/atom} :dt
The IDs must not be larger than can be stored in a 32-bit integer
since chunk IDs are 32-bit integers. :dd
{Molecule auto special bond generation overflow} :dt
Counts exceed maxspecial setting for other atoms in system. :dd
{Molecule file has angles but no nangles setting} :dt
Self-explanatory. :dd
{Molecule file has body params but no setting for them} :dt
Self-explanatory. :dd
{Molecule file has bonds but no nbonds setting} :dt
Self-explanatory. :dd
{Molecule file has dihedrals but no ndihedrals setting} :dt
Self-explanatory. :dd
{Molecule file has impropers but no nimpropers setting} :dt
Self-explanatory. :dd
{Molecule file has no Body Doubles section} :dt
Self-explanatory. :dd
{Molecule file has no Body Integers section} :dt
Self-explanatory. :dd
{Molecule file has special flags but no bonds} :dt
Self-explanatory. :dd
{Molecule file needs both Special Bond sections} :dt
Self-explanatory. :dd
{Molecule file requires atom style body} :dt
Self-explanatory. :dd
{Molecule file shake flags not before shake atoms} :dt
The order of the two sections is important. :dd
{Molecule file shake flags not before shake bonds} :dt
The order of the two sections is important. :dd
{Molecule file shake info is incomplete} :dt
All 3 SHAKE sections are needed. :dd
{Molecule file special list does not match special count} :dt
The number of values in an atom's special list does not match count. :dd
{Molecule file z center-of-mass must be 0.0 for 2d} :dt
Self-explanatory. :dd
{Molecule file z coord must be 0.0 for 2d} :dt
Self-explanatory. :dd
{Molecule natoms must be 1 for body particle} :dt
Self-explanatory. :dd
{Molecule sizescale must be 1.0 for body particle} :dt
Self-explanatory. :dd
{Molecule template ID for atom_style template does not exist} :dt
Self-explanatory. :dd
{Molecule template ID for create_atoms does not exist} :dt
Self-explanatory. :dd
{Molecule template ID for fix deposit does not exist} :dt
Self-explanatory. :dd
{Molecule template ID for fix gcmc does not exist} :dt
Self-explanatory. :dd
{Molecule template ID for fix pour does not exist} :dt
Self-explanatory. :dd
{Molecule template ID for fix rigid/small does not exist} :dt
Self-explanatory. :dd
{Molecule template ID for fix shake does not exist} :dt
Self-explanatory. :dd
{Molecule template ID must be alphanumeric or underscore characters} :dt
Self-explanatory. :dd
{Molecule topology/atom exceeds system topology/atom} :dt
The number of bonds, angles, etc per-atom in the molecule exceeds the
system setting. See the create_box command for how to specify these
values. :dd
{Molecule topology type exceeds system topology type} :dt
The number of bond, angle, etc types in the molecule exceeds the
system setting. See the create_box command for how to specify these
values. :dd
{More than one fix deform} :dt
Only one fix deform can be defined at a time. :dd
{More than one fix freeze} :dt
Only one of these fixes can be defined, since the granular pair
potentials access it. :dd
{More than one fix shake} :dt
Only one fix shake can be defined. :dd
{Mu not allowed when not using semi-grand in fix atom/swap command} :dt
Self-explanatory. :dd
{Must define angle_style before Angle Coeffs} :dt
Must use an angle_style command before reading a data file that
defines Angle Coeffs. :dd
{Must define angle_style before BondAngle Coeffs} :dt
Must use an angle_style command before reading a data file that
defines Angle Coeffs. :dd
{Must define angle_style before BondBond Coeffs} :dt
Must use an angle_style command before reading a data file that
defines Angle Coeffs. :dd
{Must define bond_style before Bond Coeffs} :dt
Must use a bond_style command before reading a data file that
defines Bond Coeffs. :dd
{Must define dihedral_style before AngleAngleTorsion Coeffs} :dt
Must use a dihedral_style command before reading a data file that
defines AngleAngleTorsion Coeffs. :dd
{Must define dihedral_style before AngleTorsion Coeffs} :dt
Must use a dihedral_style command before reading a data file that
defines AngleTorsion Coeffs. :dd
{Must define dihedral_style before BondBond13 Coeffs} :dt
Must use a dihedral_style command before reading a data file that
defines BondBond13 Coeffs. :dd
{Must define dihedral_style before Dihedral Coeffs} :dt
Must use a dihedral_style command before reading a data file that
defines Dihedral Coeffs. :dd
{Must define dihedral_style before EndBondTorsion Coeffs} :dt
Must use a dihedral_style command before reading a data file that
defines EndBondTorsion Coeffs. :dd
{Must define dihedral_style before MiddleBondTorsion Coeffs} :dt
Must use a dihedral_style command before reading a data file that
defines MiddleBondTorsion Coeffs. :dd
{Must define improper_style before AngleAngle Coeffs} :dt
Must use an improper_style command before reading a data file that
defines AngleAngle Coeffs. :dd
{Must define improper_style before Improper Coeffs} :dt
Must use an improper_style command before reading a data file that
defines Improper Coeffs. :dd
{Must define pair_style before Pair Coeffs} :dt
Must use a pair_style command before reading a data file that defines
Pair Coeffs. :dd
{Must define pair_style before PairIJ Coeffs} :dt
Must use a pair_style command before reading a data file that defines
PairIJ Coeffs. :dd
{Must have more than one processor partition to temper} :dt
Cannot use the temper command with only one processor partition. Use
the -partition command-line option. :dd
{Must read Atoms before Angles} :dt
The Atoms section of a data file must come before an Angles section. :dd
{Must read Atoms before Bodies} :dt
The Atoms section of a data file must come before a Bodies section. :dd
{Must read Atoms before Bonds} :dt
The Atoms section of a data file must come before a Bonds section. :dd
{Must read Atoms before Dihedrals} :dt
The Atoms section of a data file must come before a Dihedrals section. :dd
{Must read Atoms before Ellipsoids} :dt
The Atoms section of a data file must come before a Ellipsoids
section. :dd
{Must read Atoms before Impropers} :dt
The Atoms section of a data file must come before an Impropers
section. :dd
{Must read Atoms before Lines} :dt
The Atoms section of a data file must come before a Lines section. :dd
{Must read Atoms before Triangles} :dt
The Atoms section of a data file must come before a Triangles section. :dd
{Must read Atoms before Velocities} :dt
The Atoms section of a data file must come before a Velocities
section. :dd
{Must set both respa inner and outer} :dt
Cannot use just the inner or outer option with respa without using the
other. :dd
{Must set number of threads via package omp command} :dt
Because you are using the USER-OMP package, set the number of threads
via its settings, not by the pair_style snap nthreads setting. :dd
{Must shrink-wrap piston boundary} :dt
The boundary style of the face where the piston is applied must be of
type s (shrink-wrapped). :dd
{Must specify a region in fix deposit} :dt
The region keyword must be specified with this fix. :dd
{Must specify a region in fix pour} :dt
Self-explanatory. :dd
{Must specify at least 2 types in fix atom/swap command} :dt
Self-explanatory. :dd
{Must use 'kspace_modify pressure/scalar no' for rRESPA with kspace_style MSM} :dt
The kspace scalar pressure option cannot (yet) be used with rRESPA. :dd
{Must use 'kspace_modify pressure/scalar no' for tensor components with kspace_style msm} :dt
Otherwise MSM will compute only a scalar pressure. See the kspace_modify
command for details on this setting. :dd
{Must use 'kspace_modify pressure/scalar no' to obtain per-atom virial with kspace_style MSM} :dt
The kspace scalar pressure option cannot be used to obtain per-atom virial. :dd
{Must use 'kspace_modify pressure/scalar no' with GPU MSM Pair styles} :dt
The kspace scalar pressure option is not (yet) compatible with GPU MSM Pair styles. :dd
{Must use 'kspace_modify pressure/scalar no' with kspace_style msm/cg} :dt
The kspace scalar pressure option is not compatible with kspace_style msm/cg. :dd
{Must use -in switch with multiple partitions} :dt
A multi-partition simulation cannot read the input script from stdin.
The -in command-line option must be used to specify a file. :dd
{Must use Kokkos half/thread or full neighbor list with threads or GPUs} :dt
Using Kokkos half-neighbor lists with threading is not allowed. :dd
{Must use a block or cylinder region with fix pour} :dt
Self-explanatory. :dd
{Must use a block region with fix pour for 2d simulations} :dt
Self-explanatory. :dd
{Must use a bond style with TIP4P potential} :dt
TIP4P potentials assume bond lengths in water are constrained
by a fix shake command. :dd
{Must use a molecular atom style with fix poems molecule} :dt
Self-explanatory. :dd
{Must use a z-axis cylinder region with fix pour} :dt
Self-explanatory. :dd
{Must use an angle style with TIP4P potential} :dt
TIP4P potentials assume angles in water are constrained by a fix shake
command. :dd
{Must use atom map style array with Kokkos} :dt
See the atom_modify map command. :dd
{Must use atom style with molecule IDs with fix bond/swap} :dt
Self-explanatory. :dd
{Must use pair_style comb or comb3 with fix qeq/comb} :dt
Self-explanatory. :dd
{Must use variable energy with fix addforce} :dt
Must define an energy variable when applying a dynamic
force during minimization. :dd
{Must use variable energy with fix efield} :dt
You must define an energy when performing a minimization with a
variable E-field. :dd
{NEB command before simulation box is defined} :dt
Self-explanatory. :dd
{NEB requires damped dynamics minimizer} :dt
Use a different minimization style. :dd
{NEB requires use of fix neb} :dt
Self-explanatory. :dd
{NL ramp in wall/piston only implemented in zlo for now} :dt
The ramp keyword can only be used for piston applied to face zlo. :dd
{Need nswaptypes mu values in fix atom/swap command} :dt
Self-explanatory. :dd
{Needed bonus data not in data file} :dt
Some atom styles require bonus data. See the read_data doc page for
details. :dd
{Needed molecular topology not in data file} :dt
The header of the data file indicated bonds, angles, etc would be
included, but they are not present. :dd
{Neigh_modify exclude molecule requires atom attribute molecule} :dt
Self-explanatory. :dd
{Neigh_modify include group != atom_modify first group} :dt
Self-explanatory. :dd
{Neighbor delay must be 0 or multiple of every setting} :dt
The delay and every parameters set via the neigh_modify command are
inconsistent. If the delay setting is non-zero, then it must be a
multiple of the every setting. :dd
{Neighbor include group not allowed with ghost neighbors} :dt
This is a current restriction within LAMMPS. :dd
{Neighbor list overflow, boost neigh_modify one} :dt
There are too many neighbors of a single atom. Use the neigh_modify
command to increase the max number of neighbors allowed for one atom.
You may also want to boost the page size. :dd
{Neighbor multi not yet enabled for ghost neighbors} :dt
This is a current restriction within LAMMPS. :dd
{Neighbor multi not yet enabled for granular} :dt
Self-explanatory. :dd
{Neighbor multi not yet enabled for rRESPA} :dt
Self-explanatory. :dd
{Neighbor page size must be >= 10x the one atom setting} :dt
This is required to prevent wasting too much memory. :dd
{New atom IDs exceed maximum allowed ID} :dt
See the setting for tagint in the src/lmptype.h file. :dd
{New bond exceeded bonds per atom in create_bonds} :dt
See the read_data command for info on using the "extra/bond/per/atom"
keyword to allow for additional bonds to be formed
{New bond exceeded bonds per atom in fix bond/create} :dt
See the read_data command for info on using the "extra/bond/per/atom"
keyword to allow for additional bonds to be formed :dd
{New bond exceeded special list size in fix bond/create} :dt
See the "special_bonds extra" command
(or the "read_data extra/special/per/atom" command)
for info on how to leave space in the special bonds
list to allow for additional bonds to be formed. :dd
{Newton bond change after simulation box is defined} :dt
The newton command cannot be used to change the newton bond value
after a read_data, read_restart, or create_box command. :dd
{Next command must list all universe and uloop variables} :dt
This is to insure they stay in sync. :dd
{No Kspace style defined for compute group/group} :dt
Self-explanatory. :dd
{No OpenMP support compiled in} :dt
An OpenMP flag is set, but LAMMPS was not built with
OpenMP support. :dd
{No angle style is defined for compute angle/local} :dt
Self-explanatory. :dd
{No angles allowed with this atom style} :dt
Self-explanatory. :dd
{No atoms in data file} :dt
The header of the data file indicated that atoms would be included,
but they are not present. :dd
{No basis atoms in lattice} :dt
Basis atoms must be defined for lattice style user. :dd
{No bodies allowed with this atom style} :dt
Self-explanatory. Check data file. :dd
{No bond style is defined for compute bond/local} :dt
Self-explanatory. :dd
{No bonds allowed with this atom style} :dt
Self-explanatory. :dd
{No box information in dump. You have to use 'box no'} :dt
Self-explanatory. :dd
{No count or invalid atom count in molecule file} :dt
The number of atoms must be specified. :dd
{No dihedral style is defined for compute dihedral/local} :dt
Self-explanatory. :dd
{No dihedrals allowed with this atom style} :dt
Self-explanatory. :dd
{No dump custom arguments specified} :dt
The dump custom command requires that atom quantities be specified to
output to dump file. :dd
{No dump local arguments specified} :dt
Self-explanatory. :dd
{No ellipsoids allowed with this atom style} :dt
Self-explanatory. Check data file. :dd
{No fix gravity defined for fix pour} :dt
Gravity is required to use fix pour. :dd
{No improper style is defined for compute improper/local} :dt
Self-explanatory. :dd
{No impropers allowed with this atom style} :dt
Self-explanatory. :dd
{No input values for fix ave/spatial} :dt
Self-explanatory. :dd
{No lines allowed with this atom style} :dt
Self-explanatory. Check data file. :dd
{No matching element in ADP potential file} :dt
The ADP potential file does not contain elements that match the
requested elements. :dd
{No matching element in EAM potential file} :dt
The EAM potential file does not contain elements that match the
requested elements. :dd
{No molecule topology allowed with atom style template} :dt
The data file cannot specify the number of bonds, angles, etc,
because this info if inferred from the molecule templates. :dd
{No overlap of box and region for create_atoms} :dt
Self-explanatory. :dd
{No pair coul/streitz for fix qeq/slater} :dt
These commands must be used together. :dd
{No pair hbond/dreiding coefficients set} :dt
Self-explanatory. :dd
{No pair style defined for compute group/group} :dt
Cannot calculate group interactions without a pair style defined. :dd
{No pair style is defined for compute pair/local} :dt
Self-explanatory. :dd
{No pair style is defined for compute property/local} :dt
Self-explanatory. :dd
{No rigid bodies defined} :dt
The fix specification did not end up defining any rigid bodies. :dd
{No triangles allowed with this atom style} :dt
Self-explanatory. Check data file. :dd
{No values in fix ave/chunk command} :dt
Self-explanatory. :dd
{No values in fix ave/time command} :dt
Self-explanatory. :dd
{Non digit character between brackets in variable} :dt
Self-explanatory. :dd
{Non integer # of swaps in temper command} :dt
Swap frequency in temper command must evenly divide the total # of
timesteps. :dd
{Non-numeric box dimensions - simulation unstable} :dt
The box size has apparently blown up. :dd
{Non-zero atom IDs with atom_modify id = no} :dt
Self-explanatory. :dd
{Non-zero read_data shift z value for 2d simulation} :dt
Self-explanatory. :dd
{Nprocs not a multiple of N for -reorder} :dt
Self-explanatory. :dd
{Number of core atoms != number of shell atoms} :dt
There must be a one-to-one pairing of core and shell atoms. :dd
{Numeric index is out of bounds} :dt
A command with an argument that specifies an integer or range of
integers is using a value that is less than 1 or greater than the
maximum allowed limit. :dd
{One or more Atom IDs is negative} :dt
Atom IDs must be positive integers. :dd
{One or more atom IDs is too big} :dt
The limit on atom IDs is set by the SMALLBIG, BIGBIG, SMALLSMALL
setting in your Makefile. See Section_start 2.2 of the manual for
more details. :dd
{One or more atom IDs is zero} :dt
Either all atoms IDs must be zero or none of them. :dd
{One or more atoms belong to multiple rigid bodies} :dt
Two or more rigid bodies defined by the fix rigid command cannot
contain the same atom. :dd
{One or more rigid bodies are a single particle} :dt
Self-explanatory. :dd
{One or zero atoms in rigid body} :dt
Any rigid body defined by the fix rigid command must contain 2 or more
atoms. :dd
{Only 2 types allowed when not using semi-grand in fix atom/swap command} :dt
Self-explanatory. :dd
{Only one cut-off allowed when requesting all long} :dt
Self-explanatory. :dd
{Only one cutoff allowed when requesting all long} :dt
Self-explanatory. :dd
{Only zhi currently implemented for fix append/atoms} :dt
Self-explanatory. :dd
{Out of range atoms - cannot compute MSM} :dt
One or more atoms are attempting to map their charge to a MSM grid point
that is not owned by a processor. This is likely for one of two
reasons, both of them bad. First, it may mean that an atom near the
boundary of a processor's sub-domain has moved more than 1/2 the
"neighbor skin distance"_neighbor.html without neighbor lists being
rebuilt and atoms being migrated to new processors. This also means
you may be missing pairwise interactions that need to be computed.
The solution is to change the re-neighboring criteria via the
"neigh_modify"_neigh_modify.html command. The safest settings are
"delay 0 every 1 check yes". Second, it may mean that an atom has
moved far outside a processor's sub-domain or even the entire
simulation box. This indicates bad physics, e.g. due to highly
overlapping atoms, too large a timestep, etc. :dd
{Out of range atoms - cannot compute PPPM} :dt
One or more atoms are attempting to map their charge to a PPPM grid
point that is not owned by a processor. This is likely for one of two
reasons, both of them bad. First, it may mean that an atom near the
boundary of a processor's sub-domain has moved more than 1/2 the
"neighbor skin distance"_neighbor.html without neighbor lists being
rebuilt and atoms being migrated to new processors. This also means
you may be missing pairwise interactions that need to be computed.
The solution is to change the re-neighboring criteria via the
"neigh_modify"_neigh_modify.html command. The safest settings are
"delay 0 every 1 check yes". Second, it may mean that an atom has
moved far outside a processor's sub-domain or even the entire
simulation box. This indicates bad physics, e.g. due to highly
overlapping atoms, too large a timestep, etc. :dd
{Out of range atoms - cannot compute PPPMDisp} :dt
One or more atoms are attempting to map their charge to a PPPM grid
point that is not owned by a processor. This is likely for one of two
reasons, both of them bad. First, it may mean that an atom near the
boundary of a processor's sub-domain has moved more than 1/2 the
"neighbor skin distance"_neighbor.html without neighbor lists being
rebuilt and atoms being migrated to new processors. This also means
you may be missing pairwise interactions that need to be computed.
The solution is to change the re-neighboring criteria via the
"neigh_modify"_neigh_modify.html command. The safest settings are
"delay 0 every 1 check yes". Second, it may mean that an atom has
moved far outside a processor's sub-domain or even the entire
simulation box. This indicates bad physics, e.g. due to highly
overlapping atoms, too large a timestep, etc. :dd
{Overflow of allocated fix vector storage} :dt
This should not normally happen if the fix correctly calculated
how long the vector will grow to. Contact the developers. :dd
{Overlapping large/large in pair colloid} :dt
This potential is infinite when there is an overlap. :dd
{Overlapping small/large in pair colloid} :dt
This potential is infinite when there is an overlap. :dd
{POEMS fix must come before NPT/NPH fix} :dt
NPT/NPH fix must be defined in input script after all poems fixes,
else the fix contribution to the pressure virial is incorrect. :dd
{PPPM can only currently be used with comm_style brick} :dt
This is a current restriction in LAMMPS. :dd
{PPPM grid is too large} :dt
The global PPPM grid is larger than OFFSET in one or more dimensions.
OFFSET is currently set to 4096. You likely need to decrease the
requested accuracy. :dd
{PPPM grid stencil extends beyond nearest neighbor processor} :dt
This is not allowed if the kspace_modify overlap setting is no. :dd
{PPPM order < minimum allowed order} :dt
The default minimum order is 2. This can be reset by the
kspace_modify minorder command. :dd
{PPPM order cannot be < 2 or > than %d} :dt
This is a limitation of the PPPM implementation in LAMMPS. :dd
{PPPMDisp Coulomb grid is too large} :dt
The global PPPM grid is larger than OFFSET in one or more dimensions.
OFFSET is currently set to 4096. You likely need to decrease the
requested accuracy. :dd
{PPPMDisp Dispersion grid is too large} :dt
The global PPPM grid is larger than OFFSET in one or more dimensions.
OFFSET is currently set to 4096. You likely need to decrease the
requested accuracy. :dd
{PPPMDisp can only currently be used with comm_style brick} :dt
This is a current restriction in LAMMPS. :dd
{PPPMDisp coulomb order cannot be greater than %d} :dt
This is a limitation of the PPPM implementation in LAMMPS. :dd
{PPPMDisp used but no parameters set, for further information please see the pppm/disp documentation} :dt
An efficient and accurate usage of the pppm/disp requires settings via the kspace_modify command. Please see the pppm/disp documentation for further instructions. :dd
{PRD command before simulation box is defined} :dt
The prd command cannot be used before a read_data,
read_restart, or create_box command. :dd
{PRD nsteps must be multiple of t_event} :dt
Self-explanatory. :dd
{PRD t_corr must be multiple of t_event} :dt
Self-explanatory. :dd
{Package command after simulation box is defined} :dt
The package command cannot be used afer a read_data, read_restart, or
create_box command. :dd
{Package cuda command without USER-CUDA package enabled} :dt
The USER-CUDA package must be installed via "make yes-user-cuda"
before LAMMPS is built, and the "-c on" must be used to enable the
package. :dd
{Package gpu command without GPU package installed} :dt
The GPU package must be installed via "make yes-gpu" before LAMMPS is
built. :dd
{Package intel command without USER-INTEL package installed} :dt
The USER-INTEL package must be installed via "make yes-user-intel"
before LAMMPS is built. :dd
{Package kokkos command without KOKKOS package enabled} :dt
The KOKKOS package must be installed via "make yes-kokkos" before
LAMMPS is built, and the "-k on" must be used to enable the package. :dd
{Package omp command without USER-OMP package installed} :dt
The USER-OMP package must be installed via "make yes-user-omp" before
LAMMPS is built. :dd
{Pair body requires atom style body} :dt
Self-explanatory. :dd
{Pair body requires body style nparticle} :dt
This pair style is specific to the nparticle body style. :dd
{Pair brownian requires atom style sphere} :dt
Self-explanatory. :dd
{Pair brownian requires extended particles} :dt
One of the particles has radius 0.0. :dd
{Pair brownian requires monodisperse particles} :dt
All particles must be the same finite size. :dd
{Pair brownian/poly requires atom style sphere} :dt
Self-explanatory. :dd
{Pair brownian/poly requires extended particles} :dt
One of the particles has radius 0.0. :dd
{Pair brownian/poly requires newton pair off} :dt
Self-explanatory. :dd
{Pair coeff for hybrid has invalid style} :dt
Style in pair coeff must have been listed in pair_style command. :dd
{Pair coul/wolf requires atom attribute q} :dt
The atom style defined does not have this attribute. :dd
{Pair cutoff < Respa interior cutoff} :dt
One or more pairwise cutoffs are too short to use with the specified
rRESPA cutoffs. :dd
{Pair dipole/cut requires atom attributes q, mu, torque} :dt
The atom style defined does not have these attributes. :dd
{Pair dipole/cut/gpu requires atom attributes q, mu, torque} :dt
The atom style defined does not have this attribute. :dd
{Pair dipole/long requires atom attributes q, mu, torque} :dt
The atom style defined does not have these attributes. :dd
{Pair dipole/sf/gpu requires atom attributes q, mu, torque} :dt
The atom style defined does not one or more of these attributes. :dd
{Pair distance < table inner cutoff} :dt
Two atoms are closer together than the pairwise table allows. :dd
{Pair distance > table outer cutoff} :dt
Two atoms are further apart than the pairwise table allows. :dd
{Pair dpd requires ghost atoms store velocity} :dt
Use the comm_modify vel yes command to enable this. :dd
{Pair gayberne epsilon a,b,c coeffs are not all set} :dt
Each atom type involved in pair_style gayberne must
have these 3 coefficients set at least once. :dd
{Pair gayberne requires atom style ellipsoid} :dt
Self-explanatory. :dd
{Pair gayberne requires atoms with same type have same shape} :dt
Self-explanatory. :dd
{Pair gayberne/gpu requires atom style ellipsoid} :dt
Self-explanatory. :dd
{Pair gayberne/gpu requires atoms with same type have same shape} :dt
Self-explanatory. :dd
{Pair granular requires atom attributes radius, rmass} :dt
The atom style defined does not have these attributes. :dd
{Pair granular requires ghost atoms store velocity} :dt
Use the comm_modify vel yes command to enable this. :dd
{Pair granular with shear history requires newton pair off} :dt
This is a current restriction of the implementation of pair
granular styles with history. :dd
{Pair hybrid single calls do not support per sub-style special bond values} :dt
Self-explanatory. :dd
{Pair hybrid sub-style does not support single call} :dt
You are attempting to invoke a single() call on a pair style
that doesn't support it. :dd
{Pair hybrid sub-style is not used} :dt
No pair_coeff command used a sub-style specified in the pair_style
command. :dd
{Pair inner cutoff < Respa interior cutoff} :dt
One or more pairwise cutoffs are too short to use with the specified
rRESPA cutoffs. :dd
{Pair inner cutoff >= Pair outer cutoff} :dt
The specified cutoffs for the pair style are inconsistent. :dd
{Pair line/lj requires atom style line} :dt
Self-explanatory. :dd
{Pair lj/long/dipole/long requires atom attributes mu, torque} :dt
The atom style defined does not have these attributes. :dd
{Pair lubricate requires atom style sphere} :dt
Self-explanatory. :dd
{Pair lubricate requires ghost atoms store velocity} :dt
Use the comm_modify vel yes command to enable this. :dd
{Pair lubricate requires monodisperse particles} :dt
All particles must be the same finite size. :dd
{Pair lubricate/poly requires atom style sphere} :dt
Self-explanatory. :dd
{Pair lubricate/poly requires extended particles} :dt
One of the particles has radius 0.0. :dd
{Pair lubricate/poly requires ghost atoms store velocity} :dt
Use the comm_modify vel yes command to enable this. :dd
{Pair lubricate/poly requires newton pair off} :dt
Self-explanatory. :dd
{Pair lubricateU requires atom style sphere} :dt
Self-explanatory. :dd
{Pair lubricateU requires ghost atoms store velocity} :dt
Use the comm_modify vel yes command to enable this. :dd
{Pair lubricateU requires monodisperse particles} :dt
All particles must be the same finite size. :dd
{Pair lubricateU/poly requires ghost atoms store velocity} :dt
Use the comm_modify vel yes command to enable this. :dd
{Pair lubricateU/poly requires newton pair off} :dt
Self-explanatory. :dd
{Pair peri lattice is not identical in x, y, and z} :dt
The lattice defined by the lattice command must be cubic. :dd
{Pair peri requires a lattice be defined} :dt
Use the lattice command for this purpose. :dd
{Pair peri requires an atom map, see atom_modify} :dt
Even for atomic systems, an atom map is required to find Peridynamic
bonds. Use the atom_modify command to define one. :dd
{Pair resquared epsilon a,b,c coeffs are not all set} :dt
Self-explanatory. :dd
{Pair resquared epsilon and sigma coeffs are not all set} :dt
Self-explanatory. :dd
{Pair resquared requires atom style ellipsoid} :dt
Self-explanatory. :dd
{Pair resquared requires atoms with same type have same shape} :dt
Self-explanatory. :dd
{Pair resquared/gpu requires atom style ellipsoid} :dt
Self-explanatory. :dd
{Pair resquared/gpu requires atoms with same type have same shape} :dt
Self-explanatory. :dd
{Pair style AIREBO requires atom IDs} :dt
This is a requirement to use the AIREBO potential. :dd
{Pair style AIREBO requires newton pair on} :dt
See the newton command. This is a restriction to use the AIREBO
potential. :dd
{Pair style BOP requires atom IDs} :dt
This is a requirement to use the BOP potential. :dd
{Pair style BOP requires newton pair on} :dt
See the newton command. This is a restriction to use the BOP
potential. :dd
{Pair style COMB requires atom IDs} :dt
This is a requirement to use the AIREBO potential. :dd
{Pair style COMB requires atom attribute q} :dt
Self-explanatory. :dd
{Pair style COMB requires newton pair on} :dt
See the newton command. This is a restriction to use the COMB
potential. :dd
{Pair style COMB3 requires atom IDs} :dt
This is a requirement to use the COMB3 potential. :dd
{Pair style COMB3 requires atom attribute q} :dt
Self-explanatory. :dd
{Pair style COMB3 requires newton pair on} :dt
See the newton command. This is a restriction to use the COMB3
potential. :dd
{Pair style LCBOP requires atom IDs} :dt
This is a requirement to use the LCBOP potential. :dd
{Pair style LCBOP requires newton pair on} :dt
See the newton command. This is a restriction to use the Tersoff
potential. :dd
{Pair style MEAM requires newton pair on} :dt
See the newton command. This is a restriction to use the MEAM
potential. :dd
{Pair style SNAP requires newton pair on} :dt
See the newton command. This is a restriction to use the SNAP
potential. :dd
{Pair style Stillinger-Weber requires atom IDs} :dt
This is a requirement to use the SW potential. :dd
{Pair style Stillinger-Weber requires newton pair on} :dt
See the newton command. This is a restriction to use the SW
potential. :dd
{Pair style Tersoff requires atom IDs} :dt
This is a requirement to use the Tersoff potential. :dd
{Pair style Tersoff requires newton pair on} :dt
See the newton command. This is a restriction to use the Tersoff
potential. :dd
{Pair style Vashishta requires atom IDs} :dt
This is a requirement to use the Vashishta potential. :dd
{Pair style Vashishta requires newton pair on} :dt
See the newton command. This is a restriction to use the Vashishta
potential. :dd
{Pair style bop requires comm ghost cutoff at least 3x larger than %g} :dt
Use the communicate ghost command to set this. See the pair bop
doc page for more details. :dd
{Pair style born/coul/long requires atom attribute q} :dt
An atom style that defines this attribute must be used. :dd
{Pair style born/coul/long/gpu requires atom attribute q} :dt
The atom style defined does not have this attribute. :dd
{Pair style born/coul/wolf requires atom attribute q} :dt
The atom style defined does not have this attribute. :dd
{Pair style buck/coul/cut requires atom attribute q} :dt
The atom style defined does not have this attribute. :dd
{Pair style buck/coul/long requires atom attribute q} :dt
The atom style defined does not have these attributes. :dd
{Pair style buck/coul/long/gpu requires atom attribute q} :dt
The atom style defined does not have this attribute. :dd
{Pair style buck/long/coul/long requires atom attribute q} :dt
The atom style defined does not have this attribute. :dd
{Pair style coul/cut requires atom attribute q} :dt
The atom style defined does not have these attributes. :dd
{Pair style coul/cut/gpu requires atom attribute q} :dt
The atom style defined does not have this attribute. :dd
{Pair style coul/debye/gpu requires atom attribute q} :dt
The atom style defined does not have this attribute. :dd
{Pair style coul/dsf requires atom attribute q} :dt
The atom style defined does not have this attribute. :dd
{Pair style coul/dsf/gpu requires atom attribute q} :dt
The atom style defined does not have this attribute. :dd
{Pair style coul/long/gpu requires atom attribute q} :dt
The atom style defined does not have these attributes. :dd
{Pair style coul/streitz requires atom attribute q} :dt
Self-explanatory. :dd
{Pair style does not have extra field requested by compute pair/local} :dt
The pair style does not support the pN value requested by the compute
pair/local command. :dd
{Pair style does not support bond_style quartic} :dt
The pair style does not have a single() function, so it can
not be invoked by bond_style quartic. :dd
{Pair style does not support compute group/group} :dt
The pair_style does not have a single() function, so it cannot be
invoked by the compute group/group command. :dd
{Pair style does not support compute pair/local} :dt
The pair style does not have a single() function, so it can
not be invoked by compute pair/local. :dd
{Pair style does not support compute property/local} :dt
The pair style does not have a single() function, so it can
not be invoked by fix bond/swap. :dd
{Pair style does not support fix bond/swap} :dt
The pair style does not have a single() function, so it can
not be invoked by fix bond/swap. :dd
{Pair style does not support pair_write} :dt
The pair style does not have a single() function, so it can
not be invoked by pair write. :dd
{Pair style does not support rRESPA inner/middle/outer} :dt
You are attempting to use rRESPA options with a pair style that
does not support them. :dd
{Pair style granular with history requires atoms have IDs} :dt
Atoms in the simulation do not have IDs, so history effects
cannot be tracked by the granular pair potential. :dd
{Pair style hbond/dreiding requires an atom map, see atom_modify} :dt
Self-explanatory. :dd
{Pair style hbond/dreiding requires atom IDs} :dt
Self-explanatory. :dd
{Pair style hbond/dreiding requires molecular system} :dt
Self-explanatory. :dd
{Pair style hbond/dreiding requires newton pair on} :dt
See the newton command for details. :dd
{Pair style hybrid cannot have hybrid as an argument} :dt
Self-explanatory. :dd
{Pair style hybrid cannot have none as an argument} :dt
Self-explanatory. :dd
{Pair style is incompatible with KSpace style} :dt
If a pair style with a long-range Coulombic component is selected,
then a kspace style must also be used. :dd
{Pair style is incompatible with TIP4P KSpace style} :dt
The pair style does not have the requires TIP4P settings. :dd
{Pair style lj/charmm/coul/charmm requires atom attribute q} :dt
The atom style defined does not have these attributes. :dd
{Pair style lj/charmm/coul/long requires atom attribute q} :dt
The atom style defined does not have these attributes. :dd
{Pair style lj/charmm/coul/long/gpu requires atom attribute q} :dt
The atom style defined does not have this attribute. :dd
{Pair style lj/class2/coul/cut requires atom attribute q} :dt
The atom style defined does not have this attribute. :dd
{Pair style lj/class2/coul/long requires atom attribute q} :dt
The atom style defined does not have this attribute. :dd
{Pair style lj/class2/coul/long/gpu requires atom attribute q} :dt
The atom style defined does not have this attribute. :dd
{Pair style lj/cut/coul/cut requires atom attribute q} :dt
The atom style defined does not have this attribute. :dd
{Pair style lj/cut/coul/cut/gpu requires atom attribute q} :dt
The atom style defined does not have this attribute. :dd
{Pair style lj/cut/coul/debye/gpu requires atom attribute q} :dt
The atom style defined does not have this attribute. :dd
{Pair style lj/cut/coul/dsf requires atom attribute q} :dt
The atom style defined does not have these attributes. :dd
{Pair style lj/cut/coul/dsf/gpu requires atom attribute q} :dt
The atom style defined does not have this attribute. :dd
{Pair style lj/cut/coul/long requires atom attribute q} :dt
The atom style defined does not have this attribute. :dd
{Pair style lj/cut/coul/long/gpu requires atom attribute q} :dt
The atom style defined does not have this attribute. :dd
{Pair style lj/cut/tip4p/cut requires atom IDs} :dt
This is a requirement to use this potential. :dd
{Pair style lj/cut/tip4p/cut requires atom attribute q} :dt
The atom style defined does not have this attribute. :dd
{Pair style lj/cut/tip4p/cut requires newton pair on} :dt
See the newton command. This is a restriction to use this
potential. :dd
{Pair style lj/cut/tip4p/long requires atom IDs} :dt
There are no atom IDs defined in the system and the TIP4P potential
requires them to find O,H atoms with a water molecule. :dd
{Pair style lj/cut/tip4p/long requires atom attribute q} :dt
The atom style defined does not have these attributes. :dd
{Pair style lj/cut/tip4p/long requires newton pair on} :dt
This is because the computation of constraint forces within a water
molecule adds forces to atoms owned by other processors. :dd
{Pair style lj/gromacs/coul/gromacs requires atom attribute q} :dt
An atom_style with this attribute is needed. :dd
{Pair style lj/long/dipole/long does not currently support respa} :dt
This feature is not yet supported. :dd
{Pair style lj/long/tip4p/long requires atom IDs} :dt
There are no atom IDs defined in the system and the TIP4P potential
requires them to find O,H atoms with a water molecule. :dd
{Pair style lj/long/tip4p/long requires atom attribute q} :dt
The atom style defined does not have these attributes. :dd
{Pair style lj/long/tip4p/long requires newton pair on} :dt
This is because the computation of constraint forces within a water
molecule adds forces to atoms owned by other processors. :dd
{Pair style lj/sdk/coul/long/gpu requires atom attribute q} :dt
The atom style defined does not have this attribute. :dd
{Pair style nb3b/harmonic requires atom IDs} :dt
This is a requirement to use this potential. :dd
{Pair style nb3b/harmonic requires newton pair on} :dt
See the newton command. This is a restriction to use this potential. :dd
{Pair style nm/cut/coul/cut requires atom attribute q} :dt
The atom style defined does not have this attribute. :dd
{Pair style nm/cut/coul/long requires atom attribute q} :dt
The atom style defined does not have this attribute. :dd
{Pair style peri requires atom style peri} :dt
Self-explanatory. :dd
{Pair style polymorphic requires atom IDs} :dt
This is a requirement to use the polymorphic potential. :dd
{Pair style polymorphic requires newton pair on} :dt
See the newton command. This is a restriction to use the polymorphic
potential. :dd
{Pair style reax requires atom IDs} :dt
This is a requirement to use the ReaxFF potential. :dd
{Pair style reax requires atom attribute q} :dt
The atom style defined does not have this attribute. :dd
{Pair style reax requires newton pair on} :dt
This is a requirement to use the ReaxFF potential. :dd
{Pair style requires a KSpace style} :dt
No kspace style is defined. :dd
{Pair style requires use of kspace_style ewald/disp} :dt
Self-explanatory. :dd
{Pair style sw/gpu requires atom IDs} :dt
This is a requirement to use this potential. :dd
{Pair style sw/gpu requires newton pair off} :dt
See the newton command. This is a restriction to use this potential. :dd
{Pair style vashishta/gpu requires atom IDs} :dt
This is a requirement to use this potential. :dd
{Pair style vashishta/gpu requires newton pair off} :dt
See the newton command. This is a restriction to use this potential. :dd
{Pair style tersoff/gpu requires atom IDs} :dt
This is a requirement to use the tersoff/gpu potential. :dd
{Pair style tersoff/gpu requires newton pair off} :dt
See the newton command. This is a restriction to use this pair style. :dd
{Pair style tip4p/cut requires atom IDs} :dt
This is a requirement to use this potential. :dd
{Pair style tip4p/cut requires atom attribute q} :dt
The atom style defined does not have this attribute. :dd
{Pair style tip4p/cut requires newton pair on} :dt
See the newton command. This is a restriction to use this potential. :dd
{Pair style tip4p/long requires atom IDs} :dt
There are no atom IDs defined in the system and the TIP4P potential
requires them to find O,H atoms with a water molecule. :dd
{Pair style tip4p/long requires atom attribute q} :dt
The atom style defined does not have these attributes. :dd
{Pair style tip4p/long requires newton pair on} :dt
This is because the computation of constraint forces within a water
molecule adds forces to atoms owned by other processors. :dd
{Pair table cutoffs must all be equal to use with KSpace} :dt
When using pair style table with a long-range KSpace solver, the
cutoffs for all atom type pairs must all be the same, since the
long-range solver starts at that cutoff. :dd
{Pair table parameters did not set N} :dt
List of pair table parameters must include N setting. :dd
{Pair tersoff/zbl requires metal or real units} :dt
This is a current restriction of this pair potential. :dd
{Pair tersoff/zbl/kk requires metal or real units} :dt
This is a current restriction of this pair potential. :dd
{Pair tri/lj requires atom style tri} :dt
Self-explanatory. :dd
{Pair yukawa/colloid requires atom style sphere} :dt
Self-explanatory. :dd
{Pair yukawa/colloid requires atoms with same type have same radius} :dt
Self-explanatory. :dd
{Pair yukawa/colloid/gpu requires atom style sphere} :dt
Self-explanatory. :dd
{PairKIM only works with 3D problems} :dt
This is a current limitation. :dd
{Pair_coeff command before pair_style is defined} :dt
Self-explanatory. :dd
{Pair_coeff command before simulation box is defined} :dt
The pair_coeff command cannot be used before a read_data,
read_restart, or create_box command. :dd
{Pair_modify command before pair_style is defined} :dt
Self-explanatory. :dd
{Pair_modify special setting for pair hybrid incompatible with global special_bonds setting} :dt
Cannot override a setting of 0.0 or 1.0 or change a setting between
0.0 and 1.0. :dd
{Pair_write command before pair_style is defined} :dt
Self-explanatory. :dd
{Particle on or inside fix wall surface} :dt
Particles must be "exterior" to the wall in order for energy/force to
be calculated. :dd
{Particle outside surface of region used in fix wall/region} :dt
Particles must be inside the region for energy/force to be calculated.
A particle outside the region generates an error. :dd
{Per-atom compute in equal-style variable formula} :dt
Equal-style variables cannot use per-atom quantities. :dd
{Per-atom energy was not tallied on needed timestep} :dt
You are using a thermo keyword that requires potentials to
have tallied energy, but they didn't on this timestep. See the
variable doc page for ideas on how to make this work. :dd
{Per-atom fix in equal-style variable formula} :dt
Equal-style variables cannot use per-atom quantities. :dd
{Per-atom virial was not tallied on needed timestep} :dt
You are using a thermo keyword that requires potentials to have
tallied the virial, but they didn't on this timestep. See the
variable doc page for ideas on how to make this work. :dd
{Per-processor system is too big} :dt
The number of owned atoms plus ghost atoms on a single
processor must fit in 32-bit integer. :dd
{Potential energy ID for fix neb does not exist} :dt
Self-explanatory. :dd
{Potential energy ID for fix nvt/nph/npt does not exist} :dt
A compute for potential energy must be defined. :dd
{Potential file has duplicate entry} :dt
The potential file has more than one entry for the same element. :dd
{Potential file is missing an entry} :dt
The potential file does not have a needed entry. :dd
{Power by 0 in variable formula} :dt
Self-explanatory. :dd
{Pressure ID for fix box/relax does not exist} :dt
The compute ID needed to compute pressure for the fix does not
exist. :dd
{Pressure ID for fix modify does not exist} :dt
Self-explanatory. :dd
{Pressure ID for fix npt/nph does not exist} :dt
Self-explanatory. :dd
{Pressure ID for fix press/berendsen does not exist} :dt
The compute ID needed to compute pressure for the fix does not
exist. :dd
{Pressure ID for fix rigid npt/nph does not exist} :dt
Self-explanatory. :dd
{Pressure ID for thermo does not exist} :dt
The compute ID needed to compute pressure for thermodynamics does not
exist. :dd
{Pressure control can not be used with fix nvt} :dt
Self-explanatory. :dd
{Pressure control can not be used with fix nvt/asphere} :dt
Self-explanatory. :dd
{Pressure control can not be used with fix nvt/body} :dt
Self-explanatory. :dd
{Pressure control can not be used with fix nvt/sllod} :dt
Self-explanatory. :dd
{Pressure control can not be used with fix nvt/sphere} :dt
Self-explanatory. :dd
{Pressure control must be used with fix nph} :dt
Self-explanatory. :dd
{Pressure control must be used with fix nph/asphere} :dt
Self-explanatory. :dd
{Pressure control must be used with fix nph/body} :dt
Self-explanatory. :dd
{Pressure control must be used with fix nph/small} :dt
Self-explanatory. :dd
{Pressure control must be used with fix nph/sphere} :dt
Self-explanatory. :dd
{Pressure control must be used with fix nphug} :dt
A pressure control keyword (iso, aniso, tri, x, y, or z) must be
provided. :dd
{Pressure control must be used with fix npt} :dt
Self-explanatory. :dd
{Pressure control must be used with fix npt/asphere} :dt
Self-explanatory. :dd
{Pressure control must be used with fix npt/body} :dt
Self-explanatory. :dd
{Pressure control must be used with fix npt/sphere} :dt
Self-explanatory. :dd
{Processor count in z must be 1 for 2d simulation} :dt
Self-explanatory. :dd
{Processor partitions do not match number of allocated processors} :dt
The total number of processors in all partitions must match the number
of processors LAMMPS is running on. :dd
{Processors command after simulation box is defined} :dt
The processors command cannot be used after a read_data, read_restart,
or create_box command. :dd
{Processors custom grid file is inconsistent} :dt
The vales in the custom file are not consistent with the number of
processors you are running on or the Px,Py,Pz settings of the
processors command. Or there was not a setting for every processor. :dd
{Processors grid numa and map style are incompatible} :dt
Using numa for gstyle in the processors command requires using
cart for the map option. :dd
{Processors part option and grid style are incompatible} :dt
Cannot use gstyle numa or custom with the part option. :dd
{Processors twogrid requires proc count be a multiple of core count} :dt
Self-explanatory. :dd
{Pstart and Pstop must have the same value} :dt
Self-explanatory. :dd
{Python function evaluation failed} :dt
The Python function did not run successfully and/or did not return a
value (if it is supposed to return a value). This is probably due to
some error condition in the function. :dd
{Python function is not callable} :dt
The provided Python code was run successfully, but it not
define a callable function with the required name. :dd
{Python invoke of undefined function} :dt
Cannot invoke a function that has not been previously defined. :dd
{Python variable does not match Python function} :dt
This matching is defined by the python-style variable and the python
command. :dd
{Python variable has no function} :dt
No python command was used to define the function associated with the
python-style variable. :dd
{QEQ with 'newton pair off' not supported} :dt
See the newton command. This is a restriction to use the QEQ fixes. :dd
{R0 < 0 for fix spring command} :dt
Equilibrium spring length is invalid. :dd
{RATTLE coordinate constraints are not satisfied up to desired tolerance} :dt
Self-explanatory. :dd
{RATTLE determinant = 0.0} :dt
The determinant of the matrix being solved for a single cluster
specified by the fix rattle command is numerically invalid. :dd
{RATTLE failed} :dt
Certain constraints were not satisfied. :dd
{RATTLE velocity constraints are not satisfied up to desired tolerance} :dt
Self-explanatory. :dd
{Read data add offset is too big} :dt
It cannot be larger than the size of atom IDs, e.g. the maximum 32-bit
integer. :dd
{Read dump of atom property that isn't allocated} :dt
Self-explanatory. :dd
{Read rerun dump file timestep > specified stop} :dt
Self-explanatory. :dd
{Read restart MPI-IO input not allowed with % in filename} :dt
This is because a % signifies one file per processor and MPI-IO
creates one large file for all processors. :dd
{Read_data shrink wrap did not assign all atoms correctly} :dt
This is typically because the box-size specified in the data file is
large compared to the actual extent of atoms in a shrink-wrapped
dimension. When LAMMPS shrink-wraps the box atoms will be lost if the
processor they are re-assigned to is too far away. Choose a box
size closer to the actual extent of the atoms. :dd
{Read_dump command before simulation box is defined} :dt
The read_dump command cannot be used before a read_data, read_restart,
or create_box command. :dd
{Read_dump field not found in dump file} :dt
Self-explanatory. :dd
{Read_dump triclinic status does not match simulation} :dt
Both the dump snapshot and the current LAMMPS simulation must
be using either an orthogonal or triclinic box. :dd
{Read_dump xyz fields do not have consistent scaling/wrapping} :dt
Self-explanatory. :dd
{Reading from MPI-IO filename when MPIIO package is not installed} :dt
Self-explanatory. :dd
{Reax_defs.h setting for NATDEF is too small} :dt
Edit the setting in the ReaxFF library and re-compile the
library and re-build LAMMPS. :dd
{Reax_defs.h setting for NNEIGHMAXDEF is too small} :dt
Edit the setting in the ReaxFF library and re-compile the
library and re-build LAMMPS. :dd
{Receiving partition in processors part command is already a receiver} :dt
Cannot specify a partition to be a receiver twice. :dd
{Region ID for compute chunk/atom does not exist} :dt
Self-explanatory. :dd
{Region ID for compute reduce/region does not exist} :dt
Self-explanatory. :dd
{Region ID for compute temp/region does not exist} :dt
Self-explanatory. :dd
{Region ID for dump custom does not exist} :dt
Self-explanatory. :dd
{Region ID for fix addforce does not exist} :dt
Self-explanatory. :dd
{Region ID for fix atom/swap does not exist} :dt
Self-explanatory. :dd
{Region ID for fix ave/spatial does not exist} :dt
Self-explanatory. :dd
{Region ID for fix aveforce does not exist} :dt
Self-explanatory. :dd
{Region ID for fix deposit does not exist} :dt
Self-explanatory. :dd
{Region ID for fix efield does not exist} :dt
Self-explanatory. :dd
{Region ID for fix evaporate does not exist} :dt
Self-explanatory. :dd
{Region ID for fix gcmc does not exist} :dt
Self-explanatory. :dd
{Region ID for fix heat does not exist} :dt
Self-explanatory. :dd
{Region ID for fix setforce does not exist} :dt
Self-explanatory. :dd
{Region ID for fix wall/region does not exist} :dt
Self-explanatory. :dd
{Region ID for group dynamic does not exist} :dt
Self-explanatory. :dd
{Region ID in variable formula does not exist} :dt
Self-explanatory. :dd
{Region cannot have 0 length rotation vector} :dt
Self-explanatory. :dd
{Region for fix oneway does not exist} :dt
Self-explanatory. :dd
{Region intersect region ID does not exist} :dt
Self-explanatory. :dd
{Region union or intersect cannot be dynamic} :dt
The sub-regions can be dynamic, but not the combined region. :dd
{Region union region ID does not exist} :dt
One or more of the region IDs specified by the region union command
does not exist. :dd
{Replacing a fix, but new style != old style} :dt
A fix ID can be used a 2nd time, but only if the style matches the
previous fix. In this case it is assumed you with to reset a fix's
parameters. This error may mean you are mistakenly re-using a fix ID
when you do not intend to. :dd
{Replicate command before simulation box is defined} :dt
The replicate command cannot be used before a read_data, read_restart,
or create_box command. :dd
{Replicate did not assign all atoms correctly} :dt
Atoms replicated by the replicate command were not assigned correctly
to processors. This is likely due to some atom coordinates being
outside a non-periodic simulation box. :dd
{Replicated system atom IDs are too big} :dt
See the setting for tagint in the src/lmptype.h file. :dd
{Replicated system is too big} :dt
See the setting for bigint in the src/lmptype.h file. :dd
{Required border comm not yet implemented with Kokkos} :dt
There are various limitations in the communication options supported
by Kokkos. :dd
{Rerun command before simulation box is defined} :dt
The rerun command cannot be used before a read_data, read_restart, or
create_box command. :dd
{Rerun dump file does not contain requested snapshot} :dt
Self-explanatory. :dd
{Resetting timestep size is not allowed with fix move} :dt
This is because fix move is moving atoms based on elapsed time. :dd
{Respa inner cutoffs are invalid} :dt
The first cutoff must be <= the second cutoff. :dd
{Respa levels must be >= 1} :dt
Self-explanatory. :dd
{Respa middle cutoffs are invalid} :dt
The first cutoff must be <= the second cutoff. :dd
{Restart file MPI-IO output not allowed with % in filename} :dt
This is because a % signifies one file per processor and MPI-IO
creates one large file for all processors. :dd
{Restart file byte ordering is not recognized} :dt
The file does not appear to be a LAMMPS restart file since it doesn't
contain a recognized byte-orderomg flag at the beginning. :dd
{Restart file byte ordering is swapped} :dt
The file was written on a machine with different byte-ordering than
the machine you are reading it on. Convert it to a text data file
instead, on the machine you wrote it on. :dd
{Restart file incompatible with current version} :dt
This is probably because you are trying to read a file created with a
version of LAMMPS that is too old compared to the current version.
Use your older version of LAMMPS and convert the restart file
to a data file. :dd
{Restart file is a MPI-IO file} :dt
The file is inconsistent with the filename you specified for it. :dd
{Restart file is a multi-proc file} :dt
The file is inconsistent with the filename you specified for it. :dd
{Restart file is not a MPI-IO file} :dt
The file is inconsistent with the filename you specified for it. :dd
{Restart file is not a multi-proc file} :dt
The file is inconsistent with the filename you specified for it. :dd
{Restart variable returned a bad timestep} :dt
The variable must return a timestep greater than the current timestep. :dd
{Restrain atoms %d %d %d %d missing on proc %d at step %ld} :dt
The 4 atoms in a restrain dihedral specified by the fix restrain
command are not all accessible to a processor. This probably means an
atom has moved too far. :dd
{Restrain atoms %d %d %d missing on proc %d at step %ld} :dt
The 3 atoms in a restrain angle specified by the fix restrain
command are not all accessible to a processor. This probably means an
atom has moved too far. :dd
{Restrain atoms %d %d missing on proc %d at step %ld} :dt
The 2 atoms in a restrain bond specified by the fix restrain
command are not all accessible to a processor. This probably means an
atom has moved too far. :dd
{Reuse of compute ID} :dt
A compute ID cannot be used twice. :dd
{Reuse of dump ID} :dt
A dump ID cannot be used twice. :dd
{Reuse of molecule template ID} :dt
The template IDs must be unique. :dd
{Reuse of region ID} :dt
A region ID cannot be used twice. :dd
{Rigid body atoms %d %d missing on proc %d at step %ld} :dt
This means that an atom cannot find the atom that owns the rigid body
it is part of, or vice versa. The solution is to use the communicate
cutoff command to insure ghost atoms are acquired from far enough away
to encompass the max distance printed when the fix rigid/small command
was invoked. :dd
{Rigid body has degenerate moment of inertia} :dt
Fix poems will only work with bodies (collections of atoms) that have
non-zero principal moments of inertia. This means they must be 3 or
more non-collinear atoms, even with joint atoms removed. :dd
{Rigid fix must come before NPT/NPH fix} :dt
NPT/NPH fix must be defined in input script after all rigid fixes,
else the rigid fix contribution to the pressure virial is
incorrect. :dd
{Rmask function in equal-style variable formula} :dt
Rmask is per-atom operation. :dd
{Run command before simulation box is defined} :dt
The run command cannot be used before a read_data, read_restart, or
create_box command. :dd
{Run command start value is after start of run} :dt
Self-explanatory. :dd
{Run command stop value is before end of run} :dt
Self-explanatory. :dd
{Run_style command before simulation box is defined} :dt
The run_style command cannot be used before a read_data,
read_restart, or create_box command. :dd
{SRD bin size for fix srd differs from user request} :dt
Fix SRD had to adjust the bin size to fit the simulation box. See the
cubic keyword if you want this message to be an error vs warning. :dd
{SRD bins for fix srd are not cubic enough} :dt
The bin shape is not within tolerance of cubic. See the cubic
keyword if you want this message to be an error vs warning. :dd
{SRD particle %d started inside big particle %d on step %ld bounce %d} :dt
See the inside keyword if you want this message to be an error vs
warning. :dd
{SRD particle %d started inside wall %d on step %ld bounce %d} :dt
See the inside keyword if you want this message to be an error vs
warning. :dd
{Same dimension twice in fix ave/spatial} :dt
Self-explanatory. :dd
{Sending partition in processors part command is already a sender} :dt
Cannot specify a partition to be a sender twice. :dd
{Set command before simulation box is defined} :dt
The set command cannot be used before a read_data, read_restart,
or create_box command. :dd
{Set command floating point vector does not exist} :dt
Self-explanatory. :dd
{Set command integer vector does not exist} :dt
Self-explanatory. :dd
{Set command with no atoms existing} :dt
No atoms are yet defined so the set command cannot be used. :dd
{Set region ID does not exist} :dt
Region ID specified in set command does not exist. :dd
{Shake angles have different bond types} :dt
All 3-atom angle-constrained SHAKE clusters specified by the fix shake
command that are the same angle type, must also have the same bond
types for the 2 bonds in the angle. :dd
{Shake atoms %d %d %d %d missing on proc %d at step %ld} :dt
The 4 atoms in a single shake cluster specified by the fix shake
command are not all accessible to a processor. This probably means
an atom has moved too far. :dd
{Shake atoms %d %d %d missing on proc %d at step %ld} :dt
The 3 atoms in a single shake cluster specified by the fix shake
command are not all accessible to a processor. This probably means
an atom has moved too far. :dd
{Shake atoms %d %d missing on proc %d at step %ld} :dt
The 2 atoms in a single shake cluster specified by the fix shake
command are not all accessible to a processor. This probably means
an atom has moved too far. :dd
{Shake cluster of more than 4 atoms} :dt
A single cluster specified by the fix shake command can have no more
than 4 atoms. :dd
{Shake clusters are connected} :dt
A single cluster specified by the fix shake command must have a single
central atom with up to 3 other atoms bonded to it. :dd
{Shake determinant = 0.0} :dt
The determinant of the matrix being solved for a single cluster
specified by the fix shake command is numerically invalid. :dd
{Shake fix must come before NPT/NPH fix} :dt
NPT fix must be defined in input script after SHAKE fix, else the
SHAKE fix contribution to the pressure virial is incorrect. :dd
{Shear history overflow, boost neigh_modify one} :dt
There are too many neighbors of a single atom. Use the neigh_modify
command to increase the max number of neighbors allowed for one atom.
You may also want to boost the page size. :dd
{Small to big integers are not sized correctly} :dt
This error occurs whenthe sizes of smallint, imageint, tagint, bigint,
as defined in src/lmptype.h are not what is expected. Contact
the developers if this occurs. :dd
{Smallint setting in lmptype.h is invalid} :dt
It has to be the size of an integer. :dd
{Smallint setting in lmptype.h is not compatible} :dt
Smallint stored in restart file is not consistent with LAMMPS version
you are running. :dd
{Special list size exceeded in fix bond/create} :dt
See the special_bonds extra command
(or the read_data extra/special/per/atom command)
for info on how to leave space in the special bonds
list to allow for additional bonds to be formed. :dd
{Specified processors != physical processors} :dt
The 3d grid of processors defined by the processors command does not
match the number of processors LAMMPS is being run on. :dd
{Specified target stress must be uniaxial or hydrostatic} :dt
Self-explanatory. :dd
{Sqrt of negative value in variable formula} :dt
Self-explanatory. :dd
{Subsequent read data induced too many angles per atom} :dt
See the extra/angle/per/atom keyword for the create_box
or the read_data command to set this limit larger :dd
{Subsequent read data induced too many bonds per atom} :dt
See the extra/bond/per/atom keyword for the create_box
or the read_data command to set this limit larger :dd
{Subsequent read data induced too many dihedrals per atom} :dt
See the extra/dihedral/per/atom keyword for the create_box
or the read_data command to set this limit larger :dd
{Subsequent read data induced too many impropers per atom} :dt
See the extra/improper/per/atom keyword for the create_box
or the read_data command to set this limit larger :dd
{Substitution for illegal variable} :dt
Input script line contained a variable that could not be substituted
for. :dd
{Support for writing images in JPEG format not included} :dt
LAMMPS was not built with the -DLAMMPS_JPEG switch in the Makefile. :dd
{Support for writing images in PNG format not included} :dt
LAMMPS was not built with the -DLAMMPS_PNG switch in the Makefile. :dd
{Support for writing movies not included} :dt
LAMMPS was not built with the -DLAMMPS_FFMPEG switch in the Makefile :dd
{System in data file is too big} :dt
See the setting for bigint in the src/lmptype.h file. :dd
{System is not charge neutral, net charge = %g} :dt
The total charge on all atoms on the system is not 0.0.
For some KSpace solvers this is an error. :dd
{TAD nsteps must be multiple of t_event} :dt
Self-explanatory. :dd
{TIP4P hydrogen has incorrect atom type} :dt
The TIP4P pairwise computation found an H atom whose type does not
agree with the specified H type. :dd
{TIP4P hydrogen is missing} :dt
The TIP4P pairwise computation failed to find the correct H atom
within a water molecule. :dd
{TMD target file did not list all group atoms} :dt
The target file for the fix tmd command did not list all atoms in the
fix group. :dd
{Tad command before simulation box is defined} :dt
Self-explanatory. :dd
{Tagint setting in lmptype.h is invalid} :dt
Tagint must be as large or larger than smallint. :dd
{Tagint setting in lmptype.h is not compatible} :dt
Format of tagint stored in restart file is not consistent with LAMMPS
version you are running. See the settings in src/lmptype.h :dd
{Target pressure for fix rigid/nph cannot be < 0.0} :dt
Self-explanatory. :dd
{Target pressure for fix rigid/npt/small cannot be < 0.0} :dt
Self-explanatory. :dd
{Target temperature for fix nvt/npt/nph cannot be 0.0} :dt
Self-explanatory. :dd
{Target temperature for fix rigid/npt cannot be 0.0} :dt
Self-explanatory. :dd
{Target temperature for fix rigid/npt/small cannot be 0.0} :dt
Self-explanatory. :dd
{Target temperature for fix rigid/nvt cannot be 0.0} :dt
Self-explanatory. :dd
{Target temperature for fix rigid/nvt/small cannot be 0.0} :dt
Self-explanatory. :dd
{Temper command before simulation box is defined} :dt
The temper command cannot be used before a read_data, read_restart, or
create_box command. :dd
{Temperature ID for fix bond/swap does not exist} :dt
Self-explanatory. :dd
{Temperature ID for fix box/relax does not exist} :dt
Self-explanatory. :dd
{Temperature ID for fix nvt/npt does not exist} :dt
Self-explanatory. :dd
{Temperature ID for fix press/berendsen does not exist} :dt
Self-explanatory. :dd
{Temperature ID for fix rigid nvt/npt/nph does not exist} :dt
Self-explanatory. :dd
{Temperature ID for fix temp/berendsen does not exist} :dt
Self-explanatory. :dd
{Temperature ID for fix temp/csld does not exist} :dt
Self-explanatory. :dd
{Temperature ID for fix temp/csvr does not exist} :dt
Self-explanatory. :dd
{Temperature ID for fix temp/rescale does not exist} :dt
Self-explanatory. :dd
{Temperature compute degrees of freedom < 0} :dt
This should not happen if you are calculating the temperature
on a valid set of atoms. :dd
{Temperature control can not be used with fix nph} :dt
Self-explanatory. :dd
{Temperature control can not be used with fix nph/asphere} :dt
Self-explanatory. :dd
{Temperature control can not be used with fix nph/body} :dt
Self-explanatory. :dd
{Temperature control can not be used with fix nph/sphere} :dt
Self-explanatory. :dd
{Temperature control must be used with fix nphug} :dt
The temp keyword must be provided. :dd
{Temperature control must be used with fix npt} :dt
Self-explanatory. :dd
{Temperature control must be used with fix npt/asphere} :dt
Self-explanatory. :dd
{Temperature control must be used with fix npt/body} :dt
Self-explanatory. :dd
{Temperature control must be used with fix npt/sphere} :dt
Self-explanatory. :dd
{Temperature control must be used with fix nvt} :dt
Self-explanatory. :dd
{Temperature control must be used with fix nvt/asphere} :dt
Self-explanatory. :dd
{Temperature control must be used with fix nvt/body} :dt
Self-explanatory. :dd
{Temperature control must be used with fix nvt/sllod} :dt
Self-explanatory. :dd
{Temperature control must be used with fix nvt/sphere} :dt
Self-explanatory. :dd
{Temperature control must not be used with fix nph/small} :dt
Self-explanatory. :dd
{Temperature for fix nvt/sllod does not have a bias} :dt
The specified compute must compute temperature with a bias. :dd
{Tempering could not find thermo_pe compute} :dt
This compute is created by the thermo command. It must have been
explicitly deleted by a uncompute command. :dd
{Tempering fix ID is not defined} :dt
The fix ID specified by the temper command does not exist. :dd
{Tempering temperature fix is not valid} :dt
The fix specified by the temper command is not one that controls
temperature (nvt or langevin). :dd
{Test_descriptor_string already allocated} :dt
This is an internal error. Contact the developers. :dd
{The package gpu command is required for gpu styles} :dt
Self-explanatory. :dd
{Thermo and fix not computed at compatible times} :dt
Fixes generate values on specific timesteps. The thermo output
does not match these timesteps. :dd
{Thermo compute array is accessed out-of-range} :dt
Self-explanatory. :dd
{Thermo compute does not compute array} :dt
Self-explanatory. :dd
{Thermo compute does not compute scalar} :dt
Self-explanatory. :dd
{Thermo compute does not compute vector} :dt
Self-explanatory. :dd
{Thermo compute vector is accessed out-of-range} :dt
Self-explanatory. :dd
{Thermo custom variable cannot be indexed} :dt
Self-explanatory. :dd
{Thermo custom variable is not equal-style variable} :dt
Only equal-style variables can be output with thermodynamics, not
atom-style variables. :dd
{Thermo every variable returned a bad timestep} :dt
The variable must return a timestep greater than the current timestep. :dd
{Thermo fix array is accessed out-of-range} :dt
Self-explanatory. :dd
{Thermo fix does not compute array} :dt
Self-explanatory. :dd
{Thermo fix does not compute scalar} :dt
Self-explanatory. :dd
{Thermo fix does not compute vector} :dt
Self-explanatory. :dd
{Thermo fix vector is accessed out-of-range} :dt
Self-explanatory. :dd
{Thermo keyword in variable requires thermo to use/init pe} :dt
You are using a thermo keyword in a variable that requires
potential energy to be calculated, but your thermo output
does not use it. Add it to your thermo output. :dd
{Thermo keyword in variable requires thermo to use/init press} :dt
You are using a thermo keyword in a variable that requires pressure to
be calculated, but your thermo output does not use it. Add it to your
thermo output. :dd
{Thermo keyword in variable requires thermo to use/init temp} :dt
You are using a thermo keyword in a variable that requires temperature
to be calculated, but your thermo output does not use it. Add it to
your thermo output. :dd
{Thermo style does not use press} :dt
Cannot use thermo_modify to set this parameter since the thermo_style
is not computing this quantity. :dd
{Thermo style does not use temp} :dt
Cannot use thermo_modify to set this parameter since the thermo_style
is not computing this quantity. :dd
{Thermo_modify every variable returned a bad timestep} :dt
The returned timestep is less than or equal to the current timestep. :dd
{Thermo_modify int format does not contain d character} :dt
Self-explanatory. :dd
{Thermo_modify pressure ID does not compute pressure} :dt
The specified compute ID does not compute pressure. :dd
{Thermo_modify temperature ID does not compute temperature} :dt
The specified compute ID does not compute temperature. :dd
{Thermo_style command before simulation box is defined} :dt
The thermo_style command cannot be used before a read_data,
read_restart, or create_box command. :dd
{This variable thermo keyword cannot be used between runs} :dt
Keywords that refer to time (such as cpu, elapsed) do not
make sense in between runs. :dd
{Threshhold for an atom property that isn't allocated} :dt
A dump threshold has been requested on a quantity that is
not defined by the atom style used in this simulation. :dd
{Timestep must be >= 0} :dt
Specified timestep is invalid. :dd
{Too big a problem to use velocity create loop all} :dt
The system size must fit in a 32-bit integer to use this option. :dd
{Too big a timestep for dump dcd} :dt
The timestep must fit in a 32-bit integer to use this dump style. :dd
{Too big a timestep for dump xtc} :dt
The timestep must fit in a 32-bit integer to use this dump style. :dd
{Too few bits for lookup table} :dt
Table size specified via pair_modify command does not work with your
machine's floating point representation. :dd
{Too few lines in %s section of data file} :dt
Self-explanatory. :dd
{Too few values in body lines in data file} :dt
Self-explanatory. :dd
{Too few values in body section of molecule file} :dt
Self-explanatory. :dd
{Too many -pk arguments in command line} :dt
The string formed by concatenating the arguments is too long. Use a
package command in the input script instead. :dd
{Too many MSM grid levels} :dt
The max number of MSM grid levels is hardwired to 10. :dd
{Too many args in variable function} :dt
More args are used than any variable function allows. :dd
{Too many atom pairs for pair bop} :dt
The number of atomic pairs exceeds the expected number. Check your
atomic structure to ensure that it is realistic. :dd
{Too many atom sorting bins} :dt
This is likely due to an immense simulation box that has blown up
to a large size. :dd
{Too many atom triplets for pair bop} :dt
The number of three atom groups for angle determinations exceeds the
expected number. Check your atomic structure to ensure that it is
realistic. :dd
{Too many atoms for dump dcd} :dt
The system size must fit in a 32-bit integer to use this dump
style. :dd
{Too many atoms for dump xtc} :dt
The system size must fit in a 32-bit integer to use this dump
style. :dd
{Too many atoms to dump sort} :dt
Cannot sort when running with more than 2^31 atoms. :dd
{Too many exponent bits for lookup table} :dt
Table size specified via pair_modify command does not work with your
machine's floating point representation. :dd
{Too many groups} :dt
The maximum number of atom groups (including the "all" group) is
given by MAX_GROUP in group.cpp and is 32. :dd
{Too many iterations} :dt
You must use a number of iterations that fit in a 32-bit integer
for minimization. :dd
{Too many lines in one body in data file - boost MAXBODY} :dt
MAXBODY is a setting at the top of the src/read_data.cpp file.
Set it larger and re-compile the code. :dd
{Too many local+ghost atoms for neighbor list} :dt
The number of nlocal + nghost atoms on a processor
is limited by the size of a 32-bit integer with 2 bits
removed for masking 1-2, 1-3, 1-4 neighbors. :dd
{Too many mantissa bits for lookup table} :dt
Table size specified via pair_modify command does not work with your
machine's floating point representation. :dd
{Too many masses for fix shake} :dt
The fix shake command cannot list more masses than there are atom
types. :dd
{Too many molecules for fix poems} :dt
The limit is 2^31 = ~2 billion molecules. :dd
{Too many molecules for fix rigid} :dt
The limit is 2^31 = ~2 billion molecules. :dd
{Too many neighbor bins} :dt
This is likely due to an immense simulation box that has blown up
to a large size. :dd
{Too many timesteps} :dt
The cumulative timesteps must fit in a 64-bit integer. :dd
{Too many timesteps for NEB} :dt
You must use a number of timesteps that fit in a 32-bit integer
for NEB. :dd
{Too many total atoms} :dt
See the setting for bigint in the src/lmptype.h file. :dd
{Too many total bits for bitmapped lookup table} :dt
Table size specified via pair_modify command is too large. Note that
a value of N generates a 2^N size table. :dd
{Too many values in body lines in data file} :dt
Self-explanatory. :dd
{Too many values in body section of molecule file} :dt
Self-explanatory. :dd
{Too much buffered per-proc info for dump} :dt
The size of the buffered string must fit in a 32-bit integer for a
dump. :dd
{Too much per-proc info for dump} :dt
Number of local atoms times number of columns must fit in a 32-bit
integer for dump. :dd
{Tree structure in joint connections} :dt
Fix poems cannot (yet) work with coupled bodies whose joints connect
the bodies in a tree structure. :dd
{Triclinic box skew is too large} :dt
The displacement in a skewed direction must be less than half the box
length in that dimension. E.g. the xy tilt must be between -half and
+half of the x box length. This constraint can be relaxed by using
the box tilt command. :dd
{Tried to convert a double to int, but input_double > INT_MAX} :dt
Self-explanatory. :dd
{Trying to build an occasional neighbor list before initialization completed} :dt
This is not allowed. Source code caller needs to be modified. :dd
{Two fix ave commands using same compute chunk/atom command in incompatible ways} :dt
They are both attempting to "lock" the chunk/atom command so that the
chunk assignments persist for some number of timesteps, but are doing
it in different ways. :dd
{Two groups cannot be the same in fix spring couple} :dt
Self-explanatory. :dd
{USER-CUDA mode requires CUDA variant of min style} :dt
CUDA mode is enabled, so the min style must include a cuda suffix. :dd
{USER-CUDA mode requires CUDA variant of run style} :dt
CUDA mode is enabled, so the run style must include a cuda suffix. :dd
{USER-CUDA package does not yet support comm_style tiled} :dt
Self-explanatory. :dd
{USER-CUDA package requires a cuda enabled atom_style} :dt
Self-explanatory. :dd
{Unable to initialize accelerator for use} :dt
There was a problem initializing an accelerator for the gpu package :dd
{Unbalanced quotes in input line} :dt
No matching end double quote was found following a leading double
quote. :dd
{Unexpected end of -reorder file} :dt
Self-explanatory. :dd
{Unexpected end of AngleCoeffs section} :dt
Read a blank line. :dd
{Unexpected end of BondCoeffs section} :dt
Read a blank line. :dd
{Unexpected end of DihedralCoeffs section} :dt
Read a blank line. :dd
{Unexpected end of ImproperCoeffs section} :dt
Read a blank line. :dd
{Unexpected end of PairCoeffs section} :dt
Read a blank line. :dd
{Unexpected end of custom file} :dt
Self-explanatory. :dd
{Unexpected end of data file} :dt
LAMMPS hit the end of the data file while attempting to read a
section. Something is wrong with the format of the data file. :dd
{Unexpected end of dump file} :dt
A read operation from the file failed. :dd
{Unexpected end of fix rigid file} :dt
A read operation from the file failed. :dd
{Unexpected end of fix rigid/small file} :dt
A read operation from the file failed. :dd
{Unexpected end of molecule file} :dt
Self-explanatory. :dd
{Unexpected end of neb file} :dt
A read operation from the file failed. :dd
{Units command after simulation box is defined} :dt
The units command cannot be used after a read_data, read_restart, or
create_box command. :dd
{Universe/uloop variable count < # of partitions} :dt
A universe or uloop style variable must specify a number of values >= to the
number of processor partitions. :dd
{Unknown angle style} :dt
The choice of angle style is unknown. :dd
{Unknown atom style} :dt
The choice of atom style is unknown. :dd
{Unknown body style} :dt
The choice of body style is unknown. :dd
{Unknown bond style} :dt
The choice of bond style is unknown. :dd
{Unknown category for info is_active()} :dt
Self-explanatory. :dd
{Unknown category for info is_available()} :dt
Self-explanatory. :dd
{Unknown category for info is_defined()} :dt
Self-explanatory. :dd
{Unknown command: %s} :dt
The command is not known to LAMMPS. Check the input script. :dd
{Unknown compute style} :dt
The choice of compute style is unknown. :dd
{Unknown dihedral style} :dt
The choice of dihedral style is unknown. :dd
{Unknown dump reader style} :dt
The choice of dump reader style via the format keyword is unknown. :dd
{Unknown dump style} :dt
The choice of dump style is unknown. :dd
{Unknown error in GPU library} :dt
Self-explanatory. :dd
{Unknown fix style} :dt
The choice of fix style is unknown. :dd
{Unknown identifier in data file: %s} :dt
A section of the data file cannot be read by LAMMPS. :dd
{Unknown improper style} :dt
The choice of improper style is unknown. :dd
{Unknown keyword in thermo_style custom command} :dt
One or more specified keywords are not recognized. :dd
{Unknown kspace style} :dt
The choice of kspace style is unknown. :dd
{Unknown name for info newton category} :dt
Self-explanatory. :dd
{Unknown name for info package category} :dt
Self-explanatory. :dd
{Unknown name for info pair category} :dt
Self-explanatory. :dd
{Unknown pair style} :dt
The choice of pair style is unknown. :dd
{Unknown pair_modify hybrid sub-style} :dt
The choice of sub-style is unknown. :dd
{Unknown region style} :dt
The choice of region style is unknown. :dd
{Unknown section in molecule file} :dt
Self-explanatory. :dd
{Unknown table style in angle style table} :dt
Self-explanatory. :dd
{Unknown table style in bond style table} :dt
Self-explanatory. :dd
{Unknown table style in pair_style command} :dt
Style of table is invalid for use with pair_style table command. :dd
{Unknown unit_style} :dt
Self-explanatory. Check the input script or data file. :dd
{Unrecognized lattice type in MEAM file 1} :dt
The lattice type in an entry of the MEAM library file is not
valid. :dd
{Unrecognized lattice type in MEAM file 2} :dt
The lattice type in an entry of the MEAM parameter file is not
valid. :dd
{Unrecognized pair style in compute pair command} :dt
Self-explanatory. :dd
{Unrecognized virial argument in pair_style command} :dt
Only two options are supported: LAMMPSvirial and KIMvirial :dd
{Unsupported mixing rule in kspace_style ewald/disp} :dt
Only geometric mixing is supported. :dd
{Unsupported order in kspace_style ewald/disp} :dt
Only 1/r^6 dispersion or dipole terms are supported. :dd
{Unsupported order in kspace_style pppm/disp, pair_style %s} :dt
Only pair styles with 1/r and 1/r^6 dependence are currently supported. :dd
{Use cutoff keyword to set cutoff in single mode} :dt
Mode is single so cutoff/multi keyword cannot be used. :dd
{Use cutoff/multi keyword to set cutoff in multi mode} :dt
Mode is multi so cutoff keyword cannot be used. :dd
{Using fix nvt/sllod with inconsistent fix deform remap option} :dt
Fix nvt/sllod requires that deforming atoms have a velocity profile
provided by "remap v" as a fix deform option. :dd
{Using fix nvt/sllod with no fix deform defined} :dt
Self-explanatory. :dd
{Using fix srd with inconsistent fix deform remap option} :dt
When shearing the box in an SRD simulation, the remap v option for fix
deform needs to be used. :dd
{Using pair lubricate with inconsistent fix deform remap option} :dt
Must use remap v option with fix deform with this pair style. :dd
{Using pair lubricate/poly with inconsistent fix deform remap option} :dt
If fix deform is used, the remap v option is required. :dd
{Using suffix cuda without USER-CUDA package enabled} :dt
Self-explanatory. :dd
{Using suffix gpu without GPU package installed} :dt
Self-explanatory. :dd
{Using suffix intel without USER-INTEL package installed} :dt
Self-explanatory. :dd
{Using suffix kk without KOKKOS package enabled} :dt
Self-explanatory. :dd
{Using suffix omp without USER-OMP package installed} :dt
Self-explanatory. :dd
{Using update dipole flag requires atom attribute mu} :dt
Self-explanatory. :dd
{Using update dipole flag requires atom style sphere} :dt
Self-explanatory. :dd
{Variable ID in variable formula does not exist} :dt
Self-explanatory. :dd
{Variable atom ID is too large} :dt
Specified ID is larger than the maximum allowed atom ID. :dd
{Variable evaluation before simulation box is defined} :dt
Cannot evaluate a compute or fix or atom-based value in a variable
before the simulation has been setup. :dd
{Variable evaluation in fix wall gave bad value} :dt
The returned value for epsilon or sigma < 0.0. :dd
{Variable evaluation in region gave bad value} :dt
Variable returned a radius < 0.0. :dd
{Variable for compute ti is invalid style} :dt
Self-explanatory. :dd
{Variable for create_atoms is invalid style} :dt
The variables must be equal-style variables. :dd
{Variable for displace_atoms is invalid style} :dt
It must be an equal-style or atom-style variable. :dd
{Variable for dump every is invalid style} :dt
Only equal-style variables can be used. :dd
{Variable for dump image center is invalid style} :dt
Must be an equal-style variable. :dd
{Variable for dump image persp is invalid style} :dt
Must be an equal-style variable. :dd
{Variable for dump image phi is invalid style} :dt
Must be an equal-style variable. :dd
{Variable for dump image theta is invalid style} :dt
Must be an equal-style variable. :dd
{Variable for dump image zoom is invalid style} :dt
Must be an equal-style variable. :dd
{Variable for fix adapt is invalid style} :dt
Only equal-style variables can be used. :dd
{Variable for fix addforce is invalid style} :dt
Self-explanatory. :dd
{Variable for fix aveforce is invalid style} :dt
Only equal-style variables can be used. :dd
{Variable for fix deform is invalid style} :dt
The variable must be an equal-style variable. :dd
{Variable for fix efield is invalid style} :dt
The variable must be an equal- or atom-style variable. :dd
{Variable for fix gravity is invalid style} :dt
Only equal-style variables can be used. :dd
{Variable for fix heat is invalid style} :dt
Only equal-style or atom-style variables can be used. :dd
{Variable for fix indent is invalid style} :dt
Only equal-style variables can be used. :dd
{Variable for fix indent is not equal style} :dt
Only equal-style variables can be used. :dd
{Variable for fix langevin is invalid style} :dt
It must be an equal-style variable. :dd
{Variable for fix move is invalid style} :dt
Only equal-style variables can be used. :dd
{Variable for fix setforce is invalid style} :dt
Only equal-style variables can be used. :dd
{Variable for fix temp/berendsen is invalid style} :dt
Only equal-style variables can be used. :dd
{Variable for fix temp/csld is invalid style} :dt
Only equal-style variables can be used. :dd
{Variable for fix temp/csvr is invalid style} :dt
Only equal-style variables can be used. :dd
{Variable for fix temp/rescale is invalid style} :dt
Only equal-style variables can be used. :dd
{Variable for fix wall is invalid style} :dt
Only equal-style variables can be used. :dd
{Variable for fix wall/reflect is invalid style} :dt
Only equal-style variables can be used. :dd
{Variable for fix wall/srd is invalid style} :dt
Only equal-style variables can be used. :dd
{Variable for group dynamic is invalid style} :dt
The variable must be an atom-style variable. :dd
{Variable for group is invalid style} :dt
Only atom-style variables can be used. :dd
{Variable for region cylinder is invalid style} :dt
Only equal-style variables are allowed. :dd
{Variable for region is invalid style} :dt
Only equal-style variables can be used. :dd
{Variable for region is not equal style} :dt
Self-explanatory. :dd
{Variable for region sphere is invalid style} :dt
Only equal-style variables are allowed. :dd
{Variable for restart is invalid style} :dt
Only equal-style variables can be used. :dd
{Variable for set command is invalid style} :dt
Only atom-style variables can be used. :dd
{Variable for thermo every is invalid style} :dt
Only equal-style variables can be used. :dd
{Variable for velocity set is invalid style} :dt
Only atom-style variables can be used. :dd
{Variable for voronoi radius is not atom style} :dt
Self-explanatory. :dd
{Variable formula compute array is accessed out-of-range} :dt
Self-explanatory. :dd
{Variable formula compute vector is accessed out-of-range} :dt
Self-explanatory. :dd
{Variable formula fix array is accessed out-of-range} :dt
Self-explanatory. :dd
{Variable formula fix vector is accessed out-of-range} :dt
Self-explanatory. :dd
{Variable has circular dependency} :dt
A circular dependency is when variable "a" in used by variable "b" and
variable "b" is also used by variable "a". Circular dependencies with
longer chains of dependence are also not allowed. :dd
{Variable name between brackets must be alphanumeric or underscore characters} :dt
Self-explanatory. :dd
{Variable name for compute chunk/atom does not exist} :dt
Self-explanatory. :dd
{Variable name for compute reduce does not exist} :dt
Self-explanatory. :dd
{Variable name for compute ti does not exist} :dt
Self-explanatory. :dd
{Variable name for create_atoms does not exist} :dt
Self-explanatory. :dd
{Variable name for displace_atoms does not exist} :dt
Self-explanatory. :dd
{Variable name for dump every does not exist} :dt
Self-explanatory. :dd
{Variable name for dump image center does not exist} :dt
Self-explanatory. :dd
{Variable name for dump image persp does not exist} :dt
Self-explanatory. :dd
{Variable name for dump image phi does not exist} :dt
Self-explanatory. :dd
{Variable name for dump image theta does not exist} :dt
Self-explanatory. :dd
{Variable name for dump image zoom does not exist} :dt
Self-explanatory. :dd
{Variable name for fix adapt does not exist} :dt
Self-explanatory. :dd
{Variable name for fix addforce does not exist} :dt
Self-explanatory. :dd
{Variable name for fix ave/atom does not exist} :dt
Self-explanatory. :dd
{Variable name for fix ave/chunk does not exist} :dt
Self-explanatory. :dd
{Variable name for fix ave/correlate does not exist} :dt
Self-explanatory. :dd
{Variable name for fix ave/histo does not exist} :dt
Self-explanatory. :dd
{Variable name for fix ave/spatial does not exist} :dt
Self-explanatory. :dd
{Variable name for fix ave/time does not exist} :dt
Self-explanatory. :dd
{Variable name for fix aveforce does not exist} :dt
Self-explanatory. :dd
{Variable name for fix deform does not exist} :dt
Self-explanatory. :dd
{Variable name for fix efield does not exist} :dt
Self-explanatory. :dd
{Variable name for fix gravity does not exist} :dt
Self-explanatory. :dd
{Variable name for fix heat does not exist} :dt
Self-explanatory. :dd
{Variable name for fix indent does not exist} :dt
Self-explanatory. :dd
{Variable name for fix langevin does not exist} :dt
Self-explanatory. :dd
{Variable name for fix move does not exist} :dt
Self-explanatory. :dd
{Variable name for fix setforce does not exist} :dt
Self-explanatory. :dd
{Variable name for fix store/state does not exist} :dt
Self-explanatory. :dd
{Variable name for fix temp/berendsen does not exist} :dt
Self-explanatory. :dd
{Variable name for fix temp/csld does not exist} :dt
Self-explanatory. :dd
{Variable name for fix temp/csvr does not exist} :dt
Self-explanatory. :dd
{Variable name for fix temp/rescale does not exist} :dt
Self-explanatory. :dd
{Variable name for fix vector does not exist} :dt
Self-explanatory. :dd
{Variable name for fix wall does not exist} :dt
Self-explanatory. :dd
{Variable name for fix wall/reflect does not exist} :dt
Self-explanatory. :dd
{Variable name for fix wall/srd does not exist} :dt
Self-explanatory. :dd
{Variable name for group does not exist} :dt
Self-explanatory. :dd
{Variable name for group dynamic does not exist} :dt
Self-explanatory. :dd
{Variable name for region cylinder does not exist} :dt
Self-explanatory. :dd
{Variable name for region does not exist} :dt
Self-explanatory. :dd
{Variable name for region sphere does not exist} :dt
Self-explanatory. :dd
{Variable name for restart does not exist} :dt
Self-explanatory. :dd
{Variable name for set command does not exist} :dt
Self-explanatory. :dd
{Variable name for thermo every does not exist} :dt
Self-explanatory. :dd
{Variable name for velocity set does not exist} :dt
Self-explanatory. :dd
{Variable name for voronoi radius does not exist} :dt
Self-explanatory. :dd
{Variable name must be alphanumeric or underscore characters} :dt
Self-explanatory. :dd
{Variable uses atom property that isn't allocated} :dt
Self-explanatory. :dd
{Velocity command before simulation box is defined} :dt
The velocity command cannot be used before a read_data, read_restart,
or create_box command. :dd
{Velocity command with no atoms existing} :dt
A velocity command has been used, but no atoms yet exist. :dd
{Velocity ramp in z for a 2d problem} :dt
Self-explanatory. :dd
{Velocity rigid used with non-rigid fix-ID} :dt
Self-explanatory. :dd
{Velocity temperature ID does calculate a velocity bias} :dt
The specified compute must compute a bias for temperature. :dd
{Velocity temperature ID does not compute temperature} :dt
The compute ID given to the velocity command must compute
temperature. :dd
{Verlet/split can only currently be used with comm_style brick} :dt
This is a current restriction in LAMMPS. :dd
{Verlet/split does not yet support TIP4P} :dt
This is a current limitation. :dd
{Verlet/split requires 2 partitions} :dt
See the -partition command-line switch. :dd
{Verlet/split requires Rspace partition layout be multiple of Kspace partition layout in each dim} :dt
This is controlled by the processors command. :dd
{Verlet/split requires Rspace partition size be multiple of Kspace partition size} :dt
This is so there is an equal number of Rspace processors for every
Kspace processor. :dd
{Virial was not tallied on needed timestep} :dt
You are using a thermo keyword that requires potentials to
have tallied the virial, but they didn't on this timestep. See the
variable doc page for ideas on how to make this work. :dd
{Voro++ error: narea and neigh have a different size} :dt
This error is returned by the Voro++ library. :dd
{Wall defined twice in fix wall command} :dt
Self-explanatory. :dd
{Wall defined twice in fix wall/reflect command} :dt
Self-explanatory. :dd
{Wall defined twice in fix wall/srd command} :dt
Self-explanatory. :dd
{Water H epsilon must be 0.0 for pair style lj/cut/tip4p/cut} :dt
This is because LAMMPS does not compute the Lennard-Jones interactions
with these particles for efficiency reasons. :dd
{Water H epsilon must be 0.0 for pair style lj/cut/tip4p/long} :dt
This is because LAMMPS does not compute the Lennard-Jones interactions
with these particles for efficiency reasons. :dd
{Water H epsilon must be 0.0 for pair style lj/long/tip4p/long} :dt
This is because LAMMPS does not compute the Lennard-Jones interactions
with these particles for efficiency reasons. :dd
{World variable count doesn't match # of partitions} :dt
A world-style variable must specify a number of values equal to the
number of processor partitions. :dd
{Write_data command before simulation box is defined} :dt
Self-explanatory. :dd
{Write_restart command before simulation box is defined} :dt
The write_restart command cannot be used before a read_data,
read_restart, or create_box command. :dd
{Writing to MPI-IO filename when MPIIO package is not installed} :dt
Self-explanatory. :dd
{Zero length rotation vector with displace_atoms} :dt
Self-explanatory. :dd
{Zero length rotation vector with fix move} :dt
Self-explanatory. :dd
{Zero-length lattice orient vector} :dt
Self-explanatory. :dd
:dle
Warnings: :h4,link(warn)
:dlb
{Adjusting Coulombic cutoff for MSM, new cutoff = %g} :dt
The adjust/cutoff command is turned on and the Coulombic cutoff has been
adjusted to match the user-specified accuracy. :dd
{Angle atoms missing at step %ld} :dt
One or more of 3 atoms needed to compute a particular angle are
missing on this processor. Typically this is because the pairwise
cutoff is set too short or the angle has blown apart and an atom is
too far away. :dd
{Angle style in data file differs from currently defined angle style} :dt
Self-explanatory. :dd
{Atom style in data file differs from currently defined atom style} :dt
Self-explanatory. :dd
{Bond atom missing in box size check} :dt
The 2nd atoms needed to compute a particular bond is missing on this
processor. Typically this is because the pairwise cutoff is set too
short or the bond has blown apart and an atom is too far away. :dd
{Bond atom missing in image check} :dt
The 2nd atom in a particular bond is missing on this processor.
Typically this is because the pairwise cutoff is set too short or the
bond has blown apart and an atom is too far away. :dd
{Bond atoms missing at step %ld} :dt
The 2nd atom needed to compute a particular bond is missing on this
processor. Typically this is because the pairwise cutoff is set too
short or the bond has blown apart and an atom is too far away. :dd
{Bond style in data file differs from currently defined bond style} :dt
Self-explanatory. :dd
{Bond/angle/dihedral extent > half of periodic box length} :dt
This is a restriction because LAMMPS can be confused about which image
of an atom in the bonded interaction is the correct one to use.
"Extent" in this context means the maximum end-to-end length of the
bond/angle/dihedral. LAMMPS computes this by taking the maximum bond
length, multiplying by the number of bonds in the interaction (e.g. 3
for a dihedral) and adding a small amount of stretch. :dd
{Both groups in compute group/group have a net charge; the Kspace boundary correction to energy will be non-zero} :dt
Self-explanatory. :dd
{Calling write_dump before a full system init.} :dt
The write_dump command is used before the system has been fully
initialized as part of a 'run' or 'minimize' command. Not all dump
styles and features are fully supported at this point and thus the
command may fail or produce incomplete or incorrect output. Insert
a "run 0" command, if a full system init is required. :dd
{Cannot count rigid body degrees-of-freedom before bodies are fully initialized} :dt
This means the temperature associated with the rigid bodies may be
incorrect on this timestep. :dd
{Cannot count rigid body degrees-of-freedom before bodies are initialized} :dt
This means the temperature associated with the rigid bodies may be
incorrect on this timestep. :dd
{Cannot include log terms without 1/r terms; setting flagHI to 1} :dt
Self-explanatory. :dd
{Cannot include log terms without 1/r terms; setting flagHI to 1.} :dt
Self-explanatory. :dd
{Charges are set, but coulombic solver is not used} :dt
Self-explanatory. :dd
{Charges did not converge at step %ld: %lg} :dt
Self-explanatory. :dd
{Communication cutoff is too small for SNAP micro load balancing, increased to %lf} :dt
Self-explanatory. :dd
{Compute cna/atom cutoff may be too large to find ghost atom neighbors} :dt
The neighbor cutoff used may not encompass enough ghost atoms
to perform this operation correctly. :dd
{Computing temperature of portions of rigid bodies} :dt
The group defined by the temperature compute does not encompass all
the atoms in one or more rigid bodies, so the change in
degrees-of-freedom for the atoms in those partial rigid bodies will
not be accounted for. :dd
{Create_bonds max distance > minimum neighbor cutoff} :dt
This means atom pairs for some atom types may not be in the neighbor
list and thus no bond can be created between them. :dd
{Delete_atoms cutoff > minimum neighbor cutoff} :dt
This means atom pairs for some atom types may not be in the neighbor
list and thus an atom in that pair cannot be deleted. :dd
{Dihedral atoms missing at step %ld} :dt
One or more of 4 atoms needed to compute a particular dihedral are
missing on this processor. Typically this is because the pairwise
cutoff is set too short or the dihedral has blown apart and an atom is
too far away. :dd
{Dihedral problem} :dt
Conformation of the 4 listed dihedral atoms is extreme; you may want
to check your simulation geometry. :dd
{Dihedral problem: %d %ld %d %d %d %d} :dt
Conformation of the 4 listed dihedral atoms is extreme; you may want
to check your simulation geometry. :dd
{Dihedral style in data file differs from currently defined dihedral style} :dt
Self-explanatory. :dd
{Dump dcd/xtc timestamp may be wrong with fix dt/reset} :dt
If the fix changes the timestep, the dump dcd file will not
reflect the change. :dd
{Energy due to X extra global DOFs will be included in minimizer energies} :dt
When using fixes like box/relax, the potential energy used by the minimizer
is augmented by an additional energy provided by the fix. Thus the printed
converged energy may be different from the total potential energy. :dd
{Energy tally does not account for 'zero yes'} :dt
The energy removed by using the 'zero yes' flag is not accounted
for in the energy tally and thus energy conservation cannot be
monitored in this case. :dd
{Estimated error in splitting of dispersion coeffs is %g} :dt
Error is greater than 0.0001 percent. :dd
{Ewald/disp Newton solver failed, using old method to estimate g_ewald} :dt
Self-explanatory. Choosing a different cutoff value may help. :dd
{FENE bond too long} :dt
A FENE bond has stretched dangerously far. It's interaction strength
will be truncated to attempt to prevent the bond from blowing up. :dd
{FENE bond too long: %ld %d %d %g} :dt
A FENE bond has stretched dangerously far. It's interaction strength
will be truncated to attempt to prevent the bond from blowing up. :dd
{FENE bond too long: %ld %g} :dt
A FENE bond has stretched dangerously far. It's interaction strength
will be truncated to attempt to prevent the bond from blowing up. :dd
{Fix SRD walls overlap but fix srd overlap not set} :dt
You likely want to set this in your input script. :dd
{Fix bond/swap will ignore defined angles} :dt
See the doc page for fix bond/swap for more info on this
restriction. :dd
{Fix deposit near setting < possible overlap separation %g} :dt
This test is performed for finite size particles with a diameter, not
for point particles. The near setting is smaller than the particle
diameter which can lead to overlaps. :dd
{Fix evaporate may delete atom with non-zero molecule ID} :dt
This is probably an error, since you should not delete only one atom
of a molecule. :dd
{Fix gcmc using full_energy option} :dt
Fix gcmc has automatically turned on the full_energy option since it
is required for systems like the one specified by the user. User input
included one or more of the following: kspace, triclinic, a hybrid
pair style, an eam pair style, or no "single" function for the pair
style. :dd
{Fix property/atom mol or charge w/out ghost communication} :dt
A model typically needs these properties defined for ghost atoms. :dd
{Fix qeq CG convergence failed (%g) after %d iterations at %ld step} :dt
Self-explanatory. :dd
{Fix qeq has non-zero lower Taper radius cutoff} :dt
Absolute value must be <= 0.01. :dd
{Fix qeq has very low Taper radius cutoff} :dt
Value should typically be >= 5.0. :dd
{Fix qeq/dynamic tolerance may be too small for damped dynamics} :dt
Self-explanatory. :dd
{Fix qeq/fire tolerance may be too small for damped fires} :dt
Self-explanatory. :dd
{Fix rattle should come after all other integration fixes} :dt
This fix is designed to work after all other integration fixes change
atom positions. Thus it should be the last integration fix specified.
If not, it will not satisfy the desired constraints as well as it
otherwise would. :dd
{Fix recenter should come after all other integration fixes} :dt
Other fixes may change the position of the center-of-mass, so
fix recenter should come last. :dd
{Fix srd SRD moves may trigger frequent reneighboring} :dt
This is because the SRD particles may move long distances. :dd
{Fix srd grid size > 1/4 of big particle diameter} :dt
This may cause accuracy problems. :dd
{Fix srd particle moved outside valid domain} :dt
This may indicate a problem with your simulation parameters. :dd
{Fix srd particles may move > big particle diameter} :dt
This may cause accuracy problems. :dd
{Fix srd viscosity < 0.0 due to low SRD density} :dt
This may cause accuracy problems. :dd
{Fix thermal/conductivity comes before fix ave/spatial} :dt
The order of these 2 fixes in your input script is such that fix
thermal/conductivity comes first. If you are using fix ave/spatial to
measure the temperature profile induced by fix viscosity, then this
may cause a glitch in the profile since you are averaging immediately
after swaps have occurred. Flipping the order of the 2 fixes
typically helps. :dd
{Fix viscosity comes before fix ave/spatial} :dt
The order of these 2 fixes in your input script is such that
fix viscosity comes first. If you are using fix ave/spatial
to measure the velocity profile induced by fix viscosity, then
this may cause a glitch in the profile since you are averaging
immediately after swaps have occurred. Flipping the order
of the 2 fixes typically helps. :dd
{Fixes cannot send data in Kokkos communication, switching to classic communication} :dt
This is current restriction with Kokkos. :dd
{For better accuracy use 'pair_modify table 0'} :dt
The user-specified force accuracy cannot be achieved unless the table
feature is disabled by using 'pair_modify table 0'. :dd
{Geometric mixing assumed for 1/r^6 coefficients} :dt
Self-explanatory. :dd
{Group for fix_modify temp != fix group} :dt
The fix_modify command is specifying a temperature computation that
computes a temperature on a different group of atoms than the fix
itself operates on. This is probably not what you want to do. :dd
{H matrix size has been exceeded: m_fill=%d H.m=%d\n} :dt
This is the size of the matrix. :dd
{Ignoring unknown or incorrect info command flag} :dt
Self-explanatory. An unknown argument was given to the info command.
Compare your input with the documentation. :dd
{Improper atoms missing at step %ld} :dt
One or more of 4 atoms needed to compute a particular improper are
missing on this processor. Typically this is because the pairwise
cutoff is set too short or the improper has blown apart and an atom is
too far away. :dd
{Improper problem: %d %ld %d %d %d %d} :dt
Conformation of the 4 listed improper atoms is extreme; you may want
to check your simulation geometry. :dd
{Improper style in data file differs from currently defined improper style} :dt
Self-explanatory. :dd
{Inconsistent image flags} :dt
The image flags for a pair on bonded atoms appear to be inconsistent.
Inconsistent means that when the coordinates of the two atoms are
unwrapped using the image flags, the two atoms are far apart.
Specifically they are further apart than half a periodic box length.
Or they are more than a box length apart in a non-periodic dimension.
This is usually due to the initial data file not having correct image
flags for the 2 atoms in a bond that straddles a periodic boundary.
They should be different by 1 in that case. This is a warning because
inconsistent image flags will not cause problems for dynamics or most
LAMMPS simulations. However they can cause problems when such atoms
are used with the fix rigid or replicate commands. Note that if you
have an infinite periodic crystal with bonds then it is impossible to
have fully consistent image flags, since some bonds will cross
periodic boundaries and connect two atoms with the same image
flag. :dd
{KIM Model does not provide 'energy'; Potential energy will be zero} :dt
Self-explanatory. :dd
{KIM Model does not provide 'forces'; Forces will be zero} :dt
Self-explanatory. :dd
{KIM Model does not provide 'particleEnergy'; energy per atom will be zero} :dt
Self-explanatory. :dd
{KIM Model does not provide 'particleVirial'; virial per atom will be zero} :dt
Self-explanatory. :dd
{Kspace_modify slab param < 2.0 may cause unphysical behavior} :dt
The kspace_modify slab parameter should be larger to insure periodic
grids padded with empty space do not overlap. :dd
{Less insertions than requested} :dt
The fix pour command was unsuccessful at finding open space
for as many particles as it tried to insert. :dd
{Library error in lammps_gather_atoms} :dt
This library function cannot be used if atom IDs are not defined
or are not consecutively numbered. :dd
{Library error in lammps_scatter_atoms} :dt
This library function cannot be used if atom IDs are not defined or
are not consecutively numbered, or if no atom map is defined. See the
atom_modify command for details about atom maps. :dd
{Lost atoms via change_box: original %ld current %ld} :dt
The command options you have used caused atoms to be lost. :dd
{Lost atoms via displace_atoms: original %ld current %ld} :dt
The command options you have used caused atoms to be lost. :dd
{Lost atoms: original %ld current %ld} :dt
Lost atoms are checked for each time thermo output is done. See the
thermo_modify lost command for options. Lost atoms usually indicate
bad dynamics, e.g. atoms have been blown far out of the simulation
box, or moved further than one processor's sub-domain away before
reneighboring. :dd
{MSM mesh too small, increasing to 2 points in each direction} :dt
Self-explanatory. :dd
{Mismatch between velocity and compute groups} :dt
The temperature computation used by the velocity command will not be
on the same group of atoms that velocities are being set for. :dd
{Mixing forced for lj coefficients} :dt
Self-explanatory. :dd
{Molecule attributes do not match system attributes} :dt
An attribute is specified (e.g. diameter, charge) that is
not defined for the specified atom style. :dd
{Molecule has bond topology but no special bond settings} :dt
This means the bonded atoms will not be excluded in pair-wise
interactions. :dd
{Molecule template for create_atoms has multiple molecules} :dt
The create_atoms command will only create molecules of a single type,
i.e. the first molecule in the template. :dd
{Molecule template for fix gcmc has multiple molecules} :dt
The fix gcmc command will only create molecules of a single type,
i.e. the first molecule in the template. :dd
{Molecule template for fix shake has multiple molecules} :dt
The fix shake command will only recognize molecules of a single
type, i.e. the first molecule in the template. :dd
{More than one compute centro/atom} :dt
It is not efficient to use compute centro/atom more than once. :dd
{More than one compute cluster/atom} :dt
It is not efficient to use compute cluster/atom more than once. :dd
{More than one compute cna/atom defined} :dt
It is not efficient to use compute cna/atom more than once. :dd
{More than one compute contact/atom} :dt
It is not efficient to use compute contact/atom more than once. :dd
{More than one compute coord/atom} :dt
It is not efficient to use compute coord/atom more than once. :dd
{More than one compute damage/atom} :dt
It is not efficient to use compute ke/atom more than once. :dd
{More than one compute dilatation/atom} :dt
Self-explanatory. :dd
{More than one compute erotate/sphere/atom} :dt
It is not efficient to use compute erorate/sphere/atom more than once. :dd
{More than one compute hexorder/atom} :dt
It is not efficient to use compute hexorder/atom more than once. :dd
{More than one compute ke/atom} :dt
It is not efficient to use compute ke/atom more than once. :dd
{More than one compute orientorder/atom} :dt
It is not efficient to use compute orientorder/atom more than once. :dd
{More than one compute plasticity/atom} :dt
Self-explanatory. :dd
{More than one compute sna/atom} :dt
Self-explanatory. :dd
{More than one compute snad/atom} :dt
Self-explanatory. :dd
{More than one compute snav/atom} :dt
Self-explanatory. :dd
{More than one fix poems} :dt
It is not efficient to use fix poems more than once. :dd
{More than one fix rigid} :dt
It is not efficient to use fix rigid more than once. :dd
{Neighbor exclusions used with KSpace solver may give inconsistent Coulombic energies} :dt
This is because excluding specific pair interactions also excludes
them from long-range interactions which may not be the desired effect.
The special_bonds command handles this consistently by insuring
excluded (or weighted) 1-2, 1-3, 1-4 interactions are treated
consistently by both the short-range pair style and the long-range
solver. This is not done for exclusions of charged atom pairs via the
neigh_modify exclude command. :dd
{New thermo_style command, previous thermo_modify settings will be lost} :dt
If a thermo_style command is used after a thermo_modify command, the
settings changed by the thermo_modify command will be reset to their
default values. This is because the thermo_modify command acts on
the currently defined thermo style, and a thermo_style command creates
a new style. :dd
{No Kspace calculation with verlet/split} :dt
The 2nd partition performs a kspace calculation so the kspace_style
command must be used. :dd
{No automatic unit conversion to XTC file format conventions possible for units lj} :dt
This means no scaling will be performed. :dd
{No fixes defined, atoms won't move} :dt
If you are not using a fix like nve, nvt, npt then atom velocities and
coordinates will not be updated during timestepping. :dd
{No joints between rigid bodies, use fix rigid instead} :dt
The bodies defined by fix poems are not connected by joints. POEMS
will integrate the body motion, but it would be more efficient to use
fix rigid. :dd
{Not using real units with pair reax} :dt
This is most likely an error, unless you have created your own ReaxFF
parameter file in a different set of units. :dd
{Number of MSM mesh points changed to be a multiple of 2} :dt
MSM requires that the number of grid points in each direction be a multiple
of two and the number of grid points in one or more directions have been
adjusted to meet this requirement. :dd
{OMP_NUM_THREADS environment is not set.} :dt
This environment variable must be set appropriately to use the
USER-OMP package. :dd
{One or more atoms are time integrated more than once} :dt
This is probably an error since you typically do not want to
advance the positions or velocities of an atom more than once
per timestep. :dd
{One or more chunks do not contain all atoms in molecule} :dt
This may not be what you intended. :dd
{One or more dynamic groups may not be updated at correct point in timestep} :dt
If there are other fixes that act immediately after the initial stage
of time integration within a timestep (i.e. after atoms move), then
the command that sets up the dynamic group should appear after those
fixes. This will insure that dynamic group assignments are made
after all atoms have moved. :dd
{One or more respa levels compute no forces} :dt
This is computationally inefficient. :dd
{Pair COMB charge %.10f with force %.10f hit max barrier} :dt
Something is possibly wrong with your model. :dd
{Pair COMB charge %.10f with force %.10f hit min barrier} :dt
Something is possibly wrong with your model. :dd
{Pair brownian needs newton pair on for momentum conservation} :dt
Self-explanatory. :dd
{Pair dpd needs newton pair on for momentum conservation} :dt
Self-explanatory. :dd
{Pair dsmc: num_of_collisions > number_of_A} :dt
Collision model in DSMC is breaking down. :dd
{Pair dsmc: num_of_collisions > number_of_B} :dt
Collision model in DSMC is breaking down. :dd
{Pair style in data file differs from currently defined pair style} :dt
Self-explanatory. :dd
{Particle deposition was unsuccessful} :dt
The fix deposit command was not able to insert as many atoms as
needed. The requested volume fraction may be too high, or other atoms
may be in the insertion region. :dd
{Proc sub-domain size < neighbor skin, could lead to lost atoms} :dt
The decomposition of the physical domain (likely due to load
balancing) has led to a processor's sub-domain being smaller than the
neighbor skin in one or more dimensions. Since reneighboring is
triggered by atoms moving the skin distance, this may lead to lost
atoms, if an atom moves all the way across a neighboring processor's
sub-domain before reneighboring is triggered. :dd
{Reducing PPPM order b/c stencil extends beyond nearest neighbor processor} :dt
This may lead to a larger grid than desired. See the kspace_modify overlap
command to prevent changing of the PPPM order. :dd
{Reducing PPPMDisp Coulomb order b/c stencil extends beyond neighbor processor} :dt
This may lead to a larger grid than desired. See the kspace_modify overlap
command to prevent changing of the PPPM order. :dd
{Reducing PPPMDisp dispersion order b/c stencil extends beyond neighbor processor} :dt
This may lead to a larger grid than desired. See the kspace_modify overlap
command to prevent changing of the PPPM order. :dd
{Replacing a fix, but new group != old group} :dt
The ID and style of a fix match for a fix you are changing with a fix
command, but the new group you are specifying does not match the old
group. :dd
{Replicating in a non-periodic dimension} :dt
The parameters for a replicate command will cause a non-periodic
dimension to be replicated; this may cause unwanted behavior. :dd
{Resetting reneighboring criteria during PRD} :dt
A PRD simulation requires that neigh_modify settings be delay = 0,
every = 1, check = yes. Since these settings were not in place,
LAMMPS changed them and will restore them to their original values
after the PRD simulation. :dd
{Resetting reneighboring criteria during TAD} :dt
A TAD simulation requires that neigh_modify settings be delay = 0,
every = 1, check = yes. Since these settings were not in place,
LAMMPS changed them and will restore them to their original values
after the PRD simulation. :dd
{Resetting reneighboring criteria during minimization} :dt
Minimization requires that neigh_modify settings be delay = 0, every =
1, check = yes. Since these settings were not in place, LAMMPS
changed them and will restore them to their original values after the
minimization. :dd
{Restart file used different # of processors} :dt
The restart file was written out by a LAMMPS simulation running on a
different number of processors. Due to round-off, the trajectories of
your restarted simulation may diverge a little more quickly than if
you ran on the same # of processors. :dd
{Restart file used different 3d processor grid} :dt
The restart file was written out by a LAMMPS simulation running on a
different 3d grid of processors. Due to round-off, the trajectories
of your restarted simulation may diverge a little more quickly than if
you ran on the same # of processors. :dd
{Restart file used different boundary settings, using restart file values} :dt
Your input script cannot change these restart file settings. :dd
{Restart file used different newton bond setting, using restart file value} :dt
The restart file value will override the setting in the input script. :dd
{Restart file used different newton pair setting, using input script value} :dt
The input script value will override the setting in the restart file. :dd
{Restrain problem: %d %ld %d %d %d %d} :dt
Conformation of the 4 listed dihedral atoms is extreme; you may want
to check your simulation geometry. :dd
{Running PRD with only one replica} :dt
This is allowed, but you will get no parallel speed-up. :dd
{SRD bin shifting turned on due to small lamda} :dt
This is done to try to preserve accuracy. :dd
{SRD bin size for fix srd differs from user request} :dt
Fix SRD had to adjust the bin size to fit the simulation box. See the
cubic keyword if you want this message to be an error vs warning. :dd
{SRD bins for fix srd are not cubic enough} :dt
The bin shape is not within tolerance of cubic. See the cubic
keyword if you want this message to be an error vs warning. :dd
{SRD particle %d started inside big particle %d on step %ld bounce %d} :dt
See the inside keyword if you want this message to be an error vs
warning. :dd
{SRD particle %d started inside wall %d on step %ld bounce %d} :dt
See the inside keyword if you want this message to be an error vs
warning. :dd
{Shake determinant < 0.0} :dt
The determinant of the quadratic equation being solved for a single
cluster specified by the fix shake command is numerically suspect. LAMMPS
will set it to 0.0 and continue. :dd
{Shell command '%s' failed with error '%s'} :dt
Self-explanatory. :dd
{Shell command returned with non-zero status} :dt
This may indicate the shell command did not operate as expected. :dd
{Should not allow rigid bodies to bounce off relecting walls} :dt
LAMMPS allows this, but their dynamics are not computed correctly. :dd
{Should not use fix nve/limit with fix shake or fix rattle} :dt
This will lead to invalid constraint forces in the SHAKE/RATTLE
computation. :dd
{Simulations might be very slow because of large number of structure factors} :dt
Self-explanatory. :dd
{Slab correction not needed for MSM} :dt
Slab correction is intended to be used with Ewald or PPPM and is not needed by MSM. :dd
{System is not charge neutral, net charge = %g} :dt
The total charge on all atoms on the system is not 0.0.
For some KSpace solvers this is only a warning. :dd
{Table inner cutoff >= outer cutoff} :dt
You specified an inner cutoff for a Coulombic table that is longer
than the global cutoff. Probably not what you wanted. :dd
{Temperature for MSST is not for group all} :dt
User-assigned temperature to MSST fix does not compute temperature for
all atoms. Since MSST computes a global pressure, the kinetic energy
contribution from the temperature is assumed to also be for all atoms.
Thus the pressure used by MSST could be inaccurate. :dd
{Temperature for NPT is not for group all} :dt
User-assigned temperature to NPT fix does not compute temperature for
all atoms. Since NPT computes a global pressure, the kinetic energy
contribution from the temperature is assumed to also be for all atoms.
Thus the pressure used by NPT could be inaccurate. :dd
{Temperature for fix modify is not for group all} :dt
The temperature compute is being used with a pressure calculation
which does operate on group all, so this may be inconsistent. :dd
{Temperature for thermo pressure is not for group all} :dt
User-assigned temperature to thermo via the thermo_modify command does
not compute temperature for all atoms. Since thermo computes a global
pressure, the kinetic energy contribution from the temperature is
assumed to also be for all atoms. Thus the pressure printed by thermo
could be inaccurate. :dd
{The fix ave/spatial command has been replaced by the more flexible fix ave/chunk and compute chunk/atom commands -- fix ave/spatial will be removed in the summer of 2015} :dt
Self-explanatory. :dd
{The minimizer does not re-orient dipoles when using fix efield} :dt
This means that only the atom coordinates will be minimized,
not the orientation of the dipoles. :dd
{Too many common neighbors in CNA %d times} :dt
More than the maximum # of neighbors was found multiple times. This
was unexpected. :dd
{Too many inner timesteps in fix ttm} :dt
Self-explanatory. :dd
{Too many neighbors in CNA for %d atoms} :dt
More than the maximum # of neighbors was found multiple times. This
was unexpected. :dd
{Triclinic box skew is large} :dt
The displacement in a skewed direction is normally required to be less
than half the box length in that dimension. E.g. the xy tilt must be
between -half and +half of the x box length. You have relaxed the
constraint using the box tilt command, but the warning means that a
LAMMPS simulation may be inefficient as a result. :dd
{Use special bonds = 0,1,1 with bond style fene} :dt
Most FENE models need this setting for the special_bonds command. :dd
{Use special bonds = 0,1,1 with bond style fene/expand} :dt
Most FENE models need this setting for the special_bonds command. :dd
{Using a manybody potential with bonds/angles/dihedrals and special_bond exclusions} :dt
This is likely not what you want to do. The exclusion settings will
eliminate neighbors in the neighbor list, which the manybody potential
needs to calculated its terms correctly. :dd
{Using compute temp/deform with inconsistent fix deform remap option} :dt
Fix nvt/sllod assumes deforming atoms have a velocity profile provided
by "remap v" or "remap none" as a fix deform option. :dd
{Using compute temp/deform with no fix deform defined} :dt
This is probably an error, since it makes little sense to use
compute temp/deform in this case. :dd
{Using fix srd with box deformation but no SRD thermostat} :dt
The deformation will heat the SRD particles so this can
be dangerous. :dd
{Using kspace solver on system with no charge} :dt
Self-explanatory. :dd
{Using largest cut-off for lj/long/dipole/long long long} :dt
Self-explanatory. :dd
{Using largest cutoff for buck/long/coul/long} :dt
Self-explanatory. :dd
{Using largest cutoff for lj/long/coul/long} :dt
Self-explanatory. :dd
{Using largest cutoff for pair_style lj/long/tip4p/long} :dt
Self-explanatory. :dd
{Using package gpu without any pair style defined} :dt
Self-explanatory. :dd
{Using pair potential shift with pair_modify compute no} :dt
The shift effects will thus not be computed. :dd
{Using pair tail corrections with nonperiodic system} :dt
This is probably a bogus thing to do, since tail corrections are
computed by integrating the density of a periodic system out to
infinity. :dd
{Using pair tail corrections with pair_modify compute no} :dt
The tail corrections will thus not be computed. :dd
{pair style reax is now deprecated and will soon be retired. Users should switch to pair_style reax/c} :dt
Self-explanatory. :dd
:dle
diff --git a/doc/src/Section_howto.txt b/doc/src/Section_howto.txt
index f2f2561af..6d699fe24 100644
--- a/doc/src/Section_howto.txt
+++ b/doc/src/Section_howto.txt
@@ -1,2935 +1,2935 @@
"Previous Section"_Section_accelerate.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_example.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
6. How-to discussions :h3
This section describes how to perform common tasks using LAMMPS.
6.1 "Restarting a simulation"_#howto_1
6.2 "2d simulations"_#howto_2
6.3 "CHARMM, AMBER, and DREIDING force fields"_#howto_3
6.4 "Running multiple simulations from one input script"_#howto_4
6.5 "Multi-replica simulations"_#howto_5
6.6 "Granular models"_#howto_6
6.7 "TIP3P water model"_#howto_7
6.8 "TIP4P water model"_#howto_8
6.9 "SPC water model"_#howto_9
6.10 "Coupling LAMMPS to other codes"_#howto_10
6.11 "Visualizing LAMMPS snapshots"_#howto_11
6.12 "Triclinic (non-orthogonal) simulation boxes"_#howto_12
6.13 "NEMD simulations"_#howto_13
6.14 "Finite-size spherical and aspherical particles"_#howto_14
6.15 "Output from LAMMPS (thermo, dumps, computes, fixes, variables)"_#howto_15
6.16 "Thermostatting, barostatting and computing temperature"_#howto_16
6.17 "Walls"_#howto_17
6.18 "Elastic constants"_#howto_18
6.19 "Library interface to LAMMPS"_#howto_19
6.20 "Calculating thermal conductivity"_#howto_20
6.21 "Calculating viscosity"_#howto_21
6.22 "Calculating a diffusion coefficient"_#howto_22
6.23 "Using chunks to calculate system properties"_#howto_23
6.24 "Setting parameters for the kspace_style pppm/disp command"_#howto_24
6.25 "Polarizable models"_#howto_25
6.26 "Adiabatic core/shell model"_#howto_26
6.27 "Drude induced dipoles"_#howto_27 :all(b)
The example input scripts included in the LAMMPS distribution and
highlighted in "Section 7"_Section_example.html also show how to
setup and run various kinds of simulations.
:line
:line
6.1 Restarting a simulation :link(howto_1),h4
There are 3 ways to continue a long LAMMPS simulation. Multiple
"run"_run.html commands can be used in the same input script. Each
run will continue from where the previous run left off. Or binary
restart files can be saved to disk using the "restart"_restart.html
command. At a later time, these binary files can be read via a
"read_restart"_read_restart.html command in a new script. Or they can
be converted to text data files using the "-r command-line
-switch"_Section_start.html#start_7 and read by a
+switch"_Section_start.html#start_6 and read by a
"read_data"_read_data.html command in a new script.
Here we give examples of 2 scripts that read either a binary restart
file or a converted data file and then issue a new run command to
continue where the previous run left off. They illustrate what
settings must be made in the new script. Details are discussed in the
documentation for the "read_restart"_read_restart.html and
"read_data"_read_data.html commands.
Look at the {in.chain} input script provided in the {bench} directory
of the LAMMPS distribution to see the original script that these 2
scripts are based on. If that script had the line
restart 50 tmp.restart :pre
added to it, it would produce 2 binary restart files (tmp.restart.50
and tmp.restart.100) as it ran.
This script could be used to read the 1st restart file and re-run the
last 50 timesteps:
read_restart tmp.restart.50 :pre
neighbor 0.4 bin
neigh_modify every 1 delay 1 :pre
fix 1 all nve
fix 2 all langevin 1.0 1.0 10.0 904297 :pre
timestep 0.012 :pre
run 50 :pre
Note that the following commands do not need to be repeated because
their settings are included in the restart file: {units, atom_style,
special_bonds, pair_style, bond_style}. However these commands do
need to be used, since their settings are not in the restart file:
{neighbor, fix, timestep}.
If you actually use this script to perform a restarted run, you will
notice that the thermodynamic data match at step 50 (if you also put a
"thermo 50" command in the original script), but do not match at step
100. This is because the "fix langevin"_fix_langevin.html command
uses random numbers in a way that does not allow for perfect restarts.
As an alternate approach, the restart file could be converted to a data
file as follows:
lmp_g++ -r tmp.restart.50 tmp.restart.data :pre
Then, this script could be used to re-run the last 50 steps:
units lj
atom_style bond
pair_style lj/cut 1.12
pair_modify shift yes
bond_style fene
special_bonds 0.0 1.0 1.0 :pre
read_data tmp.restart.data :pre
neighbor 0.4 bin
neigh_modify every 1 delay 1 :pre
fix 1 all nve
fix 2 all langevin 1.0 1.0 10.0 904297 :pre
timestep 0.012 :pre
reset_timestep 50
run 50 :pre
Note that nearly all the settings specified in the original {in.chain}
script must be repeated, except the {pair_coeff} and {bond_coeff}
commands since the new data file lists the force field coefficients.
Also, the "reset_timestep"_reset_timestep.html command is used to tell
LAMMPS the current timestep. This value is stored in restart files,
but not in data files.
:line
6.2 2d simulations :link(howto_2),h4
Use the "dimension"_dimension.html command to specify a 2d simulation.
Make the simulation box periodic in z via the "boundary"_boundary.html
command. This is the default.
If using the "create box"_create_box.html command to define a
simulation box, set the z dimensions narrow, but finite, so that the
create_atoms command will tile the 3d simulation box with a single z
plane of atoms - e.g.
"create box"_create_box.html 1 -10 10 -10 10 -0.25 0.25 :pre
If using the "read data"_read_data.html command to read in a file of
atom coordinates, set the "zlo zhi" values to be finite but narrow,
similar to the create_box command settings just described. For each
atom in the file, assign a z coordinate so it falls inside the
z-boundaries of the box - e.g. 0.0.
Use the "fix enforce2d"_fix_enforce2d.html command as the last
defined fix to insure that the z-components of velocities and forces
are zeroed out every timestep. The reason to make it the last fix is
so that any forces induced by other fixes will be zeroed out.
Many of the example input scripts included in the LAMMPS distribution
are for 2d models.
NOTE: Some models in LAMMPS treat particles as finite-size spheres, as
opposed to point particles. See the "atom_style
sphere"_atom_style.html and "fix nve/sphere"_fix_nve_sphere.html
commands for details. By default, for 2d simulations, such particles
will still be modeled as 3d spheres, not 2d discs (circles), meaning
their moment of inertia will be that of a sphere. If you wish to
model them as 2d discs, see the "set density/disc"_set.html command
and the {disc} option for the "fix nve/sphere"_fix_nve_sphere.html,
"fix nvt/sphere"_fix_nvt_sphere.html, "fix
nph/sphere"_fix_nph_sphere.html, "fix npt/sphere"_fix_npt_sphere.html
commands.
:line
6.3 CHARMM, AMBER, and DREIDING force fields :link(howto_3),h4
A force field has 2 parts: the formulas that define it and the
coefficients used for a particular system. Here we only discuss
formulas implemented in LAMMPS that correspond to formulas commonly
used in the CHARMM, AMBER, and DREIDING force fields. Setting
coefficients is done in the input data file via the
"read_data"_read_data.html command or in the input script with
commands like "pair_coeff"_pair_coeff.html or
"bond_coeff"_bond_coeff.html. See "Section 9"_Section_tools.html
for additional tools that can use CHARMM or AMBER to assign force
field coefficients and convert their output into LAMMPS input.
See "(MacKerell)"_#howto-MacKerell for a description of the CHARMM force
field. See "(Cornell)"_#howto-Cornell for a description of the AMBER force
field.
:link(charmm,http://www.scripps.edu/brooks)
:link(amber,http://amber.scripps.edu)
These style choices compute force field formulas that are consistent
with common options in CHARMM or AMBER. See each command's
documentation for the formula it computes.
"bond_style"_bond_harmonic.html harmonic
"angle_style"_angle_charmm.html charmm
"dihedral_style"_dihedral_charmm.html charmmfsh
"dihedral_style"_dihedral_charmm.html charmm
"pair_style"_pair_charmm.html lj/charmmfsw/coul/charmmfsh
"pair_style"_pair_charmm.html lj/charmmfsw/coul/long
"pair_style"_pair_charmm.html lj/charmm/coul/charmm
"pair_style"_pair_charmm.html lj/charmm/coul/charmm/implicit
"pair_style"_pair_charmm.html lj/charmm/coul/long :ul
"special_bonds"_special_bonds.html charmm
"special_bonds"_special_bonds.html amber :ul
NOTE: For CHARMM, newer {charmmfsw} or {charmmfsh} styles were
released in March 2017. We recommend they be used instead of the
older {charmm} styles. See discussion of the differences on the "pair
charmm"_pair_charmm.html and "dihedral charmm"_dihedral_charmm.html
doc pages.
DREIDING is a generic force field developed by the "Goddard
group"_http://www.wag.caltech.edu at Caltech and is useful for
predicting structures and dynamics of organic, biological and
main-group inorganic molecules. The philosophy in DREIDING is to use
general force constants and geometry parameters based on simple
hybridization considerations, rather than individual force constants
and geometric parameters that depend on the particular combinations of
atoms involved in the bond, angle, or torsion terms. DREIDING has an
"explicit hydrogen bond term"_pair_hbond_dreiding.html to describe
interactions involving a hydrogen atom on very electronegative atoms
(N, O, F).
See "(Mayo)"_#howto-Mayo for a description of the DREIDING force field
These style choices compute force field formulas that are consistent
with the DREIDING force field. See each command's
documentation for the formula it computes.
"bond_style"_bond_harmonic.html harmonic
"bond_style"_bond_morse.html morse :ul
"angle_style"_angle_harmonic.html harmonic
"angle_style"_angle_cosine.html cosine
"angle_style"_angle_cosine_periodic.html cosine/periodic :ul
"dihedral_style"_dihedral_charmm.html charmm
"improper_style"_improper_umbrella.html umbrella :ul
"pair_style"_pair_buck.html buck
"pair_style"_pair_buck.html buck/coul/cut
"pair_style"_pair_buck.html buck/coul/long
"pair_style"_pair_lj.html lj/cut
"pair_style"_pair_lj.html lj/cut/coul/cut
"pair_style"_pair_lj.html lj/cut/coul/long :ul
"pair_style"_pair_hbond_dreiding.html hbond/dreiding/lj
"pair_style"_pair_hbond_dreiding.html hbond/dreiding/morse :ul
"special_bonds"_special_bonds.html dreiding :ul
:line
6.4 Running multiple simulations from one input script :link(howto_4),h4
This can be done in several ways. See the documentation for
individual commands for more details on how these examples work.
If "multiple simulations" means continue a previous simulation for
more timesteps, then you simply use the "run"_run.html command
multiple times. For example, this script
units lj
atom_style atomic
read_data data.lj
run 10000
run 10000
run 10000
run 10000
run 10000 :pre
would run 5 successive simulations of the same system for a total of
50,000 timesteps.
If you wish to run totally different simulations, one after the other,
the "clear"_clear.html command can be used in between them to
re-initialize LAMMPS. For example, this script
units lj
atom_style atomic
read_data data.lj
run 10000
clear
units lj
atom_style atomic
read_data data.lj.new
run 10000 :pre
would run 2 independent simulations, one after the other.
For large numbers of independent simulations, you can use
"variables"_variable.html and the "next"_next.html and
"jump"_jump.html commands to loop over the same input script
multiple times with different settings. For example, this
script, named in.polymer
variable d index run1 run2 run3 run4 run5 run6 run7 run8
shell cd $d
read_data data.polymer
run 10000
shell cd ..
clear
next d
jump in.polymer :pre
would run 8 simulations in different directories, using a data.polymer
file in each directory. The same concept could be used to run the
same system at 8 different temperatures, using a temperature variable
and storing the output in different log and dump files, for example
variable a loop 8
variable t index 0.8 0.85 0.9 0.95 1.0 1.05 1.1 1.15
log log.$a
read data.polymer
velocity all create $t 352839
fix 1 all nvt $t $t 100.0
dump 1 all atom 1000 dump.$a
run 100000
clear
next t
next a
jump in.polymer :pre
All of the above examples work whether you are running on 1 or
multiple processors, but assumed you are running LAMMPS on a single
partition of processors. LAMMPS can be run on multiple partitions via
the "-partition" command-line switch as described in "this
-section"_Section_start.html#start_7 of the manual.
+section"_Section_start.html#start_6 of the manual.
In the last 2 examples, if LAMMPS were run on 3 partitions, the same
scripts could be used if the "index" and "loop" variables were
replaced with {universe}-style variables, as described in the
"variable"_variable.html command. Also, the "next t" and "next a"
commands would need to be replaced with a single "next a t" command.
With these modifications, the 8 simulations of each script would run
on the 3 partitions one after the other until all were finished.
Initially, 3 simulations would be started simultaneously, one on each
partition. When one finished, that partition would then start
the 4th simulation, and so forth, until all 8 were completed.
:line
6.5 Multi-replica simulations :link(howto_5),h4
Several commands in LAMMPS run mutli-replica simulations, meaning
that multiple instances (replicas) of your simulation are run
simultaneously, with small amounts of data exchanged between replicas
periodically.
These are the relevant commands:
"neb"_neb.html for nudged elastic band calculations
"prd"_prd.html for parallel replica dynamics
"tad"_tad.html for temperature accelerated dynamics
"temper"_temper.html for parallel tempering
"fix pimd"_fix_pimd.html for path-integral molecular dynamics (PIMD) :ul
NEB is a method for finding transition states and barrier energies.
PRD and TAD are methods for performing accelerated dynamics to find
and perform infrequent events. Parallel tempering or replica exchange
runs different replicas at a series of temperature to facilitate
rare-event sampling.
These commands can only be used if LAMMPS was built with the REPLICA
package. See the "Making LAMMPS"_Section_start.html#start_3 section
for more info on packages.
PIMD runs different replicas whose individual particles are coupled
together by springs to model a system or ring-polymers.
This commands can only be used if LAMMPS was built with the USER-MISC
package. See the "Making LAMMPS"_Section_start.html#start_3 section
for more info on packages.
In all these cases, you must run with one or more processors per
replica. The processors assigned to each replica are determined at
run-time by using the "-partition command-line
-switch"_Section_start.html#start_7 to launch LAMMPS on multiple
+switch"_Section_start.html#start_6 to launch LAMMPS on multiple
partitions, which in this context are the same as replicas. E.g.
these commands:
mpirun -np 16 lmp_linux -partition 8x2 -in in.temper
mpirun -np 8 lmp_linux -partition 8x1 -in in.neb :pre
would each run 8 replicas, on either 16 or 8 processors. Note the use
-of the "-in command-line switch"_Section_start.html#start_7 to specify
+of the "-in command-line switch"_Section_start.html#start_6 to specify
the input script which is required when running in multi-replica mode.
Also note that with MPI installed on a machine (e.g. your desktop),
you can run on more (virtual) processors than you have physical
processors. Thus the above commands could be run on a
single-processor (or few-processor) desktop so that you can run
a multi-replica simulation on more replicas than you have
physical processors.
:line
6.6 Granular models :link(howto_6),h4
Granular system are composed of spherical particles with a diameter,
as opposed to point particles. This means they have an angular
velocity and torque can be imparted to them to cause them to rotate.
To run a simulation of a granular model, you will want to use
the following commands:
"atom_style sphere"_atom_style.html
"fix nve/sphere"_fix_nve_sphere.html
"fix gravity"_fix_gravity.html :ul
This compute
"compute erotate/sphere"_compute_erotate_sphere.html :ul
calculates rotational kinetic energy which can be "output with
thermodynamic info"_Section_howto.html#howto_15.
Use one of these 3 pair potentials, which compute forces and torques
between interacting pairs of particles:
"pair_style"_pair_style.html gran/history
"pair_style"_pair_style.html gran/no_history
"pair_style"_pair_style.html gran/hertzian :ul
These commands implement fix options specific to granular systems:
"fix freeze"_fix_freeze.html
"fix pour"_fix_pour.html
"fix viscous"_fix_viscous.html
"fix wall/gran"_fix_wall_gran.html :ul
The fix style {freeze} zeroes both the force and torque of frozen
atoms, and should be used for granular system instead of the fix style
{setforce}.
For computational efficiency, you can eliminate needless pairwise
computations between frozen atoms by using this command:
"neigh_modify"_neigh_modify.html exclude :ul
NOTE: By default, for 2d systems, granular particles are still modeled
as 3d spheres, not 2d discs (circles), meaning their moment of inertia
will be the same as in 3d. If you wish to model granular particles in
2d as 2d discs, see the note on this topic in "Section
6.2"_Section_howto.html#howto_2, where 2d simulations are disussed.
:line
6.7 TIP3P water model :link(howto_7),h4
The TIP3P water model as implemented in CHARMM
"(MacKerell)"_#howto-MacKerell specifies a 3-site rigid water molecule with
charges and Lennard-Jones parameters assigned to each of the 3 atoms.
In LAMMPS the "fix shake"_fix_shake.html command can be used to hold
the two O-H bonds and the H-O-H angle rigid. A bond style of
{harmonic} and an angle style of {harmonic} or {charmm} should also be
used.
These are the additional parameters (in real units) to set for O and H
atoms and the water molecule to run a rigid TIP3P-CHARMM model with a
cutoff. The K values can be used if a flexible TIP3P model (without
fix shake) is desired. If the LJ epsilon and sigma for HH and OH are
set to 0.0, it corresponds to the original 1983 TIP3P model
"(Jorgensen)"_#Jorgensen1.
O mass = 15.9994
H mass = 1.008
O charge = -0.834
H charge = 0.417
LJ epsilon of OO = 0.1521
LJ sigma of OO = 3.1507
LJ epsilon of HH = 0.0460
LJ sigma of HH = 0.4000
LJ epsilon of OH = 0.0836
LJ sigma of OH = 1.7753
K of OH bond = 450
r0 of OH bond = 0.9572
K of HOH angle = 55
theta of HOH angle = 104.52 :all(b),p
These are the parameters to use for TIP3P with a long-range Coulombic
solver (e.g. Ewald or PPPM in LAMMPS), see "(Price)"_#Price1 for
details:
O mass = 15.9994
H mass = 1.008
O charge = -0.830
H charge = 0.415
LJ epsilon of OO = 0.102
LJ sigma of OO = 3.188
LJ epsilon, sigma of OH, HH = 0.0
K of OH bond = 450
r0 of OH bond = 0.9572
K of HOH angle = 55
theta of HOH angle = 104.52 :all(b),p
Wikipedia also has a nice article on "water
models"_http://en.wikipedia.org/wiki/Water_model.
:line
6.8 TIP4P water model :link(howto_8),h4
The four-point TIP4P rigid water model extends the traditional
three-point TIP3P model by adding an additional site, usually
massless, where the charge associated with the oxygen atom is placed.
This site M is located at a fixed distance away from the oxygen along
the bisector of the HOH bond angle. A bond style of {harmonic} and an
angle style of {harmonic} or {charmm} should also be used.
A TIP4P model is run with LAMMPS using either this command
for a cutoff model:
"pair_style lj/cut/tip4p/cut"_pair_lj.html
or these two commands for a long-range model:
"pair_style lj/cut/tip4p/long"_pair_lj.html
"kspace_style pppm/tip4p"_kspace_style.html :ul
For both models, the bond lengths and bond angles should be held fixed
using the "fix shake"_fix_shake.html command.
These are the additional parameters (in real units) to set for O and H
atoms and the water molecule to run a rigid TIP4P model with a cutoff
"(Jorgensen)"_#Jorgensen1. Note that the OM distance is specified in
the "pair_style"_pair_style.html command, not as part of the pair
coefficients.
O mass = 15.9994
H mass = 1.008
O charge = -1.040
H charge = 0.520
r0 of OH bond = 0.9572
theta of HOH angle = 104.52
OM distance = 0.15
LJ epsilon of O-O = 0.1550
LJ sigma of O-O = 3.1536
LJ epsilon, sigma of OH, HH = 0.0
Coulombic cutoff = 8.5 :all(b),p
For the TIP4/Ice model (J Chem Phys, 122, 234511 (2005);
http://dx.doi.org/10.1063/1.1931662) these values can be used:
O mass = 15.9994
H mass = 1.008
O charge = -1.1794
H charge = 0.5897
r0 of OH bond = 0.9572
theta of HOH angle = 104.52
OM distance = 0.1577
LJ epsilon of O-O = 0.21084
LJ sigma of O-O = 3.1668
LJ epsilon, sigma of OH, HH = 0.0
Coulombic cutoff = 8.5 :all(b),p
For the TIP4P/2005 model (J Chem Phys, 123, 234505 (2005);
http://dx.doi.org/10.1063/1.2121687), these values can be used:
O mass = 15.9994
H mass = 1.008
O charge = -1.1128
H charge = 0.5564
r0 of OH bond = 0.9572
theta of HOH angle = 104.52
OM distance = 0.1546
LJ epsilon of O-O = 0.1852
LJ sigma of O-O = 3.1589
LJ epsilon, sigma of OH, HH = 0.0
Coulombic cutoff = 8.5 :all(b),p
These are the parameters to use for TIP4P with a long-range Coulombic
solver (e.g. Ewald or PPPM in LAMMPS):
O mass = 15.9994
H mass = 1.008
O charge = -1.0484
H charge = 0.5242
r0 of OH bond = 0.9572
theta of HOH angle = 104.52
OM distance = 0.1250
LJ epsilon of O-O = 0.16275
LJ sigma of O-O = 3.16435
LJ epsilon, sigma of OH, HH = 0.0 :all(b),p
Note that the when using the TIP4P pair style, the neighbor list
cutoff for Coulomb interactions is effectively extended by a distance
2 * (OM distance), to account for the offset distance of the
fictitious charges on O atoms in water molecules. Thus it is
typically best in an efficiency sense to use a LJ cutoff >= Coulomb
cutoff + 2*(OM distance), to shrink the size of the neighbor list.
This leads to slightly larger cost for the long-range calculation, so
you can test the trade-off for your model. The OM distance and the LJ
and Coulombic cutoffs are set in the "pair_style
lj/cut/tip4p/long"_pair_lj.html command.
Wikipedia also has a nice article on "water
models"_http://en.wikipedia.org/wiki/Water_model.
:line
6.9 SPC water model :link(howto_9),h4
The SPC water model specifies a 3-site rigid water molecule with
charges and Lennard-Jones parameters assigned to each of the 3 atoms.
In LAMMPS the "fix shake"_fix_shake.html command can be used to hold
the two O-H bonds and the H-O-H angle rigid. A bond style of
{harmonic} and an angle style of {harmonic} or {charmm} should also be
used.
These are the additional parameters (in real units) to set for O and H
atoms and the water molecule to run a rigid SPC model.
O mass = 15.9994
H mass = 1.008
O charge = -0.820
H charge = 0.410
LJ epsilon of OO = 0.1553
LJ sigma of OO = 3.166
LJ epsilon, sigma of OH, HH = 0.0
r0 of OH bond = 1.0
theta of HOH angle = 109.47 :all(b),p
Note that as originally proposed, the SPC model was run with a 9
Angstrom cutoff for both LJ and Coulommbic terms. It can also be used
with long-range Coulombics (Ewald or PPPM in LAMMPS), without changing
any of the parameters above, though it becomes a different model in
that mode of usage.
The SPC/E (extended) water model is the same, except
the partial charge assignments change:
O charge = -0.8476
H charge = 0.4238 :all(b),p
See the "(Berendsen)"_#howto-Berendsen reference for more details on both
the SPC and SPC/E models.
Wikipedia also has a nice article on "water
models"_http://en.wikipedia.org/wiki/Water_model.
:line
6.10 Coupling LAMMPS to other codes :link(howto_10),h4
LAMMPS is designed to allow it to be coupled to other codes. For
example, a quantum mechanics code might compute forces on a subset of
atoms and pass those forces to LAMMPS. Or a continuum finite element
(FE) simulation might use atom positions as boundary conditions on FE
nodal points, compute a FE solution, and return interpolated forces on
MD atoms.
LAMMPS can be coupled to other codes in at least 3 ways. Each has
advantages and disadvantages, which you'll have to think about in the
context of your application.
(1) Define a new "fix"_fix.html command that calls the other code. In
this scenario, LAMMPS is the driver code. During its timestepping,
the fix is invoked, and can make library calls to the other code,
which has been linked to LAMMPS as a library. This is the way the
"POEMS"_poems package that performs constrained rigid-body motion on
groups of atoms is hooked to LAMMPS. See the
"fix poems"_fix_poems.html command for more details. See "this
section"_Section_modify.html of the documentation for info on how to add
a new fix to LAMMPS.
:link(poems,http://www.rpi.edu/~anderk5/lab)
(2) Define a new LAMMPS command that calls the other code. This is
conceptually similar to method (1), but in this case LAMMPS and the
other code are on a more equal footing. Note that now the other code
is not called during the timestepping of a LAMMPS run, but between
runs. The LAMMPS input script can be used to alternate LAMMPS runs
with calls to the other code, invoked via the new command. The
"run"_run.html command facilitates this with its {every} option, which
makes it easy to run a few steps, invoke the command, run a few steps,
invoke the command, etc.
In this scenario, the other code can be called as a library, as in
(1), or it could be a stand-alone code, invoked by a system() call
made by the command (assuming your parallel machine allows one or more
processors to start up another program). In the latter case the
stand-alone code could communicate with LAMMPS thru files that the
command writes and reads.
See "Section 10"_Section_modify.html of the documentation for how
to add a new command to LAMMPS.
(3) Use LAMMPS as a library called by another code. In this case the
other code is the driver and calls LAMMPS as needed. Or a wrapper
code could link and call both LAMMPS and another code as libraries.
Again, the "run"_run.html command has options that allow it to be
invoked with minimal overhead (no setup or clean-up) if you wish to do
multiple short runs, driven by another program.
Examples of driver codes that call LAMMPS as a library are included in
the examples/COUPLE directory of the LAMMPS distribution; see
examples/COUPLE/README for more details:
simple: simple driver programs in C++ and C which invoke LAMMPS as a
library :ulb,l
lammps_quest: coupling of LAMMPS and "Quest"_quest, to run classical
MD with quantum forces calculated by a density functional code :l
lammps_spparks: coupling of LAMMPS and "SPPARKS"_spparks, to couple
a kinetic Monte Carlo model for grain growth using MD to calculate
strain induced across grain boundaries :l
:ule
:link(quest,http://dft.sandia.gov/Quest)
:link(spparks,http://www.sandia.gov/~sjplimp/spparks.html)
"This section"_Section_start.html#start_5 of the documentation
describes how to build LAMMPS as a library. Once this is done, you
can interface with LAMMPS either via C++, C, Fortran, or Python (or
any other language that supports a vanilla C-like interface). For
example, from C++ you could create one (or more) "instances" of
LAMMPS, pass it an input script to process, or execute individual
commands, all by invoking the correct class methods in LAMMPS. From C
or Fortran you can make function calls to do the same things. See
"Section 11"_Section_python.html of the manual for a description
of the Python wrapper provided with LAMMPS that operates through the
LAMMPS library interface.
The files src/library.cpp and library.h contain the C-style interface
to LAMMPS. See "Section 6.19"_Section_howto.html#howto_19 of the
manual for a description of the interface and how to extend it for
your needs.
Note that the lammps_open() function that creates an instance of
LAMMPS takes an MPI communicator as an argument. This means that
instance of LAMMPS will run on the set of processors in the
communicator. Thus the calling code can run LAMMPS on all or a subset
of processors. For example, a wrapper script might decide to
alternate between LAMMPS and another code, allowing them both to run
on all the processors. Or it might allocate half the processors to
LAMMPS and half to the other code and run both codes simultaneously
before syncing them up periodically. Or it might instantiate multiple
instances of LAMMPS to perform different calculations.
:line
6.11 Visualizing LAMMPS snapshots :link(howto_11),h4
LAMMPS itself does not do visualization, but snapshots from LAMMPS
simulations can be visualized (and analyzed) in a variety of ways.
LAMMPS snapshots are created by the "dump"_dump.html command which can
create files in several formats. The native LAMMPS dump format is a
text file (see "dump atom" or "dump custom") which can be visualized
by several popular visualization tools. The "dump image"_dump_image.html
and "dump movie"_dump_image.html styles can output internally rendered
images and convert a sequence of them to a movie during the MD run.
Several programs included with LAMMPS as auxiliary tools can convert
between LAMMPS format files and other formats.
See the "Section 9"_Section_tools.html doc page for details.
A Python-based toolkit distributed by our group can read native LAMMPS
dump files, including custom dump files with additional columns of
user-specified atom information, and convert them to various formats
or pipe them into visualization software directly. See the "Pizza.py
WWW site"_pizza for details. Specifically, Pizza.py can convert
LAMMPS dump files into PDB, XYZ, "Ensight"_ensight, and VTK formats.
Pizza.py can pipe LAMMPS dump files directly into the Raster3d and
RasMol visualization programs. Pizza.py has tools that do interactive
3d OpenGL visualization and one that creates SVG images of dump file
snapshots.
:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
:link(ensight,http://www.ensight.com)
:link(atomeye,http://mt.seas.upenn.edu/Archive/Graphics/A)
:line
6.12 Triclinic (non-orthogonal) simulation boxes :link(howto_12),h4
By default, LAMMPS uses an orthogonal simulation box to encompass the
particles. The "boundary"_boundary.html command sets the boundary
conditions of the box (periodic, non-periodic, etc). The orthogonal
box has its "origin" at (xlo,ylo,zlo) and is defined by 3 edge vectors
starting from the origin given by [a] = (xhi-xlo,0,0); [b] =
(0,yhi-ylo,0); [c] = (0,0,zhi-zlo). The 6 parameters
(xlo,xhi,ylo,yhi,zlo,zhi) are defined at the time the simulation box
is created, e.g. by the "create_box"_create_box.html or
"read_data"_read_data.html or "read_restart"_read_restart.html
commands. Additionally, LAMMPS defines box size parameters lx,ly,lz
where lx = xhi-xlo, and similarly in the y and z dimensions. The 6
parameters, as well as lx,ly,lz, can be output via the "thermo_style
custom"_thermo_style.html command.
LAMMPS also allows simulations to be performed in triclinic
(non-orthogonal) simulation boxes shaped as a parallelepiped with
triclinic symmetry. The parallelepiped has its "origin" at
(xlo,ylo,zlo) and is defined by 3 edge vectors starting from the
origin given by [a] = (xhi-xlo,0,0); [b] = (xy,yhi-ylo,0); [c] =
(xz,yz,zhi-zlo). {xy,xz,yz} can be 0.0 or positive or negative values
and are called "tilt factors" because they are the amount of
displacement applied to faces of an originally orthogonal box to
transform it into the parallelepiped. In LAMMPS the triclinic
simulation box edge vectors [a], [b], and [c] cannot be arbitrary
vectors. As indicated, [a] must lie on the positive x axis. [b] must
lie in the xy plane, with strictly positive y component. [c] may have
any orientation with strictly positive z component. The requirement
that [a], [b], and [c] have strictly positive x, y, and z components,
respectively, ensures that [a], [b], and [c] form a complete
right-handed basis. These restrictions impose no loss of generality,
since it is possible to rotate/invert any set of 3 crystal basis
vectors so that they conform to the restrictions.
For example, assume that the 3 vectors [A],[B],[C] are the edge
vectors of a general parallelepiped, where there is no restriction on
[A],[B],[C] other than they form a complete right-handed basis i.e.
[A] x [B] . [C] > 0. The equivalent LAMMPS [a],[b],[c] are a linear
rotation of [A], [B], and [C] and can be computed as follows:
:c,image(Eqs/transform.jpg)
where A = | [A] | indicates the scalar length of [A]. The hat symbol (^)
indicates the corresponding unit vector. {beta} and {gamma} are angles
between the vectors described below. Note that by construction,
[a], [b], and [c] have strictly positive x, y, and z components, respectively.
If it should happen that
[A], [B], and [C] form a left-handed basis, then the above equations
are not valid for [c]. In this case, it is necessary
to first apply an inversion. This can be achieved
by interchanging two basis vectors or by changing the sign of one of them.
For consistency, the same rotation/inversion applied to the basis vectors
must also be applied to atom positions, velocities,
and any other vector quantities.
This can be conveniently achieved by first converting to
fractional coordinates in the
old basis and then converting to distance coordinates in the new basis.
The transformation is given by the following equation:
:c,image(Eqs/rotate.jpg)
where {V} is the volume of the box, [X] is the original vector quantity and
[x] is the vector in the LAMMPS basis.
There is no requirement that a triclinic box be periodic in any
dimension, though it typically should be in at least the 2nd dimension
of the tilt (y in xy) if you want to enforce a shift in periodic
boundary conditions across that boundary. Some commands that work
with triclinic boxes, e.g. the "fix deform"_fix_deform.html and "fix
npt"_fix_nh.html commands, require periodicity or non-shrink-wrap
boundary conditions in specific dimensions. See the command doc pages
for details.
The 9 parameters (xlo,xhi,ylo,yhi,zlo,zhi,xy,xz,yz) are defined at the
time the simulation box is created. This happens in one of 3 ways.
If the "create_box"_create_box.html command is used with a region of
style {prism}, then a triclinic box is setup. See the
"region"_region.html command for details. If the
"read_data"_read_data.html command is used to define the simulation
box, and the header of the data file contains a line with the "xy xz
yz" keyword, then a triclinic box is setup. See the
"read_data"_read_data.html command for details. Finally, if the
"read_restart"_read_restart.html command reads a restart file which
was written from a simulation using a triclinic box, then a triclinic
box will be setup for the restarted simulation.
Note that you can define a triclinic box with all 3 tilt factors =
0.0, so that it is initially orthogonal. This is necessary if the box
will become non-orthogonal, e.g. due to the "fix npt"_fix_nh.html or
"fix deform"_fix_deform.html commands. Alternatively, you can use the
"change_box"_change_box.html command to convert a simulation box from
orthogonal to triclinic and vice versa.
As with orthogonal boxes, LAMMPS defines triclinic box size parameters
lx,ly,lz where lx = xhi-xlo, and similarly in the y and z dimensions.
The 9 parameters, as well as lx,ly,lz, can be output via the
"thermo_style custom"_thermo_style.html command.
To avoid extremely tilted boxes (which would be computationally
inefficient), LAMMPS normally requires that no tilt factor can skew
the box more than half the distance of the parallel box length, which
is the 1st dimension in the tilt factor (x for xz). This is required
both when the simulation box is created, e.g. via the
"create_box"_create_box.html or "read_data"_read_data.html commands,
as well as when the box shape changes dynamically during a simulation,
e.g. via the "fix deform"_fix_deform.html or "fix npt"_fix_nh.html
commands.
For example, if xlo = 2 and xhi = 12, then the x box length is 10 and
the xy tilt factor must be between -5 and 5. Similarly, both xz and
yz must be between -(xhi-xlo)/2 and +(yhi-ylo)/2. Note that this is
not a limitation, since if the maximum tilt factor is 5 (as in this
example), then configurations with tilt = ..., -15, -5, 5, 15, 25,
... are geometrically all equivalent. If the box tilt exceeds this
limit during a dynamics run (e.g. via the "fix deform"_fix_deform.html
command), then the box is "flipped" to an equivalent shape with a tilt
factor within the bounds, so the run can continue. See the "fix
deform"_fix_deform.html doc page for further details.
One exception to this rule is if the 1st dimension in the tilt
factor (x for xy) is non-periodic. In that case, the limits on the
tilt factor are not enforced, since flipping the box in that dimension
does not change the atom positions due to non-periodicity. In this
mode, if you tilt the system to extreme angles, the simulation will
simply become inefficient, due to the highly skewed simulation box.
The limitation on not creating a simulation box with a tilt factor
skewing the box more than half the distance of the parallel box length
can be overridden via the "box"_box.html command. Setting the {tilt}
keyword to {large} allows any tilt factors to be specified.
Box flips that may occur using the "fix deform"_fix_deform.html or
"fix npt"_fix_nh.html commands can be turned off using the {flip no}
option with either of the commands.
Note that if a simulation box has a large tilt factor, LAMMPS will run
less efficiently, due to the large volume of communication needed to
acquire ghost atoms around a processor's irregular-shaped sub-domain.
For extreme values of tilt, LAMMPS may also lose atoms and generate an
error.
Triclinic crystal structures are often defined using three lattice
constants {a}, {b}, and {c}, and three angles {alpha}, {beta} and
{gamma}. Note that in this nomenclature, the a, b, and c lattice
constants are the scalar lengths of the edge vectors [a], [b], and [c]
defined above. The relationship between these 6 quantities
(a,b,c,alpha,beta,gamma) and the LAMMPS box sizes (lx,ly,lz) =
(xhi-xlo,yhi-ylo,zhi-zlo) and tilt factors (xy,xz,yz) is as follows:
:c,image(Eqs/box.jpg)
The inverse relationship can be written as follows:
:c,image(Eqs/box_inverse.jpg)
The values of {a}, {b}, {c} , {alpha}, {beta} , and {gamma} can be printed
out or accessed by computes using the
"thermo_style custom"_thermo_style.html keywords
{cella}, {cellb}, {cellc}, {cellalpha}, {cellbeta}, {cellgamma},
respectively.
As discussed on the "dump"_dump.html command doc page, when the BOX
BOUNDS for a snapshot is written to a dump file for a triclinic box,
an orthogonal bounding box which encloses the triclinic simulation box
is output, along with the 3 tilt factors (xy, xz, yz) of the triclinic
box, formatted as follows:
ITEM: BOX BOUNDS xy xz yz
xlo_bound xhi_bound xy
ylo_bound yhi_bound xz
zlo_bound zhi_bound yz :pre
This bounding box is convenient for many visualization programs and is
calculated from the 9 triclinic box parameters
(xlo,xhi,ylo,yhi,zlo,zhi,xy,xz,yz) as follows:
xlo_bound = xlo + MIN(0.0,xy,xz,xy+xz)
xhi_bound = xhi + MAX(0.0,xy,xz,xy+xz)
ylo_bound = ylo + MIN(0.0,yz)
yhi_bound = yhi + MAX(0.0,yz)
zlo_bound = zlo
zhi_bound = zhi :pre
These formulas can be inverted if you need to convert the bounding box
back into the triclinic box parameters, e.g. xlo = xlo_bound -
MIN(0.0,xy,xz,xy+xz).
One use of triclinic simulation boxes is to model solid-state crystals
with triclinic symmetry. The "lattice"_lattice.html command can be
used with non-orthogonal basis vectors to define a lattice that will
tile a triclinic simulation box via the
"create_atoms"_create_atoms.html command.
A second use is to run Parinello-Rahman dynamics via the "fix
npt"_fix_nh.html command, which will adjust the xy, xz, yz tilt
factors to compensate for off-diagonal components of the pressure
tensor. The analog for an "energy minimization"_minimize.html is
the "fix box/relax"_fix_box_relax.html command.
A third use is to shear a bulk solid to study the response of the
material. The "fix deform"_fix_deform.html command can be used for
this purpose. It allows dynamic control of the xy, xz, yz tilt
factors as a simulation runs. This is discussed in the next section
on non-equilibrium MD (NEMD) simulations.
:line
6.13 NEMD simulations :link(howto_13),h4
Non-equilibrium molecular dynamics or NEMD simulations are typically
used to measure a fluid's rheological properties such as viscosity.
In LAMMPS, such simulations can be performed by first setting up a
non-orthogonal simulation box (see the preceding Howto section).
A shear strain can be applied to the simulation box at a desired
strain rate by using the "fix deform"_fix_deform.html command. The
"fix nvt/sllod"_fix_nvt_sllod.html command can be used to thermostat
the sheared fluid and integrate the SLLOD equations of motion for the
system. Fix nvt/sllod uses "compute
temp/deform"_compute_temp_deform.html to compute a thermal temperature
by subtracting out the streaming velocity of the shearing atoms. The
velocity profile or other properties of the fluid can be monitored via
the "fix ave/chunk"_fix_ave_chunk.html command.
As discussed in the previous section on non-orthogonal simulation
boxes, the amount of tilt or skew that can be applied is limited by
LAMMPS for computational efficiency to be 1/2 of the parallel box
length. However, "fix deform"_fix_deform.html can continuously strain
a box by an arbitrary amount. As discussed in the "fix
deform"_fix_deform.html command, when the tilt value reaches a limit,
the box is flipped to the opposite limit which is an equivalent tiling
of periodic space. The strain rate can then continue to change as
before. In a long NEMD simulation these box re-shaping events may
occur many times.
In a NEMD simulation, the "remap" option of "fix
deform"_fix_deform.html should be set to "remap v", since that is what
"fix nvt/sllod"_fix_nvt_sllod.html assumes to generate a velocity
profile consistent with the applied shear strain rate.
An alternative method for calculating viscosities is provided via the
"fix viscosity"_fix_viscosity.html command.
NEMD simulations can also be used to measure transport properties of a fluid
through a pore or channel. Simulations of steady-state flow can be performed
using the "fix flow/gauss"_fix_flow_gauss.html command.
:line
6.14 Finite-size spherical and aspherical particles :link(howto_14),h4
Typical MD models treat atoms or particles as point masses. Sometimes
it is desirable to have a model with finite-size particles such as
spheroids or ellipsoids or generalized aspherical bodies. The
difference is that such particles have a moment of inertia, rotational
energy, and angular momentum. Rotation is induced by torque coming
from interactions with other particles.
LAMMPS has several options for running simulations with these kinds of
particles. The following aspects are discussed in turn:
atom styles
pair potentials
time integration
computes, thermodynamics, and dump output
rigid bodies composed of finite-size particles :ul
Example input scripts for these kinds of models are in the body,
colloid, dipole, ellipse, line, peri, pour, and tri directories of the
"examples directory"_Section_example.html in the LAMMPS distribution.
Atom styles :h5
There are several "atom styles"_atom_style.html that allow for
definition of finite-size particles: sphere, dipole, ellipsoid, line,
tri, peri, and body.
The sphere style defines particles that are spheriods and each
particle can have a unique diameter and mass (or density). These
particles store an angular velocity (omega) and can be acted upon by
torque. The "set" command can be used to modify the diameter and mass
of individual particles, after then are created.
The dipole style does not actually define finite-size particles, but
is often used in conjunction with spherical particles, via a command
like
atom_style hybrid sphere dipole :pre
This is because when dipoles interact with each other, they induce
torques, and a particle must be finite-size (i.e. have a moment of
inertia) in order to respond and rotate. See the "atom_style
dipole"_atom_style.html command for details. The "set" command can be
used to modify the orientation and length of the dipole moment of
individual particles, after then are created.
The ellipsoid style defines particles that are ellipsoids and thus can
be aspherical. Each particle has a shape, specified by 3 diameters,
and mass (or density). These particles store an angular momentum and
their orientation (quaternion), and can be acted upon by torque. They
do not store an angular velocity (omega), which can be in a different
direction than angular momentum, rather they compute it as needed.
The "set" command can be used to modify the diameter, orientation, and
mass of individual particles, after then are created. It also has a
brief explanation of what quaternions are.
The line style defines line segment particles with two end points and
a mass (or density). They can be used in 2d simulations, and they can
be joined together to form rigid bodies which represent arbitrary
polygons.
The tri style defines triangular particles with three corner points
and a mass (or density). They can be used in 3d simulations, and they
can be joined together to form rigid bodies which represent arbitrary
particles with a triangulated surface.
The peri style is used with "Peridynamic models"_pair_peri.html and
defines particles as having a volume, that is used internally in the
"pair_style peri"_pair_peri.html potentials.
The body style allows for definition of particles which can represent
complex entities, such as surface meshes of discrete points,
collections of sub-particles, deformable objects, etc. The body style
is discussed in more detail on the "body"_body.html doc page.
Note that if one of these atom styles is used (or multiple styles via
the "atom_style hybrid"_atom_style.html command), not all particles in
the system are required to be finite-size or aspherical.
For example, in the ellipsoid style, if the 3 shape parameters are set
to the same value, the particle will be a sphere rather than an
ellipsoid. If the 3 shape parameters are all set to 0.0 or if the
diameter is set to 0.0, it will be a point particle. In the line or
tri style, if the lineflag or triflag is specified as 0, then it
will be a point particle.
Some of the pair styles used to compute pairwise interactions between
finite-size particles also compute the correct interaction with point
particles as well, e.g. the interaction between a point particle and a
finite-size particle or between two point particles. If necessary,
"pair_style hybrid"_pair_hybrid.html can be used to insure the correct
interactions are computed for the appropriate style of interactions.
Likewise, using groups to partition particles (ellipsoids versus
spheres versus point particles) will allow you to use the appropriate
time integrators and temperature computations for each class of
particles. See the doc pages for various commands for details.
Also note that for "2d simulations"_dimension.html, atom styles sphere
and ellipsoid still use 3d particles, rather than as circular disks or
ellipses. This means they have the same moment of inertia as the 3d
object. When temperature is computed, the correct degrees of freedom
are used for rotation in a 2d versus 3d system.
Pair potentials :h5
When a system with finite-size particles is defined, the particles
will only rotate and experience torque if the force field computes
such interactions. These are the various "pair
styles"_pair_style.html that generate torque:
"pair_style gran/history"_pair_gran.html
"pair_style gran/hertzian"_pair_gran.html
"pair_style gran/no_history"_pair_gran.html
"pair_style dipole/cut"_pair_dipole.html
"pair_style gayberne"_pair_gayberne.html
"pair_style resquared"_pair_resquared.html
"pair_style brownian"_pair_brownian.html
"pair_style lubricate"_pair_lubricate.html
"pair_style line/lj"_pair_line_lj.html
"pair_style tri/lj"_pair_tri_lj.html
"pair_style body"_pair_body.html :ul
The granular pair styles are used with spherical particles. The
dipole pair style is used with the dipole atom style, which could be
applied to spherical or ellipsoidal particles. The GayBerne and
REsquared potentials require ellipsoidal particles, though they will
also work if the 3 shape parameters are the same (a sphere). The
Brownian and lubrication potentials are used with spherical particles.
The line, tri, and body potentials are used with line segment,
triangular, and body particles respectively.
Time integration :h5
There are several fixes that perform time integration on finite-size
spherical particles, meaning the integrators update the rotational
orientation and angular velocity or angular momentum of the particles:
"fix nve/sphere"_fix_nve_sphere.html
"fix nvt/sphere"_fix_nvt_sphere.html
"fix npt/sphere"_fix_npt_sphere.html :ul
Likewise, there are 3 fixes that perform time integration on
ellipsoidal particles:
"fix nve/asphere"_fix_nve_asphere.html
"fix nvt/asphere"_fix_nvt_asphere.html
"fix npt/asphere"_fix_npt_asphere.html :ul
The advantage of these fixes is that those which thermostat the
particles include the rotational degrees of freedom in the temperature
calculation and thermostatting. The "fix langevin"_fix_langevin
command can also be used with its {omgea} or {angmom} options to
thermostat the rotational degrees of freedom for spherical or
ellipsoidal particles. Other thermostatting fixes only operate on the
translational kinetic energy of finite-size particles.
These fixes perform constant NVE time integration on line segment,
triangular, and body particles:
"fix nve/line"_fix_nve_line.html
"fix nve/tri"_fix_nve_tri.html
"fix nve/body"_fix_nve_body.html :ul
Note that for mixtures of point and finite-size particles, these
integration fixes can only be used with "groups"_group.html which
contain finite-size particles.
Computes, thermodynamics, and dump output :h5
There are several computes that calculate the temperature or
rotational energy of spherical or ellipsoidal particles:
"compute temp/sphere"_compute_temp_sphere.html
"compute temp/asphere"_compute_temp_asphere.html
"compute erotate/sphere"_compute_erotate_sphere.html
"compute erotate/asphere"_compute_erotate_asphere.html :ul
These include rotational degrees of freedom in their computation. If
you wish the thermodynamic output of temperature or pressure to use
one of these computes (e.g. for a system entirely composed of
finite-size particles), then the compute can be defined and the
"thermo_modify"_thermo_modify.html command used. Note that by default
thermodynamic quantities will be calculated with a temperature that
only includes translational degrees of freedom. See the
"thermo_style"_thermo_style.html command for details.
These commands can be used to output various attributes of finite-size
particles:
"dump custom"_dump.html
"compute property/atom"_compute_property_atom.html
"dump local"_dump.html
"compute body/local"_compute_body_local.html :ul
Attributes include the dipole moment, the angular velocity, the
angular momentum, the quaternion, the torque, the end-point and
corner-point coordinates (for line and tri particles), and
sub-particle attributes of body particles.
Rigid bodies composed of finite-size particles :h5
The "fix rigid"_fix_rigid.html command treats a collection of
particles as a rigid body, computes its inertia tensor, sums the total
force and torque on the rigid body each timestep due to forces on its
constituent particles, and integrates the motion of the rigid body.
If any of the constituent particles of a rigid body are finite-size
particles (spheres or ellipsoids or line segments or triangles), then
their contribution to the inertia tensor of the body is different than
if they were point particles. This means the rotational dynamics of
the rigid body will be different. Thus a model of a dimer is
different if the dimer consists of two point masses versus two
spheroids, even if the two particles have the same mass. Finite-size
particles that experience torque due to their interaction with other
particles will also impart that torque to a rigid body they are part
of.
See the "fix rigid" command for example of complex rigid-body models
it is possible to define in LAMMPS.
Note that the "fix shake"_fix_shake.html command can also be used to
treat 2, 3, or 4 particles as a rigid body, but it always assumes the
particles are point masses.
Also note that body particles cannot be modeled with the "fix
rigid"_fix_rigid.html command. Body particles are treated by LAMMPS
as single particles, though they can store internal state, such as a
list of sub-particles. Individual body partices are typically treated
as rigid bodies, and their motion integrated with a command like "fix
nve/body"_fix_nve_body.html. Interactions between pairs of body
particles are computed via a command like "pair_style
body"_pair_body.html.
:line
6.15 Output from LAMMPS (thermo, dumps, computes, fixes, variables) :link(howto_15),h4
There are four basic kinds of LAMMPS output:
"Thermodynamic output"_thermo_style.html, which is a list
of quantities printed every few timesteps to the screen and logfile. :ulb,l
"Dump files"_dump.html, which contain snapshots of atoms and various
per-atom values and are written at a specified frequency. :l
Certain fixes can output user-specified quantities to files: "fix
ave/time"_fix_ave_time.html for time averaging, "fix
ave/chunk"_fix_ave_chunk.html for spatial or other averaging, and "fix
print"_fix_print.html for single-line output of
"variables"_variable.html. Fix print can also output to the
screen. :l
"Restart files"_restart.html. :l
:ule
A simulation prints one set of thermodynamic output and (optionally)
restart files. It can generate any number of dump files and fix
output files, depending on what "dump"_dump.html and "fix"_fix.html
commands you specify.
As discussed below, LAMMPS gives you a variety of ways to determine
what quantities are computed and printed when the thermodynamics,
dump, or fix commands listed above perform output. Throughout this
discussion, note that users can also "add their own computes and fixes
to LAMMPS"_Section_modify.html which can then generate values that can
then be output with these commands.
The following sub-sections discuss different LAMMPS command related
to output and the kind of data they operate on and produce:
"Global/per-atom/local data"_#global
"Scalar/vector/array data"_#scalar
"Thermodynamic output"_#thermo
"Dump file output"_#dump
"Fixes that write output files"_#fixoutput
"Computes that process output quantities"_#computeoutput
"Fixes that process output quantities"_#fixprocoutput
"Computes that generate values to output"_#compute
"Fixes that generate values to output"_#fix
"Variables that generate values to output"_#variable
"Summary table of output options and data flow between commands"_#table :ul
Global/per-atom/local data :h5,link(global)
Various output-related commands work with three different styles of
data: global, per-atom, or local. A global datum is one or more
system-wide values, e.g. the temperature of the system. A per-atom
datum is one or more values per atom, e.g. the kinetic energy of each
atom. Local datums are calculated by each processor based on the
atoms it owns, but there may be zero or more per atom, e.g. a list of
bond distances.
Scalar/vector/array data :h5,link(scalar)
Global, per-atom, and local datums can each come in three kinds: a
single scalar value, a vector of values, or a 2d array of values. The
doc page for a "compute" or "fix" or "variable" that generates data
will specify both the style and kind of data it produces, e.g. a
per-atom vector.
When a quantity is accessed, as in many of the output commands
discussed below, it can be referenced via the following bracket
notation, where ID in this case is the ID of a compute. The leading
"c_" would be replaced by "f_" for a fix, or "v_" for a variable:
c_ID | entire scalar, vector, or array
c_ID\[I\] | one element of vector, one column of array
c_ID\[I\]\[J\] | one element of array :tb(s=|)
In other words, using one bracket reduces the dimension of the data
once (vector -> scalar, array -> vector). Using two brackets reduces
the dimension twice (array -> scalar). Thus a command that uses
scalar values as input can typically also process elements of a vector
or array.
Thermodynamic output :h5,link(thermo)
The frequency and format of thermodynamic output is set by the
"thermo"_thermo.html, "thermo_style"_thermo_style.html, and
"thermo_modify"_thermo_modify.html commands. The
"thermo_style"_thermo_style.html command also specifies what values
are calculated and written out. Pre-defined keywords can be specified
(e.g. press, etotal, etc). Three additional kinds of keywords can
also be specified (c_ID, f_ID, v_name), where a "compute"_compute.html
or "fix"_fix.html or "variable"_variable.html provides the value to be
output. In each case, the compute, fix, or variable must generate
global values for input to the "thermo_style custom"_dump.html
command.
Note that thermodynamic output values can be "extensive" or
"intensive". The former scale with the number of atoms in the system
(e.g. total energy), the latter do not (e.g. temperature). The
setting for "thermo_modify norm"_thermo_modify.html determines whether
extensive quantities are normalized or not. Computes and fixes
produce either extensive or intensive values; see their individual doc
pages for details. "Equal-style variables"_variable.html produce only
intensive values; you can include a division by "natoms" in the
formula if desired, to make an extensive calculation produce an
intensive result.
Dump file output :h5,link(dump)
Dump file output is specified by the "dump"_dump.html and
"dump_modify"_dump_modify.html commands. There are several
pre-defined formats (dump atom, dump xtc, etc).
There is also a "dump custom"_dump.html format where the user
specifies what values are output with each atom. Pre-defined atom
attributes can be specified (id, x, fx, etc). Three additional kinds
of keywords can also be specified (c_ID, f_ID, v_name), where a
"compute"_compute.html or "fix"_fix.html or "variable"_variable.html
provides the values to be output. In each case, the compute, fix, or
variable must generate per-atom values for input to the "dump
custom"_dump.html command.
There is also a "dump local"_dump.html format where the user specifies
what local values to output. A pre-defined index keyword can be
specified to enumerate the local values. Two additional kinds of
keywords can also be specified (c_ID, f_ID), where a
"compute"_compute.html or "fix"_fix.html or "variable"_variable.html
provides the values to be output. In each case, the compute or fix
must generate local values for input to the "dump local"_dump.html
command.
Fixes that write output files :h5,link(fixoutput)
Several fixes take various quantities as input and can write output
files: "fix ave/time"_fix_ave_time.html, "fix
ave/chunk"_fix_ave_chunk.html, "fix ave/histo"_fix_ave_histo.html,
"fix ave/correlate"_fix_ave_correlate.html, and "fix
print"_fix_print.html.
The "fix ave/time"_fix_ave_time.html command enables direct output to
a file and/or time-averaging of global scalars or vectors. The user
specifies one or more quantities as input. These can be global
"compute"_compute.html values, global "fix"_fix.html values, or
"variables"_variable.html of any style except the atom style which
produces per-atom values. Since a variable can refer to keywords used
by the "thermo_style custom"_thermo_style.html command (like temp or
press) and individual per-atom values, a wide variety of quantities
can be time averaged and/or output in this way. If the inputs are one
or more scalar values, then the fix generate a global scalar or vector
of output. If the inputs are one or more vector values, then the fix
generates a global vector or array of output. The time-averaged
output of this fix can also be used as input to other output commands.
The "fix ave/chunk"_fix_ave_chunk.html command enables direct output
to a file of chunk-averaged per-atom quantities like those output in
dump files. Chunks can represent spatial bins or other collections of
atoms, e.g. individual molecules. The per-atom quantities can be atom
density (mass or number) or atom attributes such as position,
velocity, force. They can also be per-atom quantities calculated by a
"compute"_compute.html, by a "fix"_fix.html, or by an atom-style
"variable"_variable.html. The chunk-averaged output of this fix can
also be used as input to other output commands.
The "fix ave/histo"_fix_ave_histo.html command enables direct output
to a file of histogrammed quantities, which can be global or per-atom
or local quantities. The histogram output of this fix can also be
used as input to other output commands.
The "fix ave/correlate"_fix_ave_correlate.html command enables direct
output to a file of time-correlated quantities, which can be global
values. The correlation matrix output of this fix can also be used as
input to other output commands.
The "fix print"_fix_print.html command can generate a line of output
written to the screen and log file or to a separate file, periodically
during a running simulation. The line can contain one or more
"variable"_variable.html values for any style variable except the
vector or atom styles). As explained above, variables themselves can
contain references to global values generated by "thermodynamic
keywords"_thermo_style.html, "computes"_compute.html,
"fixes"_fix.html, or other "variables"_variable.html, or to per-atom
values for a specific atom. Thus the "fix print"_fix_print.html
command is a means to output a wide variety of quantities separate
from normal thermodynamic or dump file output.
Computes that process output quantities :h5,link(computeoutput)
The "compute reduce"_compute_reduce.html and "compute
reduce/region"_compute_reduce.html commands take one or more per-atom
or local vector quantities as inputs and "reduce" them (sum, min, max,
ave) to scalar quantities. These are produced as output values which
can be used as input to other output commands.
The "compute slice"_compute_slice.html command take one or more global
vector or array quantities as inputs and extracts a subset of their
values to create a new vector or array. These are produced as output
values which can be used as input to other output commands.
The "compute property/atom"_compute_property_atom.html command takes a
list of one or more pre-defined atom attributes (id, x, fx, etc) and
stores the values in a per-atom vector or array. These are produced
as output values which can be used as input to other output commands.
The list of atom attributes is the same as for the "dump
custom"_dump.html command.
The "compute property/local"_compute_property_local.html command takes
a list of one or more pre-defined local attributes (bond info, angle
info, etc) and stores the values in a local vector or array. These
are produced as output values which can be used as input to other
output commands.
Fixes that process output quantities :h5,link(fixprocoutput)
The "fix vector"_fix_vector.html command can create global vectors as
output from global scalars as input, accumulating them one element at
a time.
The "fix ave/atom"_fix_ave_atom.html command performs time-averaging
of per-atom vectors. The per-atom quantities can be atom attributes
such as position, velocity, force. They can also be per-atom
quantities calculated by a "compute"_compute.html, by a
"fix"_fix.html, or by an atom-style "variable"_variable.html. The
time-averaged per-atom output of this fix can be used as input to
other output commands.
The "fix store/state"_fix_store_state.html command can archive one or
more per-atom attributes at a particular time, so that the old values
can be used in a future calculation or output. The list of atom
attributes is the same as for the "dump custom"_dump.html command,
including per-atom quantities calculated by a "compute"_compute.html,
by a "fix"_fix.html, or by an atom-style "variable"_variable.html.
The output of this fix can be used as input to other output commands.
Computes that generate values to output :h5,link(compute)
Every "compute"_compute.html in LAMMPS produces either global or
per-atom or local values. The values can be scalars or vectors or
arrays of data. These values can be output using the other commands
described in this section. The doc page for each compute command
describes what it produces. Computes that produce per-atom or local
values have the word "atom" or "local" in their style name. Computes
without the word "atom" or "local" produce global values.
Fixes that generate values to output :h5,link(fix)
Some "fixes"_fix.html in LAMMPS produces either global or per-atom or
local values which can be accessed by other commands. The values can
be scalars or vectors or arrays of data. These values can be output
using the other commands described in this section. The doc page for
each fix command tells whether it produces any output quantities and
describes them.
Variables that generate values to output :h5,link(variable)
"Variables"_variable.html defined in an input script can store one or
more strings. But equal-style, vector-style, and atom-style or
atomfile-style variables generate a global scalar value, global vector
or values, or a per-atom vector, respectively, when accessed. The
formulas used to define these variables can contain references to the
thermodynamic keywords and to global and per-atom data generated by
computes, fixes, and other variables. The values generated by
variables can be used as input to and thus output by the other
commands described in this section.
Summary table of output options and data flow between commands :h5,link(table)
This table summarizes the various commands that can be used for
generating output from LAMMPS. Each command produces output data of
some kind and/or writes data to a file. Most of the commands can take
data from other commands as input. Thus you can link many of these
commands together in pipeline form, where data produced by one command
is used as input to another command and eventually written to the
screen or to a file. Note that to hook two commands together the
output and input data types must match, e.g. global/per-atom/local
data and scalar/vector/array data.
Also note that, as described above, when a command takes a scalar as
input, that could be an element of a vector or array. Likewise a
vector input could be a column of an array.
Command: Input: Output:
"thermo_style custom"_thermo_style.html: global scalars: screen, log file:
"dump custom"_dump.html: per-atom vectors: dump file:
"dump local"_dump.html: local vectors: dump file:
"fix print"_fix_print.html: global scalar from variable: screen, file:
"print"_print.html: global scalar from variable: screen:
"computes"_compute.html: N/A: global/per-atom/local scalar/vector/array:
"fixes"_fix.html: N/A: global/per-atom/local scalar/vector/array:
"variables"_variable.html: global scalars and vectors, per-atom vectors: global scalar and vector, per-atom vector:
"compute reduce"_compute_reduce.html: per-atom/local vectors: global scalar/vector:
"compute slice"_compute_slice.html: global vectors/arrays: global vector/array:
"compute property/atom"_compute_property_atom.html: per-atom vectors: per-atom vector/array:
"compute property/local"_compute_property_local.html: local vectors: local vector/array:
"fix vector"_fix_vector.html: global scalars: global vector:
"fix ave/atom"_fix_ave_atom.html: per-atom vectors: per-atom vector/array:
"fix ave/time"_fix_ave_time.html: global scalars/vectors: global scalar/vector/array, file:
"fix ave/chunk"_fix_ave_chunk.html: per-atom vectors: global array, file:
"fix ave/histo"_fix_ave_histo.html: global/per-atom/local scalars and vectors: global array, file:
"fix ave/correlate"_fix_ave_correlate.html: global scalars: global array, file:
"fix store/state"_fix_store_state.html: per-atom vectors: per-atom vector/array :tb(c=3,s=:)
:line
6.16 Thermostatting, barostatting, and computing temperature :link(howto_16),h4
Thermostatting means controlling the temperature of particles in an MD
simulation. Barostatting means controlling the pressure. Since the
pressure includes a kinetic component due to particle velocities, both
these operations require calculation of the temperature. Typically a
target temperature (T) and/or pressure (P) is specified by the user,
and the thermostat or barostat attempts to equilibrate the system to
the requested T and/or P.
Temperature is computed as kinetic energy divided by some number of
degrees of freedom (and the Boltzmann constant). Since kinetic energy
is a function of particle velocity, there is often a need to
distinguish between a particle's advection velocity (due to some
aggregate motion of particles) and its thermal velocity. The sum of
the two is the particle's total velocity, but the latter is often what
is wanted to compute a temperature.
LAMMPS has several options for computing temperatures, any of which
can be used in thermostatting and barostatting. These "compute
commands"_compute.html calculate temperature, and the "compute
pressure"_compute_pressure.html command calculates pressure.
"compute temp"_compute_temp.html
"compute temp/sphere"_compute_temp_sphere.html
"compute temp/asphere"_compute_temp_asphere.html
"compute temp/com"_compute_temp_com.html
"compute temp/deform"_compute_temp_deform.html
"compute temp/partial"_compute_temp_partial.html
"compute temp/profile"_compute_temp_profile.html
"compute temp/ramp"_compute_temp_ramp.html
"compute temp/region"_compute_temp_region.html :ul
All but the first 3 calculate velocity biases directly (e.g. advection
velocities) that are removed when computing the thermal temperature.
"Compute temp/sphere"_compute_temp_sphere.html and "compute
temp/asphere"_compute_temp_asphere.html compute kinetic energy for
finite-size particles that includes rotational degrees of freedom.
They both allow for velocity biases indirectly, via an optional extra
argument, another temperature compute that subtracts a velocity bias.
This allows the translational velocity of spherical or aspherical
particles to be adjusted in prescribed ways.
Thermostatting in LAMMPS is performed by "fixes"_fix.html, or in one
case by a pair style. Several thermostatting fixes are available:
Nose-Hoover (nvt), Berendsen, CSVR, Langevin, and direct rescaling
(temp/rescale). Dissipative particle dynamics (DPD) thermostatting
can be invoked via the {dpd/tstat} pair style:
"fix nvt"_fix_nh.html
"fix nvt/sphere"_fix_nvt_sphere.html
"fix nvt/asphere"_fix_nvt_asphere.html
"fix nvt/sllod"_fix_nvt_sllod.html
"fix temp/berendsen"_fix_temp_berendsen.html
"fix temp/csvr"_fix_temp_csvr.html
"fix langevin"_fix_langevin.html
"fix temp/rescale"_fix_temp_rescale.html
"pair_style dpd/tstat"_pair_dpd.html :ul
"Fix nvt"_fix_nh.html only thermostats the translational velocity of
particles. "Fix nvt/sllod"_fix_nvt_sllod.html also does this, except
that it subtracts out a velocity bias due to a deforming box and
integrates the SLLOD equations of motion. See the "NEMD
simulations"_#howto_13 section of this page for further details. "Fix
nvt/sphere"_fix_nvt_sphere.html and "fix
nvt/asphere"_fix_nvt_asphere.html thermostat not only translation
velocities but also rotational velocities for spherical and aspherical
particles.
DPD thermostatting alters pairwise interactions in a manner analogous
to the per-particle thermostatting of "fix
langevin"_fix_langevin.html.
Any of the thermostatting fixes can use temperature computes that
remove bias which has two effects. First, the current calculated
temperature, which is compared to the requested target temperature, is
calculated with the velocity bias removed. Second, the thermostat
adjusts only the thermal temperature component of the particle's
velocities, which are the velocities with the bias removed. The
removed bias is then added back to the adjusted velocities. See the
doc pages for the individual fixes and for the
"fix_modify"_fix_modify.html command for instructions on how to assign
a temperature compute to a thermostatting fix. For example, you can
apply a thermostat to only the x and z components of velocity by using
it in conjunction with "compute
temp/partial"_compute_temp_partial.html. Of you could thermostat only
the thermal temperature of a streaming flow of particles without
affecting the streaming velocity, by using "compute
temp/profile"_compute_temp_profile.html.
NOTE: Only the nvt fixes perform time integration, meaning they update
the velocities and positions of particles due to forces and velocities
respectively. The other thermostat fixes only adjust velocities; they
do NOT perform time integration updates. Thus they should be used in
conjunction with a constant NVE integration fix such as these:
"fix nve"_fix_nve.html
"fix nve/sphere"_fix_nve_sphere.html
"fix nve/asphere"_fix_nve_asphere.html :ul
Barostatting in LAMMPS is also performed by "fixes"_fix.html. Two
barosttating methods are currently available: Nose-Hoover (npt and
nph) and Berendsen:
"fix npt"_fix_nh.html
"fix npt/sphere"_fix_npt_sphere.html
"fix npt/asphere"_fix_npt_asphere.html
"fix nph"_fix_nh.html
"fix press/berendsen"_fix_press_berendsen.html :ul
The "fix npt"_fix_nh.html commands include a Nose-Hoover thermostat
and barostat. "Fix nph"_fix_nh.html is just a Nose/Hoover barostat;
it does no thermostatting. Both "fix nph"_fix_nh.html and "fix
press/berendsen"_fix_press_berendsen.html can be used in conjunction
with any of the thermostatting fixes.
As with the thermostats, "fix npt"_fix_nh.html and "fix
nph"_fix_nh.html only use translational motion of the particles in
computing T and P and performing thermo/barostatting. "Fix
npt/sphere"_fix_npt_sphere.html and "fix
npt/asphere"_fix_npt_asphere.html thermo/barostat using not only
translation velocities but also rotational velocities for spherical
and aspherical particles.
All of the barostatting fixes use the "compute
pressure"_compute_pressure.html compute to calculate a current
pressure. By default, this compute is created with a simple "compute
temp"_compute_temp.html (see the last argument of the "compute
pressure"_compute_pressure.html command), which is used to calculated
the kinetic component of the pressure. The barostatting fixes can
also use temperature computes that remove bias for the purpose of
computing the kinetic component which contributes to the current
pressure. See the doc pages for the individual fixes and for the
"fix_modify"_fix_modify.html command for instructions on how to assign
a temperature or pressure compute to a barostatting fix.
NOTE: As with the thermostats, the Nose/Hoover methods ("fix
npt"_fix_nh.html and "fix nph"_fix_nh.html) perform time integration.
"Fix press/berendsen"_fix_press_berendsen.html does NOT, so it should
be used with one of the constant NVE fixes or with one of the NVT
fixes.
Finally, thermodynamic output, which can be setup via the
"thermo_style"_thermo_style.html command, often includes temperature
and pressure values. As explained on the doc page for the
"thermo_style"_thermo_style.html command, the default T and P are
setup by the thermo command itself. They are NOT the ones associated
with any thermostatting or barostatting fix you have defined or with
any compute that calculates a temperature or pressure. Thus if you
want to view these values of T and P, you need to specify them
explicitly via a "thermo_style custom"_thermo_style.html command. Or
you can use the "thermo_modify"_thermo_modify.html command to
re-define what temperature or pressure compute is used for default
thermodynamic output.
:line
6.17 Walls :link(howto_17),h4
Walls in an MD simulation are typically used to bound particle motion,
i.e. to serve as a boundary condition.
Walls in LAMMPS can be of rough (made of particles) or idealized
surfaces. Ideal walls can be smooth, generating forces only in the
normal direction, or frictional, generating forces also in the
tangential direction.
Rough walls, built of particles, can be created in various ways. The
particles themselves can be generated like any other particle, via the
"lattice"_lattice.html and "create_atoms"_create_atoms.html commands,
or read in via the "read_data"_read_data.html command.
Their motion can be constrained by many different commands, so that
they do not move at all, move together as a group at constant velocity
or in response to a net force acting on them, move in a prescribed
fashion (e.g. rotate around a point), etc. Note that if a time
integration fix like "fix nve"_fix_nve.html or "fix nvt"_fix_nh.html
is not used with the group that contains wall particles, their
positions and velocities will not be updated.
"fix aveforce"_fix_aveforce.html - set force on particles to average value, so they move together
"fix setforce"_fix_setforce.html - set force on particles to a value, e.g. 0.0
"fix freeze"_fix_freeze.html - freeze particles for use as granular walls
"fix nve/noforce"_fix_nve_noforce.html - advect particles by their velocity, but without force
"fix move"_fix_move.html - prescribe motion of particles by a linear velocity, oscillation, rotation, variable :ul
The "fix move"_fix_move.html command offers the most generality, since
the motion of individual particles can be specified with
"variable"_variable.html formula which depends on time and/or the
particle position.
For rough walls, it may be useful to turn off pairwise interactions
between wall particles via the "neigh_modify
exclude"_neigh_modify.html command.
Rough walls can also be created by specifying frozen particles that do
not move and do not interact with mobile particles, and then tethering
other particles to the fixed particles, via a "bond"_bond_style.html.
The bonded particles do interact with other mobile particles.
Idealized walls can be specified via several fix commands. "Fix
wall/gran"_fix_wall_gran.html creates frictional walls for use with
granular particles; all the other commands create smooth walls.
"fix wall/reflect"_fix_wall_reflect.html - reflective flat walls
"fix wall/lj93"_fix_wall.html - flat walls, with Lennard-Jones 9/3 potential
"fix wall/lj126"_fix_wall.html - flat walls, with Lennard-Jones 12/6 potential
"fix wall/colloid"_fix_wall.html - flat walls, with "pair_style colloid"_pair_colloid.html potential
"fix wall/harmonic"_fix_wall.html - flat walls, with repulsive harmonic spring potential
"fix wall/region"_fix_wall_region.html - use region surface as wall
"fix wall/gran"_fix_wall_gran.html - flat or curved walls with "pair_style granular"_pair_gran.html potential :ul
The {lj93}, {lj126}, {colloid}, and {harmonic} styles all allow the
flat walls to move with a constant velocity, or oscillate in time.
The "fix wall/region"_fix_wall_region.html command offers the most
generality, since the region surface is treated as a wall, and the
geometry of the region can be a simple primitive volume (e.g. a
sphere, or cube, or plane), or a complex volume made from the union
and intersection of primitive volumes. "Regions"_region.html can also
specify a volume "interior" or "exterior" to the specified primitive
shape or {union} or {intersection}. "Regions"_region.html can also be
"dynamic" meaning they move with constant velocity, oscillate, or
rotate.
The only frictional idealized walls currently in LAMMPS are flat or
curved surfaces specified by the "fix wall/gran"_fix_wall_gran.html
command. At some point we plan to allow regoin surfaces to be used as
frictional walls, as well as triangulated surfaces.
:line
6.18 Elastic constants :link(howto_18),h4
Elastic constants characterize the stiffness of a material. The formal
definition is provided by the linear relation that holds between the
stress and strain tensors in the limit of infinitesimal deformation.
In tensor notation, this is expressed as s_ij = C_ijkl * e_kl, where
the repeated indices imply summation. s_ij are the elements of the
symmetric stress tensor. e_kl are the elements of the symmetric strain
tensor. C_ijkl are the elements of the fourth rank tensor of elastic
constants. In three dimensions, this tensor has 3^4=81 elements. Using
Voigt notation, the tensor can be written as a 6x6 matrix, where C_ij
is now the derivative of s_i w.r.t. e_j. Because s_i is itself a
derivative w.r.t. e_i, it follows that C_ij is also symmetric, with at
most 7*6/2 = 21 distinct elements.
At zero temperature, it is easy to estimate these derivatives by
deforming the simulation box in one of the six directions using the
"change_box"_change_box.html command and measuring the change in the
stress tensor. A general-purpose script that does this is given in the
examples/elastic directory described in "this
section"_Section_example.html.
Calculating elastic constants at finite temperature is more
challenging, because it is necessary to run a simulation that perfoms
time averages of differential properties. One way to do this is to
measure the change in average stress tensor in an NVT simulations when
the cell volume undergoes a finite deformation. In order to balance
the systematic and statistical errors in this method, the magnitude of
the deformation must be chosen judiciously, and care must be taken to
fully equilibrate the deformed cell before sampling the stress
tensor. Another approach is to sample the triclinic cell fluctuations
that occur in an NPT simulation. This method can also be slow to
converge and requires careful post-processing "(Shinoda)"_#Shinoda1
:line
6.19 Library interface to LAMMPS :link(howto_19),h4
As described in "Section 2.5"_Section_start.html#start_5, LAMMPS
can be built as a library, so that it can be called by another code,
used in a "coupled manner"_Section_howto.html#howto_10 with other
codes, or driven through a "Python interface"_Section_python.html.
All of these methodologies use a C-style interface to LAMMPS that is
provided in the files src/library.cpp and src/library.h. The
functions therein have a C-style argument list, but contain C++ code
you could write yourself in a C++ application that was invoking LAMMPS
directly. The C++ code in the functions illustrates how to invoke
internal LAMMPS operations. Note that LAMMPS classes are defined
within a LAMMPS namespace (LAMMPS_NS) if you use them from another C++
application.
Library.cpp contains these functions for creating and destroying an
instance of LAMMPS and sending it commands to execute. See the
documentation in the src/library.cpp file for details:
void lammps_open(int, char **, MPI_Comm, void **)
void lammps_open_no_mpi(int, char **, void **)
void lammps_close(void *)
int lammps_version(void *)
void lammps_file(void *, char *)
char *lammps_command(void *, char *)
void lammps_commands_list(void *, int, char **)
void lammps_commands_string(void *, char *)
void lammps_free(void *) :pre
The lammps_open() function is used to initialize LAMMPS, passing in a
list of strings as if they were "command-line
-arguments"_Section_start.html#start_7 when LAMMPS is run in
+arguments"_Section_start.html#start_6 when LAMMPS is run in
stand-alone mode from the command line, and a MPI communicator for
LAMMPS to run under. It returns a ptr to the LAMMPS object that is
created, and which is used in subsequent library calls. The
lammps_open() function can be called multiple times, to create
multiple instances of LAMMPS.
LAMMPS will run on the set of processors in the communicator. This
means the calling code can run LAMMPS on all or a subset of
processors. For example, a wrapper script might decide to alternate
between LAMMPS and another code, allowing them both to run on all the
processors. Or it might allocate half the processors to LAMMPS and
half to the other code and run both codes simultaneously before
syncing them up periodically. Or it might instantiate multiple
instances of LAMMPS to perform different calculations.
The lammps_open_no_mpi() function is similar except that no MPI
communicator is passed from the caller. Instead, MPI_COMM_WORLD is
used to instantiate LAMMPS, and MPI is initialized if necessary.
The lammps_close() function is used to shut down an instance of LAMMPS
and free all its memory.
The lammps_version() function can be used to determined the specific
version of the underlying LAMMPS code. This is particularly useful
when loading LAMMPS as a shared library via dlopen(). The code using
the library interface can than use this information to adapt to
changes to the LAMMPS command syntax between versions. The returned
LAMMPS version code is an integer (e.g. 2 Sep 2015 results in
20150902) that grows with every new LAMMPS version.
The lammps_file(), lammps_command(), lammps_commands_list(), and
lammps_commands_string() functions are used to pass one or more
commands to LAMMPS to execute, the same as if they were coming from an
input script.
Via these functions, the calling code can read or generate a series of
LAMMPS commands one or multiple at a time and pass it thru the library
interface to setup a problem and then run it in stages. The caller
can interleave the command function calls with operations it performs,
calls to extract information from or set information within LAMMPS, or
calls to another code's library.
The lammps_file() function passes the filename of an input script.
The lammps_command() function passes a single command as a string.
The lammps_commands_list() function passes multiple commands in a
char** list. In both lammps_command() and lammps_commands_list(),
individual commands may or may not have a trailing newline. The
lammps_commands_string() function passes multiple commands
concatenated into one long string, separated by newline characters.
In both lammps_commands_list() and lammps_commands_string(), a single
command can be spread across multiple lines, if the last printable
character of all but the last line is "&", the same as if the lines
appeared in an input script.
The lammps_free() function is a clean-up function to free memory that
the library allocated previously via other function calls. See
comments in src/library.cpp file for which other functions need this
clean-up.
Library.cpp also contains these functions for extracting information
from LAMMPS and setting value within LAMMPS. Again, see the
documentation in the src/library.cpp file for details, including
which quantities can be queried by name:
void *lammps_extract_global(void *, char *)
void lammps_extract_box(void *, double *, double *,
double *, double *, double *, int *, int *)
void *lammps_extract_atom(void *, char *)
void *lammps_extract_compute(void *, char *, int, int)
void *lammps_extract_fix(void *, char *, int, int, int, int)
void *lammps_extract_variable(void *, char *, char *) :pre
void lammps_reset_box(void *, double *, double *, double, double, double)
int lammps_set_variable(void *, char *, char *) :pre
double lammps_get_thermo(void *, char *)
int lammps_get_natoms(void *)
void lammps_gather_atoms(void *, double *)
void lammps_scatter_atoms(void *, double *) :pre
void lammps_create_atoms(void *, int, tagint *, int *, double *, double *,
imageint *, int) :pre
The extract functions return a pointer to various global or per-atom
quantities stored in LAMMPS or to values calculated by a compute, fix,
or variable. The pointer returned by the extract_global() function
can be used as a permanent reference to a value which may change. For
the extract_atom() method, see the extract() method in the
src/atom.cpp file for a list of valid per-atom properties. New names
could easily be added if the property you want is not listed. For the
other extract functions, the underlying storage may be reallocated as
LAMMPS runs, so you need to re-call the function to assure a current
pointer or returned value(s).
The lammps_reset_box() function resets the size and shape of the
simulation box, e.g. as part of restoring a previously extracted and
saved state of a simulation.
The lammps_set_variable() function can set an existing string-style
variable to a new string value, so that subsequent LAMMPS commands can
access the variable.
The lammps_get_thermo() function returns the current value of a thermo
keyword as a double precision value.
The lammps_get_natoms() function returns the total number of atoms in
the system and can be used by the caller to allocate space for the
lammps_gather_atoms() and lammps_scatter_atoms() functions. The
gather function collects peratom info of the requested type (atom
coords, types, forces, etc) from all processors, orders them by atom
ID, and returns a full list to each calling processor. The scatter
function does the inverse. It distributes the same peratom values,
passed by the caller, to each atom owned by individual processors.
Both methods are thus a means to extract or assign (overwrite) any
peratom quantities within LAMMPS. See the extract() method in the
src/atom.cpp file for a list of valid per-atom properties. New names
could easily be added if the property you want is not listed.
A special treatment is applied for accessing image flags via the
"image" property. Image flags are stored in a packed format with all
three image flags stored in a single integer. When signaling to access
the image flags as 3 individual values per atom instead of 1, the data
is transparently packed or unpacked by the library interface.
The lammps_create_atoms() function takes a list of N atoms as input
with atom types and coords (required), an optionally atom IDs and
velocities and image flags. It uses the coords of each atom to assign
it as a new atom to the processor that owns it. This function is
useful to add atoms to a simulation or (in tandem with
lammps_reset_box()) to restore a previously extracted and saved state
of a simulation. Additional properties for the new atoms can then be
assigned via the lammps_scatter_atoms() or lammps_extract_atom()
functions.
The examples/COUPLE and python directories have example C++ and C and
Python codes which show how a driver code can link to LAMMPS as a
library, run LAMMPS on a subset of processors, grab data from LAMMPS,
change it, and put it back into LAMMPS.
NOTE: You can write code for additional functions as needed to define
how your code talks to LAMMPS and add them to src/library.cpp and
src/library.h, as well as to the "Python
interface"_Section_python.html. The added functions can access or
change any LAMMPS data you wish.
:line
6.20 Calculating thermal conductivity :link(howto_20),h4
The thermal conductivity kappa of a material can be measured in at
least 4 ways using various options in LAMMPS. See the examples/KAPPA
directory for scripts that implement the 4 methods discussed here for
a simple Lennard-Jones fluid model. Also, see "this
section"_Section_howto.html#howto_21 of the manual for an analogous
discussion for viscosity.
The thermal conductivity tensor kappa is a measure of the propensity
of a material to transmit heat energy in a diffusive manner as given
by Fourier's law
J = -kappa grad(T)
where J is the heat flux in units of energy per area per time and
grad(T) is the spatial gradient of temperature. The thermal
conductivity thus has units of energy per distance per time per degree
K and is often approximated as an isotropic quantity, i.e. as a
scalar.
The first method is to setup two thermostatted regions at opposite
ends of a simulation box, or one in the middle and one at the end of a
periodic box. By holding the two regions at different temperatures
with a "thermostatting fix"_Section_howto.html#howto_13, the energy
added to the hot region should equal the energy subtracted from the
cold region and be proportional to the heat flux moving between the
regions. See the papers by "Ikeshoji and Hafskjold"_#howto-Ikeshoji
and "Wirnsberger et al"_#howto-Wirnsberger for details of this idea.
Note that thermostatting fixes such as "fix nvt"_fix_nh.html, "fix
langevin"_fix_langevin.html, and "fix
temp/rescale"_fix_temp_rescale.html store the cumulative energy they
add/subtract.
Alternatively, as a second method, the "fix heat"_fix_heat.html or
"fix ehex"_fix_ehex.html commands can be used in place of thermostats
on each of two regions to add/subtract specified amounts of energy to
both regions. In both cases, the resulting temperatures of the two
regions can be monitored with the "compute temp/region" command and
the temperature profile of the intermediate region can be monitored
with the "fix ave/chunk"_fix_ave_chunk.html and "compute
ke/atom"_compute_ke_atom.html commands.
The third method is to perform a reverse non-equilibrium MD simulation
using the "fix thermal/conductivity"_fix_thermal_conductivity.html
command which implements the rNEMD algorithm of Muller-Plathe.
Kinetic energy is swapped between atoms in two different layers of the
simulation box. This induces a temperature gradient between the two
layers which can be monitored with the "fix
ave/chunk"_fix_ave_chunk.html and "compute
ke/atom"_compute_ke_atom.html commands. The fix tallies the
cumulative energy transfer that it performs. See the "fix
thermal/conductivity"_fix_thermal_conductivity.html command for
details.
The fourth method is based on the Green-Kubo (GK) formula which
relates the ensemble average of the auto-correlation of the heat flux
to kappa. The heat flux can be calculated from the fluctuations of
per-atom potential and kinetic energies and per-atom stress tensor in
a steady-state equilibrated simulation. This is in contrast to the
two preceding non-equilibrium methods, where energy flows continuously
between hot and cold regions of the simulation box.
The "compute heat/flux"_compute_heat_flux.html command can calculate
the needed heat flux and describes how to implement the Green_Kubo
formalism using additional LAMMPS commands, such as the "fix
ave/correlate"_fix_ave_correlate.html command to calculate the needed
auto-correlation. See the doc page for the "compute
heat/flux"_compute_heat_flux.html command for an example input script
that calculates the thermal conductivity of solid Ar via the GK
formalism.
:line
6.21 Calculating viscosity :link(howto_21),h4
The shear viscosity eta of a fluid can be measured in at least 5 ways
using various options in LAMMPS. See the examples/VISCOSITY directory
for scripts that implement the 5 methods discussed here for a simple
Lennard-Jones fluid model. Also, see "this
section"_Section_howto.html#howto_20 of the manual for an analogous
discussion for thermal conductivity.
Eta is a measure of the propensity of a fluid to transmit momentum in
a direction perpendicular to the direction of velocity or momentum
flow. Alternatively it is the resistance the fluid has to being
sheared. It is given by
J = -eta grad(Vstream)
where J is the momentum flux in units of momentum per area per time.
and grad(Vstream) is the spatial gradient of the velocity of the fluid
moving in another direction, normal to the area through which the
momentum flows. Viscosity thus has units of pressure-time.
The first method is to perform a non-equilibrium MD (NEMD) simulation
by shearing the simulation box via the "fix deform"_fix_deform.html
command, and using the "fix nvt/sllod"_fix_nvt_sllod.html command to
thermostat the fluid via the SLLOD equations of motion.
Alternatively, as a second method, one or more moving walls can be
used to shear the fluid in between them, again with some kind of
thermostat that modifies only the thermal (non-shearing) components of
velocity to prevent the fluid from heating up.
In both cases, the velocity profile setup in the fluid by this
procedure can be monitored by the "fix
ave/chunk"_fix_ave_chunk.html command, which determines
grad(Vstream) in the equation above. E.g. the derivative in the
y-direction of the Vx component of fluid motion or grad(Vstream) =
dVx/dy. The Pxy off-diagonal component of the pressure or stress
tensor, as calculated by the "compute pressure"_compute_pressure.html
command, can also be monitored, which is the J term in the equation
above. See "this section"_Section_howto.html#howto_13 of the manual
for details on NEMD simulations.
The third method is to perform a reverse non-equilibrium MD simulation
using the "fix viscosity"_fix_viscosity.html command which implements
the rNEMD algorithm of Muller-Plathe. Momentum in one dimension is
swapped between atoms in two different layers of the simulation box in
a different dimension. This induces a velocity gradient which can be
monitored with the "fix ave/chunk"_fix_ave_chunk.html command.
The fix tallies the cumulative momentum transfer that it performs.
See the "fix viscosity"_fix_viscosity.html command for details.
The fourth method is based on the Green-Kubo (GK) formula which
relates the ensemble average of the auto-correlation of the
stress/pressure tensor to eta. This can be done in a fully
equilibrated simulation which is in contrast to the two preceding
non-equilibrium methods, where momentum flows continuously through the
simulation box.
Here is an example input script that calculates the viscosity of
liquid Ar via the GK formalism:
# Sample LAMMPS input script for viscosity of liquid Ar :pre
units real
variable T equal 86.4956
variable V equal vol
variable dt equal 4.0
variable p equal 400 # correlation length
variable s equal 5 # sample interval
variable d equal $p*$s # dump interval :pre
# convert from LAMMPS real units to SI :pre
variable kB equal 1.3806504e-23 # \[J/K/] Boltzmann
variable atm2Pa equal 101325.0
variable A2m equal 1.0e-10
variable fs2s equal 1.0e-15
variable convert equal $\{atm2Pa\}*$\{atm2Pa\}*$\{fs2s\}*$\{A2m\}*$\{A2m\}*$\{A2m\} :pre
# setup problem :pre
dimension 3
boundary p p p
lattice fcc 5.376 orient x 1 0 0 orient y 0 1 0 orient z 0 0 1
region box block 0 4 0 4 0 4
create_box 1 box
create_atoms 1 box
mass 1 39.948
pair_style lj/cut 13.0
pair_coeff * * 0.2381 3.405
timestep $\{dt\}
thermo $d :pre
# equilibration and thermalization :pre
velocity all create $T 102486 mom yes rot yes dist gaussian
fix NVT all nvt temp $T $T 10 drag 0.2
run 8000 :pre
# viscosity calculation, switch to NVE if desired :pre
#unfix NVT
#fix NVE all nve :pre
reset_timestep 0
variable pxy equal pxy
variable pxz equal pxz
variable pyz equal pyz
fix SS all ave/correlate $s $p $d &
v_pxy v_pxz v_pyz type auto file S0St.dat ave running
variable scale equal $\{convert\}/($\{kB\}*$T)*$V*$s*$\{dt\}
variable v11 equal trap(f_SS\[3\])*$\{scale\}
variable v22 equal trap(f_SS\[4\])*$\{scale\}
variable v33 equal trap(f_SS\[5\])*$\{scale\}
thermo_style custom step temp press v_pxy v_pxz v_pyz v_v11 v_v22 v_v33
run 100000
variable v equal (v_v11+v_v22+v_v33)/3.0
variable ndens equal count(all)/vol
print "average viscosity: $v \[Pa.s\] @ $T K, $\{ndens\} /A^3" :pre
The fifth method is related to the above Green-Kubo method,
but uses the Einstein formulation, analogous to the Einstein
mean-square-displacement formulation for self-diffusivity. The
time-integrated momentum fluxes play the role of Cartesian
coordinates, whose mean-square displacement increases linearly
with time at sufficiently long times.
:line
6.22 Calculating a diffusion coefficient :link(howto_22),h4
The diffusion coefficient D of a material can be measured in at least
2 ways using various options in LAMMPS. See the examples/DIFFUSE
directory for scripts that implement the 2 methods discussed here for
a simple Lennard-Jones fluid model.
The first method is to measure the mean-squared displacement (MSD) of
the system, via the "compute msd"_compute_msd.html command. The slope
of the MSD versus time is proportional to the diffusion coefficient.
The instantaneous MSD values can be accumulated in a vector via the
"fix vector"_fix_vector.html command, and a line fit to the vector to
compute its slope via the "variable slope"_variable.html function, and
thus extract D.
The second method is to measure the velocity auto-correlation function
(VACF) of the system, via the "compute vacf"_compute_vacf.html
command. The time-integral of the VACF is proportional to the
diffusion coefficient. The instantaneous VACF values can be
accumulated in a vector via the "fix vector"_fix_vector.html command,
and time integrated via the "variable trap"_variable.html function,
and thus extract D.
:line
6.23 Using chunks to calculate system properties :link(howto_23),h4
In LAMMS, "chunks" are collections of atoms, as defined by the
"compute chunk/atom"_compute_chunk_atom.html command, which assigns
each atom to a chunk ID (or to no chunk at all). The number of chunks
and the assignment of chunk IDs to atoms can be static or change over
time. Examples of "chunks" are molecules or spatial bins or atoms
with similar values (e.g. coordination number or potential energy).
The per-atom chunk IDs can be used as input to two other kinds of
commands, to calculate various properties of a system:
"fix ave/chunk"_fix_ave_chunk.html
any of the "compute */chunk"_compute.html commands :ul
Here, each of the 3 kinds of chunk-related commands is briefly
overviewed. Then some examples are given of how to compute different
properties with chunk commands.
Compute chunk/atom command: :h5
This compute can assign atoms to chunks of various styles. Only atoms
in the specified group and optional specified region are assigned to a
chunk. Here are some possible chunk definitions:
atoms in same molecule | chunk ID = molecule ID |
atoms of same atom type | chunk ID = atom type |
all atoms with same atom property (charge, radius, etc) | chunk ID = output of compute property/atom |
atoms in same cluster | chunk ID = output of "compute cluster/atom"_compute_cluster_atom.html command |
atoms in same spatial bin | chunk ID = bin ID |
atoms in same rigid body | chunk ID = molecule ID used to define rigid bodies |
atoms with similar potential energy | chunk ID = output of "compute pe/atom"_compute_pe_atom.html |
atoms with same local defect structure | chunk ID = output of "compute centro/atom"_compute_centro_atom.html or "compute coord/atom"_compute_coord_atom.html command :tb(s=|,c=2)
Note that chunk IDs are integer values, so for atom properties or
computes that produce a floating point value, they will be truncated
to an integer. You could also use the compute in a variable that
scales the floating point value to spread it across multiple integers.
Spatial bins can be of various kinds, e.g. 1d bins = slabs, 2d bins =
pencils, 3d bins = boxes, spherical bins, cylindrical bins.
This compute also calculates the number of chunks {Nchunk}, which is
used by other commands to tally per-chunk data. {Nchunk} can be a
static value or change over time (e.g. the number of clusters). The
chunk ID for an individual atom can also be static (e.g. a molecule
ID), or dynamic (e.g. what spatial bin an atom is in as it moves).
Note that this compute allows the per-atom output of other
"computes"_compute.html, "fixes"_fix.html, and
"variables"_variable.html to be used to define chunk IDs for each
atom. This means you can write your own compute or fix to output a
per-atom quantity to use as chunk ID. See
"Section 10"_Section_modify.html of the documentation for how to
do this. You can also define a "per-atom variable"_variable.html in
the input script that uses a formula to generate a chunk ID for each
atom.
Fix ave/chunk command: :h5
This fix takes the ID of a "compute
chunk/atom"_compute_chunk_atom.html command as input. For each chunk,
it then sums one or more specified per-atom values over the atoms in
each chunk. The per-atom values can be any atom property, such as
velocity, force, charge, potential energy, kinetic energy, stress,
etc. Additional keywords are defined for per-chunk properties like
density and temperature. More generally any per-atom value generated
by other "computes"_compute.html, "fixes"_fix.html, and "per-atom
variables"_variable.html, can be summed over atoms in each chunk.
Similar to other averaging fixes, this fix allows the summed per-chunk
values to be time-averaged in various ways, and output to a file. The
fix produces a global array as output with one row of values per
chunk.
Compute */chunk commands: :h5
Currently the following computes operate on chunks of atoms to produce
per-chunk values.
"compute com/chunk"_compute_com_chunk.html
"compute gyration/chunk"_compute_gyration_chunk.html
"compute inertia/chunk"_compute_inertia_chunk.html
"compute msd/chunk"_compute_msd_chunk.html
"compute property/chunk"_compute_property_chunk.html
"compute temp/chunk"_compute_temp_chunk.html
"compute torque/chunk"_compute_vcm_chunk.html
"compute vcm/chunk"_compute_vcm_chunk.html :ul
They each take the ID of a "compute
chunk/atom"_compute_chunk_atom.html command as input. As their names
indicate, they calculate the center-of-mass, radius of gyration,
moments of inertia, mean-squared displacement, temperature, torque,
and velocity of center-of-mass for each chunk of atoms. The "compute
property/chunk"_compute_property_chunk.html command can tally the
count of atoms in each chunk and extract other per-chunk properties.
The reason these various calculations are not part of the "fix
ave/chunk command"_fix_ave_chunk.html, is that each requires a more
complicated operation than simply summing and averaging over per-atom
values in each chunk. For example, many of them require calculation
of a center of mass, which requires summing mass*position over the
atoms and then dividing by summed mass.
All of these computes produce a global vector or global array as
output, wih one or more values per chunk. They can be used
in various ways:
As input to the "fix ave/time"_fix_ave_time.html command, which can
write the values to a file and optionally time average them. :ulb,l
As input to the "fix ave/histo"_fix_ave_histo.html command to
histogram values across chunks. E.g. a histogram of cluster sizes or
molecule diffusion rates. :l
As input to special functions of "equal-style
variables"_variable.html, like sum() and max(). E.g. to find the
largest cluster or fastest diffusing molecule. :l
:ule
Example calculations with chunks :h5
Here are examples using chunk commands to calculate various
properties:
(1) Average velocity in each of 1000 2d spatial bins:
compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.01 units reduced
fix 1 all ave/chunk 100 10 1000 cc1 vx vy file tmp.out :pre
(2) Temperature in each spatial bin, after subtracting a flow
velocity:
compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.1 units reduced
compute vbias all temp/profile 1 0 0 y 10
fix 1 all ave/chunk 100 10 1000 cc1 temp bias vbias file tmp.out :pre
(3) Center of mass of each molecule:
compute cc1 all chunk/atom molecule
compute myChunk all com/chunk cc1
fix 1 all ave/time 100 1 100 c_myChunk\[*\] file tmp.out mode vector :pre
(4) Total force on each molecule and ave/max across all molecules:
compute cc1 all chunk/atom molecule
fix 1 all ave/chunk 1000 1 1000 cc1 fx fy fz file tmp.out
variable xave equal ave(f_1\[2\])
variable xmax equal max(f_1\[2\])
thermo 1000
thermo_style custom step temp v_xave v_xmax :pre
(5) Histogram of cluster sizes:
compute cluster all cluster/atom 1.0
compute cc1 all chunk/atom c_cluster compress yes
compute size all property/chunk cc1 count
fix 1 all ave/histo 100 1 100 0 20 20 c_size mode vector ave running beyond ignore file tmp.histo :pre
:line
6.24 Setting parameters for the "kspace_style pppm/disp"_kspace_style.html command :link(howto_24),h4
The PPPM method computes interactions by splitting the pair potential
into two parts, one of which is computed in a normal pairwise fashion,
the so-called real-space part, and one of which is computed using the
Fourier transform, the so called reciprocal-space or kspace part. For
both parts, the potential is not computed exactly but is approximated.
Thus, there is an error in both parts of the computation, the
real-space and the kspace error. The just mentioned facts are true
both for the PPPM for Coulomb as well as dispersion interactions. The
deciding difference - and also the reason why the parameters for
pppm/disp have to be selected with more care - is the impact of the
errors on the results: The kspace error of the PPPM for Coulomb and
dispersion interaction and the real-space error of the PPPM for
Coulomb interaction have the character of noise. In contrast, the
real-space error of the PPPM for dispersion has a clear physical
interpretation: the underprediction of cohesion. As a consequence, the
real-space error has a much stronger effect than the kspace error on
simulation results for pppm/disp. Parameters must thus be chosen in a
way that this error is much smaller than the kspace error.
When using pppm/disp and not making any specifications on the PPPM
parameters via the kspace modify command, parameters will be tuned
such that the real-space error and the kspace error are equal. This
will result in simulations that are either inaccurate or slow, both of
which is not desirable. For selecting parameters for the pppm/disp
that provide fast and accurate simulations, there are two approaches,
which both have their up- and downsides.
The first approach is to set desired real-space an kspace accuracies
via the {kspace_modify force/disp/real} and {kspace_modify
force/disp/kspace} commands. Note that the accuracies have to be
specified in force units and are thus dependent on the chosen unit
settings. For real units, 0.0001 and 0.002 seem to provide reasonable
accurate and efficient computations for the real-space and kspace
accuracies. 0.002 and 0.05 work well for most systems using lj
units. PPPM parameters will be generated based on the desired
accuracies. The upside of this approach is that it usually provides a
good set of parameters and will work for both the {kspace_modify diff
ad} and {kspace_modify diff ik} options. The downside of the method
is that setting the PPPM parameters will take some time during the
initialization of the simulation.
The second approach is to set the parameters for the pppm/disp
explicitly using the {kspace_modify mesh/disp}, {kspace_modify
order/disp}, and {kspace_modify gewald/disp} commands. This approach
requires a more experienced user who understands well the impact of
the choice of parameters on the simulation accuracy and
performance. This approach provides a fast initialization of the
simulation. However, it is sensitive to errors: A combination of
parameters that will perform well for one system might result in
far-from-optimal conditions for other simulations. For example,
parameters that provide accurate and fast computations for
all-atomistic force fields can provide insufficient accuracy or
united-atomistic force fields (which is related to that the latter
typically have larger dispersion coefficients).
To avoid inaccurate or inefficient simulations, the pppm/disp stops
simulations with an error message if no action is taken to control the
PPPM parameters. If the automatic parameter generation is desired and
real-space and kspace accuracies are desired to be equal, this error
message can be suppressed using the {kspace_modify disp/auto yes}
command.
A reasonable approach that combines the upsides of both methods is to
make the first run using the {kspace_modify force/disp/real} and
{kspace_modify force/disp/kspace} commands, write down the PPPM
parameters from the outut, and specify these parameters using the
second approach in subsequent runs (which have the same composition,
force field, and approximately the same volume).
Concerning the performance of the pppm/disp there are two more things
to consider. The first is that when using the pppm/disp, the cutoff
parameter does no longer affect the accuracy of the simulation
(subject to that gewald/disp is adjusted when changing the cutoff).
The performance can thus be increased by examining different values
for the cutoff parameter. A lower bound for the cutoff is only set by
the truncation error of the repulsive term of pair potentials.
The second is that the mixing rule of the pair style has an impact on
the computation time when using the pppm/disp. Fastest computations
are achieved when using the geometric mixing rule. Using the
arithmetic mixing rule substantially increases the computational cost.
The computational overhead can be reduced using the {kspace_modify
mix/disp geom} and {kspace_modify splittol} commands. The first
command simply enforces geometric mixing of the dispersion
coefficients in kspace computations. This introduces some error in
the computations but will also significantly speed-up the
simulations. The second keyword sets the accuracy with which the
dispersion coefficients are approximated using a matrix factorization
approach. This may result in better accuracy then using the first
command, but will usually also not provide an equally good increase of
efficiency.
Finally, pppm/disp can also be used when no mixing rules apply.
This can be achieved using the {kspace_modify mix/disp none} command.
Note that the code does not check automatically whether any mixing
rule is fulfilled. If mixing rules do not apply, the user will have
to specify this command explicitly.
:line
6.25 Polarizable models :link(howto_25),h4
In polarizable force fields the charge distributions in molecules and
materials respond to their electrostatic environments. Polarizable
systems can be simulated in LAMMPS using three methods:
the fluctuating charge method, implemented in the "QEQ"_fix_qeq.html
package, :ulb,l
the adiabatic core-shell method, implemented in the
"CORESHELL"_#howto_26 package, :l
the thermalized Drude dipole method, implemented in the
"USER-DRUDE"_#howto_27 package. :l
:ule
The fluctuating charge method calculates instantaneous charges on
interacting atoms based on the electronegativity equalization
principle. It is implemented in the "fix qeq"_fix_qeq.html which is
available in several variants. It is a relatively efficient technique
since no additional particles are introduced. This method allows for
charge transfer between molecules or atom groups. However, because the
charges are located at the interaction sites, off-plane components of
polarization cannot be represented in planar molecules or atom groups.
The two other methods share the same basic idea: polarizable atoms are
split into one core atom and one satellite particle (called shell or
Drude particle) attached to it by a harmonic spring. Both atoms bear
a charge and they represent collectively an induced electric dipole.
These techniques are computationally more expensive than the QEq
method because of additional particles and bonds. These two
charge-on-spring methods differ in certain features, with the
core-shell model being normally used for ionic/crystalline materials,
whereas the so-called Drude model is normally used for molecular
systems and fluid states.
The core-shell model is applicable to crystalline materials where the
high symmetry around each site leads to stable trajectories of the
core-shell pairs. However, bonded atoms in molecules can be so close
that a core would interact too strongly or even capture the Drude
particle of a neighbor. The Drude dipole model is relatively more
complex in order to remediate this and other issues. Specifically, the
Drude model includes specific thermostating of the core-Drude pairs
and short-range damping of the induced dipoles.
The three polarization methods can be implemented through a
self-consistent calculation of charges or induced dipoles at each
timestep. In the fluctuating charge scheme this is done by the matrix
inversion method in "fix qeq/point"_fix_qeq.html, but for core-shell
or Drude-dipoles the relaxed-dipoles technique would require an slow
iterative procedure. These self-consistent solutions yield accurate
trajectories since the additional degrees of freedom representing
polarization are massless. An alternative is to attribute a mass to
the additional degrees of freedom and perform time integration using
an extended Lagrangian technique. For the fluctuating charge scheme
this is done by "fix qeq/dynamic"_fix_qeq.html, and for the
charge-on-spring models by the methods outlined in the next two
sections. The assignment of masses to the additional degrees of
freedom can lead to unphysical trajectories if care is not exerted in
choosing the parameters of the polarizable models and the simulation
conditions.
In the core-shell model the vibration of the shells is kept faster
than the ionic vibrations to mimic the fast response of the
polarizable electrons. But in molecular systems thermalizing the
core-Drude pairs at temperatures comparable to the rest of the
simulation leads to several problems (kinetic energy transfer, too
short a timestep, etc.) In order to avoid these problems the relative
motion of the Drude particles with respect to their cores is kept
"cold" so the vibration of the core-Drude pairs is very slow,
approaching the self-consistent regime. In both models the
temperature is regulated using the velocities of the center of mass of
core+shell (or Drude) pairs, but in the Drude model the actual
relative core-Drude particle motion is thermostated separately as
well.
:line
6.26 Adiabatic core/shell model :link(howto_26),h4
The adiabatic core-shell model by "Mitchell and
Fincham"_#MitchellFincham is a simple method for adding
polarizability to a system. In order to mimic the electron shell of
an ion, a satellite particle is attached to it. This way the ions are
split into a core and a shell where the latter is meant to react to
the electrostatic environment inducing polarizability.
Technically, shells are attached to the cores by a spring force f =
k*r where k is a parametrized spring constant and r is the distance
between the core and the shell. The charges of the core and the shell
add up to the ion charge, thus q(ion) = q(core) + q(shell). This
setup introduces the ion polarizability (alpha) given by
alpha = q(shell)^2 / k. In a
similar fashion the mass of the ion is distributed on the core and the
shell with the core having the larger mass.
To run this model in LAMMPS, "atom_style"_atom_style.html {full} can
be used since atom charge and bonds are needed. Each kind of
core/shell pair requires two atom types and a bond type. The core and
shell of a core/shell pair should be bonded to each other with a
harmonic bond that provides the spring force. For example, a data file
for NaCl, as found in examples/coreshell, has this format:
432 atoms # core and shell atoms
216 bonds # number of core/shell springs :pre
4 atom types # 2 cores and 2 shells for Na and Cl
2 bond types :pre
0.0 24.09597 xlo xhi
0.0 24.09597 ylo yhi
0.0 24.09597 zlo zhi :pre
Masses # core/shell mass ratio = 0.1 :pre
1 20.690784 # Na core
2 31.90500 # Cl core
3 2.298976 # Na shell
4 3.54500 # Cl shell :pre
Atoms :pre
1 1 2 1.5005 0.00000000 0.00000000 0.00000000 # core of core/shell pair 1
2 1 4 -2.5005 0.00000000 0.00000000 0.00000000 # shell of core/shell pair 1
3 2 1 1.5056 4.01599500 4.01599500 4.01599500 # core of core/shell pair 2
4 2 3 -0.5056 4.01599500 4.01599500 4.01599500 # shell of core/shell pair 2
(...) :pre
Bonds # Bond topology for spring forces :pre
1 2 1 2 # spring for core/shell pair 1
2 2 3 4 # spring for core/shell pair 2
(...) :pre
Non-Coulombic (e.g. Lennard-Jones) pairwise interactions are only
defined between the shells. Coulombic interactions are defined
between all cores and shells. If desired, additional bonds can be
specified between cores.
The "special_bonds"_special_bonds.html command should be used to
turn-off the Coulombic interaction within core/shell pairs, since that
interaction is set by the bond spring. This is done using the
"special_bonds"_special_bonds.html command with a 1-2 weight = 0.0,
which is the default value. It needs to be considered whether one has
to adjust the "special_bonds"_special_bonds.html weighting according
to the molecular topology since the interactions of the shells are
bypassed over an extra bond.
Note that this core/shell implementation does not require all ions to
be polarized. One can mix core/shell pairs and ions without a
satellite particle if desired.
Since the core/shell model permits distances of r = 0.0 between the
core and shell, a pair style with a "cs" suffix needs to be used to
implement a valid long-range Coulombic correction. Several such pair
styles are provided in the CORESHELL package. See "this doc
page"_pair_cs.html for details. All of the core/shell enabled pair
styles require the use of a long-range Coulombic solver, as specified
by the "kspace_style"_kspace_style.html command. Either the PPPM or
Ewald solvers can be used.
For the NaCL example problem, these pair style and bond style settings
are used:
pair_style born/coul/long/cs 20.0 20.0
pair_coeff * * 0.0 1.000 0.00 0.00 0.00
pair_coeff 3 3 487.0 0.23768 0.00 1.05 0.50 #Na-Na
pair_coeff 3 4 145134.0 0.23768 0.00 6.99 8.70 #Na-Cl
pair_coeff 4 4 405774.0 0.23768 0.00 72.40 145.40 #Cl-Cl :pre
bond_style harmonic
bond_coeff 1 63.014 0.0
bond_coeff 2 25.724 0.0 :pre
When running dynamics with the adiabatic core/shell model, the
following issues should be considered. The relative motion of
the core and shell particles corresponds to the polarization,
hereby an instantaneous relaxation of the shells is approximated
and a fast core/shell spring frequency ensures a nearly constant
internal kinetic energy during the simulation.
Thermostats can alter this polarization behaviour, by scaling the
internal kinetic energy, meaning the shell will not react freely to
its electrostatic environment.
Therefore it is typically desirable to decouple the relative motion of
the core/shell pair, which is an imaginary degree of freedom, from the
real physical system. To do that, the "compute
temp/cs"_compute_temp_cs.html command can be used, in conjunction with
any of the thermostat fixes, such as "fix nvt"_fix_nh.html or "fix
langevin"_fix_langevin. This compute uses the center-of-mass velocity
of the core/shell pairs to calculate a temperature, and insures that
velocity is what is rescaled for thermostatting purposes. This
compute also works for a system with both core/shell pairs and
non-polarized ions (ions without an attached satellite particle). The
"compute temp/cs"_compute_temp_cs.html command requires input of two
groups, one for the core atoms, another for the shell atoms.
Non-polarized ions which might also be included in the treated system
should not be included into either of these groups, they are taken
into account by the {group-ID} (2nd argument) of the compute. The
groups can be defined using the "group {type}"_group.html command.
Note that to perform thermostatting using this definition of
temperature, the "fix modify temp"_fix_modify.html command should be
used to assign the compute to the thermostat fix. Likewise the
"thermo_modify temp"_thermo_modify.html command can be used to make
this temperature be output for the overall system.
For the NaCl example, this can be done as follows:
group cores type 1 2
group shells type 3 4
compute CSequ all temp/cs cores shells
fix thermoberendsen all temp/berendsen 1427 1427 0.4 # thermostat for the true physical system
fix thermostatequ all nve # integrator as needed for the berendsen thermostat
fix_modify thermoberendsen temp CSequ
thermo_modify temp CSequ # output of center-of-mass derived temperature :pre
The pressure for the core/shell system is computed via the regular
LAMMPS convention by "treating the cores and shells as individual
particles"_#MitchellFincham2. For the thermo output of the pressure
as well as for the application of a barostat, it is necessary to
use an additional "pressure"_compute_pressure compute based on the
default "temperature"_compute_temp and specifying it as a second
argument in "fix modify"_fix_modify.html and
"thermo_modify"_thermo_modify.html resulting in:
(...)
compute CSequ all temp/cs cores shells
compute thermo_press_lmp all pressure thermo_temp # pressure for individual particles
thermo_modify temp CSequ press thermo_press_lmp # modify thermo to regular pressure
fix press_bar all npt temp 300 300 0.04 iso 0 0 0.4
fix_modify press_bar temp CSequ press thermo_press_lmp # pressure modification for correct kinetic scalar :pre
If "compute temp/cs"_compute_temp_cs.html is used, the decoupled
relative motion of the core and the shell should in theory be
stable. However numerical fluctuation can introduce a small
momentum to the system, which is noticable over long trajectories.
Therefore it is recommendable to use the "fix
momentum"_fix_momentum.html command in combination with "compute
temp/cs"_compute_temp_cs.html when equilibrating the system to
prevent any drift.
When initializing the velocities of a system with core/shell pairs, it
is also desirable to not introduce energy into the relative motion of
the core/shell particles, but only assign a center-of-mass velocity to
the pairs. This can be done by using the {bias} keyword of the
"velocity create"_velocity.html command and assigning the "compute
temp/cs"_compute_temp_cs.html command to the {temp} keyword of the
"velocity"_velocity.html command, e.g.
velocity all create 1427 134 bias yes temp CSequ
velocity all scale 1427 temp CSequ :pre
To maintain the correct polarizability of the core/shell pairs, the
kinetic energy of the internal motion shall remain nearly constant.
Therefore the choice of spring force and mass ratio need to ensure
much faster relative motion of the 2 atoms within the core/shell pair
than their center-of-mass velocity. This allows the shells to
effectively react instantaneously to the electrostatic environment and
limits energy transfer to or from the core/shell oscillators.
This fast movement also dictates the timestep that can be used.
The primary literature of the adiabatic core/shell model suggests that
the fast relative motion of the core/shell pairs only allows negligible
energy transfer to the environment.
The mentioned energy transfer will typically lead to a small drift
in total energy over time. This internal energy can be monitored
using the "compute chunk/atom"_compute_chunk_atom.html and "compute
temp/chunk"_compute_temp_chunk.html commands. The internal kinetic
energies of each core/shell pair can then be summed using the sum()
special function of the "variable"_variable.html command. Or they can
be time/averaged and output using the "fix ave/time"_fix_ave_time.html
command. To use these commands, each core/shell pair must be defined
as a "chunk". If each core/shell pair is defined as its own molecule,
the molecule ID can be used to define the chunks. If cores are bonded
to each other to form larger molecules, the chunks can be identified
by the "fix property/atom"_fix_property_atom.html via assigning a
core/shell ID to each atom using a special field in the data file read
by the "read_data"_read_data.html command. This field can then be
accessed by the "compute property/atom"_compute_property_atom.html
command, to use as input to the "compute
chunk/atom"_compute_chunk_atom.html command to define the core/shell
pairs as chunks.
For example if core/shell pairs are the only molecules:
read_data NaCl_CS_x0.1_prop.data
compute prop all property/atom molecule
compute cs_chunk all chunk/atom c_prop
compute cstherm all temp/chunk cs_chunk temp internal com yes cdof 3.0 # note the chosen degrees of freedom for the core/shell pairs
fix ave_chunk all ave/time 10 1 10 c_cstherm file chunk.dump mode vector :pre
For example if core/shell pairs and other molecules are present:
fix csinfo all property/atom i_CSID # property/atom command
read_data NaCl_CS_x0.1_prop.data fix csinfo NULL CS-Info # atom property added in the data-file
compute prop all property/atom i_CSID
(...) :pre
The additional section in the date file would be formatted like this:
CS-Info # header of additional section :pre
1 1 # column 1 = atom ID, column 2 = core/shell ID
2 1
3 2
4 2
5 3
6 3
7 4
8 4
(...) :pre
:line
6.27 Drude induced dipoles :link(howto_27),h4
The thermalized Drude model, similarly to the "core-shell"_#howto_26
model, represents induced dipoles by a pair of charges (the core atom
and the Drude particle) connected by a harmonic spring. The Drude
model has a number of features aimed at its use in molecular systems
("Lamoureux and Roux"_#howto-Lamoureux):
Thermostating of the additional degrees of freedom associated with the
induced dipoles at very low temperature, in terms of the reduced
coordinates of the Drude particles with respect to their cores. This
makes the trajectory close to that of relaxed induced dipoles. :ulb,l
Consistent definition of 1-2 to 1-4 neighbors. A core-Drude particle
pair represents a single (polarizable) atom, so the special screening
factors in a covalent structure should be the same for the core and
the Drude particle. Drude particles have to inherit the 1-2, 1-3, 1-4
special neighbor relations from their respective cores. :l
Stabilization of the interactions between induced dipoles. Drude
dipoles on covalently bonded atoms interact too strongly due to the
short distances, so an atom may capture the Drude particle of a
neighbor, or the induced dipoles within the same molecule may align
too much. To avoid this, damping at short range can be done by Thole
functions (for which there are physical grounds). This Thole damping
is applied to the point charges composing the induced dipole (the
charge of the Drude particle and the opposite charge on the core, not
to the total charge of the core atom). :l
:ule
A detailed tutorial covering the usage of Drude induced dipoles in
LAMMPS is "available here"_tutorial_drude.html.
As with the core-shell model, the cores and Drude particles should
appear in the data file as standard atoms. The same holds for the
springs between them, which are described by standard harmonic bonds.
The nature of the atoms (core, Drude particle or non-polarizable) is
specified via the "fix drude"_fix_drude.html command. The special
list of neighbors is automatically refactored to account for the
equivalence of core and Drude particles as regards special 1-2 to 1-4
screening. It may be necessary to use the {extra} keyword of the
"special_bonds"_special_bonds.html command. If using "fix
shake"_fix_shake.html, make sure no Drude particle is in this fix
group.
There are two ways to thermostat the Drude particles at a low
temperature: use either "fix langevin/drude"_fix_langevin_drude.html
for a Langevin thermostat, or "fix
drude/transform/*"_fix_drude_transform.html for a Nose-Hoover
thermostat. The former requires use of the command "comm_modify vel
yes"_comm_modify.html. The latter requires two separate integration
fixes like {nvt} or {npt}. The correct temperatures of the reduced
degrees of freedom can be calculated using the "compute
temp/drude"_compute_temp_drude.html. This requires also to use the
command {comm_modify vel yes}.
Short-range damping of the induced dipole interactions can be achieved
using Thole functions through the "pair style
thole"_pair_thole.html in "pair_style hybrid/overlay"_pair_hybrid.html
with a Coulomb pair style. It may be useful to use {coul/long/cs} or
similar from the CORESHELL package if the core and Drude particle come
too close, which can cause numerical issues.
:line
:line
:link(howto-Berendsen)
[(Berendsen)] Berendsen, Grigera, Straatsma, J Phys Chem, 91,
6269-6271 (1987).
:link(howto-Cornell)
[(Cornell)] Cornell, Cieplak, Bayly, Gould, Merz, Ferguson,
Spellmeyer, Fox, Caldwell, Kollman, JACS 117, 5179-5197 (1995).
:link(Horn)
[(Horn)] Horn, Swope, Pitera, Madura, Dick, Hura, and Head-Gordon,
J Chem Phys, 120, 9665 (2004).
:link(howto-Ikeshoji)
[(Ikeshoji)] Ikeshoji and Hafskjold, Molecular Physics, 81, 251-261
(1994).
:link(howto-Wirnsberger)
[(Wirnsberger)] Wirnsberger, Frenkel, and Dellago, J Chem Phys, 143, 124104
(2015).
:link(howto-MacKerell)
[(MacKerell)] MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field,
Fischer, Gao, Guo, Ha, et al, J Phys Chem, 102, 3586 (1998).
:link(howto-Mayo)
[(Mayo)] Mayo, Olfason, Goddard III, J Phys Chem, 94, 8897-8909
(1990).
:link(Jorgensen1)
[(Jorgensen)] Jorgensen, Chandrasekhar, Madura, Impey, Klein, J Chem
Phys, 79, 926 (1983).
:link(Price1)
[(Price)] Price and Brooks, J Chem Phys, 121, 10096 (2004).
:link(Shinoda1)
[(Shinoda)] Shinoda, Shiga, and Mikami, Phys Rev B, 69, 134103 (2004).
:link(MitchellFincham)
[(Mitchell and Fincham)] Mitchell, Fincham, J Phys Condensed Matter,
5, 1031-1038 (1993).
:link(MitchellFincham2)
[(Fincham)] Fincham, Mackrodt and Mitchell, J Phys Condensed Matter,
6, 393-404 (1994).
:link(howto-Lamoureux)
[(Lamoureux and Roux)] G. Lamoureux, B. Roux, J. Chem. Phys 119, 3025 (2003)
diff --git a/doc/src/Section_packages.txt b/doc/src/Section_packages.txt
index 76f88b8ab..54a2685b8 100644
--- a/doc/src/Section_packages.txt
+++ b/doc/src/Section_packages.txt
@@ -1,2634 +1,2634 @@
"Previous Section"_Section_commands.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
Section"_Section_accelerate.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
4. Packages :h3
This section gives an overview of the optional packages that extend
LAMMPS functionality with instructions on how to build LAMMPS with
each of them. Packages are groups of files that enable a specific set
of features. For example, force fields for molecular systems or
granular systems are in packages. You can see the list of all
packages and "make" commands to manage them by typing "make package"
from within the src directory of the LAMMPS distribution. "Section
2.3"_Section_start.html#start_3 gives general info on how to install
and un-install packages as part of the LAMMPS build process.
There are two kinds of packages in LAMMPS, standard and user packages:
"Table of standard packages"_#table_standard
"Table of user packages"_#table_user :ul
Standard packages are supported by the LAMMPS developers and are
written in a syntax and style consistent with the rest of LAMMPS.
This means the developers will answer questions about them, debug and
fix them if necessary, and keep them compatible with future changes to
LAMMPS.
User packages have been contributed by users, and begin with the
"user" prefix. If they are a single command (single file), they are
typically in the user-misc package. User packages don't necessarily
meet the requirements of the standard packages. If you have problems
using a feature provided in a user package, you may need to contact
the contributor directly to get help. Information on how to submit
additions you make to LAMMPS as single files or as a standard or user
package are given in "this section"_Section_modify.html#mod_15 of the
manual.
Following the next two tables is a sub-section for each package. It
lists authors (if applicable) and summarizes the package contents. It
has specific instructions on how to install the package, including (if
necessary) downloading or building any extra library it requires. It
also gives links to documentation, example scripts, and
pictures/movies (if available) that illustrate use of the package.
NOTE: To see the complete list of commands a package adds to LAMMPS,
just look at the files in its src directory, e.g. "ls src/GRANULAR".
Files with names that start with fix, compute, atom, pair, bond,
angle, etc correspond to commands with the same style names.
In these two tables, the "Example" column is a sub-directory in the
examples directory of the distribution which has an input script that
uses the package. E.g. "peptide" refers to the examples/peptide
directory; USER/atc refers to the examples/USER/atc directory. The
"Library" column indicates whether an extra library is needed to build
and use the package:
dash = no library
sys = system library: you likely have it on your machine
int = internal library: provided with LAMMPS, but you may need to build it
ext = external library: you will need to download and install it on your machine :ul
:line
:line
[Standard packages] :link(table_standard),p
Package, Description, Doc page, Example, Library
"ASPHERE"_#ASPHERE, aspherical particle models, "Section 6.6.14"_Section_howto.html#howto_14, ellipse, -
"BODY"_#BODY, body-style particles, "body"_body.html, body, -
"CLASS2"_#CLASS2, class 2 force fields, "pair_style lj/class2"_pair_class2.html, -, -
"COLLOID"_#COLLOID, colloidal particles, "atom_style colloid"_atom_style.html, colloid, -
"COMPRESS"_#COMPRESS, I/O compression, "dump */gz"_dump.html, -, sys
"CORESHELL"_#CORESHELL, adiabatic core/shell model, "Section 6.6.25"_Section_howto.html#howto_25, coreshell, -
"DIPOLE"_#DIPOLE, point dipole particles, "pair_style dipole/cut"_pair_dipole.html, dipole, -
"GPU"_#GPU, GPU-enabled styles, "Section 5.3.1"_accelerate_gpu.html, WWW bench, int
"GRANULAR"_#GRANULAR, granular systems, "Section 6.6.6"_Section_howto.html#howto_6, pour, -
"KIM"_#KIM, openKIM wrapper, "pair_style kim"_pair_kim.html, kim, ext
"KOKKOS"_#KOKKOS, Kokkos-enabled styles, "Section 5.3.3"_accelerate_kokkos.html, WWW bench, -
"KSPACE"_#KSPACE, long-range Coulombic solvers, "kspace_style"_kspace_style.html, peptide, -
"MANYBODY"_#MANYBODY, many-body potentials, "pair_style tersoff"_pair_tersoff.html, shear, -
"MC"_#MC, Monte Carlo options, "fix gcmc"_fix_gcmc.html, -, -
"MEAM"_#MEAM, modified EAM potential, "pair_style meam"_pair_meam.html, meam, int
"MISC"_#MISC, miscellanous single-file commands, -, -, -
"MOLECULE"_#MOLECULE, molecular system force fields, "Section 6.6.3"_Section_howto.html#howto_3, peptide, -
"MPIIO"_#MPIIO, MPI parallel I/O dump and restart, "dump"_dump.html, -, -
"MSCG"_#MSCG, multi-scale coarse-graining wrapper, "fix mscg"_fix_mscg.html, mscg, ext
"OPT"_#OPT, optimized pair styles, "Section 5.3.5"_accelerate_opt.html, WWW bench, -
"PERI"_#PERI, Peridynamics models, "pair_style peri"_pair_peri.html, peri, -
"POEMS"_#POEMS, coupled rigid body motion, "fix poems"_fix_poems.html, rigid, int
"PYTHON"_#PYTHON, embed Python code in an input script, "python"_python.html, python, sys
"QEQ"_#QEQ, QEq charge equilibration, "fix qeq"_fix_qeq.html, qeq, -
"REAX"_#REAX, ReaxFF potential (Fortran), "pair_style reax"_pair_reax.html, reax, int
"REPLICA"_#REPLICA, multi-replica methods, "Section 6.6.5"_Section_howto.html#howto_5, tad, -
"RIGID"_#RIGID, rigid bodies and constraints, "fix rigid"_fix_rigid.html, rigid, -
"SHOCK"_#SHOCK, shock loading methods, "fix msst"_fix_msst.html, -, -
"SNAP"_#SNAP, quantum-fitted potential, "pair snap"_pair_snap.html, snap, -
"SRD"_#SRD, stochastic rotation dynamics, "fix srd"_fix_srd.html, srd, -
"VORONOI"_#VORONOI, Voronoi tesselation, "compute voronoi/atom"_compute_voronoi_atom.html, -, ext
:tb(ea=c,ca1=l)
[USER packages] :link(table_user),p
Package, Description, Doc page, Example, Library
"USER-ATC"_#USER-ATC, atom-to-continuum coupling, "fix atc"_fix_atc.html, USER/atc, int
"USER-AWPMD"_#USER-AWPMD, wave-packet MD, "pair_style awpmd/cut"_pair_awpmd.html, USER/awpmd, int
"USER-CGDNA"_#USER-CGDNA, coarse-grained DNA force fields, src/USER-CGDNA/README, USER/cgdna, -
"USER-CGSDK"_#USER-CGSDK, SDK coarse-graining model, "pair_style lj/sdk"_pair_sdk.html, USER/cgsdk, -
"USER-COLVARS"_#USER-COLVARS, collective variables library, "fix colvars"_fix_colvars.html, USER/colvars, int
"USER-DIFFRACTION"_#USER-DIFFRACTION, virtual x-ray and electron diffraction,"compute xrd"_compute_xrd.html, USER/diffraction, -
"USER-DPD"_#USER-DPD, reactive dissipative particle dynamics, src/USER-DPD/README, USER/dpd, -
"USER-DRUDE"_#USER-DRUDE, Drude oscillators, "tutorial"_tutorial_drude.html, USER/drude, -
"USER-EFF"_#USER-EFF, electron force field,"pair_style eff/cut"_pair_eff.html, USER/eff, -
"USER-FEP"_#USER-FEP, free energy perturbation,"compute fep"_compute_fep.html, USER/fep, -
"USER-H5MD"_#USER-H5MD, dump output via HDF5,"dump h5md"_dump_h5md.html, -, ext
"USER-INTEL"_#USER-INTEL, optimized Intel CPU and KNL styles,"Section 5.3.2"_accelerate_intel.html, WWW bench, -
"USER-LB"_#USER-LB, Lattice Boltzmann fluid,"fix lb/fluid"_fix_lb_fluid.html, USER/lb, -
"USER-MANIFOLD"_#USER-MANIFOLD, motion on 2d surfaces,"fix manifoldforce"_fix_manifoldforce.html, USER/manifold, -
"USER-MEAMC"_#USER-MEAMC, modified EAM potential (C++), "pair_style meam/c"_pair_meam.html, meam, -
"USER-MGPT"_#USER-MGPT, fast MGPT multi-ion potentials, "pair_style mgpt"_pair_mgpt.html, USER/mgpt, -
"USER-MISC"_#USER-MISC, single-file contributions, USER-MISC/README, USER/misc, -
"USER-MOLFILE"_#USER-MOLFILE, "VMD"_vmd_home molfile plug-ins,"dump molfile"_dump_molfile.html, -, ext
"USER-NETCDF"_#USER-NETCDF, dump output via NetCDF,"dump netcdf"_dump_netcdf.html, -, ext
"USER-OMP"_#USER-OMP, OpenMP-enabled styles,"Section 5.3.4"_accelerate_omp.html, WWW bench, -
"USER-PHONON"_#USER-PHONON, phonon dynamical matrix,"fix phonon"_fix_phonon.html, USER/phonon, -
"USER-QMMM"_#USER-QMMM, QM/MM coupling,"fix qmmm"_fix_qmmm.html, USER/qmmm, ext
"USER-QTB"_#USER-QTB, quantum nuclear effects,"fix qtb"_fix_qtb.html "fix qbmsst"_fix_qbmsst.html, qtb, -
"USER-QUIP"_#USER-QUIP, QUIP/libatoms interface,"pair_style quip"_pair_quip.html, USER/quip, ext
"USER-REAXC"_#USER-REAXC, ReaxFF potential (C/C++) ,"pair_style reaxc"_pair_reaxc.html, reax, -
"USER-SMD"_#USER-SMD, smoothed Mach dynamics,"SMD User Guide"_PDF/SMD_LAMMPS_userguide.pdf, USER/smd, ext
"USER-SMTBQ"_#USER-SMTBQ, second moment tight binding QEq potential,"pair_style smtbq"_pair_smtbq.html, USER/smtbq, -
"USER-SPH"_#USER-SPH, smoothed particle hydrodynamics,"SPH User Guide"_PDF/SPH_LAMMPS_userguide.pdf, USER/sph, -
"USER-TALLY"_#USER-TALLY, pairwise tally computes,"compute XXX/tally"_compute_tally.html, USER/tally, -
"USER-VTK"_#USER-VTK, dump output via VTK, "compute vtk"_dump_vtk.html, -, ext
:tb(ea=c,ca1=l)
:line
:line
ASPHERE package :link(ASPHERE),h4
[Contents:]
Computes, time-integration fixes, and pair styles for aspherical
particle models including ellipsoids, 2d lines, and 3d triangles.
[Install or un-install:]
make yes-asphere
make machine :pre
make no-asphere
make machine :pre
[Supporting info:]
src/ASPHERE: filenames -> commands
"Section 6.14"_Section_howto.html#howto_14
"pair_style gayberne"_pair_gayberne.html
"pair_style resquared"_pair_resquared.html
"doc/PDF/pair_gayberne_extra.pdf"_PDF/pair_gayberne_extra.pdf
"doc/PDF/pair_resquared_extra.pdf"_PDF/pair_resquared_extra.pdf
examples/ASPHERE
examples/ellipse
http://lammps.sandia.gov/movies.html#line
http://lammps.sandia.gov/movies.html#tri :ul
:line
BODY package :link(BODY),h4
[Contents:]
Body-style particles with internal structure. Computes,
time-integration fixes, pair styles, as well as the body styles
themselves. See the "body"_body.html doc page for an overview.
[Install or un-install:]
make yes-body
make machine :pre
make no-body
make machine :pre
[Supporting info:]
src/BODY filenames -> commands
"body"_body.html
"atom_style body"_atom_style.html
"fix nve/body"_fix_nve_body.html
"pair_style body"_pair_body.html
examples/body :ul
:line
CLASS2 package :link(CLASS2),h4
[Contents:]
Bond, angle, dihedral, improper, and pair styles for the COMPASS
CLASS2 molecular force field.
[Install or un-install:]
make yes-class2
make machine :pre
make no-class2
make machine :pre
[Supporting info:]
src/CLASS2: filenames -> commands
"bond_style class2"_bond_class2.html
"angle_style class2"_angle_class2.html
"dihedral_style class2"_dihedral_class2.html
"improper_style class2"_improper_class2.html
"pair_style lj/class2"_pair_class2.html :ul
:line
COLLOID package :link(COLLOID),h4
[Contents:]
Coarse-grained finite-size colloidal particles. Pair stayle and fix
wall styles for colloidal interactions. Includes the Fast Lubrication
Dynamics (FLD) method for hydrodynamic interactions, which is a
simplified approximation to Stokesian dynamics.
[Authors:] This package includes Fast Lubrication Dynamics pair styles
which were created by Amit Kumar and Michael Bybee from Jonathan
Higdon's group at UIUC.
[Install or un-install:]
make yes-colloid
make machine :pre
make no-colloid
make machine :pre
[Supporting info:]
src/COLLOID: filenames -> commands
"fix wall/colloid"_fix_wall.html
"pair_style colloid"_pair_colloid.html
"pair_style yukawa/colloid"_pair_yukawa_colloid.html
"pair_style brownian"_pair_brownian.html
"pair_style lubricate"_pair_lubricate.html
"pair_style lubricateU"_pair_lubricateU.html
examples/colloid
examples/srd :ul
:line
COMPRESS package :link(COMPRESS),h4
[Contents:]
Compressed output of dump files via the zlib compression library,
using dump styles with a "gz" in their style name.
To use this package you must have the zlib compression library
available on your system.
[Author:] Axel Kohlmeyer (Temple U).
[Install or un-install:]
Note that building with this package assumes you have the zlib
compression library available on your system. The LAMMPS build uses
the settings in the lib/compress/Makefile.lammps file in the
compile/link process. You should only need to edit this file if the
LAMMPS build fails on your system.
make yes-compress
make machine :pre
make no-compress
make machine :pre
[Supporting info:]
src/COMPRESS: filenames -> commands
src/COMPRESS/README
lib/compress/README
"dump atom/gz"_dump.html
"dump cfg/gz"_dump.html
"dump custom/gz"_dump.html
"dump xyz/gz"_dump.html :ul
:line
CORESHELL package :link(CORESHELL),h4
[Contents:]
Compute and pair styles that implement the adiabatic core/shell model
for polarizability. The pair styles augment Born, Buckingham, and
Lennard-Jones styles with core/shell capabilities. The "compute
temp/cs"_compute_temp_cs.html command calculates the temperature of a
system with core/shell particles. See "Section
6.26"_Section_howto.html#howto_26 for an overview of how to use this
package.
[Author:] Hendrik Heenen (Technical U of Munich).
[Install or un-install:]
make yes-coreshell
make machine :pre
make no-coreshell
make machine :pre
[Supporting info:]
src/CORESHELL: filenames -> commands
"Section 6.26"_Section_howto.html#howto_26
"Section 6.25"_Section_howto.html#howto_25
"compute temp/cs"_compute_temp_cs.html
"pair_style born/coul/long/cs"_pair_cs.html
"pair_style buck/coul/long/cs"_pair_cs.html
"pair_style lj/cut/coul/long/cs"_pair_lj.html
examples/coreshell :ul
:line
DIPOLE package :link(DIPOLE),h4
[Contents:]
An atom style and several pair styles for point dipole models with
short-range or long-range interactions.
[Install or un-install:]
make yes-dipole
make machine :pre
make no-dipole
make machine :pre
[Supporting info:]
src/DIPOLE: filenames -> commands
"atom_style dipole"_atom_style.html
"pair_style lj/cut/dipole/cut"_pair_dipole.html
"pair_style lj/cut/dipole/long"_pair_dipole.html
"pair_style lj/long/dipole/long"_pair_dipole.html
examples/dipole :ul
:line
GPU package :link(GPU),h4
[Contents:]
Dozens of pair styles and a version of the PPPM long-range Coulombic
solver optimized for NVIDIA GPUs. All such styles have a "gpu" as a
suffix in their style name. "Section 5.3.1"_accelerate_gpu.html gives
details of what hardware and Cuda software is required on your system,
and details on how to build and use this package. Its styles can be
invoked at run time via the "-sf gpu" or "-suffix gpu" "command-line
-switches"_Section_start.html#start_7. See also the "KOKKOS"_#KOKKOS
+switches"_Section_start.html#start_6. See also the "KOKKOS"_#KOKKOS
package, which has GPU-enabled styles.
[Authors:] Mike Brown (Intel) while at Sandia and ORNL and Trung Nguyen
(Northwestern U) while at ORNL.
[Install or un-install:]
Before building LAMMPS with this package, you must first build the GPU
library in lib/gpu from a set of provided C and Cuda files. You can
do this manually if you prefer; follow the instructions in
lib/gpu/README. You can also do it in one step from the lammps/src
dir, using a command like these, which simply invoke the
lib/gpu/Install.py script with the specified args:
make lib-gpu # print help message
make lib-gpu args="-m" # build GPU library with default Makefile.linux
make lib-gpu args="-i xk7 -p single -o xk7.single" # create new Makefile.xk7.single, altered for single-precision
make lib-gpu args="-i xk7 -p single -o xk7.single -m" # ditto, also build GPU library
Note that this procedure starts with one of the existing
Makefile.machine files in lib/gpu. It allows you to alter 4 important
settings in that Makefile, via the -h, -a, -p, -e switches,
and save the new Makefile, if desired:
CUDA_HOME = where NVIDIA Cuda software is installed on your system
CUDA_ARCH = what GPU hardware you have (see help message for details)
CUDA_PRECISION = precision (double, mixed, single)
EXTRAMAKE = which Makefile.lammps.* file to copy to Makefile.lammps :ul
If the library build is successful, 2 files should be created:
lib/gpu/libgpu.a and lib/gpu/Makefile.lammps. The latter has settings
that enable LAMMPS to link with Cuda libraries. If the settings in
Makefile.lammps for your machine are not correct, the LAMMPS build
will fail.
You can then install/un-install the package and build LAMMPS in the
usual manner:
make yes-gpu
make machine :pre
make no-gpu
make machine :pre
NOTE: If you re-build the GPU library in lib/gpu, you should always
un-install the GPU package, then re-install it and re-build LAMMPS.
This is because the compilation of files in the GPU package use the
library settings from the lib/gpu/Makefile.machine used to build the
GPU library.
[Supporting info:]
src/GPU: filenames -> commands
src/GPU/README
lib/gpu/README
"Section 5.3"_Section_accelerate.html#acc_3
"Section 5.3.1"_accelerate_gpu.html
-"Section 2.7 -sf gpu"_Section_start.html#start_7
-"Section 2.7 -pk gpu"_Section_start.html#start_7
+"Section 2.6 -sf gpu"_Section_start.html#start_6
+"Section 2.6 -pk gpu"_Section_start.html#start_6
"package gpu"_package.html
Pair Styles section of "Section 3.5"_Section_commands.html#cmd_5 for pair styles followed by (g)
"Benchmarks page"_http://lammps.sandia.gov/bench.html of web site :ul
:line
GRANULAR package :link(GRANULAR),h4
[Contents:]
Pair styles and fixes for finite-size granular particles, which
interact with each other and boundaries via frictional and dissipative
potentials.
[Install or un-install:]
make yes-granular
make machine :pre
make no-granular
make machine :pre
[Supporting info:]
src/GRANULAR: filenames -> commands
"Section 6.6"_Section_howto.html#howto_6,
"fix pour"_fix_pour.html
"fix wall/gran"_fix_wall_gran.html
"pair_style gran/hooke"_pair_gran.html
"pair_style gran/hertz/history"_pair_gran.html
examples/granregion
examples/pour
bench/in.chute
http://lammps.sandia.gov/pictures.html#jamming
http://lammps.sandia.gov/movies.html#hopper
http://lammps.sandia.gov/movies.html#dem
http://lammps.sandia.gov/movies.html#brazil
http://lammps.sandia.gov/movies.html#granregion :ul
:line
KIM package :link(KIM),h4
[Contents:]
A "pair_style kim"_pair_kim.html command which is a wrapper on the
Knowledge Base for Interatomic Models (KIM) repository of interatomic
potentials, enabling any of them to be used in LAMMPS simulations.
To use this package you must have the KIM library available on your
system.
Information about the KIM project can be found at its website:
https://openkim.org. The KIM project is led by Ellad Tadmor and Ryan
Elliott (U Minnesota) and James Sethna (Cornell U).
[Authors:] Ryan Elliott (U Minnesota) is the main developer for the KIM
API which the "pair_style kim"_pair_kim.html command uses. He
developed the pair style in collaboration with Valeriu Smirichinski (U
Minnesota).
[Install or un-install:]
Using this package requires the KIM library and its models
(interatomic potentials) to be downloaded and installed on your
system. The library can be downloaded and built in lib/kim or
elsewhere on your system. Details of the download, build, and install
process for KIM are given in the lib/kim/README file.
Once that process is complete, you can then install/un-install the
package and build LAMMPS in the usual manner:
make yes-kim
make machine :pre
make no-kim
make machine :pre
[Supporting info:]
src/KIM: filenames -> commands
src/KIM/README
lib/kim/README
"pair_style kim"_pair_kim.html
examples/kim :ul
:line
KOKKOS package :link(KOKKOS),h4
[Contents:]
Dozens of atom, pair, bond, angle, dihedral, improper, fix, compute
styles adapted to compile using the Kokkos library which can convert
them to OpenMP or Cuda code so that they run efficiently on multicore
CPUs, KNLs, or GPUs. All the styles have a "kk" as a suffix in their
style name. "Section 5.3.3"_accelerate_kokkos.html gives details of
what hardware and software is required on your system, and how to
build and use this package. Its styles can be invoked at run time via
the "-sf kk" or "-suffix kk" "command-line
-switches"_Section_start.html#start_7. Also see the "GPU"_#GPU,
+switches"_Section_start.html#start_6. Also see the "GPU"_#GPU,
"OPT"_#OPT, "USER-INTEL"_#USER-INTEL, and "USER-OMP"_#USER-OMP
packages, which have styles optimized for CPUs, KNLs, and GPUs.
You must have a C++11 compatible compiler to use this package.
[Authors:] The KOKKOS package was created primarily by Christian Trott
and Stan Moore (Sandia), with contributions from other folks as well.
It uses the open-source "Kokkos library"_https://github.com/kokkos
which was developed by Carter Edwards, Christian Trott, and others at
Sandia, and which is included in the LAMMPS distribution in
lib/kokkos.
[Install or un-install:]
For the KOKKOS package, you have 3 choices when building. You can
build with either CPU or KNL or GPU support. Each choice requires
additional settings in your Makefile.machine for the KOKKOS_DEVICES
and KOKKOS_ARCH settings. See the src/MAKE/OPTIONS/Makefile.kokkos*
files for examples.
For multicore CPUs using OpenMP:
KOKKOS_DEVICES = OpenMP
KOKKOS_ARCH = HSW # HSW = Haswell, SNB = SandyBridge, BDW = Broadwell, etc
For Intel KNLs using OpenMP:
KOKKOS_DEVICES = OpenMP
KOKKOS_ARCH = KNL
For NVIDIA GPUs using Cuda:
KOKKOS_DEVICES = Cuda
KOKKOS_ARCH = Pascal60,Power8 # P100 hosted by an IBM Power8, etc
KOKKOS_ARCH = Kepler37,Power8 # K80 hosted by an IBM Power8, etc
For GPUs, you also need these 2 lines in your Makefile.machine before
the CC line is defined, in this case for use with OpenMPI mpicxx. The
2 lines define a nvcc wrapper compiler, which will use nvcc for
compiling Cuda files or use a C++ compiler for non-Kokkos, non-Cuda
files.
KOKKOS_ABSOLUTE_PATH = $(shell cd $(KOKKOS_PATH); pwd)
export OMPI_CXX = $(KOKKOS_ABSOLUTE_PATH)/config/nvcc_wrapper
CC = mpicxx
Once you have an appropriate Makefile.machine, you can
install/un-install the package and build LAMMPS in the usual manner.
Note that you cannot build one executable to run on multiple hardware
targets (CPU or KNL or GPU). You need to build LAMMPS once for each
hardware target, to produce a separate executable. Also note that we
do not recommend building with other acceleration packages installed
(GPU, OPT, USER-INTEL, USER-OMP) when also building with KOKKOS.
make yes-kokkos
make machine :pre
make no-kokkos
make machine :pre
[Supporting info:]
src/KOKKOS: filenames -> commands
src/KOKKOS/README
lib/kokkos/README
"Section 5.3"_Section_accelerate.html#acc_3
"Section 5.3.3"_accelerate_kokkos.html
-"Section 2.7 -k on ..."_Section_start.html#start_7
-"Section 2.7 -sf kk"_Section_start.html#start_7
-"Section 2.7 -pk kokkos"_Section_start.html#start_7
+"Section 2.6 -k on ..."_Section_start.html#start_6
+"Section 2.6 -sf kk"_Section_start.html#start_6
+"Section 2.6 -pk kokkos"_Section_start.html#start_6
"package kokkos"_package.html
Styles sections of "Section 3.5"_Section_commands.html#cmd_5 for styles followed by (k)
"Benchmarks page"_http://lammps.sandia.gov/bench.html of web site :ul
:line
KSPACE package :link(KSPACE),h4
[Contents:]
A variety of long-range Coulombic solvers, as well as pair styles
which compute the corresponding short-range pairwise Coulombic
interactions. These include Ewald, particle-particle particle-mesh
(PPPM), and multilevel summation method (MSM) solvers.
[Install or un-install:]
Building with this package requires a 1d FFT library be present on
your system for use by the PPPM solvers. This can be the KISS FFT
library provided with LAMMPS, 3rd party libraries like FFTW, or a
vendor-supplied FFT library. See step 6 of "Section
2.2.2"_Section_start.html#start_2_2 of the manual for details on how
to select different FFT options in your machine Makefile.
make yes-kspace
make machine :pre
make no-kspace
make machine :pre
[Supporting info:]
src/KSPACE: filenames -> commands
"kspace_style"_kspace_style.html
"doc/PDF/kspace.pdf"_PDF/kspace.pdf
"Section 6.7"_Section_howto.html#howto_7
"Section 6.8"_Section_howto.html#howto_8
"Section 6.9"_Section_howto.html#howto_9
"pair_style coul"_pair_coul.html
Pair Styles section of "Section 3.5"_Section_commands.html#cmd_5 with "long" or "msm" in pair style name
examples/peptide
bench/in.rhodo :ul
:line
MANYBODY package :link(MANYBODY),h4
[Contents:]
A variety of manybody and bond-order potentials. These include
(AI)REBO, BOP, EAM, EIM, Stillinger-Weber, and Tersoff potentials.
[Install or un-install:]
make yes-manybody
make machine :pre
make no-manybody
make machine :pre
[Supporting info:]
src/MANYBODY: filenames -> commands
Pair Styles section of "Section 3.5"_Section_commands.html#cmd_5
examples/comb
examples/eim
examples/nb3d
examples/shear
examples/streitz
examples/vashishta
bench/in.eam :ul
:line
MC package :link(MC),h4
[Contents:]
Several fixes and a pair style that have Monte Carlo (MC) or MC-like
attributes. These include fixes for creating, breaking, and swapping
bonds, for performing atomic swaps, and performing grand-canonical MC
(GCMC) in conjuction with dynamics.
[Install or un-install:]
make yes-mc
make machine :pre
make no-mc
make machine :pre
[Supporting info:]
src/MC: filenames -> commands
"fix atom/swap"_fix_atom_swap.html
"fix bond/break"_fix_bond_break.html
"fix bond/create"_fix_bond_create.html
"fix bond/swap"_fix_bond_swap.html
"fix gcmc"_fix_gcmc.html
"pair_style dsmc"_pair_dsmc.html
http://lammps.sandia.gov/movies.html#gcmc :ul
:line
MEAM package :link(MEAM),h4
[Contents:]
A pair style for the modified embedded atom (MEAM) potential.
[Author:] Greg Wagner (Northwestern U) while at Sandia.
[Install or un-install:]
Before building LAMMPS with this package, you must first build the
MEAM library in lib/meam. You can do this manually if you prefer;
follow the instructions in lib/meam/README. You can also do it in one
step from the lammps/src dir, using a command like these, which simply
invoke the lib/meam/Install.py script with the specified args:
make lib-meam # print help message
make lib-meam args="-m gfortran" # build with GNU Fortran compiler
make lib-meam args="-m ifort" # build with Intel ifort compiler :pre
The build should produce two files: lib/meam/libmeam.a and
lib/meam/Makefile.lammps. The latter is copied from an existing
Makefile.lammps.* and has settings needed to link C++ (LAMMPS) with
Fortran (MEAM library). Typically the two compilers used for LAMMPS
and the MEAM library need to be consistent (e.g. both Intel or both
GNU compilers). If necessary, you can edit/create a new
lib/meam/Makefile.machine file for your system, which should define an
EXTRAMAKE variable to specify a corresponding Makefile.lammps.machine
file.
You can then install/un-install the package and build LAMMPS in the
usual manner:
make yes-meam
make machine :pre
make no-meam
make machine :pre
NOTE: You should test building the MEAM library with both the Intel
and GNU compilers to see if a simulation runs faster with one versus
the other on your system.
[Supporting info:]
src/MEAM: filenames -> commands
src/meam/README
lib/meam/README
"pair_style meam"_pair_meam.html
examples/meam :ul
:line
MISC package :link(MISC),h4
[Contents:]
A variety of compute, fix, pair, dump styles with specialized
capabilities that don't align with other packages. Do a directory
listing, "ls src/MISC", to see the list of commands.
[Install or un-install:]
make yes-misc
make machine :pre
make no-misc
make machine :pre
[Supporting info:]
src/MISC: filenames -> commands
"compute ti"_compute_ti.html
"fix evaporate"_fix_evaporate.html
"fix orient/fcc"_fix_orient.html
"fix ttm"_fix_ttm.html
"fix thermal/conductivity"_fix_thermal_conductivity.html
"fix viscosity"_fix_viscosity.html
examples/KAPPA
examples/VISCOSITY
http://lammps.sandia.gov/pictures.html#ttm
http://lammps.sandia.gov/movies.html#evaporation :ul
:line
MOLECULE package :link(MOLECULE),h4
[Contents:]
A large number of atom, pair, bond, angle, dihedral, improper styles
that are used to model molecular systems with fixed covalent bonds.
The pair styles include the Dreiding (hydrogen-bonding) and CHARMM
force fields, and a TIP4P water model.
[Install or un-install:]
make yes-molecule
make machine :pre
make no-molecule
make machine :pre
[Supporting info:]
src/MOLECULE: filenames -> commands
"atom_style"_atom_style.html
"bond_style"_bond_style.html
"angle_style"_angle_style.html
"dihedral_style"_dihedral_style.html
"improper_style"_improper_style.html
"pair_style hbond/dreiding/lj"_pair_hbond_dreiding.html
"pair_style lj/charmm/coul/charmm"_pair_charmm.html
"Section 6.3"_Section_howto.html#howto_3
examples/cmap
examples/dreiding
examples/micelle,
examples/peptide
bench/in.chain
bench/in.rhodo :ul
:line
MPIIO package :link(MPIIO),h4
[Contents:]
Support for parallel output/input of dump and restart files via the
MPIIO library. It adds "dump styles"_dump.html with a "mpiio" in
their style name. Restart files with an ".mpiio" suffix are also
written and read in parallel.
[Install or un-install:]
Note that MPIIO is part of the standard message-passing interface
(MPI) library, so you should not need any additional compiler or link
settings, beyond what LAMMPS normally uses for MPI on your system.
make yes-mpiio
make machine :pre
make no-mpiio
make machine :pre
[Supporting info:]
src/MPIIO: filenames -> commands
"dump"_dump.html
"restart"_restart.html
"write_restart"_write_restart.html
"read_restart"_read_restart.html :ul
:line
MSCG package :link(mscg),h4
[Contents:]
A "fix mscg"_fix_mscg.html command which can parameterize a
Mulit-Scale Coarse-Graining (MSCG) model using the open-source "MS-CG
library"_mscg_home.
:link(mscg_home,https://github.com/uchicago-voth/MSCG-release)
To use this package you must have the MS-CG library available on your
system.
[Authors:] The fix was written by Lauren Abbott (Sandia). The MS-CG
library was developed by Jacob Wagner in Greg Voth's group at the
University of Chicago.
[Install or un-install:]
Before building LAMMPS with this package, you must first download and
build the MS-CG library. Building the MS-CG library and using it from
LAMMPS requires a C++11 compatible compiler, and that LAPACK and GSL
(GNU Scientific Library) libraries be installed on your machine. See
the lib/mscg/README and MSCG/Install files for more details.
Assuming these libraries are in place, you can do the download and
build of MS-CG manually if you prefer; follow the instructions in
lib/mscg/README. You can also do it in one step from the lammps/src
dir, using a command like these, which simply invoke the
lib/mscg/Install.py script with the specified args:
make lib-mscg # print help message
make lib-mscg args="-g -b -l" # download and build in default lib/mscg/MSCG-release-master
make lib-mscg args="-h . MSCG -g -b -l" # download and build in lib/mscg/MSCG
make lib-mscg args="-h ~ MSCG -g -b -l" # download and build in ~/mscg :pre
Note that the final -l switch is to create 2 symbolic (soft) links,
"includelink" and "liblink", in lib/mscg to point to the MS-CG src
dir. When LAMMPS builds it will use these links. You should not need
to edit the lib/mscg/Makefile.lammps file.
You can then install/un-install the package and build LAMMPS in the
usual manner:
make yes-mscg
make machine :pre
make no-mscg
make machine :pre
[Supporting info:]
src/MSCG: filenames -> commands
src/MSCG/README
lib/mscg/README
examples/mscg :ul
:line
OPT package :link(OPT),h4
[Contents:]
A handful of pair styles which are optimized for improved CPU
performance on single or multiple cores. These include EAM, LJ,
CHARMM, and Morse potentials. The styles have an "opt" suffix in
their style name. "Section 5.3.5"_accelerate_opt.html gives details
of how to build and use this package. Its styles can be invoked at
run time via the "-sf opt" or "-suffix opt" "command-line
-switches"_Section_start.html#start_7. See also the "KOKKOS"_#KOKKOS,
+switches"_Section_start.html#start_6. See also the "KOKKOS"_#KOKKOS,
"USER-INTEL"_#USER-INTEL, and "USER-OMP"_#USER-OMP packages, which
have styles optimized for CPU performance.
[Authors:] James Fischer (High Performance Technologies), David Richie,
and Vincent Natoli (Stone Ridge Technolgy).
[Install or un-install:]
make yes-opt
make machine :pre
make no-opt
make machine :pre
NOTE: The compile flag "-restrict" must be used to build LAMMPS with
the OPT package. It should be added to the CCFLAGS line of your
Makefile.machine. See Makefile.opt in src/MAKE/OPTIONS for an
example.
CCFLAGS: add -restrict :ul
[Supporting info:]
src/OPT: filenames -> commands
"Section 5.3"_Section_accelerate.html#acc_3
"Section 5.3.5"_accelerate_opt.html
-"Section 2.7 -sf opt"_Section_start.html#start_7
+"Section 2.6 -sf opt"_Section_start.html#start_6
Pair Styles section of "Section 3.5"_Section_commands.html#cmd_5 for pair styles followed by (t)
"Benchmarks page"_http://lammps.sandia.gov/bench.html of web site :ul
:line
PERI package :link(PERI),h4
[Contents:]
An atom style, several pair styles which implement different
Peridynamics materials models, and several computes which calculate
diagnostics. Peridynamics is a a particle-based meshless continuum
model.
[Authors:] The original package was created by Mike Parks (Sandia).
Additional Peridynamics models were added by Rezwanur Rahman and John
Foster (UTSA).
[Install or un-install:]
make yes-peri
make machine :pre
make no-peri
make machine :pre
[Supporting info:]
src/PERI: filenames -> commands
"doc/PDF/PDLammps_overview.pdf"_PDF/PDLammps_overview.pdf
"doc/PDF/PDLammps_EPS.pdf"_PDF/PDLammps_EPS.pdf
"doc/PDF/PDLammps_VES.pdf"_PDF/PDLammps_VES.pdf
"atom_style peri"_atom_style.html
"pair_style peri/*"_pair_peri.html
"compute damage/atom"_compute_damage_atom.html
"compute plasticity/atom"_compute_plasticity_atom.html
examples/peri
http://lammps.sandia.gov/movies.html#peri :ul
:line
POEMS package :link(POEMS),h4
[Contents:]
A fix that wraps the Parallelizable Open source Efficient Multibody
Software (POEMS) library, which is able to simulate the dynamics of
articulated body systems. These are systems with multiple rigid
bodies (collections of particles) whose motion is coupled by
connections at hinge points.
[Author:] Rudra Mukherjee (JPL) while at RPI.
[Install or un-install:]
Before building LAMMPS with this package, you must first build the
POEMS library in lib/poems. You can do this manually if you prefer;
follow the instructions in lib/poems/README. You can also do it in
one step from the lammps/src dir, using a command like these, which
simply invoke the lib/poems/Install.py script with the specified args:
make lib-poems # print help message
make lib-poems args="-m g++" # build with GNU g++ compiler
make lib-poems args="-m icc" # build with Intel icc compiler :pre
The build should produce two files: lib/poems/libpoems.a and
lib/poems/Makefile.lammps. The latter is copied from an existing
Makefile.lammps.* and has settings needed to build LAMMPS with the
POEMS library (though typically the settings are just blank). If
necessary, you can edit/create a new lib/poems/Makefile.machine file
for your system, which should define an EXTRAMAKE variable to specify
a corresponding Makefile.lammps.machine file.
You can then install/un-install the package and build LAMMPS in the
usual manner:
make yes-poems
make machine :pre
make no-meam
make machine :pre
[Supporting info:]
src/POEMS: filenames -> commands
src/POEMS/README
lib/poems/README
"fix poems"_fix_poems.html
examples/rigid :ul
:line
PYTHON package :link(PYTHON),h4
[Contents:]
A "python"_python.html command which allow you to execute Python code
from a LAMMPS input script. The code can be in a separate file or
embedded in the input script itself. See "Section
11.2"_Section_python.html#py_2 for an overview of using Python from
LAMMPS in this manner and the entire section for other ways to use
LAMMPS and Python together.
[Install or un-install:]
make yes-python
make machine :pre
make no-python
make machine :pre
NOTE: Building with the PYTHON package assumes you have a Python
shared library available on your system, which needs to be a Python 2
version, 2.6 or later. Python 3 is not yet supported. See the
lib/python/README for more details. Note that the build uses the
lib/python/Makefile.lammps file in the compile/link process. You
should only need to create a new Makefile.lammps.* file (and copy it
to Makefile.lammps) if the LAMMPS build fails.
[Supporting info:]
src/PYTHON: filenames -> commands
"Section 11"_Section_python.html
lib/python/README
examples/python :ul
:line
QEQ package :link(QEQ),h4
[Contents:]
Several fixes for performing charge equilibration (QEq) via different
algorithms. These can be used with pair styles that perform QEq as
part of their formulation.
[Install or un-install:]
make yes-qeq
make machine :pre
make no-qeq
make machine :pre
[Supporting info:]
src/QEQ: filenames -> commands
"fix qeq/*"_fix_qeq.html
examples/qeq
examples/streitz :ul
:line
REAX package :link(REAX),h4
[Contents:]
A pair style which wraps a Fortran library which implements the ReaxFF
potential, which is a universal reactive force field. See the
"USER-REAXC package"_#USER-REAXC for an alternate implementation in
C/C++. Also a "fix reax/bonds"_fix_reax_bonds.html command for
monitoring molecules as bonds are created and destroyed.
[Author:] Aidan Thompson (Sandia).
[Install or un-install:]
Before building LAMMPS with this package, you must first build the
REAX library in lib/reax. You can do this manually if you prefer;
follow the instructions in lib/reax/README. You can also do it in one
step from the lammps/src dir, using a command like these, which simply
invoke the lib/reax/Install.py script with the specified args:
make lib-reax # print help message
make lib-reax args="-m gfortran" # build with GNU Fortran compiler
make lib-reax args="-m ifort" # build with Intel ifort compiler :pre
The build should produce two files: lib/reax/libreax.a and
lib/reax/Makefile.lammps. The latter is copied from an existing
Makefile.lammps.* and has settings needed to link C++ (LAMMPS) with
Fortran (REAX library). Typically the two compilers used for LAMMPS
and the REAX library need to be consistent (e.g. both Intel or both
GNU compilers). If necessary, you can edit/create a new
lib/reax/Makefile.machine file for your system, which should define an
EXTRAMAKE variable to specify a corresponding Makefile.lammps.machine
file.
You can then install/un-install the package and build LAMMPS in the
usual manner:
make yes-reax
make machine :pre
make no-reax
make machine :pre
[Supporting info:]
src/REAX: filenames -> commands
lib/reax/README
"pair_style reax"_pair_reax.html
"fix reax/bonds"_fix_reax_bonds.html
examples/reax :ul
:line
REPLICA package :link(REPLICA),h4
[Contents:]
A collection of multi-replica methods which can be used when running
multiple LAMMPS simulations (replicas). See "Section
6.5"_Section_howto.html#howto_5 for an overview of how to run
multi-replica simulations in LAMMPS. Methods in the package include
nudged elastic band (NEB), parallel replica dynamics (PRD),
temperature accelerated dynamics (TAD), parallel tempering, and a
verlet/split algorithm for performing long-range Coulombics on one set
of processors, and the remainder of the force field calcalation on
another set.
[Install or un-install:]
make yes-replica
make machine :pre
make no-replica
make machine :pre
[Supporting info:]
src/REPLICA: filenames -> commands
"Section 6.5"_Section_howto.html#howto_5
"neb"_neb.html
"prd"_prd.html
"tad"_tad.html
"temper"_temper.html,
"run_style verlet/split"_run_style.html
examples/neb
examples/prd
examples/tad :ul
:line
RIGID package :link(RIGID),h4
[Contents:]
Fixes which enforce rigid constraints on collections of atoms or
particles. This includes SHAKE and RATTLE, as well as varous
rigid-body integrators for a few large bodies or many small bodies.
Also several computes which calculate properties of rigid bodies.
To install/build:
make yes-rigid
make machine :pre
To un-install/re-build:
make no-rigid
make machine :pre
[Supporting info:]
src/RIGID: filenames -> commands
"compute erotate/rigid"_compute_erotate_rigid.html
fix shake"_fix_shake.html
"fix rattle"_fix_shake.html
"fix rigid/*"_fix_rigid.html
examples/ASPHERE
examples/rigid
bench/in.rhodo
http://lammps.sandia.gov/movies.html#box
http://lammps.sandia.gov/movies.html#star :ul
:line
SHOCK package :link(SHOCK),h4
[Contents:]
Fixes for running impact simulations where a shock-wave passes through
a material.
[Install or un-install:]
make yes-shock
make machine :pre
make no-shock
make machine :pre
[Supporting info:]
src/SHOCK: filenames -> commands
"fix append/atoms"_fix_append_atoms.html
"fix msst"_fix_msst.html
"fix nphug"_fix_nphug.html
"fix wall/piston"_fix_wall_piston.html
examples/hugoniostat
examples/msst :ul
:line
SNAP package :link(SNAP),h4
[Contents:]
A pair style for the spectral neighbor analysis potential (SNAP).
SNAP is methodology for deriving a highly accurate classical potential
fit to a large archive of quantum mechanical (DFT) data. Also several
computes which analyze attributes of the potential.
[Author:] Aidan Thompson (Sandia).
[Install or un-install:]
make yes-snap
make machine :pre
make no-snap
make machine :pre
[Supporting info:]
src/SNAP: filenames -> commands
"pair snap"_pair_snap.html
"compute sna/atom"_compute_sna_atom.html
"compute snad/atom"_compute_sna_atom.html
"compute snav/atom"_compute_sna_atom.html
examples/snap :ul
:line
SRD package :link(SRD),h4
[Contents:]
A pair of fixes which implement the Stochastic Rotation Dynamics (SRD)
method for coarse-graining of a solvent, typically around large
colloidal particles.
To install/build:
make yes-srd
make machine :pre
To un-install/re-build:
make no-srd
make machine :pre
[Supporting info:]
src/SRD: filenames -> commands
"fix srd"_fix_srd.html
"fix wall/srd"_fix_wall_srd.html
examples/srd
examples/ASPHERE
http://lammps.sandia.gov/movies.html#tri
http://lammps.sandia.gov/movies.html#line
http://lammps.sandia.gov/movies.html#poly :ul
:line
VORONOI package :link(VORONOI),h4
[Contents:]
A compute command which calculates the Voronoi tesselation of a
collection of atoms by wrapping the "Voro++ library"_voro_home. This
can be used to calculate the local volume or each atoms or its near
neighbors.
:link(voro_home,http://math.lbl.gov/voro++)
To use this package you must have the Voro++ library available on your
system.
[Author:] Daniel Schwen (INL) while at LANL. The open-source Voro++
library was written by Chris Rycroft (Harvard U) while at UC Berkeley
and LBNL.
[Install or un-install:]
Before building LAMMPS with this package, you must first download and
build the Voro++ library. You can do this manually if you prefer;
follow the instructions in lib/voronoi/README. You can also do it in
one step from the lammps/src dir, using a command like these, which
simply invoke the lib/voronoi/Install.py script with the specified
args:
make lib-voronoi # print help message
make lib-voronoi args="-g -b -l" # download and build in default lib/voronoi/voro++-0.4.6
make lib-voronoi args="-h . voro++ -g -b -l" # download and build in lib/voronoi/voro++
make lib-voronoi args="-h ~ voro++ -g -b -l" # download and build in ~/voro++ :pre
Note that the final -l switch is to create 2 symbolic (soft) links,
"includelink" and "liblink", in lib/voronoi to point to the Voro++ src
dir. When LAMMPS builds it will use these links. You should not need
to edit the lib/voronoi/Makefile.lammps file.
You can then install/un-install the package and build LAMMPS in the
usual manner:
make yes-voronoi
make machine :pre
make no-voronoi
make machine :pre
[Supporting info:]
src/VORONOI: filenames -> commands
src/VORONOI/README
lib/voronoi/README
"compute voronoi/atom"_compute_voronoi_atom.html
examples/voronoi :ul
:line
:line
USER-ATC package :link(USER-ATC),h4
[Contents:]
ATC stands for atoms-to-continuum. This package implements a "fix
atc"_fix_atc.html command to either couple molecular dynamics with
continuum finite element equations or perform on-the-fly conversion of
atomic information to continuum fields.
[Authors:] Reese Jones, Jeremy Templeton, Jon Zimmerman (Sandia).
[Install or un-install:]
Before building LAMMPS with this package, you must first build the ATC
library in lib/atc. You can do this manually if you prefer; follow
the instructions in lib/atc/README. You can also do it in one step
from the lammps/src dir, using a command like these, which simply
invoke the lib/atc/Install.py script with the specified args:
make lib-atc # print help message
make lib-atc args="-m g++" # build with GNU g++ compiler
make lib-atc args="-m icc" # build with Intel icc compiler :pre
The build should produce two files: lib/atc/libatc.a and
lib/atc/Makefile.lammps. The latter is copied from an existing
Makefile.lammps.* and has settings needed to build LAMMPS with the ATC
library. If necessary, you can edit/create a new
lib/atc/Makefile.machine file for your system, which should define an
EXTRAMAKE variable to specify a corresponding Makefile.lammps.machine
file.
Note that the Makefile.lammps file has settings for the BLAS and
LAPACK linear algebra libraries. As explained in lib/atc/README these
can either exist on your system, or you can use the files provided in
lib/linalg. In the latter case you also need to build the library
in lib/linalg with a command like these:
make lib-linalg # print help message
make lib-atc args="-m gfortran" # build with GNU Fortran compiler
You can then install/un-install the package and build LAMMPS in the
usual manner:
make yes-user-atc
make machine :pre
make no-user-atc
make machine :pre
[Supporting info:]
src/USER-ATC: filenames -> commands
src/USER-ATC/README
"fix atc"_fix_atc.html
examples/USER/atc
http://lammps.sandia.gov/pictures.html#atc :ul
:line
USER-AWPMD package :link(USER-AWPMD),h4
[Contents:]
AWPMD stands for Antisymmetrized Wave Packet Molecular Dynamics. This
package implements an atom, pair, and fix style which allows electrons
to be treated as explicit particles in a classical molecular dynamics
model.
[Author:] Ilya Valuev (JIHT, Russia).
[Install or un-install:]
Before building LAMMPS with this package, you must first build the
AWPMD library in lib/awpmd. You can do this manually if you prefer;
follow the instructions in lib/awpmd/README. You can also do it in
one step from the lammps/src dir, using a command like these, which
simply invoke the lib/awpmd/Install.py script with the specified args:
make lib-awpmd # print help message
make lib-awpmd args="-m g++" # build with GNU g++ compiler
make lib-awpmd args="-m icc" # build with Intel icc compiler :pre
The build should produce two files: lib/awpmd/libawpmd.a and
lib/awpmd/Makefile.lammps. The latter is copied from an existing
Makefile.lammps.* and has settings needed to build LAMMPS with the
AWPMD library. If necessary, you can edit/create a new
lib/awpmd/Makefile.machine file for your system, which should define
an EXTRAMAKE variable to specify a corresponding
Makefile.lammps.machine file.
Note that the Makefile.lammps file has settings for the BLAS and
LAPACK linear algebra libraries. As explained in lib/awpmd/README
these can either exist on your system, or you can use the files
provided in lib/linalg. In the latter case you also need to build the
library in lib/linalg with a command like these:
make lib-linalg # print help message
make lib-atc args="-m gfortran" # build with GNU Fortran compiler
You can then install/un-install the package and build LAMMPS in the
usual manner:
make yes-user-awpmd
make machine :pre
make no-user-awpmd
make machine :pre
[Supporting info:]
src/USER-AWPMD: filenames -> commands
src/USER-AWPMD/README
"pair awpmd/cut"_pair_awpmd.html
examples/USER/awpmd :ul
:line
USER-CGDNA package :link(USER-CGDNA),h4
[Contents:]
Several pair styles, a bond style, and integration fixes for
coarse-grained models of single- and double-stranded DNA based on the
oxDNA model of Doye, Louis and Ouldridge at the University of Oxford.
This includes Langevin-type rigid-body integrators with improved
stability.
[Author:] Oliver Henrich (University of Strathclyde, Glasgow).
[Install or un-install:]
make yes-user-cgdna
make machine :pre
make no-user-cgdna
make machine :pre
[Supporting info:]
src/USER-CGDNA: filenames -> commands
/src/USER-CGDNA/README
"pair_style oxdna/*"_pair_oxdna.html
"pair_style oxdna2/*"_pair_oxdna2.html
"bond_style oxdna/*"_bond_oxdna.html
"bond_style oxdna2/*"_bond_oxdna.html
"fix nve/dotc/langevin"_fix_nve_dotc_langevin.html :ul
:line
USER-CGSDK package :link(USER-CGSDK),h4
[Contents:]
Several pair styles and an angle style which implement the
coarse-grained SDK model of Shinoda, DeVane, and Klein which enables
simulation of ionic liquids, electrolytes, lipids and charged amino
acids.
[Author:] Axel Kohlmeyer (Temple U).
[Install or un-install:]
make yes-user-cgsdk
make machine :pre
make no-user-cgsdk
make machine :pre
[Supporting info:]
src/USER-CGSDK: filenames -> commands
src/USER-CGSDK/README
"pair_style lj/sdk/*"_pair_sdk.html
"angle_style sdk"_angle_sdk.html
examples/USER/cgsdk
http://lammps.sandia.gov/pictures.html#cg :ul
:line
USER-COLVARS package :link(USER-COLVARS),h4
[Contents:]
COLVARS stands for collective variables, which can be used to
implement various enhanced sampling methods, including Adaptive
Biasing Force, Metadynamics, Steered MD, Umbrella Sampling and
Restraints. A "fix colvars"_fix_colvars.html command is implemented
which wraps a COLVARS library, which implements these methods.
simulations.
[Authors:] Axel Kohlmeyer (Temple U). The COLVARS library was written
by Giacomo Fiorin (ICMS, Temple University, Philadelphia, PA, USA) and
Jerome Henin (LISM, CNRS, Marseille, France).
[Install or un-install:]
Before building LAMMPS with this package, you must first build the
COLVARS library in lib/colvars. You can do this manually if you
prefer; follow the instructions in lib/colvars/README. You can also
do it in one step from the lammps/src dir, using a command like these,
which simply invoke the lib/colvars/Install.py script with the
specified args:
make lib-colvars # print help message
make lib-colvars args="-m g++" # build with GNU g++ compiler :pre
The build should produce two files: lib/colvars/libcolvars.a and
lib/colvars/Makefile.lammps. The latter is copied from an existing
Makefile.lammps.* and has settings needed to build LAMMPS with the
COLVARS library (though typically the settings are just blank). If
necessary, you can edit/create a new lib/colvars/Makefile.machine file
for your system, which should define an EXTRAMAKE variable to specify
a corresponding Makefile.lammps.machine file.
You can then install/un-install the package and build LAMMPS in the
usual manner:
make yes-user-colvars
make machine :pre
make no-user-colvars
make machine :pre
[Supporting info:]
src/USER-COLVARS: filenames -> commands
"doc/PDF/colvars-refman-lammps.pdf"_PDF/colvars-refman-lammps.pdf
src/USER-COLVARS/README
lib/colvars/README
"fix colvars"_fix_colvars.html
examples/USER/colvars :ul
:line
USER-DIFFRACTION package :link(USER-DIFFRACTION),h4
[Contents:]
Two computes and a fix for calculating x-ray and electron diffraction
intensities based on kinematic diffraction theory.
[Author:] Shawn Coleman while at the U Arkansas.
[Install or un-install:]
make yes-user-diffraction
make machine :pre
make no-user-diffraction
make machine :pre
[Supporting info:]
src/USER-DIFFRACTION: filenames -> commands
"compute saed"_compute_saed.html
"compute xrd"_compute_xrd.html
"fix saed/vtk"_fix_saed_vtk.html
examples/USER/diffraction :ul
:line
USER-DPD package :link(USER-DPD),h4
[Contents:]
DPD stands for dissipative particle dynamics. This package implements
coarse-grained DPD-based models for energetic, reactive molecular
crystalline materials. It includes many pair styles specific to these
systems, including for reactive DPD, where each particle has internal
state for multiple species and a coupled set of chemical reaction ODEs
are integrated each timestep. Highly accurate time intergrators for
isothermal, isoenergetic, isobaric and isenthalpic conditions are
included. These enable long timesteps via the Shardlow splitting
algorithm.
[Authors:] Jim Larentzos (ARL), Tim Mattox (Engility Corp), and and John
Brennan (ARL).
[Install or un-install:]
make yes-user-dpd
make machine :pre
make no-user-dpd
make machine :pre
[Supporting info:]
src/USER-DPD: filenames -> commands
/src/USER-DPD/README
"compute dpd"_compute_dpd.html
"compute dpd/atom"_compute_dpd_atom.html
"fix eos/cv"_fix_eos_table.html
"fix eos/table"_fix_eos_table.html
"fix eos/table/rx"_fix_eos_table_rx.html
"fix shardlow"_fix_shardlow.html
"fix rx"_fix_rx.html
"pair table/rx"_pair_table_rx.html
"pair dpd/fdt"_pair_dpd_fdt.html
"pair dpd/fdt/energy"_pair_dpd_fdt.html
"pair exp6/rx"_pair_exp6_rx.html
"pair multi/lucy"_pair_multi_lucy.html
"pair multi/lucy/rx"_pair_multi_lucy_rx.html
examples/USER/dpd :ul
:line
USER-DRUDE package :link(USER-DRUDE),h4
[Contents:]
Fixes, pair styles, and a compute to simulate thermalized Drude
oscillators as a model of polarization. See "Section
6.27"_Section_howto.html#howto_27 for an overview of how to use the
package. There are auxiliary tools for using this package in
tools/drude.
[Authors:] Alain Dequidt (U Blaise Pascal Clermont-Ferrand), Julien
Devemy (CNRS), and Agilio Padua (U Blaise Pascal).
[Install or un-install:]
make yes-user-drude
make machine :pre
make no-user-drude
make machine :pre
[Supporting info:]
src/USER-DRUDE: filenames -> commands
"Section 6.27"_Section_howto.html#howto_27
"Section 6.25"_Section_howto.html#howto_25
src/USER-DRUDE/README
"fix drude"_fix_drude.html
"fix drude/transform/*"_fix_drude_transform.html
"compute temp/drude"_compute_temp_drude.html
"pair thole"_pair_thole.html
"pair lj/cut/thole/long"_pair_thole.html
examples/USER/drude
tools/drude :ul
:line
USER-EFF package :link(USER-EFF),h4
[Contents:]
EFF stands for electron force field which allows a classical MD code
to model electrons as particles of variable radius. This package
contains atom, pair, fix and compute styles which implement the eFF as
described in A. Jaramillo-Botero, J. Su, Q. An, and W.A. Goddard III,
JCC, 2010. The eFF potential was first introduced by Su and Goddard,
in 2007. There are auxiliary tools for using this package in
tools/eff; see its README file.
[Author:] Andres Jaramillo-Botero (CalTech).
[Install or un-install:]
make yes-user-eff
make machine :pre
make no-user-eff
make machine :pre
[Supporting info:]
src/USER-EFF: filenames -> commands
src/USER-EFF/README
"atom_style electron"_atom_style.html
"fix nve/eff"_fix_nve_eff.html
"fix nvt/eff"_fix_nh_eff.html
"fix npt/eff"_fix_nh_eff.html
"fix langevin/eff"_fix_langevin_eff.html
"compute temp/eff"_compute_temp_eff.html
"pair eff/cut"_pair_eff.html
"pair eff/inline"_pair_eff.html
examples/USER/eff
tools/eff/README
tools/eff
http://lammps.sandia.gov/movies.html#eff :ul
:line
USER-FEP package :link(USER-FEP),h4
[Contents:]
FEP stands for free energy perturbation. This package provides
methods for performing FEP simulations by using a "fix
adapt/fep"_fix_adapt_fep.html command with soft-core pair potentials,
which have a "soft" in their style name. There are auxiliary tools
for using this package in tools/fep; see its README file.
[Author:] Agilio Padua (Universite Blaise Pascal Clermont-Ferrand)
[Install or un-install:]
make yes-user-fep
make machine :pre
make no-user-fep
make machine :pre
[Supporting info:]
src/USER-FEP: filenames -> commands
src/USER-FEP/README
"fix adapt/fep"_fix_adapt_fep.html
"compute fep"_compute_fep.html
"pair_style */soft"_pair_lj_soft.html
examples/USER/fep
tools/fep/README
tools/fep :ul
:line
USER-H5MD package :link(USER-H5MD),h4
[Contents:]
H5MD stands for HDF5 for MD. "HDF5"_HDF5 is a portable, binary,
self-describing file format, used by many scientific simulations.
H5MD is a format for molecular simulations, built on top of HDF5.
This package implements a "dump h5md"_dump_h5md.html command to output
LAMMPS snapshots in this format.
:link(HDF5,http://www.hdfgroup.org/HDF5)
To use this package you must have the HDF5 library available on your
system.
[Author:] Pierre de Buyl (KU Leuven) created both the package and the
H5MD format.
[Install or un-install:]
Note that to follow these steps to compile and link to the CH5MD
library, you need the standard HDF5 software package installed on your
system, which should include the h5cc compiler and the HDF5 library.
Before building LAMMPS with this package, you must first build the
CH5MD library in lib/h5md. You can do this manually if you prefer;
follow the instructions in lib/h5md/README. You can also do it in one
step from the lammps/src 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
The build should produce two files: lib/h5md/libch5md.a and
lib/h5md/Makefile.lammps. The latter is copied from an existing
Makefile.lammps.* and has settings needed to build LAMMPS with the
system HDF5 library. If necessary, you can edit/create a new
lib/h5md/Makefile.machine file for your system, which should define an
EXTRAMAKE variable to specify a corresponding Makefile.lammps.machine
file.
You can then install/un-install the package and build LAMMPS in the
usual manner:
make yes-user-h5md
make machine :pre
make no-user-h5md
make machine :pre
[Supporting info:]
src/USER-H5MD: filenames -> commands
src/USER-H5MD/README
lib/h5md/README
"dump h5md"_dump_h5md.html :ul
:line
USER-INTEL package :link(USER-INTEL),h4
[Contents:]
Dozens of pair, fix, bond, angle, dihedral, improper, and kspace
styles which are optimized for Intel CPUs and KNLs (Knights Landing).
All of them have an "intel" in their style name. "Section
5.3.2"_accelerate_intel.html gives details of what hardware and
compilers are required on your system, and how to build and use this
package. Its styles can be invoked at run time via the "-sf intel" or
-"-suffix intel" "command-line switches"_Section_start.html#start_7.
+"-suffix intel" "command-line switches"_Section_start.html#start_6.
Also see the "KOKKOS"_#KOKKOS, "OPT"_#OPT, and "USER-OMP"_#USER-OMP
packages, which have styles optimized for CPUs and KNLs.
You need to have an Intel compiler, version 14 or higher to take full
advantage of this package.
[Author:] Mike Brown (Intel).
[Install or un-install:]
For the USER-INTEL package, you have 2 choices when building. You can
build with either CPU or KNL support. Each choice requires additional
settings in your Makefile.machine for CCFLAGS and LINKFLAGS and
optimized malloc libraries. See the
src/MAKE/OPTIONS/Makefile.intel_cpu and src/MAKE/OPTIONS/Makefile.knl
files for examples.
For CPUs:
OPTFLAGS = -xHost -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)
LIB = -ltbbmalloc -ltbbmalloc_proxy
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)
LIB = -ltbbmalloc
Once you have an appropriate Makefile.machine, you can
install/un-install the package and build LAMMPS in the usual manner.
Note that you cannot build one executable to run on multiple hardware
targets (Intel CPUs or KNL). You need to build LAMMPS once for each
hardware target, to produce a separate executable.
You should also typically install the USER-OMP package, as it can be
used in tandem with the USER-INTEL package to good effect, as
explained in "Section 5.3.2"_accelerate_intel.html.
make yes-user-intel yes-user-omp
make machine :pre
make no-user-intel no-user-omp
make machine :pre
[Supporting info:]
src/USER-INTEL: filenames -> commands
src/USER-INTEL/README
"Section 5.3"_Section_accelerate.html#acc_3
"Section 5.3.2"_accelerate_gpu.html
-"Section 2.7 -sf intel"_Section_start.html#start_7
-"Section 2.7 -pk intel"_Section_start.html#start_7
+"Section 2.6 -sf intel"_Section_start.html#start_6
+"Section 2.6 -pk intel"_Section_start.html#start_6
"package intel"_package.html
Styles sections of "Section 3.5"_Section_commands.html#cmd_5 for styles followed by (i)
src/USER-INTEL/TEST
"Benchmarks page"_http://lammps.sandia.gov/bench.html of web site :ul
:line
USER-LB package :link(USER-LB),h4
[Contents:]
Fixes which implement a background Lattice-Boltzmann (LB) fluid, which
can be used to model MD particles influenced by hydrodynamic forces.
[Authors:] Frances Mackay and Colin Denniston (University of Western
Ontario).
[Install or un-install:]
make yes-user-lb
make machine :pre
make no-user-lb
make machine :pre
[Supporting info:]
src/USER-LB: filenames -> commands
src/USER-LB/README
"fix lb/fluid"_fix_lb_fluid.html
"fix lb/momentum"_fix_lb_momentum.html
"fix lb/viscous"_fix_lb_viscous.html
examples/USER/lb :ul
:line
USER-MGPT package :link(USER-MGPT),h4
[Contents:]
A pair style which provides a fast implementation of the quantum-based
MGPT multi-ion potentials. The MGPT or model GPT method derives from
first-principles DFT-based generalized pseudopotential theory (GPT)
through a series of systematic approximations valid for mid-period
transition metals with nearly half-filled d bands. The MGPT method
was originally developed by John Moriarty at LLNL. The pair style in
this package calculates forces and energies using an optimized
matrix-MGPT algorithm due to Tomas Oppelstrup at LLNL.
[Authors:] Tomas Oppelstrup and John Moriarty (LLNL).
[Install or un-install:]
make yes-user-mgpt
make machine :pre
make no-user-mgpt
make machine :pre
[Supporting info:]
src/USER-MGPT: filenames -> commands
src/USER-MGPT/README
"pair_style mgpt"_pair_mgpt.html
examples/USER/mgpt :ul
:line
USER-MISC package :link(USER-MISC),h4
[Contents:]
A potpourri of (mostly) unrelated features contributed to LAMMPS by
users. Each feature is a single fix, compute, pair, bond, angle,
dihedral, improper, or command style.
[Authors:] The author for each style in the package is listed in the
src/USER-MISC/README file.
[Install or un-install:]
make yes-user-misc
make machine :pre
make no-user-misc
make machine :pre
[Supporting info:]
src/USER-MISC: filenames -> commands
src/USER-MISC/README
one doc page per individual command listed in src/USER-MISC/README
examples/USER/misc :ul
:line
USER-MANIFOLD package :link(USER-MANIFOLD),h4
[Contents:]
Several fixes and a "manifold" class which enable simulations of
particles constrained to a manifold (a 2D surface within the 3D
simulation box). This is done by applying the RATTLE constraint
algorithm to formulate single-particle constraint functions
g(xi,yi,zi) = 0 and their derivative (i.e. the normal of the manifold)
n = grad(g).
[Author:] Stefan Paquay (until 2017: Eindhoven University of Technology (TU/e), The
Netherlands; since 2017: Brandeis University, Waltham, MA, USA)
[Install or un-install:]
make yes-user-manifold
make machine :pre
make no-user-manifold
make machine :pre
[Supporting info:]
src/USER-MANIFOLD: filenames -> commands
src/USER-MANIFOLD/README
"doc/manifolds"_manifolds.html
"fix manifoldforce"_fix_manifoldforce.html
"fix nve/manifold/rattle"_fix_nve_manifold_rattle.html
"fix nvt/manifold/rattle"_fix_nvt_manifold_rattle.html
examples/USER/manifold
http://lammps.sandia.gov/movies.html#manifold :ul
:line
USER-MEAMC package :link(USER-MEAMC),h4
[Contents:]
A pair style for the modified embedded atom (MEAM) potential
translated from the Fortran version in the "MEAM"_MEAM package
to plain C++. In contrast to the MEAM package, no library
needs to be compiled and the pair style can be instantiated
multiple times.
[Author:] Sebastian Huetter, (Otto-von-Guericke University Magdeburg)
based on the Fortran version of Greg Wagner (Northwestern U) while at
Sandia.
[Install or un-install:]
make yes-user-meamc
make machine :pre
make no-user-meamc
make machine :pre
[Supporting info:]
src/USER-MEAMC: filenames -> commands
src/USER-MEAMC/README
"pair meam/c"_pair_meam.html
examples/meam :ul
:line
USER-MOLFILE package :link(USER-MOLFILE),h4
[Contents:]
A "dump molfile"_dump_molfile.html command which uses molfile plugins
that are bundled with the "VMD"_vmd_home
molecular visualization and analysis program, to enable LAMMPS to dump
snapshots in formats compatible with various molecular simulation
tools.
:link(vmd_home,http://www.ks.uiuc.edu/Research/vmd)
To use this package you must have the desired VMD plugins available on
your system.
Note that this package only provides the interface code, not the
plugins themselves, which will be accessed when requesting a specific
plugin via the "dump molfile"_dump_molfile.html command. Plugins can
be obtained from a VMD installation which has to match the platform
that you are using to compile LAMMPS for. By adding plugins to VMD,
support for new file formats can be added to LAMMPS (or VMD or other
programs that use them) without having to recompile the application
itself. More information about the VMD molfile plugins can be found
at
"http://www.ks.uiuc.edu/Research/vmd/plugins/molfile"_http://www.ks.uiuc.edu/Research/vmd/plugins/molfile.
[Author:] Axel Kohlmeyer (Temple U).
[Install or un-install:]
Note that the lib/molfile/Makefile.lammps file has a setting for a
dynamic loading library libdl.a that should is typically present on
all systems, which is required for LAMMPS to link with this package.
If the setting is not valid for your system, you will need to edit the
Makefile.lammps file. See lib/molfile/README and
lib/molfile/Makefile.lammps for details.
make yes-user-molfile
make machine :pre
make no-user-molfile
make machine :pre
[Supporting info:]
src/USER-MOLFILE: filenames -> commands
src/USER-MOLFILE/README
lib/molfile/README
"dump molfile"_dump_molfile.html :ul
:line
USER-NETCDF package :link(USER-NETCDF),h4
[Contents:]
Dump styles for writing NetCDF formatted dump files. NetCDF is a
portable, binary, self-describing file format developed on top of
HDF5. The file contents follow the AMBER NetCDF trajectory conventions
(http://ambermd.org/netcdf/nctraj.xhtml), but include extensions.
To use this package you must have the NetCDF library available on your
system.
Note that NetCDF files can be directly visualized with the following
tools:
"Ovito"_ovito (Ovito supports the AMBER convention and the extensions mentioned above)
"VMD"_vmd_home
"AtomEye"_atomeye (the libAtoms version of AtomEye contains a NetCDF reader not present in the standard distribution) :ul
:link(ovito,http://www.ovito.org)
:link(atomeye,http://www.libatoms.org)
[Author:] Lars Pastewka (Karlsruhe Institute of Technology).
[Install or un-install:]
Note that to follow these steps, you need the standard NetCDF software
package installed on your system. The lib/netcdf/Makefile.lammps file
has settings for NetCDF include and library files that LAMMPS needs to
compile and linkk with this package. If the settings are not valid
for your system, you will need to edit the Makefile.lammps file. See
lib/netcdf/README for details.
make yes-user-netcdf
make machine :pre
make no-user-netcdf
make machine :pre
[Supporting info:]
src/USER-NETCDF: filenames -> commands
src/USER-NETCDF/README
lib/netcdf/README
"dump netcdf"_dump_netcdf.html :ul
:line
USER-OMP package :link(USER-OMP),h4
[Contents:]
Hundreds of pair, fix, compute, bond, angle, dihedral, improper, and
kspace styles which are altered to enable threading on many-core CPUs
via OpenMP directives. All of them have an "omp" in their style name.
"Section 5.3.4"_accelerate_omp.html gives details of what hardware and
compilers are required on your system, and how to build and use this
package. Its styles can be invoked at run time via the "-sf omp" or
-"-suffix omp" "command-line switches"_Section_start.html#start_7.
+"-suffix omp" "command-line switches"_Section_start.html#start_6.
Also see the "KOKKOS"_#KOKKOS, "OPT"_#OPT, and
"USER-INTEL"_#USER-INTEL packages, which have styles optimized for
CPUs.
[Author:] Axel Kohlmeyer (Temple U).
NOTE: The compile flags "-restrict" and "-fopenmp" must be used to
build LAMMPS with the USER-OMP package, as well as the link flag
"-fopenmp". They should be added to the CCFLAGS and LINKFLAGS lines
of your Makefile.machine. See src/MAKE/OPTIONS/Makefile.omp for an
example.
Once you have an appropriate Makefile.machine, you can
install/un-install the package and build LAMMPS in the usual manner:
[Install or un-install:]
make yes-user-omp
make machine :pre
make no-user-omp
make machine :pre
CCFLAGS: add -fopenmp and -restrict
LINKFLAGS: add -fopenmp :ul
[Supporting info:]
src/USER-OMP: filenames -> commands
src/USER-OMP/README
"Section 5.3"_Section_accelerate.html#acc_3
"Section 5.3.4"_accelerate_omp.html
-"Section 2.7 -sf omp"_Section_start.html#start_7
-"Section 2.7 -pk omp"_Section_start.html#start_7
+"Section 2.6 -sf omp"_Section_start.html#start_6
+"Section 2.6 -pk omp"_Section_start.html#start_6
"package omp"_package.html
Styles sections of "Section 3.5"_Section_commands.html#cmd_5 for styles followed by (o)
"Benchmarks page"_http://lammps.sandia.gov/bench.html of web site :ul
:line
USER-PHONON package :link(USER-PHONON),h4
[Contents:]
A "fix phonon"_fix_phonon.html command that calculates dynamical
matrices, which can then be used to compute phonon dispersion
relations, directly from molecular dynamics simulations.
[Author:] Ling-Ti Kong (Shanghai Jiao Tong University).
[Install or un-install:]
make yes-user-phonon
make machine :pre
make no-user-phonon
make machine :pre
[Supporting info:]
src/USER-PHONON: filenames -> commands
src/USER-PHONON/README
"fix phonon"_fix_phonon.html
examples/USER/phonon :ul
:line
USER-QMMM package :link(USER-QMMM),h4
[Contents:]
A "fix qmmm"_fix_qmmm.html command which allows LAMMPS to be used in a
QM/MM simulation, currently only in combination with the "Quantum
ESPRESSO"_espresso package.
:link(espresso,http://www.quantum-espresso.org)
To use this package you must have Quantum ESPRESSO available on your
system.
The current implementation only supports an ONIOM style mechanical
coupling to the Quantum ESPRESSO plane wave DFT package.
Electrostatic coupling is in preparation and the interface has been
written in a manner that coupling to other QM codes should be possible
without changes to LAMMPS itself.
[Author:] Axel Kohlmeyer (Temple U).
[Install or un-install:]
Before building LAMMPS with this package, you must first build the
QMMM library in lib/qmmm. You can do this manually if you prefer;
follow the first two steps explained in lib/colvars/README. You can
also do it in one step from the lammps/src dir, using a command like
these, which simply invoke the lib/colvars/Install.py script with the
specified args:
make lib-qmmm # print help message
make lib-qmmm args="-m gfortran" # build with GNU Fortran compiler :pre
The build should produce two files: lib/qmmm/libqmmm.a and
lib/qmmm/Makefile.lammps. The latter is copied from an existing
Makefile.lammps.* and has settings needed to build LAMMPS with the
QMMM library (though typically the settings are just blank). If
necessary, you can edit/create a new lib/qmmm/Makefile.machine file
for your system, which should define an EXTRAMAKE variable to specify
a corresponding Makefile.lammps.machine file.
You can then install/un-install the package and build LAMMPS in the
usual manner:
make yes-user-qmmm
make machine :pre
make no-user-qmmm
make machine :pre
NOTE: The LAMMPS executable these steps produce is not yet functional
for a QM/MM simulation. You must also build Quantum ESPRESSO and
create a new executable which links LAMMPS and Quanutm ESPRESSO
together. These are steps 3 and 4 described in the lib/qmmm/README
file.
[Supporting info:]
src/USER-QMMM: filenames -> commands
src/USER-QMMM/README
lib/qmmm/README
"fix phonon"_fix_phonon.html
lib/qmmm/example-ec/README
lib/qmmm/example-mc/README :ul
:line
USER-QTB package :link(USER-QTB),h4
[Contents:]
Two fixes which provide a self-consistent quantum treatment of
vibrational modes in a classical molecular dynamics simulation. By
coupling the MD simulation to a colored thermostat, it introduces zero
point energy into the system, altering the energy power spectrum and
the heat capacity to account for their quantum nature. This is useful
when modeling systems at temperatures lower than their classical
limits or when temperatures ramp across the classical limits in a
simulation.
[Author:] Yuan Shen (Stanford U).
[Install or un-install:]
make yes-user-qtb
make machine :pre
make no-user-qtb
make machine :pre
[Supporting info:]
src/USER-QTB: filenames -> commands
src/USER-QTB/README
"fix qtb"_fix_qtb.html
"fix qbmsst"_fix_qbmsst.html
examples/USER/qtb :ul
:line
USER-QUIP package :link(USER-QUIP),h4
[Contents:]
A "pair_style quip"_pair_quip.html command which wraps the "QUIP
libAtoms library"_quip, which includes a variety of interatomic
potentials, including Gaussian Approximation Potential (GAP) models
developed by the Cambridge University group.
:link(quip,https://github.com/libAtoms/QUIP)
To use this package you must have the QUIP libAatoms library available
on your system.
[Author:] Albert Bartok (Cambridge University)
[Install or un-install:]
Note that to follow these steps to compile and link to the QUIP
library, you must first download and build QUIP on your systems. It
can be obtained from GitHub. See step 1 and step 1.1 in the
lib/quip/README file for details on how to do this. Note that it
requires setting two environment variables, QUIP_ROOT and QUIP_ARCH,
which will be accessed by the lib/quip/Makefile.lammps file which is
used when you compile and link LAMMPS with this package. You should
only need to edit this file if the LAMMPS build can not use its
settings to successfully build on your system.
You can then install/un-install the package and build LAMMPS in the
usual manner:
make yes-user-quip
make machine :pre
make no-user-quip
make machine :pre
[Supporting info:]
src/USER-QUIP: filenames -> commands
src/USER-QUIP/README
"pair_style quip"_pair_quip.html
examples/USER/quip :ul
:line
USER-REAXC package :link(USER-REAXC),h4
[Contents:]
A pair style which implements the ReaxFF potential in C/C++ (in
contrast to the "REAX package"_#REAX and its Fortran library). ReaxFF
is universal reactive force field. See the src/USER-REAXC/README file
for more info on differences between the two packages. Also two fixes
for monitoring molecules as bonds are created and destroyed.
[Author:] Hasan Metin Aktulga (MSU) while at Purdue University.
[Install or un-install:]
make yes-user-reaxc
make machine :pre
make no-user-reaxc
make machine :pre
[Supporting info:]
src/USER-REAXC: filenames -> commands
src/USER-REAXC/README
"pair_style reax/c"_pair_reaxc.html
"fix reax/c/bonds"_fix_reax_bonds.html
"fix reax/c/species"_fix_reaxc_species.html
examples/reax :ul
:line
USER-SMD package :link(USER-SMD),h4
[Contents:]
An atom style, fixes, computes, and several pair styles which
implements smoothed Mach dynamics (SMD) for solids, which is a model
related to smoothed particle hydrodynamics (SPH) for liquids (see the
"USER-SPH package"_#USER-SPH).
This package solves solids mechanics problems via a state of the art
stabilized meshless method with hourglass control. It can specify
hydrostatic interactions independently from material strength models,
i.e. pressure and deviatoric stresses are separated. It provides many
material models (Johnson-Cook, plasticity with hardening,
Mie-Grueneisen, Polynomial EOS) and allows new material models to be
added. It implements rigid boundary conditions (walls) which can be
specified as surface geometries from *.STL files.
[Author:] Georg Ganzenmuller (Fraunhofer-Institute for High-Speed
Dynamics, Ernst Mach Institute, Germany).
[Install or un-install:]
Before building LAMMPS with this package, you must first download the
Eigen library. Eigen is a template library, so you do not need to
build it, just download it. You can do this manually if you prefer;
follow the instructions in lib/smd/README. You can also do it in one
step from the lammps/src dir, using a command like these, which simply
invoke the lib/smd/Install.py script with the specified args:
make lib-smd # print help message
make lib-smd args="-g -l" # download in default lib/smd/eigen-eigen-*
make lib-smd args="-h . eigen -g -l" # download in lib/smd/eigen
make lib-smd args="-h ~ eigen -g -l" # download and build in ~/eigen :pre
Note that the final -l switch is to create a symbolic (soft) link
named "includelink" in lib/smd to point to the Eigen dir. When LAMMPS
builds it will use this link. You should not need to edit the
lib/smd/Makefile.lammps file.
You can then install/un-install the package and build LAMMPS in the
usual manner:
make yes-user-smd
make machine :pre
make no-user-smd
make machine :pre
[Supporting info:]
src/USER-SMD: filenames -> commands
src/USER-SMD/README
doc/PDF/SMD_LAMMPS_userguide.pdf
examples/USER/smd
http://lammps.sandia.gov/movies.html#smd :ul
:line
USER-SMTBQ package :link(USER-SMTBQ),h4
[Contents:]
A pair style which implements a Second Moment Tight Binding model with
QEq charge equilibration (SMTBQ) potential for the description of
ionocovalent bonds in oxides.
[Authors:] Nicolas Salles, Emile Maras, Olivier Politano, and Robert
Tetot (LAAS-CNRS, France).
[Install or un-install:]
make yes-user-smtbq
make machine :pre
make no-user-smtbq
make machine :pre
[Supporting info:]
src/USER-SMTBQ: filenames -> commands
src/USER-SMTBQ/README
"pair_style smtbq"_pair_smtbq.html
examples/USER/smtbq :ul
:line
USER-SPH package :link(USER-SPH),h4
[Contents:]
An atom style, fixes, computes, and several pair styles which
implements smoothed particle hydrodynamics (SPH) for liquids. See the
related "USER-SMD package"_#USER-SMD package for smooth Mach dynamics
(SMD) for solids.
This package contains ideal gas, Lennard-Jones equation of states,
Tait, and full support for complete (i.e. internal-energy dependent)
equations of state. It allows for plain or Monaghans XSPH integration
of the equations of motion. It has options for density continuity or
density summation to propagate the density field. It has
"set"_set.html command options to set the internal energy and density
of particles from the input script and allows the same quantities to
be output with thermodynamic output or to dump files via the "compute
property/atom"_compute_property_atom.html command.
[Author:] Georg Ganzenmuller (Fraunhofer-Institute for High-Speed
Dynamics, Ernst Mach Institute, Germany).
[Install or un-install:]
make yes-user-sph
make machine :pre
make no-user-sph
make machine :pre
[Supporting info:]
src/USER-SPH: filenames -> commands
src/USER-SPH/README
doc/PDF/SPH_LAMMPS_userguide.pdf
examples/USER/sph
http://lammps.sandia.gov/movies.html#sph :ul
:line
USER-TALLY package :link(USER-TALLY),h4
[Contents:]
Several compute styles that can be called when pairwise interactions
are calculated to tally information (forces, heat flux, energy,
stress, etc) about individual interactions.
[Author:] Axel Kohlmeyer (Temple U).
[Install or un-install:]
make yes-user-tally
make machine :pre
make no-user-tally
make machine :pre
[Supporting info:]
src/USER-TALLY: filenames -> commands
src/USER-TALLY/README
"compute */tally"_compute_tally.html
examples/USER/tally :ul
:line
USER-VTK package :link(USER-VTK),h4
[Contents:]
A "dump vtk"_dump_vtk.html command which outputs
snapshot info in the "VTK format"_vtk, enabling visualization by
"Paraview"_paraview or other visuzlization packages.
:link(vtk,http://www.vtk.org)
:link(paraview,http://www.paraview.org)
To use this package you must have VTK library available on your
system.
[Authors:] Richard Berger (JKU) and Daniel Queteschiner (DCS Computing).
[Install or un-install:]
The lib/vtk/Makefile.lammps file has settings for accessing VTK files
and its library, which are required for LAMMPS to build and link with
this package. If the settings are not valid for your system, check if
one of the other lib/vtk/Makefile.lammps.* files is compatible and
copy it to Makefile.lammps. If none of the provided files work, you
will need to edit the Makefile.lammps file.
You can then install/un-install the package and build LAMMPS in the
usual manner:
make yes-user-vtk
make machine :pre
make no-user-vtk
make machine :pre
[Supporting info:]
src/USER-VTK: filenames -> commands
src/USER-VTK/README
lib/vtk/README
"dump vtk"_dump_vtk.html :ul
diff --git a/doc/src/Section_python.txt b/doc/src/Section_python.txt
index 1e67fca32..f4b6bdad9 100644
--- a/doc/src/Section_python.txt
+++ b/doc/src/Section_python.txt
@@ -1,866 +1,866 @@
"Previous Section"_Section_modify.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_errors.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
11. Python interface to LAMMPS :h3
LAMMPS can work together with Python in three ways. First, Python can
wrap LAMMPS through the "LAMMPS library
interface"_Section_howto.html#howto_19, so that a Python script can
create one or more instances of LAMMPS and launch one or more
simulations. In Python lingo, this is "extending" Python with LAMMPS.
Second, the low-level Python interface can be used indirectly through the
PyLammps and IPyLammps wrapper classes in Python. These wrappers try to
simplify the usage of LAMMPS in Python by providing an object-based interface
to common LAMMPS functionality. It also reduces the amount of code necessary to
parameterize LAMMPS scripts through Python and makes variables and computes
directly accessible. See "PyLammps interface"_#py_9 for more details.
Third, LAMMPS can use the Python interpreter, so that a LAMMPS input
script can invoke Python code, and pass information back-and-forth
between the input script and Python functions you write. The Python
code can also callback to LAMMPS to query or change its attributes.
In Python lingo, this is "embedding" Python in LAMMPS.
This section describes how to use these three approaches.
11.1 "Overview of running LAMMPS from Python"_#py_1
11.2 "Overview of using Python from a LAMMPS script"_#py_2
11.3 "Building LAMMPS as a shared library"_#py_3
11.4 "Installing the Python wrapper into Python"_#py_4
11.5 "Extending Python with MPI to run in parallel"_#py_5
11.6 "Testing the Python-LAMMPS interface"_#py_6
11.7 "Using LAMMPS from Python"_#py_7
11.8 "Example Python scripts that use LAMMPS"_#py_8
11.9 "PyLammps interface"_#py_9 :ul
If you are not familiar with it, "Python"_http://www.python.org is a
powerful scripting and programming language which can essentially do
anything that faster, lower-level languages like C or C++ can do, but
typically with much fewer lines of code. When used in embedded mode,
Python can perform operations that the simplistic LAMMPS input script
syntax cannot. Python can be also be used as a "glue" language to
drive a program through its library interface, or to hook multiple
pieces of software together, such as a simulation package plus a
visualization package, or to run a coupled multiscale or multiphysics
model.
See "Section 6.10"_Section_howto.html#howto_10 of the manual and
the couple directory of the distribution for more ideas about coupling
LAMMPS to other codes. See "Section
6.19"_Section_howto.html#howto_19 for a description of the LAMMPS
library interface provided in src/library.cpp and src/library.h, and
how to extend it for your needs. As described below, that interface
is what is exposed to Python either when calling LAMMPS from Python or
when calling Python from a LAMMPS input script and then calling back
to LAMMPS from Python code. The library interface is designed to be
easy to add functions to. Thus the Python interface to LAMMPS is also
easy to extend as well.
If you create interesting Python scripts that run LAMMPS or
interesting Python functions that can be called from a LAMMPS input
script, that you think would be useful to other users, please "email
them to the developers"_http://lammps.sandia.gov/authors.html. We can
include them in the LAMMPS distribution.
:line
:line
11.1 Overview of running LAMMPS from Python :link(py_1),h4
The LAMMPS distribution includes a python directory with all you need
to run LAMMPS from Python. The python/lammps.py file wraps the LAMMPS
library interface, with one wrapper function per LAMMPS library
function. This file makes it is possible to do the following either
from a Python script, or interactively from a Python prompt: create
one or more instances of LAMMPS, invoke LAMMPS commands or give it an
input script, run LAMMPS incrementally, extract LAMMPS results, an
modify internal LAMMPS variables. From a Python script you can do
this in serial or parallel. Running Python interactively in parallel
does not generally work, unless you have a version of Python that
extends standard Python to enable multiple instances of Python to read
what you type.
To do all of this, you must first build LAMMPS as a shared library,
then insure that your Python can find the python/lammps.py file and
the shared library. These steps are explained in subsequent sections
11.3 and 11.4. Sections 11.5 and 11.6 discuss using MPI from a
parallel Python program and how to test that you are ready to use
LAMMPS from Python. Section 11.7 lists all the functions in the
current LAMMPS library interface and how to call them from Python.
Section 11.8 gives some examples of coupling LAMMPS to other tools via
Python. For example, LAMMPS can easily be coupled to a GUI or other
visualization tools that display graphs or animations in real time as
LAMMPS runs. Examples of such scripts are included in the python
directory.
Two advantages of using Python to run LAMMPS are how concise the
language is, and that it can be run interactively, enabling rapid
development and debugging of programs. If you use it to mostly invoke
costly operations within LAMMPS, such as running a simulation for a
reasonable number of timesteps, then the overhead cost of invoking
LAMMPS thru Python will be negligible.
The Python wrapper for LAMMPS uses the amazing and magical (to me)
"ctypes" package in Python, which auto-generates the interface code
needed between Python and a set of C interface routines for a library.
Ctypes is part of standard Python for versions 2.5 and later. You can
check which version of Python you have installed, by simply typing
"python" at a shell prompt.
:line
11.2 Overview of using Python from a LAMMPS script :link(py_2),h4
LAMMPS has several commands which can be used to invoke Python
code directly from an input script:
"python"_python.html
"variable python"_variable.html
"fix python"_fix_python.html
"pair_style python"_pair_python.html :ul
The "python"_python.html command which can be used to define and
execute a Python function that you write the code for. The Python
function can also be assigned to a LAMMPS python-style variable via
the "variable"_variable.html command. Each time the variable is
evaluated, either in the LAMMPS input script itself, or by another
LAMMPS command that uses the variable, this will trigger the Python
function to be invoked.
The Python code for the function can be included directly in the input
script or in an auxiliary file. The function can have arguments which
are mapped to LAMMPS variables (also defined in the input script) and
it can return a value to a LAMMPS variable. This is thus a mechanism
for your input script to pass information to a piece of Python code,
ask Python to execute the code, and return information to your input
script.
Note that a Python function can be arbitrarily complex. It can import
other Python modules, instantiate Python classes, call other Python
functions, etc. The Python code that you provide can contain more
code than the single function. It can contain other functions or
Python classes, as well as global variables or other mechanisms for
storing state between calls from LAMMPS to the function.
The Python function you provide can consist of "pure" Python code that
only performs operations provided by standard Python. However, the
Python function can also "call back" to LAMMPS through its
Python-wrapped library interface, in the manner described in the
previous section 11.1. This means it can issue LAMMPS input script
commands or query and set internal LAMMPS state. As an example, this
can be useful in an input script to create a more complex loop with
branching logic, than can be created using the simple looping and
branching logic enabled by the "next"_next.html and "if"_if.html
commands.
See the "python"_python.html doc page and the "variable"_variable.html
doc page for its python-style variables for more info, including
examples of Python code you can write for both pure Python operations
and callbacks to LAMMPS.
The "fix python"_fix_python.html command can execute
Python code at selected timesteps during a simulation run.
The "pair_style python"_pair_python command allows you to define
pairwise potentials as python code which encodes a single pairwise
interaction. This is useful for rapid-developement and debugging of a
new potential.
To use any of these commands, you only need to build LAMMPS with the
PYTHON package installed:
make yes-python
make machine :pre
Note that this will link LAMMPS with the Python library on your
system, which typically requires several auxiliary system libraries to
also be linked. The list of these libraries and the paths to find
them are specified in the lib/python/Makefile.lammps file. You need
to insure that file contains the correct information for your version
of Python and your machine to successfully build LAMMPS. See the
lib/python/README file for more info.
If you want to write Python code with callbacks to LAMMPS, then you
must also follow the steps overviewed in the preceding section (11.1)
for running LAMMPS from Python. I.e. you must build LAMMPS as a
shared library and insure that Python can find the python/lammps.py
file and the shared library.
:line
11.3 Building LAMMPS as a shared library :link(py_3),h4
Instructions on how to build LAMMPS as a shared library are given in
-"Section 2.5"_Section_start.html#start_5. A shared library is one
+"Section 2.4"_Section_start.html#start_4. A shared library is one
that is dynamically loadable, which is what Python requires to wrap
LAMMPS. On Linux this is a library file that ends in ".so", not ".a".
From the src directory, type
make foo mode=shlib :pre
where foo is the machine target name, such as linux or g++ or serial.
This should create the file liblammps_foo.so in the src directory, as
well as a soft link liblammps.so, which is what the Python wrapper will
load by default. Note that if you are building multiple machine
versions of the shared library, the soft link is always set to the
most recently built version.
NOTE: If you are building LAMMPS with an MPI or FFT library or other
auxiliary libraries (used by various packages), then all of these
extra libraries must also be shared libraries. If the LAMMPS
shared-library build fails with an error complaining about this, see
-"Section 2.5"_Section_start.html#start_5 for more details.
+"Section 2.4"_Section_start.html#start_4 for more details.
:line
11.4 Installing the Python wrapper into Python :link(py_4),h4
For Python to invoke LAMMPS, there are 2 files it needs to know about:
python/lammps.py
src/liblammps.so :ul
Lammps.py is the Python wrapper on the LAMMPS library interface.
Liblammps.so is the shared LAMMPS library that Python loads, as
described above.
You can insure Python can find these files in one of two ways:
set two environment variables
run the python/install.py script :ul
If you set the paths to these files as environment variables, you only
have to do it once. For the csh or tcsh shells, add something like
this to your ~/.cshrc file, one line for each of the two files:
setenv PYTHONPATH $\{PYTHONPATH\}:/home/sjplimp/lammps/python
setenv LD_LIBRARY_PATH $\{LD_LIBRARY_PATH\}:/home/sjplimp/lammps/src :pre
If you use the python/install.py script, you need to invoke it every
time you rebuild LAMMPS (as a shared library) or make changes to the
python/lammps.py file.
You can invoke install.py from the python directory as
% python install.py \[libdir\] \[pydir\] :pre
The optional libdir is where to copy the LAMMPS shared library to; the
default is /usr/local/lib. The optional pydir is where to copy the
lammps.py file to; the default is the site-packages directory of the
version of Python that is running the install script.
Note that libdir must be a location that is in your default
LD_LIBRARY_PATH, like /usr/local/lib or /usr/lib. And pydir must be a
location that Python looks in by default for imported modules, like
its site-packages dir. If you want to copy these files to
non-standard locations, such as within your own user space, you will
need to set your PYTHONPATH and LD_LIBRARY_PATH environment variables
accordingly, as above.
If the install.py script does not allow you to copy files into system
directories, prefix the python command with "sudo". If you do this,
make sure that the Python that root runs is the same as the Python you
run. E.g. you may need to do something like
% sudo /usr/local/bin/python install.py \[libdir\] \[pydir\] :pre
You can also invoke install.py from the make command in the src
directory as
% make install-python :pre
In this mode you cannot append optional arguments. Again, you may
need to prefix this with "sudo". In this mode you cannot control
which Python is invoked by root.
Note that if you want Python to be able to load different versions of
the LAMMPS shared library (see "this section"_#py_5 below), you will
need to manually copy files like liblammps_g++.so into the appropriate
system directory. This is not needed if you set the LD_LIBRARY_PATH
environment variable as described above.
:line
11.5 Extending Python with MPI to run in parallel :link(py_5),h4
If you wish to run LAMMPS in parallel from Python, you need to extend
your Python with an interface to MPI. This also allows you to
make MPI calls directly from Python in your script, if you desire.
There are several Python packages available that purport to wrap MPI
as a library and allow MPI functions to be called from Python. However,
development on most of them seems to be halted except on:
"mpi4py"_https://bitbucket.org/mpi4py/mpi4py
"PyPar"_https://github.com/daleroberts/pypar :ul
Both packages, PyPar and mpi4py have been successfully tested with
LAMMPS. PyPar is simpler and easy to set up and use, but supports
only a subset of MPI. Mpi4py is more MPI-feature complete, but also a
bit more complex to use. As of version 2.0.0, mpi4py is the only
python MPI wrapper that allows passing a custom MPI communicator to
the LAMMPS constructor, which means one can easily run one or more
LAMMPS instances on subsets of the total MPI ranks.
:line
PyPar requires the ubiquitous "Numpy package"_http://numpy.scipy.org
be installed in your Python. After launching Python, type
import numpy :pre
to see if it is installed. If not, here is how to install it (version
1.3.0b1 as of April 2009). Unpack the numpy tarball and from its
top-level directory, type
python setup.py build
sudo python setup.py install :pre
The "sudo" is only needed if required to copy Numpy files into your
Python distribution's site-packages directory.
To install PyPar (version pypar-2.1.4_94 as of Aug 2012), unpack it
and from its "source" directory, type
python setup.py build
sudo python setup.py install :pre
Again, the "sudo" is only needed if required to copy PyPar files into
your Python distribution's site-packages directory.
If you have successfully installed PyPar, you should be able to run
Python and type
import pypar :pre
without error. You should also be able to run python in parallel
on a simple test script
% mpirun -np 4 python test.py :pre
where test.py contains the lines
import pypar
print "Proc %d out of %d procs" % (pypar.rank(),pypar.size()) :pre
and see one line of output for each processor you run on.
NOTE: To use PyPar and LAMMPS in parallel from Python, you must insure
both are using the same version of MPI. If you only have one MPI
installed on your system, this is not an issue, but it can be if you
have multiple MPIs. Your LAMMPS build is explicit about which MPI it
is using, since you specify the details in your lo-level
src/MAKE/Makefile.foo file. PyPar uses the "mpicc" command to find
information about the MPI it uses to build against. And it tries to
load "libmpi.so" from the LD_LIBRARY_PATH. This may or may not find
the MPI library that LAMMPS is using. If you have problems running
both PyPar and LAMMPS together, this is an issue you may need to
address, e.g. by moving other MPI installations so that PyPar finds
the right one.
:line
To install mpi4py (version mpi4py-2.0.0 as of Oct 2015), unpack it
and from its main directory, type
python setup.py build
sudo python setup.py install :pre
Again, the "sudo" is only needed if required to copy mpi4py files into
your Python distribution's site-packages directory. To install with
user privilege into the user local directory type
python setup.py install --user :pre
If you have successfully installed mpi4py, you should be able to run
Python and type
from mpi4py import MPI :pre
without error. You should also be able to run python in parallel
on a simple test script
% mpirun -np 4 python test.py :pre
where test.py contains the lines
from mpi4py import MPI
comm = MPI.COMM_WORLD
print "Proc %d out of %d procs" % (comm.Get_rank(),comm.Get_size()) :pre
and see one line of output for each processor you run on.
NOTE: To use mpi4py and LAMMPS in parallel from Python, you must
insure both are using the same version of MPI. If you only have one
MPI installed on your system, this is not an issue, but it can be if
you have multiple MPIs. Your LAMMPS build is explicit about which MPI
it is using, since you specify the details in your lo-level
src/MAKE/Makefile.foo file. Mpi4py uses the "mpicc" command to find
information about the MPI it uses to build against. And it tries to
load "libmpi.so" from the LD_LIBRARY_PATH. This may or may not find
the MPI library that LAMMPS is using. If you have problems running
both mpi4py and LAMMPS together, this is an issue you may need to
address, e.g. by moving other MPI installations so that mpi4py finds
the right one.
:line
11.6 Testing the Python-LAMMPS interface :link(py_6),h4
To test if LAMMPS is callable from Python, launch Python interactively
and type:
>>> from lammps import lammps
>>> lmp = lammps() :pre
If you get no errors, you're ready to use LAMMPS from Python. If the
2nd command fails, the most common error to see is
OSError: Could not load LAMMPS dynamic library :pre
which means Python was unable to load the LAMMPS shared library. This
typically occurs if the system can't find the LAMMPS shared library or
one of the auxiliary shared libraries it depends on, or if something
about the library is incompatible with your Python. The error message
should give you an indication of what went wrong.
You can also test the load directly in Python as follows, without
first importing from the lammps.py file:
>>> from ctypes import CDLL
>>> CDLL("liblammps.so") :pre
If an error occurs, carefully go thru the steps in "Section
-2.5"_Section_start.html#start_5 and above about building a shared
+2.4"_Section_start.html#start_4 and above about building a shared
library and about insuring Python can find the necessary two files
it needs.
[Test LAMMPS and Python in serial:] :h5
To run a LAMMPS test in serial, type these lines into Python
interactively from the bench directory:
>>> from lammps import lammps
>>> lmp = lammps()
>>> lmp.file("in.lj") :pre
Or put the same lines in the file test.py and run it as
% python test.py :pre
Either way, you should see the results of running the in.lj benchmark
on a single processor appear on the screen, the same as if you had
typed something like:
lmp_g++ -in in.lj :pre
[Test LAMMPS and Python in parallel:] :h5
To run LAMMPS in parallel, assuming you have installed the
"PyPar"_https://github.com/daleroberts/pypar package as discussed
above, create a test.py file containing these lines:
import pypar
from lammps import lammps
lmp = lammps()
lmp.file("in.lj")
print "Proc %d out of %d procs has" % (pypar.rank(),pypar.size()),lmp
pypar.finalize() :pre
To run LAMMPS in parallel, assuming you have installed the
"mpi4py"_https://bitbucket.org/mpi4py/mpi4py package as discussed
above, create a test.py file containing these lines:
from mpi4py import MPI
from lammps import lammps
lmp = lammps()
lmp.file("in.lj")
me = MPI.COMM_WORLD.Get_rank()
nprocs = MPI.COMM_WORLD.Get_size()
print "Proc %d out of %d procs has" % (me,nprocs),lmp
MPI.Finalize() :pre
You can either script in parallel as:
% mpirun -np 4 python test.py :pre
and you should see the same output as if you had typed
% mpirun -np 4 lmp_g++ -in in.lj :pre
Note that if you leave out the 3 lines from test.py that specify PyPar
commands you will instantiate and run LAMMPS independently on each of
the P processors specified in the mpirun command. In this case you
should get 4 sets of output, each showing that a LAMMPS run was made
on a single processor, instead of one set of output showing that
LAMMPS ran on 4 processors. If the 1-processor outputs occur, it
means that PyPar is not working correctly.
Also note that once you import the PyPar module, PyPar initializes MPI
for you, and you can use MPI calls directly in your Python script, as
described in the PyPar documentation. The last line of your Python
script should be pypar.finalize(), to insure MPI is shut down
correctly.
[Running Python scripts:] :h5
Note that any Python script (not just for LAMMPS) can be invoked in
one of several ways:
% python foo.script
% python -i foo.script
% foo.script :pre
The last command requires that the first line of the script be
something like this:
#!/usr/local/bin/python
#!/usr/local/bin/python -i :pre
where the path points to where you have Python installed, and that you
have made the script file executable:
% chmod +x foo.script :pre
Without the "-i" flag, Python will exit when the script finishes.
With the "-i" flag, you will be left in the Python interpreter when
the script finishes, so you can type subsequent commands. As
mentioned above, you can only run Python interactively when running
Python on a single processor, not in parallel.
:line
:line
11.7 Using LAMMPS from Python :link(py_7),h4
As described above, the Python interface to LAMMPS consists of a
Python "lammps" module, the source code for which is in
python/lammps.py, which creates a "lammps" object, with a set of
methods that can be invoked on that object. The sample Python code
below assumes you have first imported the "lammps" module in your
Python script, as follows:
from lammps import lammps :pre
These are the methods defined by the lammps module. If you look at
the files src/library.cpp and src/library.h you will see that they
correspond one-to-one with calls you can make to the LAMMPS library
from a C++ or C or Fortran program, and which are described in
"Section 6.19"_Section_howto.html#howto_19 of the manual.
lmp = lammps() # create a LAMMPS object using the default liblammps.so library
# 4 optional args are allowed: name, cmdargs, ptr, comm
lmp = lammps(ptr=lmpptr) # use lmpptr as previously created LAMMPS object
lmp = lammps(comm=split) # create a LAMMPS object with a custom communicator, requires mpi4py 2.0.0 or later
lmp = lammps(name="g++") # create a LAMMPS object using the liblammps_g++.so library
lmp = lammps(name="g++",cmdargs=list) # add LAMMPS command-line args, e.g. list = \["-echo","screen"\] :pre
lmp.close() # destroy a LAMMPS object :pre
version = lmp.version() # return the numerical version id, e.g. LAMMPS 2 Sep 2015 -> 20150902
lmp.file(file) # run an entire input script, file = "in.lj"
lmp.command(cmd) # invoke a single LAMMPS command, cmd = "run 100" :pre
lmp.commands_list(cmdlist) # invoke commands in cmdlist = ["run 10", "run 20"]
lmp.commands_string(multicmd) # invoke commands in multicmd = "run 10\nrun 20"
xlo = lmp.extract_global(name,type) # extract a global quantity
# name = "boxxlo", "nlocal", etc
# type = 0 = int
# 1 = double :pre
coords = lmp.extract_atom(name,type) # extract a per-atom quantity
# name = "x", "type", etc
# type = 0 = vector of ints
# 1 = array of ints
# 2 = vector of doubles
# 3 = array of doubles :pre
eng = lmp.extract_compute(id,style,type) # extract value(s) from a compute
v3 = lmp.extract_fix(id,style,type,i,j) # extract value(s) from a fix
# id = ID of compute or fix
# style = 0 = global data
# 1 = per-atom data
# 2 = local data
# type = 0 = scalar
# 1 = vector
# 2 = array
# i,j = indices of value in global vector or array :pre
var = lmp.extract_variable(name,group,flag) # extract value(s) from a variable
# name = name of variable
# group = group ID (ignored for equal-style variables)
# flag = 0 = equal-style variable
# 1 = atom-style variable :pre
flag = lmp.set_variable(name,value) # set existing named string-style variable to value, flag = 0 if successful
value = lmp.get_thermo(name) # return current value of a thermo keyword
natoms = lmp.get_natoms() # total # of atoms as int
data = lmp.gather_atoms(name,type,count) # return per-atom property of all atoms gathered into data, ordered by atom ID
# name = "x", "charge", "type", etc
# count = # of per-atom values, 1 or 3, etc
lmp.scatter_atoms(name,type,count,data) # scatter per-atom property to all atoms from data, ordered by atom ID
# name = "x", "charge", "type", etc
# count = # of per-atom values, 1 or 3, etc :pre
:line
The lines
from lammps import lammps
lmp = lammps() :pre
create an instance of LAMMPS, wrapped in a Python class by the lammps
Python module, and return an instance of the Python class as lmp. It
is used to make all subsequent calls to the LAMMPS library.
Additional arguments to lammps() can be used to tell Python the name
of the shared library to load or to pass arguments to the LAMMPS
instance, the same as if LAMMPS were launched from a command-line
prompt.
If the ptr argument is set like this:
lmp = lammps(ptr=lmpptr) :pre
then lmpptr must be an argument passed to Python via the LAMMPS
"python"_python.html command, when it is used to define a Python
function that is invoked by the LAMMPS input script. This mode of
using Python with LAMMPS is described above in 11.2. The variable
lmpptr refers to the instance of LAMMPS that called the embedded
Python interpreter. Using it as an argument to lammps() allows the
returned Python class instance "lmp" to make calls to that instance of
LAMMPS. See the "python"_python.html command doc page for examples
using this syntax.
Note that you can create multiple LAMMPS objects in your Python
script, and coordinate and run multiple simulations, e.g.
from lammps import lammps
lmp1 = lammps()
lmp2 = lammps()
lmp1.file("in.file1")
lmp2.file("in.file2") :pre
The file(), command(), commands_list(), commands_string() methods
allow an input script, a single command, or multiple commands to be
invoked.
The extract_global(), extract_atom(), extract_compute(),
extract_fix(), and extract_variable() methods return values or
pointers to data structures internal to LAMMPS.
For extract_global() see the src/library.cpp file for the list of
valid names. New names could easily be added. A double or integer is
returned. You need to specify the appropriate data type via the type
argument.
For extract_atom(), a pointer to internal LAMMPS atom-based data is
returned, which you can use via normal Python subscripting. See the
extract() method in the src/atom.cpp file for a list of valid names.
Again, new names could easily be added if the property you want is not
listed. A pointer to a vector of doubles or integers, or a pointer to
an array of doubles (double **) or integers (int **) is returned. You
need to specify the appropriate data type via the type argument.
For extract_compute() and extract_fix(), the global, per-atom, or
local data calculated by the compute or fix can be accessed. What is
returned depends on whether the compute or fix calculates a scalar or
vector or array. For a scalar, a single double value is returned. If
the compute or fix calculates a vector or array, a pointer to the
internal LAMMPS data is returned, which you can use via normal Python
subscripting. The one exception is that for a fix that calculates a
global vector or array, a single double value from the vector or array
is returned, indexed by I (vector) or I and J (array). I,J are
zero-based indices. The I,J arguments can be left out if not needed.
See "Section 6.15"_Section_howto.html#howto_15 of the manual for a
discussion of global, per-atom, and local data, and of scalar, vector,
and array data types. See the doc pages for individual
"computes"_compute.html and "fixes"_fix.html for a description of what
they calculate and store.
For extract_variable(), an "equal-style or atom-style
variable"_variable.html is evaluated and its result returned.
For equal-style variables a single double value is returned and the
group argument is ignored. For atom-style variables, a vector of
doubles is returned, one value per atom, which you can use via normal
Python subscripting. The values will be zero for atoms not in the
specified group.
The get_natoms() method returns the total number of atoms in the
simulation, as an int.
The gather_atoms() method allows any per-atom property (coordinates,
velocities, etc) to be extracted from LAMMPS. It returns a ctypes
vector of ints or doubles as specified by type, of length
count*natoms, for the named property for all atoms in the simulation.
The data is ordered by count and then by atom ID. See the extract()
method in the src/atom.cpp file for a list of valid names. Again, new
names could easily be added if the property you want is missing. The
vector can be used via normal Python subscripting. If atom IDs are
not consecutively ordered within LAMMPS, a None is returned as
indication of an error. A special treatment is applied for image flags
stored in the "image" property. All three image flags are stored in
a packed format in a single integer, so count would be 1 to retrieve
that integer, however also a count value of 3 can be used and then
the image flags will be unpacked into 3 individual integers, ordered
in a similar fashion as coordinates.
Note that the data structure gather_atoms("x") returns is different
from the data structure returned by extract_atom("x") in four ways.
(1) Gather_atoms() returns a vector which you index as x\[i\];
extract_atom() returns an array which you index as x\[i\]\[j\]. (2)
Gather_atoms() orders the atoms by atom ID while extract_atom() does
not. (3) Gathert_atoms() returns a list of all atoms in the
simulation; extract_atoms() returns just the atoms local to each
processor. (4) Finally, the gather_atoms() data structure is a copy
of the atom coords stored internally in LAMMPS, whereas extract_atom()
returns an array that effectively points directly to the internal
data. This means you can change values inside LAMMPS from Python by
assigning a new values to the extract_atom() array. To do this with
the gather_atoms() vector, you need to change values in the vector,
then invoke the scatter_atoms() method.
The scatter_atoms() method allows any per-atom property (coordinates,
velocities, etc) to be inserted into LAMMPS, overwriting the current
property. It takes a vector of ints or doubles as specified by type,
of length count*natoms, for the named property for all atoms in the
simulation. The data should be ordered by count and then by atom ID.
See the extract() method in the src/atom.cpp file for a list of valid
names. Again, new names could easily be added if the property you
want is missing. It uses the vector of data to overwrite the
corresponding properties for each atom inside LAMMPS. This requires
LAMMPS to have its "map" option enabled; see the
"atom_modify"_atom_modify.html command for details. If it is not, or
if atom IDs are not consecutively ordered, no coordinates are reset.
Similar as for gather_atoms() a special treatment is applied for image
flags, which can be provided in packed (count = 1) or unpacked (count = 3)
format and in the latter case, they will be packed before applied to
atoms.
The array of coordinates passed to scatter_atoms() must be a ctypes
vector of ints or doubles, allocated and initialized something like
this:
from ctypes import *
natoms = lmp.get_natoms()
n3 = 3*natoms
x = (n3*c_double)()
x\[0\] = x coord of atom with ID 1
x\[1\] = y coord of atom with ID 1
x\[2\] = z coord of atom with ID 1
x\[3\] = x coord of atom with ID 2
...
x\[n3-1\] = z coord of atom with ID natoms
lmp.scatter_atoms("x",1,3,x) :pre
Alternatively, you can just change values in the vector returned by
gather_atoms("x",1,3), since it is a ctypes vector of doubles.
:line
As noted above, these Python class methods correspond one-to-one with
the functions in the LAMMPS library interface in src/library.cpp and
library.h. This means you can extend the Python wrapper via the
following steps:
Add a new interface function to src/library.cpp and
src/library.h. :ulb,l
Rebuild LAMMPS as a shared library. :l
Add a wrapper method to python/lammps.py for this interface
function. :l
You should now be able to invoke the new interface function from a
Python script. Isn't ctypes amazing? :l
:ule
:line
:line
11.8 Example Python scripts that use LAMMPS :link(py_8),h4
These are the Python scripts included as demos in the python/examples
directory of the LAMMPS distribution, to illustrate the kinds of
things that are possible when Python wraps LAMMPS. If you create your
own scripts, send them to us and we can include them in the LAMMPS
distribution.
trivial.py, read/run a LAMMPS input script thru Python,
demo.py, invoke various LAMMPS library interface routines,
simple.py, run in parallel, similar to examples/COUPLE/simple/simple.cpp,
split.py, same as simple.py but running in parallel on a subset of procs,
gui.py, GUI go/stop/temperature-slider to control LAMMPS,
plot.py, real-time temperature plot with GnuPlot via Pizza.py,
viz_tool.py, real-time viz via some viz package,
vizplotgui_tool.py, combination of viz_tool.py and plot.py and gui.py :tb(c=2)
:line
For the viz_tool.py and vizplotgui_tool.py commands, replace "tool"
with "gl" or "atomeye" or "pymol" or "vmd", depending on what
visualization package you have installed.
Note that for GL, you need to be able to run the Pizza.py GL tool,
which is included in the pizza sub-directory. See the "Pizza.py doc
pages"_pizza for more info:
:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
Note that for AtomEye, you need version 3, and there is a line in the
scripts that specifies the path and name of the executable. See the
AtomEye WWW pages "here"_atomeye or "here"_atomeye3 for more details:
http://mt.seas.upenn.edu/Archive/Graphics/A
http://mt.seas.upenn.edu/Archive/Graphics/A3/A3.html :pre
:link(atomeye,http://mt.seas.upenn.edu/Archive/Graphics/A)
:link(atomeye3,http://mt.seas.upenn.edu/Archive/Graphics/A3/A3.html)
The latter link is to AtomEye 3 which has the scriping
capability needed by these Python scripts.
Note that for PyMol, you need to have built and installed the
open-source version of PyMol in your Python, so that you can import it
from a Python script. See the PyMol WWW pages "here"_pymolhome or
"here"_pymolopen for more details:
http://www.pymol.org
http://sourceforge.net/scm/?type=svn&group_id=4546 :pre
:link(pymolhome,http://www.pymol.org)
:link(pymolopen,http://sourceforge.net/scm/?type=svn&group_id=4546)
The latter link is to the open-source version.
Note that for VMD, you need a fairly current version (1.8.7 works for
me) and there are some lines in the pizza/vmd.py script for 4 PIZZA
variables that have to match the VMD installation on your system.
:line
See the python/README file for instructions on how to run them and the
source code for individual scripts for comments about what they do.
Here are screenshots of the vizplotgui_tool.py script in action for
different visualization package options. Click to see larger images:
:image(JPG/screenshot_gl_small.jpg,JPG/screenshot_gl.jpg)
:image(JPG/screenshot_atomeye_small.jpg,JPG/screenshot_atomeye.jpg)
:image(JPG/screenshot_pymol_small.jpg,JPG/screenshot_pymol.jpg)
:image(JPG/screenshot_vmd_small.jpg,JPG/screenshot_vmd.jpg)
11.9 PyLammps interface :link(py_9),h4
Please see the "PyLammps Tutorial"_tutorial_pylammps.html.
diff --git a/doc/src/Section_start.txt b/doc/src/Section_start.txt
index b7a471c3f..c798005f5 100644
--- a/doc/src/Section_start.txt
+++ b/doc/src/Section_start.txt
@@ -1,1799 +1,1799 @@
"Previous Section"_Section_intro.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_commands.html :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
2. Getting Started :h3
This section describes how to build and run LAMMPS, for both new and
experienced users.
2.1 "What's in the LAMMPS distribution"_#start_1
2.2 "Making LAMMPS"_#start_2
2.3 "Making LAMMPS with optional packages"_#start_3
-2.5 "Building LAMMPS as a library"_#start_4
-2.6 "Running LAMMPS"_#start_5
-2.7 "Command-line options"_#start_6
-2.8 "Screen output"_#start_7
-2.9 "Tips for users of previous versions"_#start_8 :all(b)
+2.4 "Building LAMMPS as a library"_#start_4
+2.5 "Running LAMMPS"_#start_5
+2.6 "Command-line options"_#start_6
+2.7 "Screen output"_#start_7
+2.8 "Tips for users of previous versions"_#start_8 :all(b)
:line
2.1 What's in the LAMMPS distribution :h4,link(start_1)
When you download a LAMMPS tarball you will need to unzip and untar
the downloaded file with the following commands, after placing the
tarball in an appropriate directory.
tar -xzvf lammps*.tar.gz :pre
This will create a LAMMPS directory containing two files and several
sub-directories:
README: text file
LICENSE: the GNU General Public License (GPL)
bench: benchmark problems
doc: documentation
examples: simple test problems
potentials: embedded atom method (EAM) potential files
src: source files
tools: pre- and post-processing tools :tb(s=:)
Note that the "download page"_download also has links to download
pre-build Windows installers, as well as pre-built packages for
several widely used Linux distributions. It also has instructions
for how to download/install LAMMPS for Macs (via Homebrew), and to
download and update LAMMPS from SVN and Git repositories, which gives
you access to the up-to-date sources that are used by the LAMMPS
core developers.
:link(download,http://lammps.sandia.gov/download.html)
The Windows and Linux packages for serial or parallel include
only selected packages and bug-fixes/upgrades listed on "this
page"_http://lammps.sandia.gov/bug.html up to a certain date, as
stated on the download page. If you want an executable with
non-included packages or that is more current, then you'll need to
build LAMMPS yourself, as discussed in the next section.
Skip to the "Running LAMMPS"_#start_6 sections for info on how to
launch a LAMMPS Windows executable on a Windows box.
:line
2.2 Making LAMMPS :h4,link(start_2)
This section has the following sub-sections:
2.2.1 "Read this first"_#start_2_1
2.2.1 "Steps to build a LAMMPS executable"_#start_2_2
2.2.3 "Common errors that can occur when making LAMMPS"_#start_2_3
2.2.4 "Additional build tips"_#start_2_4
2.2.5 "Building for a Mac"_#start_2_5
2.2.6 "Building for Windows"_#start_2_6 :all(b)
:line
Read this first :h5,link(start_2_1)
If you want to avoid building LAMMPS yourself, read the preceeding
section about options available for downloading and installing
executables. Details are discussed on the "download"_download page.
Building LAMMPS can be simple or not-so-simple. If all you need are
the default packages installed in LAMMPS, and MPI is already installed
on your machine, or you just want to run LAMMPS in serial, then you
can typically use the Makefile.mpi or Makefile.serial files in
src/MAKE by typing one of these lines (from the src dir):
make mpi
make serial :pre
Note that on a facility supercomputer, there are often "modules"
loaded in your environment that provide the compilers and MPI you
should use. In this case, the "mpicxx" compile/link command in
Makefile.mpi should simply work by accessing those modules.
It may be the case that one of the other Makefile.machine files in the
src/MAKE sub-directories is a better match to your system (type "make"
to see a list), you can use it as-is by typing (for example):
make stampede :pre
If any of these builds (with an existing Makefile.machine) works on
your system, then you're done!
If you need to install an optional package with a LAMMPS command you
want to use, and the package does not depend on an extra library, you
can simply type
make name :pre
before invoking (or re-invoking) the above steps. "Name" is the
lower-case name of the package, e.g. replica or user-misc.
If you want to do one of the following:
use a LAMMPS command that requires an extra library (e.g. "dump image"_dump_image.html)
build with a package that requires an extra library
build with an accelerator package that requires special compiler/linker settings
run on a machine that has its own compilers, settings, or libraries :ul
then building LAMMPS is more complicated. You may need to find where
extra libraries exist on your machine or install them if they don't.
You may need to build extra libraries that are included in the LAMMPS
distribution, before building LAMMPS itself. You may need to edit a
Makefile.machine file to make it compatible with your system.
Please read the following sections carefully. If you are not
comfortable with makefiles, or building codes on a Unix platform, or
running an MPI job on your machine, please find a local expert to help
you. Many compilation, linking, and run problems users experience are
often not LAMMPS issues - they are peculiar to the user's system,
compilers, libraries, etc. Such questions are better answered by a
local expert.
If you have a build problem that you are convinced is a LAMMPS issue
(e.g. the compiler complains about a line of LAMMPS source code), then
please post the issue to the "LAMMPS mail
list"_http://lammps.sandia.gov/mail.html.
If you succeed in building LAMMPS on a new kind of machine, for which
there isn't a similar machine Makefile included in the
src/MAKE/MACHINES directory, then send it to the developers and we can
include it in the LAMMPS distribution.
:line
Steps to build a LAMMPS executable :h5,link(start_2_2)
Step 0 :h6
The src directory contains the C++ source and header files for LAMMPS.
It also contains a top-level Makefile and a MAKE sub-directory with
low-level Makefile.* files for many systems and machines. See the
src/MAKE/README file for a quick overview of what files are available
and what sub-directories they are in.
The src/MAKE dir has a few files that should work as-is on many
platforms. The src/MAKE/OPTIONS dir has more that invoke additional
compiler, MPI, and other setting options commonly used by LAMMPS, to
illustrate their syntax. The src/MAKE/MACHINES dir has many more that
have been tweaked or optimized for specific machines. These files are
all good starting points if you find you need to change them for your
machine. Put any file you edit into the src/MAKE/MINE directory and
it will be never be touched by any LAMMPS updates.
>From within the src directory, type "make" or "gmake". You should see
a list of available choices from src/MAKE and all of its
sub-directories. If one of those has the options you want or is the
machine you want, you can type a command like:
make mpi :pre
or
make serial :pre
or
gmake mac :pre
Note that the corresponding Makefile.machine can exist in src/MAKE or
any of its sub-directories. If a file with the same name appears in
multiple places (not a good idea), the order they are used is as
follows: src/MAKE/MINE, src/MAKE, src/MAKE/OPTIONS, src/MAKE/MACHINES.
This gives preference to a file you have created/edited and put in
src/MAKE/MINE.
Note that on a multi-processor or multi-core platform you can launch a
parallel make, by using the "-j" switch with the make command, which
will build LAMMPS more quickly.
If you get no errors and an executable like [lmp_mpi] or [lmp_serial]
or [lmp_mac] is produced, then you're done; it's your lucky day.
Note that by default only a few of LAMMPS optional packages are
installed. To build LAMMPS with optional packages, see "this
section"_#start_3 below.
Step 1 :h6
If Step 0 did not work, you will need to create a low-level Makefile
for your machine, like Makefile.foo. You should make a copy of an
existing Makefile.* in src/MAKE or one of its sub-directories as a
starting point. The only portions of the file you need to edit are
the first line, the "compiler/linker settings" section, and the
"LAMMPS-specific settings" section. When it works, put the edited
file in src/MAKE/MINE and it will not be altered by any future LAMMPS
updates.
Step 2 :h6
Change the first line of Makefile.foo to list the word "foo" after the
"#", and whatever other options it will set. This is the line you
will see if you just type "make".
Step 3 :h6
The "compiler/linker settings" section lists compiler and linker
settings for your C++ compiler, including optimization flags. You can
use g++, the open-source GNU compiler, which is available on all Unix
systems. You can also use mpicxx which will typically be available if
MPI is installed on your system, though you should check which actual
compiler it wraps. Vendor compilers often produce faster code. On
boxes with Intel CPUs, we suggest using the Intel icc compiler, which
can be downloaded from "Intel's compiler site"_intel.
:link(intel,http://www.intel.com/software/products/noncom)
If building a C++ code on your machine requires additional libraries,
then you should list them as part of the LIB variable. You should
not need to do this if you use mpicxx.
The DEPFLAGS setting is what triggers the C++ compiler to create a
dependency list for a source file. This speeds re-compilation when
source (*.cpp) or header (*.h) files are edited. Some compilers do
not support dependency file creation, or may use a different switch
than -D. GNU g++ and Intel icc works with -D. If your compiler can't
create dependency files, then you'll need to create a Makefile.foo
patterned after Makefile.storm, which uses different rules that do not
involve dependency files. Note that when you build LAMMPS for the
first time on a new platform, a long list of *.d files will be printed
out rapidly. This is not an error; it is the Makefile doing its
normal creation of dependencies.
Step 4 :h6
The "system-specific settings" section has several parts. Note that
if you change any -D setting in this section, you should do a full
re-compile, after typing "make clean" (which will describe different
clean options).
The LMP_INC variable is used to include options that turn on ifdefs
within the LAMMPS code. The options that are currently recogized are:
-DLAMMPS_GZIP
-DLAMMPS_JPEG
-DLAMMPS_PNG
-DLAMMPS_FFMPEG
-DLAMMPS_MEMALIGN
-DLAMMPS_XDR
-DLAMMPS_SMALLBIG
-DLAMMPS_BIGBIG
-DLAMMPS_SMALLSMALL
-DLAMMPS_LONGLONG_TO_LONG
-DLAMMPS_EXCEPTIONS
-DPACK_ARRAY
-DPACK_POINTER
-DPACK_MEMCPY :ul
The read_data and dump commands will read/write gzipped files if you
compile with -DLAMMPS_GZIP. It requires that your machine supports
the "popen()" function in the standard runtime library and that a gzip
executable can be found by LAMMPS during a run.
NOTE: on some clusters with high-speed networks, using the fork()
library calls (required by popen()) can interfere with the fast
communication library and lead to simulations using compressed output
or input to hang or crash. For selected operations, compressed file
I/O is also available using a compression library instead, which are
provided in the COMPRESS package. From more details about compiling
LAMMPS with packages, please see below.
If you use -DLAMMPS_JPEG, the "dump image"_dump_image.html command
will be able to write out JPEG image files. For JPEG files, you must
also link LAMMPS with a JPEG library, as described below. If you use
-DLAMMPS_PNG, the "dump image"_dump.html command will be able to write
out PNG image files. For PNG files, you must also link LAMMPS with a
PNG library, as described below. If neither of those two defines are
used, LAMMPS will only be able to write out uncompressed PPM image
files.
If you use -DLAMMPS_FFMPEG, the "dump movie"_dump_image.html command
will be available to support on-the-fly generation of rendered movies
the need to store intermediate image files. It requires that your
machines supports the "popen" function in the standard runtime library
and that an FFmpeg executable can be found by LAMMPS during the run.
NOTE: Similar to the note above, this option can conflict with
high-speed networks, because it uses popen().
Using -DLAMMPS_MEMALIGN= enables the use of the
posix_memalign() call instead of malloc() when large chunks or memory
are allocated by LAMMPS. This can help to make more efficient use of
vector instructions of modern CPUS, since dynamically allocated memory
has to be aligned on larger than default byte boundaries (e.g. 16
bytes instead of 8 bytes on x86 type platforms) for optimal
performance.
If you use -DLAMMPS_XDR, the build will include XDR compatibility
files for doing particle dumps in XTC format. This is only necessary
if your platform does have its own XDR files available. See the
Restrictions section of the "dump"_dump.html command for details.
Use at most one of the -DLAMMPS_SMALLBIG, -DLAMMPS_BIGBIG,
-DLAMMPS_SMALLSMALL settings. The default is -DLAMMPS_SMALLBIG. These
settings refer to use of 4-byte (small) vs 8-byte (big) integers
within LAMMPS, as specified in src/lmptype.h. The only reason to use
the BIGBIG setting is to enable simulation of huge molecular systems
(which store bond topology info) with more than 2 billion atoms, or to
track the image flags of moving atoms that wrap around a periodic box
more than 512 times. Normally, the only reason to use SMALLSMALL is
if your machine does not support 64-bit integers, though you can use
SMALLSMALL setting if you are running in serial or on a desktop
machine or small cluster where you will never run large systems or for
long time (more than 2 billion atoms, more than 2 billion timesteps).
See the "Additional build tips"_#start_2_4 section below for more
details on these settings.
Note that the USER-ATC package is not currently compatible with
-DLAMMPS_BIGBIG. Also the GPU package requires the lib/gpu library to
be compiled with the same setting, or the link will fail.
The -DLAMMPS_LONGLONG_TO_LONG setting may be needed if your system or
MPI version does not recognize "long long" data types. In this case a
"long" data type is likely already 64-bits, in which case this setting
will convert to that data type.
The -DLAMMPS_EXCEPTIONS setting can be used to activate alternative
versions of error handling inside of LAMMPS. This is useful when
external codes drive LAMMPS as a library. Using this option, LAMMPS
errors do not kill the caller. Instead, the call stack is unwound and
control returns to the caller. The library interface provides the
lammps_has_error() and lammps_get_last_error_message() functions to
detect and find out more about a LAMMPS error.
Using one of the -DPACK_ARRAY, -DPACK_POINTER, and -DPACK_MEMCPY
options can make for faster parallel FFTs (in the PPPM solver) on some
platforms. The -DPACK_ARRAY setting is the default. See the
"kspace_style"_kspace_style.html command for info about PPPM. See
Step 6 below for info about building LAMMPS with an FFT library.
Step 5 :h6
The 3 MPI variables are used to specify an MPI library to build LAMMPS
with. Note that you do not need to set these if you use the MPI
compiler mpicxx for your CC and LINK setting in the section above.
The MPI wrapper knows where to find the needed files.
If you want LAMMPS to run in parallel, you must have an MPI library
installed on your platform. If MPI is installed on your system in the
usual place (under /usr/local), you also may not need to specify these
3 variables, assuming /usr/local is in your path. On some large
parallel machines which use "modules" for their compile/link
environements, you may simply need to include the correct module in
your build environment, before building LAMMPS. Or the parallel
machine may have a vendor-provided MPI which the compiler has no
trouble finding.
Failing this, these 3 variables can be used to specify where the mpi.h
file (MPI_INC) and the MPI library file (MPI_PATH) are found and the
name of the library file (MPI_LIB).
If you are installing MPI yourself, we recommend Argonne's MPICH2
or OpenMPI. MPICH can be downloaded from the "Argonne MPI
site"_http://www.mcs.anl.gov/research/projects/mpich2/. OpenMPI can
be downloaded from the "OpenMPI site"_http://www.open-mpi.org.
Other MPI packages should also work. If you are running on a big
parallel platform, your system people or the vendor should have
already installed a version of MPI, which is likely to be faster
than a self-installed MPICH or OpenMPI, so find out how to build
and link with it. If you use MPICH or OpenMPI, you will have to
configure and build it for your platform. The MPI configure script
should have compiler options to enable you to use the same compiler
you are using for the LAMMPS build, which can avoid problems that can
arise when linking LAMMPS to the MPI library.
If you just want to run LAMMPS on a single processor, you can use the
dummy MPI library provided in src/STUBS, since you don't need a true
MPI library installed on your system. See src/MAKE/Makefile.serial
for how to specify the 3 MPI variables in this case. You will also
need to build the STUBS library for your platform before making LAMMPS
itself. Note that if you are building with src/MAKE/Makefile.serial,
e.g. by typing "make serial", then the STUBS library is built for you.
To build the STUBS library from the src directory, type "make
mpi-stubs", or from the src/STUBS dir, type "make". This should
create a libmpi_stubs.a file suitable for linking to LAMMPS. If the
build fails, you will need to edit the STUBS/Makefile for your
platform.
The file STUBS/mpi.c provides a CPU timer function called MPI_Wtime()
that calls gettimeofday() . If your system doesn't support
gettimeofday() , you'll need to insert code to call another timer.
Note that the ANSI-standard function clock() rolls over after an hour
or so, and is therefore insufficient for timing long LAMMPS
simulations.
Step 6 :h6
The 3 FFT variables allow you to specify an FFT library which LAMMPS
uses (for performing 1d FFTs) when running the particle-particle
particle-mesh (PPPM) option for long-range Coulombics via the
"kspace_style"_kspace_style.html command.
LAMMPS supports common open-source or vendor-supplied FFT libraries
for this purpose. If you leave these 3 variables blank, LAMMPS will
use the open-source "KISS FFT library"_http://kissfft.sf.net, which is
included in the LAMMPS distribution. This library is portable to all
platforms and for typical LAMMPS simulations is almost as fast as FFTW
or vendor optimized libraries. If you are not including the KSPACE
package in your build, you can also leave the 3 variables blank.
Otherwise, select which kinds of FFTs to use as part of the FFT_INC
setting by a switch of the form -DFFT_XXX. Recommended values for XXX
are: MKL or FFTW3. FFTW2 and NONE are supported as legacy options.
Selecting -DFFT_FFTW will use the FFTW3 library and -DFFT_NONE will
use the KISS library described above.
You may also need to set the FFT_INC, FFT_PATH, and FFT_LIB variables,
so the compiler and linker can find the needed FFT header and library
files. Note that on some large parallel machines which use "modules"
for their compile/link environements, you may simply need to include
the correct module in your build environment. Or the parallel machine
may have a vendor-provided FFT library which the compiler has no
trouble finding. See the src/MAKE/OPTIONS/Makefile.fftw file for an
example of how to specify these variables to use the FFTW3 library.
FFTW is fast, portable library that should also work on any platform
and typically be faster than KISS FFT. You can download it from
"www.fftw.org"_http://www.fftw.org. Both the legacy version 2.1.X and
the newer 3.X versions are supported as -DFFT_FFTW2 or -DFFT_FFTW3.
Building FFTW for your box should be as simple as ./configure; make;
make install. The install command typically requires root privileges
(e.g. invoke it via sudo), unless you specify a local directory with
the "--prefix" option of configure. Type "./configure --help" to see
various options.
If you wish to have FFTW support for single-precision FFTs (see below
about -DFFT_SINGLE) in addition to the default double-precision FFTs,
you will need to build FFTW a second time for single-precision. For
FFTW3, do this via:
make clean
./configure --enable-single; make; make install :pre
which should produce the additional library libfftw3f.a.
For FFTW2, do this:
make clean
./configure --enable-float --enable-type-prefix; make; make install :pre
which should produce the additional library libsfftw.a and additional
include file sfttw.a. Note that on some platforms FFTW2 has been
pre-installed for both single- and double-precision, and may already
have these files as well as libdfftw.a and dfftw.h for double
precision.
The FFT_INC variable also allows for a -DFFT_SINGLE setting that will
use single-precision FFTs with PPPM, which can speed-up long-range
calulations, particularly in parallel or on GPUs. Fourier transform
and related PPPM operations are somewhat insensitive to floating point
truncation errors and thus do not always need to be performed in
double precision. Using the -DFFT_SINGLE setting trades off a little
accuracy for reduced memory use and parallel communication costs for
transposing 3d FFT data. Note that single precision FFTs have only
been tested with the FFTW3, FFTW2, MKL, and KISS FFT options.
When using -DFFT_SINGLE with FFTW3 or FFTW2, you need to build FFTW
with support for single-precision, as explained above. For FFTW3 you
also need to include -lfftw3f with the FFT_LIB setting, in addition to
-lfftw3. For FFTW2, you also need to specify -DFFT_SIZE with the
FFT_INC setting and -lsfftw with the FFT_LIB setting (in place of
-lfftw). Similarly, if FFTW2 has been preinstalled with an explicit
double-precision library (libdfftw.a and not the default libfftw.a),
then you can specify -DFFT_SIZE (and not -DFFT_SINGLE), and specify
-ldfftw to use double-precision FFTs.
Step 7 :h6
The 3 JPG variables allow you to specify a JPEG and/or PNG library
which LAMMPS uses when writing out JPEG or PNG files via the "dump
image"_dump_image.html command. These can be left blank if you do not
use the -DLAMMPS_JPEG or -DLAMMPS_PNG switches discussed above in Step
4, since in that case JPEG/PNG output will be disabled.
A standard JPEG library usually goes by the name libjpeg.a or
libjpeg.so and has an associated header file jpeglib.h. Whichever
JPEG library you have on your platform, you'll need to set the
appropriate JPG_INC, JPG_PATH, and JPG_LIB variables, so that the
compiler and linker can find it.
A standard PNG library usually goes by the name libpng.a or libpng.so
and has an associated header file png.h. Whichever PNG library you
have on your platform, you'll need to set the appropriate JPG_INC,
JPG_PATH, and JPG_LIB variables, so that the compiler and linker can
find it.
As before, if these header and library files are in the usual place on
your machine, you may not need to set these variables.
Step 8 :h6
Note that by default only a few of LAMMPS optional packages are
installed. To build LAMMPS with optional packages, see "this
section"_#start_3 below, before proceeding to Step 9.
Step 9 :h6
That's it. Once you have a correct Makefile.foo, and you have
pre-built any other needed libraries (e.g. MPI, FFT, etc) all you need
to do from the src directory is type something like this:
make foo
make -j N foo
gmake foo
gmake -j N foo :pre
The -j or -j N switches perform a parallel build which can be much
faster, depending on how many cores your compilation machine has. N
is the number of cores the build runs on.
You should get the executable lmp_foo when the build is complete.
:line
Errors that can occur when making LAMMPS: h5 :link(start_2_3)
If an error occurs when building LAMMPS, the compiler or linker will
state very explicitly what the problem is. The error message should
give you a hint as to which of the steps above has failed, and what
you need to do in order to fix it. Building a code with a Makefile is
a very logical process. The compiler and linker need to find the
appropriate files and those files need to be compatible with LAMMPS
settings and source files. When a make fails, there is usually a very
simple reason, which you or a local expert will need to fix.
Here are two non-obvious errors that can occur:
(1) If the make command breaks immediately with errors that indicate
it can't find files with a "*" in their names, this can be because
your machine's native make doesn't support wildcard expansion in a
makefile. Try gmake instead of make. If that doesn't work, try using
a -f switch with your make command to use a pre-generated
Makefile.list which explicitly lists all the needed files, e.g.
make makelist
make -f Makefile.list linux
gmake -f Makefile.list mac :pre
The first "make" command will create a current Makefile.list with all
the file names in your src dir. The 2nd "make" command (make or
gmake) will use it to build LAMMPS. Note that you should
include/exclude any desired optional packages before using the "make
makelist" command.
(2) If you get an error that says something like 'identifier "atoll"
is undefined', then your machine does not support "long long"
integers. Try using the -DLAMMPS_LONGLONG_TO_LONG setting described
above in Step 4.
:line
Additional build tips :h5,link(start_2_4)
Building LAMMPS for multiple platforms. :h6
You can make LAMMPS for multiple platforms from the same src
directory. Each target creates its own object sub-directory called
Obj_target where it stores the system-specific *.o files.
Cleaning up. :h6
Typing "make clean-all" or "make clean-machine" will delete *.o object
files created when LAMMPS is built, for either all builds or for a
particular machine.
Changing the LAMMPS size limits via -DLAMMPS_SMALLBIG or
-DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL :h6
As explained above, any of these 3 settings can be specified on the
LMP_INC line in your low-level src/MAKE/Makefile.foo.
The default is -DLAMMPS_SMALLBIG which allows for systems with up to
2^63 atoms and 2^63 timesteps (about 9e18). The atom limit is for
atomic systems which do not store bond topology info and thus do not
require atom IDs. If you use atom IDs for atomic systems (which is
the default) or if you use a molecular model, which stores bond
topology info and thus requires atom IDs, the limit is 2^31 atoms
(about 2 billion). This is because the IDs are stored in 32-bit
integers.
Likewise, with this setting, the 3 image flags for each atom (see the
"dump"_dump.html doc page for a discussion) are stored in a 32-bit
integer, which means the atoms can only wrap around a periodic box (in
each dimension) at most 512 times. If atoms move through the periodic
box more than this many times, the image flags will "roll over",
e.g. from 511 to -512, which can cause diagnostics like the
mean-squared displacement, as calculated by the "compute
msd"_compute_msd.html command, to be faulty.
To allow for larger atomic systems with atom IDs or larger molecular
systems or larger image flags, compile with -DLAMMPS_BIGBIG. This
stores atom IDs and image flags in 64-bit integers. This enables
atomic or molecular systems with atom IDS of up to 2^63 atoms (about
9e18). And image flags will not "roll over" until they reach 2^20 =
1048576.
If your system does not support 8-byte integers, you will need to
compile with the -DLAMMPS_SMALLSMALL setting. This will restrict the
total number of atoms (for atomic or molecular systems) and timesteps
to 2^31 (about 2 billion). Image flags will roll over at 2^9 = 512.
Note that in src/lmptype.h there are definitions of all these data
types as well as the MPI data types associated with them. The MPI
types need to be consistent with the associated C data types, or else
LAMMPS will generate a run-time error. As far as we know, the
settings defined in src/lmptype.h are portable and work on every
current system.
In all cases, the size of problem that can be run on a per-processor
basis is limited by 4-byte integer storage to 2^31 atoms per processor
(about 2 billion). This should not normally be a limitation since such
a problem would have a huge per-processor memory footprint due to
neighbor lists and would run very slowly in terms of CPU secs/timestep.
:line
Building for a Mac :h5,link(start_2_5)
OS X is a derivative of BSD Unix, so it should just work. See the
src/MAKE/MACHINES/Makefile.mac and Makefile.mac_mpi files.
:line
Building for Windows :h5,link(start_2_6)
If you want to build a Windows version of LAMMPS, you can build it
yourself, but it may require some effort. LAMMPS expects a Unix-like
build environment for the default build procedure. This can be done
using either Cygwin or MinGW; the latter also exists as a ready-to-use
Linux-to-Windows cross-compiler in several Linux distributions. In
these cases, you can do the installation after installing several
unix-style commands like make, grep, sed and bash with some shell
utilities.
For Cygwin and the MinGW cross-compilers, suitable makefiles are
provided in src/MAKE/MACHINES. When using other compilers, like
Visual C++ or Intel compilers for Windows, you may have to implement
your own build system. Since none of the current LAMMPS core developers
has significant experience building executables on Windows, we are
happy to distribute contributed instructions and modifications, but
we cannot provide support for those.
With the so-called "Anniversary Update" to Windows 10, there is a
Ubuntu Linux subsystem available for Windows, that can be installed
and then used to compile/install LAMMPS as if you are running on a
Ubuntu Linux system instead of Windows.
As an alternative, you can download "daily builds" (and some older
versions) of the installer packages from
"rpm.lammps.org/windows.html"_http://rpm.lammps.org/windows.html.
These executables are built with most optional packages and the
download includes documentation, potential files, some tools and
many examples, but no source code.
:line
2.3 Making LAMMPS with optional packages :h4,link(start_3)
This section has the following sub-sections:
2.3.1 "Package basics"_#start_3_1
2.3.2 "Including/excluding packages"_#start_3_2
2.3.3 "Packages that require extra libraries"_#start_3_3 :all(b)
:line
Package basics: :h5,link(start_3_1)
The source code for LAMMPS is structured as a set of core files which
are always included, plus optional packages. Packages are groups of
files that enable a specific set of features. For example, force
fields for molecular systems or granular systems are in packages.
"Section 4"_Section_packages.html in the manual has details about all
the packages, which come in two flavors: [standard] and [user]
packages. It also has specific instructions for building LAMMPS with
any package which requires an extra library. General instructions are
below.
You can see the list of all packages by typing "make package" from
within the src directory of the LAMMPS distribution. It will also
list various make commands that can be used to manage packages.
If you use a command in a LAMMPS input script that is part of a
package, you must have built LAMMPS with that package, else you will
get an error that the style is invalid or the command is unknown.
Every command's doc page specfies if it is part of a package. You can
type
lmp_machine -h :pre
to run your executable with the optional "-h command-line
-switch"_#start_7 for "help", which will list the styles and commands
+switch"_#start_6 for "help", which will list the styles and commands
known to your executable, and immediately exit.
:line
Including/excluding packages :h5,link(start_3_2)
To use (or not use) a package you must install it (or un-install it)
before building LAMMPS. From the src directory, this is as simple as:
make yes-colloid
make mpi :pre
or
make no-user-omp
make mpi :pre
NOTE: You should NOT install/un-install packages and build LAMMPS in a
single make command using multiple targets, e.g. make yes-colloid mpi.
This is because the make procedure creates a list of source files that
will be out-of-date for the build if the package configuration changes
within the same command.
Any package can be installed or not in a LAMMPS build, independent of
all other packages. However, some packages include files derived from
files in other packages. LAMMPS checks for this and does the right
thing. I.e. individual files are only included if their dependencies
are already included. Likewise, if a package is excluded, other files
dependent on that package are also excluded.
NOTE: The one exception is that we do not recommend building with both
the KOKKOS package installed and any of the other acceleration
packages (GPU, OPT, USER-INTEL, USER-OMP) also installed. This is
because of how Kokkos sometimes builds using a wrapper compiler which
can make it difficult to invoke all the compile/link flags correctly
for both Kokkos and non-Kokkos files.
If you will never run simulations that use the features in a
particular packages, there is no reason to include it in your build.
For some packages, this will keep you from having to build extra
libraries, and will also produce a smaller executable which may run a
bit faster.
When you download a LAMMPS tarball, three packages are pre-installed
in the src directory -- KSPACE, MANYBODY, MOLECULE -- because they are
so commonly used. When you download LAMMPS source files from the SVN
or Git repositories, no packages are pre-installed.
Packages are installed or un-installed by typing
make yes-name
make no-name :pre
where "name" is the name of the package in lower-case, e.g. name =
kspace for the KSPACE package or name = user-atc for the USER-ATC
package. You can also type any of these commands:
make yes-all | install all packages
make no-all | un-install all packages
make yes-standard or make yes-std | install standard packages
make no-standard or make no-std| un-install standard packages
make yes-user | install user packages
make no-user | un-install user packages
make yes-lib | install packages that require extra libraries
make no-lib | un-install packages that require extra libraries
make yes-ext | install packages that require external libraries
make no-ext | un-install packages that require external libraries :tb(s=|)
which install/un-install various sets of packages. Typing "make
package" will list all the these commands.
NOTE: Installing or un-installing a package works by simply moving
files back and forth between the main src directory and
sub-directories with the package name (e.g. src/KSPACE, src/USER-ATC),
so that the files are included or excluded when LAMMPS is built.
After you have installed or un-installed a package, you must re-build
LAMMPS for the action to take effect.
The following make commands help manage files that exist in both the
src directory and in package sub-directories. You do not normally
need to use these commands unless you are editing LAMMPS files or have
downloaded a patch from the LAMMPS web site.
Typing "make package-status" or "make ps" will show which packages are
currently installed. For those that are installed, it will list any
files that are different in the src directory and package
sub-directory.
Typing "make package-update" or "make pu" will overwrite src files
with files from the package sub-directories if the package is
installed. It should be used after a patch has been applied, since
patches only update the files in the package sub-directory, but not
the src files.
Typing "make package-overwrite" will overwrite files in the package
sub-directories with src files.
Typing "make package-diff" lists all differences between these files.
Again, just type "make package" to see all of the package-related make
options.
:line
Packages that require extra libraries :h5,link(start_3_3)
A few of the standard and user packages require extra libraries. See
"Section 4"_Section_packages.html for two tables of packages which
indicate which ones require libraries. For each such package, the
Section 4 doc page gives details on how to build the extra library,
including how to download it if necessary. The basic ideas are
summarized here.
[System libraries:]
Packages in the tables "Section 4"_Section_packages.html with a "sys"
in the last column link to system libraries that typically already
exist on your machine. E.g. the python package links to a system
Python library. If your machine does not have the required library,
you will have to download and install it on your machine, in either
the system or user space.
[Internal libraries:]
Packages in the tables "Section 4"_Section_packages.html with an "int"
in the last column link to internal libraries whose source code is
included with LAMMPS, in the lib/name directory where name is the
package name. You must first build the library in that directory
before building LAMMPS with that package installed. E.g. the gpu
package links to a library you build in the lib/gpu dir. You can
often do the build in one step by typing "make lib-name args=..."
from the src dir, with appropriate arguments. You can leave off the
args to see a help message. See "Section 4"_Section_packages.html for
details for each package.
[External libraries:]
Packages in the tables "Section 4"_Section_packages.html with an "ext"
in the last column link to exernal libraries whose source code is not
included with LAMMPS. You must first download and install the library
before building LAMMPS with that package installed. E.g. the voronoi
package links to the freely available "Voro++ library"_voro_home2. You
can often do the download/build in one step by typing "make lib-name
args=..." from the src dir, with appropriate arguments. You can leave
off the args to see a help message. See "Section
4"_Section_packages.html for details for each package.
:link(voro_home2,http://math.lbl.gov/voro++)
[Possible errors:]
There are various common errors which can occur when building extra
libraries or when building LAMMPS with packages that require the extra
libraries.
If you cannot build the extra library itself successfully, you may
need to edit or create an appropriate Makefile for your machine, e.g.
with appropriate compiler or system settings. Provided makefiles are
typically in the lib/name directory. E.g. see the Makefile.* files in
lib/gpu.
The LAMMPS build often uses settings in a lib/name/Makefile.lammps
file which either exists in the LAMMPS distribution or is created or
copied from a lib/name/Makefile.lammps.* file when the library is
built. If those settings are not correct for your machine you will
need to edit or create an appropriate Makefile.lammps file.
Package-specific details for these steps are given in "Section
4"_Section_packages.html an in README files in the lib/name
directories.
[Compiler options needed for accelerator packages:]
Several packages contain code that is optimized for specific hardware,
e.g. CPU, KNL, or GPU. These are the OPT, GPU, KOKKOS, USER-INTEL,
and USER-OMP packages. Compiling and linking the source files in
these accelerator packages for optimal performance requires specific
settings in the Makefile.machine file you use.
A summary of the Makefile.machine settings needed for each of these
packages is given in "Section 4"_Section_packages.html. More info is
given on the doc pages that describe each package in detail:
5.3.1 "USER-INTEL package"_accelerate_intel.html
5.3.2 "GPU package"_accelerate_intel.html
5.3.3 "KOKKOS package"_accelerate_kokkos.html
5.3.4 "USER-OMP package"_accelerate_omp.html
5.3.5 "OPT package"_accelerate_opt.html :all(b)
You can also use or examine the following machine Makefiles in
src/MAKE/OPTIONS, which include the settings. Note that the
USER-INTEL and KOKKOS packages can use settings that build LAMMPS for
different hardware. The USER-INTEL package can be compiled for Intel
CPUs and KNLs; the KOKKOS package builds for CPUs (OpenMP), GPUs
(Cuda), and Intel KNLs.
Makefile.intel_cpu
Makefile.intel_phi
Makefile.kokkos_omp
Makefile.kokkos_cuda
Makefile.kokkos_phi
Makefile.omp
Makefile.opt :ul
:line
2.4 Building LAMMPS as a library :h4,link(start_4)
LAMMPS can be built as either a static or shared library, which can
then be called from another application or a scripting language. See
"this section"_Section_howto.html#howto_10 for more info on coupling
LAMMPS to other codes. See "this section"_Section_python.html for
more info on wrapping and running LAMMPS from Python.
Static library :h5
To build LAMMPS as a static library (*.a file on Linux), type
make foo mode=lib :pre
where foo is the machine name. This kind of library is typically used
to statically link a driver application to LAMMPS, so that you can
insure all dependencies are satisfied at compile time. This will use
the ARCHIVE and ARFLAGS settings in src/MAKE/Makefile.foo. The build
will create the file liblammps_foo.a which another application can
link to. It will also create a soft link liblammps.a, which will
point to the most recently built static library.
Shared library :h5
To build LAMMPS as a shared library (*.so file on Linux), which can be
dynamically loaded, e.g. from Python, type
make foo mode=shlib :pre
where foo is the machine name. This kind of library is required when
wrapping LAMMPS with Python; see "Section 11"_Section_python.html
for details. This will use the SHFLAGS and SHLIBFLAGS settings in
src/MAKE/Makefile.foo and perform the build in the directory
Obj_shared_foo. This is so that each file can be compiled with the
-fPIC flag which is required for inclusion in a shared library. The
build will create the file liblammps_foo.so which another application
can link to dyamically. It will also create a soft link liblammps.so,
which will point to the most recently built shared library. This is
the file the Python wrapper loads by default.
Note that for a shared library to be usable by a calling program, all
the auxiliary libraries it depends on must also exist as shared
libraries. This will be the case for libraries included with LAMMPS,
such as the dummy MPI library in src/STUBS or any package libraries in
lib/packages, since they are always built as shared libraries using
the -fPIC switch. However, if a library like MPI or FFTW does not
exist as a shared library, the shared library build will generate an
error. This means you will need to install a shared library version
of the auxiliary library. The build instructions for the library
should tell you how to do this.
Here is an example of such errors when the system FFTW or provided
lib/colvars library have not been built as shared libraries:
/usr/bin/ld: /usr/local/lib/libfftw3.a(mapflags.o): relocation
R_X86_64_32 against '.rodata' can not be used when making a shared
object; recompile with -fPIC
/usr/local/lib/libfftw3.a: could not read symbols: Bad value :pre
/usr/bin/ld: ../../lib/colvars/libcolvars.a(colvarmodule.o):
relocation R_X86_64_32 against '__pthread_key_create' can not be used
when making a shared object; recompile with -fPIC
../../lib/colvars/libcolvars.a: error adding symbols: Bad value :pre
As an example, here is how to build and install the "MPICH
library"_mpich, a popular open-source version of MPI, distributed by
Argonne National Labs, as a shared library in the default
/usr/local/lib location:
:link(mpich,http://www-unix.mcs.anl.gov/mpi)
./configure --enable-shared
make
make install :pre
You may need to use "sudo make install" in place of the last line if
you do not have write privileges for /usr/local/lib. The end result
should be the file /usr/local/lib/libmpich.so.
[Additional requirement for using a shared library:] :h5
The operating system finds shared libraries to load at run-time using
the environment variable LD_LIBRARY_PATH. So you may wish to copy the
file src/liblammps.so or src/liblammps_g++.so (for example) to a place
the system can find it by default, such as /usr/local/lib, or you may
wish to add the LAMMPS src directory to LD_LIBRARY_PATH, so that the
current version of the shared library is always available to programs
that use it.
For the csh or tcsh shells, you would add something like this to your
~/.cshrc file:
setenv LD_LIBRARY_PATH $\{LD_LIBRARY_PATH\}:/home/sjplimp/lammps/src :pre
Calling the LAMMPS library :h5
Either flavor of library (static or shared) allows one or more LAMMPS
objects to be instantiated from the calling program.
When used from a C++ program, all of LAMMPS is wrapped in a LAMMPS_NS
namespace; you can safely use any of its classes and methods from
within the calling code, as needed.
When used from a C or Fortran program or a scripting language like
Python, the library has a simple function-style interface, provided in
src/library.cpp and src/library.h.
See the sample codes in examples/COUPLE/simple for examples of C++ and
C and Fortran codes that invoke LAMMPS thru its library interface.
There are other examples as well in the COUPLE directory which are
discussed in "Section 6.10"_Section_howto.html#howto_10 of the
manual. See "Section 11"_Section_python.html of the manual for a
description of the Python wrapper provided with LAMMPS that operates
through the LAMMPS library interface.
The files src/library.cpp and library.h define the C-style API for
using LAMMPS as a library. See "Section
6.19"_Section_howto.html#howto_19 of the manual for a description of the
interface and how to extend it for your needs.
:line
2.5 Running LAMMPS :h4,link(start_5)
By default, LAMMPS runs by reading commands from standard input. Thus
if you run the LAMMPS executable by itself, e.g.
lmp_linux :pre
it will simply wait, expecting commands from the keyboard. Typically
you should put commands in an input script and use I/O redirection,
e.g.
lmp_linux < in.file :pre
For parallel environments this should also work. If it does not, use
the '-in' command-line switch, e.g.
lmp_linux -in in.file :pre
"This section"_Section_commands.html describes how input scripts are
structured and what commands they contain.
You can test LAMMPS on any of the sample inputs provided in the
examples or bench directory. Input scripts are named in.* and sample
outputs are named log.*.name.P where name is a machine and P is the
number of processors it was run on.
Here is how you might run a standard Lennard-Jones benchmark on a
Linux box, using mpirun to launch a parallel job:
cd src
make linux
cp lmp_linux ../bench
cd ../bench
mpirun -np 4 lmp_linux -in in.lj :pre
See "this page"_bench for timings for this and the other benchmarks on
various platforms. Note that some of the example scripts require
LAMMPS to be built with one or more of its optional packages.
:link(bench,http://lammps.sandia.gov/bench.html)
:line
On a Windows box, you can skip making LAMMPS and simply download an
installer package from "here"_http://rpm.lammps.org/windows.html
For running the non-MPI executable, follow these steps:
Get a command prompt by going to Start->Run... ,
then typing "cmd". :ulb,l
Move to the directory where you have your input, e.g. a copy of
the [in.lj] input from the bench folder. (e.g. by typing: cd "Documents"). :l
At the command prompt, type "lmp_serial -in in.lj", replacing [in.lj]
with the name of your LAMMPS input script. :l
:ule
For the MPI version, which allows you to run LAMMPS under Windows on
multiple processors, follow these steps:
Download and install
"MPICH2"_http://www.mcs.anl.gov/research/projects/mpich2/downloads/index.php?s=downloads
for Windows. :ulb,l
The LAMMPS Windows installer packages will automatically adjust your
path for the default location of this MPI package. After the installation
of the MPICH software, it needs to be integrated into the system.
For this you need to start a Command Prompt in {Administrator Mode}
(right click on the icon and select it). Change into the MPICH2
installation directory, then into the subdirectory [bin] and execute
[smpd.exe -install]. Exit the command window.
Get a new, regular command prompt by going to Start->Run... ,
then typing "cmd". :l
Move to the directory where you have your input file
(e.g. by typing: cd "Documents"). :l
Then type something like this:
mpiexec -localonly 4 lmp_mpi -in in.lj :pre
or
mpiexec -np 4 lmp_mpi -in in.lj :pre
replacing in.lj with the name of your LAMMPS input script. For the latter
case, you may be prompted to enter your password. :l
In this mode, output may not immediately show up on the screen, so if
your input script takes a long time to execute, you may need to be
patient before the output shows up. :l
The parallel executable can also run on a single processor by typing
something like:
lmp_mpi -in in.lj :pre
:ule
:line
The screen output from LAMMPS is described in a section below. As it
runs, LAMMPS also writes a log.lammps file with the same information.
Note that this sequence of commands copies the LAMMPS executable
(lmp_linux) to the directory with the input files. This may not be
necessary, but some versions of MPI reset the working directory to
where the executable is, rather than leave it as the directory where
you launch mpirun from (if you launch lmp_linux on its own and not
under mpirun). If that happens, LAMMPS will look for additional input
files and write its output files to the executable directory, rather
than your working directory, which is probably not what you want.
If LAMMPS encounters errors in the input script or while running a
simulation it will print an ERROR message and stop or a WARNING
message and continue. See "Section 12"_Section_errors.html for a
discussion of the various kinds of errors LAMMPS can or can't detect,
a list of all ERROR and WARNING messages, and what to do about them.
LAMMPS can run a problem on any number of processors, including a
single processor. In theory you should get identical answers on any
number of processors and on any machine. In practice, numerical
round-off can cause slight differences and eventual divergence of
molecular dynamics phase space trajectories.
LAMMPS can run as large a problem as will fit in the physical memory
of one or more processors. If you run out of memory, you must run on
more processors or setup a smaller problem.
:line
2.6 Command-line options :h4,link(start_6)
At run time, LAMMPS recognizes several optional command-line switches
which may be used in any order. Either the full word or a one-or-two
letter abbreviation can be used:
-e or -echo
-h or -help
-i or -in
-k or -kokkos
-l or -log
-nc or -nocite
-pk or -package
-p or -partition
-pl or -plog
-ps or -pscreen
-r or -restart
-ro or -reorder
-sc or -screen
-sf or -suffix
-v or -var :ul
For example, lmp_ibm might be launched as follows:
mpirun -np 16 lmp_ibm -v f tmp.out -l my.log -sc none -in in.alloy
mpirun -np 16 lmp_ibm -var f tmp.out -log my.log -screen none -in in.alloy :pre
Here are the details on the options:
-echo style :pre
Set the style of command echoing. The style can be {none} or {screen}
or {log} or {both}. Depending on the style, each command read from
the input script will be echoed to the screen and/or logfile. This
can be useful to figure out which line of your script is causing an
input error. The default value is {log}. The echo style can also be
set by using the "echo"_echo.html command in the input script itself.
-help :pre
Print a brief help summary and a list of options compiled into this
executable for each LAMMPS style (atom_style, fix, compute,
pair_style, bond_style, etc). This can tell you if the command you
want to use was included via the appropriate package at compile time.
LAMMPS will print the info and immediately exit if this switch is
used.
-in file :pre
Specify a file to use as an input script. This is an optional switch
when running LAMMPS in one-partition mode. If it is not specified,
LAMMPS reads its script from standard input, typically from a script
via I/O redirection; e.g. lmp_linux < in.run. I/O redirection should
also work in parallel, but if it does not (in the unlikely case that
an MPI implementation does not support it), then use the -in flag.
Note that this is a required switch when running LAMMPS in
multi-partition mode, since multiple processors cannot all read from
stdin.
-kokkos on/off keyword/value ... :pre
Explicitly enable or disable KOKKOS support, as provided by the KOKKOS
package. Even if LAMMPS is built with this package, as described
above in "Section 2.3"_#start_3, this switch must be set to enable
running with the KOKKOS-enabled styles the package provides. If the
switch is not set (the default), LAMMPS will operate as if the KOKKOS
package were not installed; i.e. you can run standard LAMMPS or with
the GPU or USER-OMP packages, for testing or benchmarking purposes.
Additional optional keyword/value pairs can be specified which
determine how Kokkos will use the underlying hardware on your
platform. These settings apply to each MPI task you launch via the
"mpirun" or "mpiexec" command. You may choose to run one or more MPI
tasks per physical node. Note that if you are running on a desktop
machine, you typically have one physical node. On a cluster or
supercomputer there may be dozens or 1000s of physical nodes.
Either the full word or an abbreviation can be used for the keywords.
Note that the keywords do not use a leading minus sign. I.e. the
keyword is "t", not "-t". Also note that each of the keywords has a
default setting. Example of when to use these options and what
settings to use on different platforms is given in "Section
5.3"_Section_accelerate.html#acc_3.
d or device
g or gpus
t or threads
n or numa :ul
device Nd :pre
This option is only relevant if you built LAMMPS with CUDA=yes, you
have more than one GPU per node, and if you are running with only one
MPI task per node. The Nd setting is the ID of the GPU on the node to
run on. By default Nd = 0. If you have multiple GPUs per node, they
have consecutive IDs numbered as 0,1,2,etc. This setting allows you
to launch multiple independent jobs on the node, each with a single
MPI task per node, and assign each job to run on a different GPU.
gpus Ng Ns :pre
This option is only relevant if you built LAMMPS with CUDA=yes, you
have more than one GPU per node, and you are running with multiple MPI
tasks per node (up to one per GPU). The Ng setting is how many GPUs
you will use. The Ns setting is optional. If set, it is the ID of a
GPU to skip when assigning MPI tasks to GPUs. This may be useful if
your desktop system reserves one GPU to drive the screen and the rest
are intended for computational work like running LAMMPS. By default
Ng = 1 and Ns is not set.
Depending on which flavor of MPI you are running, LAMMPS will look for
one of these 3 environment variables
SLURM_LOCALID (various MPI variants compiled with SLURM support)
MV2_COMM_WORLD_LOCAL_RANK (Mvapich)
OMPI_COMM_WORLD_LOCAL_RANK (OpenMPI) :pre
which are initialized by the "srun", "mpirun" or "mpiexec" commands.
The environment variable setting for each MPI rank is used to assign a
unique GPU ID to the MPI task.
threads Nt :pre
This option assigns Nt number of threads to each MPI task for
performing work when Kokkos is executing in OpenMP or pthreads mode.
The default is Nt = 1, which essentially runs in MPI-only mode. If
there are Np MPI tasks per physical node, you generally want Np*Nt =
the number of physical cores per node, to use your available hardware
optimally. This also sets the number of threads used by the host when
LAMMPS is compiled with CUDA=yes.
numa Nm :pre
This option is only relevant when using pthreads with hwloc support.
In this case Nm defines the number of NUMA regions (typicaly sockets)
on a node which will be utilizied by a single MPI rank. By default Nm
= 1. If this option is used the total number of worker-threads per
MPI rank is threads*numa. Currently it is always almost better to
assign at least one MPI rank per NUMA region, and leave numa set to
its default value of 1. This is because letting a single process span
multiple NUMA regions induces a significant amount of cross NUMA data
traffic which is slow.
-log file :pre
Specify a log file for LAMMPS to write status information to. In
one-partition mode, if the switch is not used, LAMMPS writes to the
file log.lammps. If this switch is used, LAMMPS writes to the
specified file. In multi-partition mode, if the switch is not used, a
log.lammps file is created with hi-level status information. Each
partition also writes to a log.lammps.N file where N is the partition
ID. If the switch is specified in multi-partition mode, the hi-level
logfile is named "file" and each partition also logs information to a
file.N. For both one-partition and multi-partition mode, if the
specified file is "none", then no log files are created. Using a
"log"_log.html command in the input script will override this setting.
Option -plog will override the name of the partition log files file.N.
-nocite :pre
Disable writing the log.cite file which is normally written to list
references for specific cite-able features used during a LAMMPS run.
See the "citation page"_http://lammps.sandia.gov/cite.html for more
details.
-package style args .... :pre
Invoke the "package"_package.html command with style and args. The
syntax is the same as if the command appeared at the top of the input
script. For example "-package gpu 2" or "-pk gpu 2" is the same as
"package gpu 2"_package.html in the input script. The possible styles
and args are documented on the "package"_package.html doc page. This
switch can be used multiple times, e.g. to set options for the
USER-INTEL and USER-OMP packages which can be used together.
Along with the "-suffix" command-line switch, this is a convenient
mechanism for invoking accelerator packages and their options without
having to edit an input script.
-partition 8x2 4 5 ... :pre
Invoke LAMMPS in multi-partition mode. When LAMMPS is run on P
processors and this switch is not used, LAMMPS runs in one partition,
i.e. all P processors run a single simulation. If this switch is
used, the P processors are split into separate partitions and each
partition runs its own simulation. The arguments to the switch
specify the number of processors in each partition. Arguments of the
form MxN mean M partitions, each with N processors. Arguments of the
form N mean a single partition with N processors. The sum of
processors in all partitions must equal P. Thus the command
"-partition 8x2 4 5" has 10 partitions and runs on a total of 25
processors.
Running with multiple partitions can e useful for running
"multi-replica simulations"_Section_howto.html#howto_5, where each
replica runs on on one or a few processors. Note that with MPI
installed on a machine (e.g. your desktop), you can run on more
(virtual) processors than you have physical processors.
To run multiple independent simulatoins from one input script, using
multiple partitions, see "Section 6.4"_Section_howto.html#howto_4
of the manual. World- and universe-style "variables"_variable.html
are useful in this context.
-plog file :pre
Specify the base name for the partition log files, so partition N
writes log information to file.N. If file is none, then no partition
log files are created. This overrides the filename specified in the
-log command-line option. This option is useful when working with
large numbers of partitions, allowing the partition log files to be
suppressed (-plog none) or placed in a sub-directory (-plog
replica_files/log.lammps) If this option is not used the log file for
partition N is log.lammps.N or whatever is specified by the -log
command-line option.
-pscreen file :pre
Specify the base name for the partition screen file, so partition N
writes screen information to file.N. If file is none, then no
partition screen files are created. This overrides the filename
specified in the -screen command-line option. This option is useful
when working with large numbers of partitions, allowing the partition
screen files to be suppressed (-pscreen none) or placed in a
sub-directory (-pscreen replica_files/screen). If this option is not
used the screen file for partition N is screen.N or whatever is
specified by the -screen command-line option.
-restart restartfile {remap} datafile keyword value ... :pre
Convert the restart file into a data file and immediately exit. This
is the same operation as if the following 2-line input script were
run:
read_restart restartfile {remap}
write_data datafile keyword value ... :pre
Note that the specified restartfile and datafile can have wild-card
characters ("*",%") as described by the
"read_restart"_read_restart.html and "write_data"_write_data.html
commands. But a filename such as file.* will need to be enclosed in
quotes to avoid shell expansion of the "*" character.
Note that following restartfile, the optional flag {remap} can be
used. This has the same effect as adding it to the
"read_restart"_read_restart.html command, as explained on its doc
page. This is only useful if the reading of the restart file triggers
an error that atoms have been lost. In that case, use of the remap
flag should allow the data file to still be produced.
Also note that following datafile, the same optional keyword/value
pairs can be listed as used by the "write_data"_write_data.html
command.
-reorder nth N
-reorder custom filename :pre
Reorder the processors in the MPI communicator used to instantiate
LAMMPS, in one of several ways. The original MPI communicator ranks
all P processors from 0 to P-1. The mapping of these ranks to
physical processors is done by MPI before LAMMPS begins. It may be
useful in some cases to alter the rank order. E.g. to insure that
cores within each node are ranked in a desired order. Or when using
the "run_style verlet/split"_run_style.html command with 2 partitions
to insure that a specific Kspace processor (in the 2nd partition) is
matched up with a specific set of processors in the 1st partition.
See the "Section 5"_Section_accelerate.html doc pages for
more details.
If the keyword {nth} is used with a setting {N}, then it means every
Nth processor will be moved to the end of the ranking. This is useful
when using the "run_style verlet/split"_run_style.html command with 2
partitions via the -partition command-line switch. The first set of
processors will be in the first partition, the 2nd set in the 2nd
partition. The -reorder command-line switch can alter this so that
the 1st N procs in the 1st partition and one proc in the 2nd partition
will be ordered consecutively, e.g. as the cores on one physical node.
This can boost performance. For example, if you use "-reorder nth 4"
and "-partition 9 3" and you are running on 12 processors, the
processors will be reordered from
0 1 2 3 4 5 6 7 8 9 10 11 :pre
to
0 1 2 4 5 6 8 9 10 3 7 11 :pre
so that the processors in each partition will be
0 1 2 4 5 6 8 9 10
3 7 11 :pre
See the "processors" command for how to insure processors from each
partition could then be grouped optimally for quad-core nodes.
If the keyword is {custom}, then a file that specifies a permutation
of the processor ranks is also specified. The format of the reorder
file is as follows. Any number of initial blank or comment lines
(starting with a "#" character) can be present. These should be
followed by P lines of the form:
I J :pre
where P is the number of processors LAMMPS was launched with. Note
that if running in multi-partition mode (see the -partition switch
above) P is the total number of processors in all partitions. The I
and J values describe a permutation of the P processors. Every I and
J should be values from 0 to P-1 inclusive. In the set of P I values,
every proc ID should appear exactly once. Ditto for the set of P J
values. A single I,J pairing means that the physical processor with
rank I in the original MPI communicator will have rank J in the
reordered communicator.
Note that rank ordering can also be specified by many MPI
implementations, either by environment variables that specify how to
order physical processors, or by config files that specify what
physical processors to assign to each MPI rank. The -reorder switch
simply gives you a portable way to do this without relying on MPI
itself. See the "processors out"_processors.html command for how
to output info on the final assignment of physical processors to
the LAMMPS simulation domain.
-screen file :pre
Specify a file for LAMMPS to write its screen information to. In
one-partition mode, if the switch is not used, LAMMPS writes to the
screen. If this switch is used, LAMMPS writes to the specified file
instead and you will see no screen output. In multi-partition mode,
if the switch is not used, hi-level status information is written to
the screen. Each partition also writes to a screen.N file where N is
the partition ID. If the switch is specified in multi-partition mode,
the hi-level screen dump is named "file" and each partition also
writes screen information to a file.N. For both one-partition and
multi-partition mode, if the specified file is "none", then no screen
output is performed. Option -pscreen will override the name of the
partition screen files file.N.
-suffix style args :pre
Use variants of various styles if they exist. The specified style can
be {cuda}, {gpu}, {intel}, {kk}, {omp}, {opt}, or {hybrid}. These
refer to optional packages that LAMMPS can be built with, as described
above in "Section 2.3"_#start_3. The "gpu" style corresponds to the
GPU package, the "intel" style to the USER-INTEL package, the "kk"
style to the KOKKOS package, the "opt" style to the OPT package, and
the "omp" style to the USER-OMP package. The hybrid style is the only
style that accepts arguments. It allows for two packages to be
specified. The first package specified is the default and will be used
if it is available. If no style is available for the first package,
the style for the second package will be used if available. For
example, "-suffix hybrid intel omp" will use styles from the
USER-INTEL package if they are installed and available, but styles for
the USER-OMP package otherwise.
Along with the "-package" command-line switch, this is a convenient
mechanism for invoking accelerator packages and their options without
having to edit an input script.
As an example, all of the packages provide a "pair_style
lj/cut"_pair_lj.html variant, with style names lj/cut/gpu,
lj/cut/intel, lj/cut/kk, lj/cut/omp, and lj/cut/opt. A variant style
can be specified explicitly in your input script, e.g. pair_style
lj/cut/gpu. If the -suffix switch is used the specified suffix
(gpu,intel,kk,omp,opt) is automatically appended whenever your input
script command creates a new "atom"_atom_style.html,
"pair"_pair_style.html, "fix"_fix.html, "compute"_compute.html, or
"run"_run_style.html style. If the variant version does not exist,
the standard version is created.
For the GPU package, using this command-line switch also invokes the
default GPU settings, as if the command "package gpu 1" were used at
the top of your input script. These settings can be changed by using
the "-package gpu" command-line switch or the "package
gpu"_package.html command in your script.
For the USER-INTEL package, using this command-line switch also
invokes the default USER-INTEL settings, as if the command "package
intel 1" were used at the top of your input script. These settings
can be changed by using the "-package intel" command-line switch or
the "package intel"_package.html command in your script. If the
USER-OMP package is also installed, the hybrid style with "intel omp"
arguments can be used to make the omp suffix a second choice, if a
requested style is not available in the USER-INTEL package. It will
also invoke the default USER-OMP settings, as if the command "package
omp 0" were used at the top of your input script. These settings can
be changed by using the "-package omp" command-line switch or the
"package omp"_package.html command in your script.
For the KOKKOS package, using this command-line switch also invokes
the default KOKKOS settings, as if the command "package kokkos" were
used at the top of your input script. These settings can be changed
by using the "-package kokkos" command-line switch or the "package
kokkos"_package.html command in your script.
For the OMP package, using this command-line switch also invokes the
default OMP settings, as if the command "package omp 0" were used at
the top of your input script. These settings can be changed by using
the "-package omp" command-line switch or the "package
omp"_package.html command in your script.
The "suffix"_suffix.html command can also be used within an input
script to set a suffix, or to turn off or back on any suffix setting
made via the command line.
-var name value1 value2 ... :pre
Specify a variable that will be defined for substitution purposes when
the input script is read. This switch can be used multiple times to
define multiple variables. "Name" is the variable name which can be a
single character (referenced as $x in the input script) or a full
string (referenced as $\{abc\}). An "index-style
variable"_variable.html will be created and populated with the
subsequent values, e.g. a set of filenames. Using this command-line
option is equivalent to putting the line "variable name index value1
value2 ..." at the beginning of the input script. Defining an index
variable as a command-line argument overrides any setting for the same
index variable in the input script, since index variables cannot be
re-defined. See the "variable"_variable.html command for more info on
defining index and other kinds of variables and "this
section"_Section_commands.html#cmd_2 for more info on using variables
in input scripts.
NOTE: Currently, the command-line parser looks for arguments that
start with "-" to indicate new switches. Thus you cannot specify
multiple variable values if any of they start with a "-", e.g. a
negative numeric value. It is OK if the first value1 starts with a
"-", since it is automatically skipped.
:line
2.7 LAMMPS screen output :h4,link(start_7)
As LAMMPS reads an input script, it prints information to both the
screen and a log file about significant actions it takes to setup a
simulation. When the simulation is ready to begin, LAMMPS performs
various initializations and prints the amount of memory (in MBytes per
processor) that the simulation requires. It also prints details of
the initial thermodynamic state of the system. During the run itself,
thermodynamic information is printed periodically, every few
timesteps. When the run concludes, LAMMPS prints the final
thermodynamic state and a total run time for the simulation. It then
appends statistics about the CPU time and storage requirements for the
simulation. An example set of statistics is shown here:
Loop time of 2.81192 on 4 procs for 300 steps with 2004 atoms :pre
Performance: 18.436 ns/day 1.302 hours/ns 106.689 timesteps/s
97.0% CPU use with 4 MPI tasks x no OpenMP threads :pre
MPI task timings breakdown:
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 1.9808 | 2.0134 | 2.0318 | 1.4 | 71.60
Bond | 0.0021894 | 0.0060319 | 0.010058 | 4.7 | 0.21
Kspace | 0.3207 | 0.3366 | 0.36616 | 3.1 | 11.97
Neigh | 0.28411 | 0.28464 | 0.28516 | 0.1 | 10.12
Comm | 0.075732 | 0.077018 | 0.07883 | 0.4 | 2.74
Output | 0.00030518 | 0.00042665 | 0.00078821 | 1.0 | 0.02
Modify | 0.086606 | 0.086631 | 0.086668 | 0.0 | 3.08
Other | | 0.007178 | | | 0.26 :pre
Nlocal: 501 ave 508 max 490 min
Histogram: 1 0 0 0 0 0 1 1 0 1
Nghost: 6586.25 ave 6628 max 6548 min
Histogram: 1 0 1 0 0 0 1 0 0 1
Neighs: 177007 ave 180562 max 170212 min
Histogram: 1 0 0 0 0 0 0 1 1 1 :pre
Total # of neighbors = 708028
Ave neighs/atom = 353.307
Ave special neighs/atom = 2.34032
Neighbor list builds = 26
Dangerous builds = 0 :pre
The first section provides a global loop timing summary. The {loop time}
is the total wall time for the section. The {Performance} line is
provided for convenience to help predicting the number of loop
continuations required and for comparing performance with other,
similar MD codes. The {CPU use} line provides the CPU utilzation per
MPI task; it should be close to 100% times the number of OpenMP
threads (or 1 of no OpenMP). Lower numbers correspond to delays due
to file I/O or insufficient thread utilization.
The MPI task section gives the breakdown of the CPU run time (in
seconds) into major categories:
{Pair} stands for all non-bonded force computation
{Bond} stands for bonded interactions: bonds, angles, dihedrals, impropers
{Kspace} stands for reciprocal space interactions: Ewald, PPPM, MSM
{Neigh} stands for neighbor list construction
{Comm} stands for communicating atoms and their properties
{Output} stands for writing dumps and thermo output
{Modify} stands for fixes and computes called by them
{Other} is the remaining time :ul
For each category, there is a breakdown of the least, average and most
amount of wall time a processor spent on this section. Also you have the
variation from the average time. Together these numbers allow to gauge
the amount of load imbalance in this segment of the calculation. Ideally
the difference between minimum, maximum and average is small and thus
the variation from the average close to zero. The final column shows
the percentage of the total loop time is spent in this section.
When using the "timer full"_timer.html setting, an additional column
is present that also prints the CPU utilization in percent. In
addition, when using {timer full} and the "package omp"_package.html
command are active, a similar timing summary of time spent in threaded
regions to monitor thread utilization and load balance is provided. A
new entry is the {Reduce} section, which lists the time spent in
reducing the per-thread data elements to the storage for non-threaded
computation. These thread timings are taking from the first MPI rank
only and and thus, as the breakdown for MPI tasks can change from MPI
rank to MPI rank, this breakdown can be very different for individual
ranks. Here is an example output for this section:
Thread timings breakdown (MPI rank 0):
Total threaded time 0.6846 / 90.6%
Section | min time | avg time | max time |%varavg| %total
---------------------------------------------------------------
Pair | 0.5127 | 0.5147 | 0.5167 | 0.3 | 75.18
Bond | 0.0043139 | 0.0046779 | 0.0050418 | 0.5 | 0.68
Kspace | 0.070572 | 0.074541 | 0.07851 | 1.5 | 10.89
Neigh | 0.084778 | 0.086969 | 0.089161 | 0.7 | 12.70
Reduce | 0.0036485 | 0.003737 | 0.0038254 | 0.1 | 0.55 :pre
The third section lists the number of owned atoms (Nlocal), ghost atoms
(Nghost), and pair-wise neighbors stored per processor. The max and min
values give the spread of these values across processors with a 10-bin
histogram showing the distribution. The total number of histogram counts
is equal to the number of processors.
The last section gives aggregate statistics for pair-wise neighbors
and special neighbors that LAMMPS keeps track of (see the
"special_bonds"_special_bonds.html command). The number of times
neighbor lists were rebuilt during the run is given as well as the
number of potentially "dangerous" rebuilds. If atom movement
triggered neighbor list rebuilding (see the
"neigh_modify"_neigh_modify.html command), then dangerous
reneighborings are those that were triggered on the first timestep
atom movement was checked for. If this count is non-zero you may wish
to reduce the delay factor to insure no force interactions are missed
by atoms moving beyond the neighbor skin distance before a rebuild
takes place.
If an energy minimization was performed via the
"minimize"_minimize.html command, additional information is printed,
e.g.
Minimization stats:
Stopping criterion = linesearch alpha is zero
Energy initial, next-to-last, final =
-6372.3765206 -8328.46998942 -8328.46998942
Force two-norm initial, final = 1059.36 5.36874
Force max component initial, final = 58.6026 1.46872
Final line search alpha, max atom move = 2.7842e-10 4.0892e-10
Iterations, force evaluations = 701 1516 :pre
The first line prints the criterion that determined the minimization
to be completed. The third line lists the initial and final energy,
as well as the energy on the next-to-last iteration. The next 2 lines
give a measure of the gradient of the energy (force on all atoms).
The 2-norm is the "length" of this force vector; the inf-norm is the
largest component. Then some information about the line search and
statistics on how many iterations and force-evaluations the minimizer
required. Multiple force evaluations are typically done at each
iteration to perform a 1d line minimization in the search direction.
If a "kspace_style"_kspace_style.html long-range Coulombics solve was
performed during the run (PPPM, Ewald), then additional information is
printed, e.g.
FFT time (% of Kspce) = 0.200313 (8.34477)
FFT Gflps 3d 1d-only = 2.31074 9.19989 :pre
The first line gives the time spent doing 3d FFTs (4 per timestep) and
the fraction it represents of the total KSpace time (listed above).
Each 3d FFT requires computation (3 sets of 1d FFTs) and communication
(transposes). The total flops performed is 5Nlog_2(N), where N is the
number of points in the 3d grid. The FFTs are timed with and without
the communication and a Gflop rate is computed. The 3d rate is with
communication; the 1d rate is without (just the 1d FFTs). Thus you
can estimate what fraction of your FFT time was spent in
communication, roughly 75% in the example above.
:line
2.8 Tips for users of previous LAMMPS versions :h4,link(start_8)
The current C++ began with a complete rewrite of LAMMPS 2001, which
was written in F90. Features of earlier versions of LAMMPS are listed
in "Section 13"_Section_history.html. The F90 and F77 versions
(2001 and 99) are also freely distributed as open-source codes; check
the "LAMMPS WWW Site"_lws for distribution information if you prefer
those versions. The 99 and 2001 versions are no longer under active
development; they do not have all the features of C++ LAMMPS.
If you are a previous user of LAMMPS 2001, these are the most
significant changes you will notice in C++ LAMMPS:
(1) The names and arguments of many input script commands have
changed. All commands are now a single word (e.g. read_data instead
of read data).
(2) All the functionality of LAMMPS 2001 is included in C++ LAMMPS,
but you may need to specify the relevant commands in different ways.
(3) The format of the data file can be streamlined for some problems.
See the "read_data"_read_data.html command for details. The data file
section "Nonbond Coeff" has been renamed to "Pair Coeff" in C++ LAMMPS.
(4) Binary restart files written by LAMMPS 2001 cannot be read by C++
LAMMPS with a "read_restart"_read_restart.html command. This is
because they were output by F90 which writes in a different binary
format than C or C++ writes or reads. Use the {restart2data} tool
provided with LAMMPS 2001 to convert the 2001 restart file to a text
data file. Then edit the data file as necessary before using the C++
LAMMPS "read_data"_read_data.html command to read it in.
(5) There are numerous small numerical changes in C++ LAMMPS that mean
you will not get identical answers when comparing to a 2001 run.
However, your initial thermodynamic energy and MD trajectory should be
close if you have setup the problem for both codes the same.
diff --git a/doc/src/accelerate_gpu.txt b/doc/src/accelerate_gpu.txt
index 2ac7d62f6..68e9fa477 100644
--- a/doc/src/accelerate_gpu.txt
+++ b/doc/src/accelerate_gpu.txt
@@ -1,254 +1,254 @@
"Previous Section"_Section_packages.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
"Return to Section accelerate overview"_Section_accelerate.html
5.3.1 GPU package :h5
The GPU package was developed by Mike Brown at ORNL and his
collaborators, particularly Trung Nguyen (ORNL). It provides GPU
versions of many pair styles, including the 3-body Stillinger-Weber
pair style, and for "kspace_style pppm"_kspace_style.html for
long-range Coulombics. It has the following general features:
It is designed to exploit common GPU hardware configurations where one
or more GPUs are coupled to many cores of one or more multi-core CPUs,
e.g. within a node of a parallel machine. :ulb,l
Atom-based data (e.g. coordinates, forces) moves back-and-forth
between the CPU(s) and GPU every timestep. :l
Neighbor lists can be built on the CPU or on the GPU :l
The charge assignment and force interpolation portions of PPPM can be
run on the GPU. The FFT portion, which requires MPI communication
between processors, runs on the CPU. :l
Asynchronous force computations can be performed simultaneously on the
CPU(s) and GPU. :l
It allows for GPU computations to be performed in single or double
precision, or in mixed-mode precision, where pairwise forces are
computed in single precision, but accumulated into double-precision
force vectors. :l
LAMMPS-specific code is in the GPU package. It makes calls to a
generic GPU library in the lib/gpu directory. This library provides
NVIDIA support as well as more general OpenCL support, so that the
same functionality can eventually be supported on a variety of GPU
hardware. :l
:ule
Here is a quick overview of how to enable and use the GPU package:
build the library in lib/gpu for your GPU hardware with the desired precision settings
install the GPU package and build LAMMPS as usual
use the mpirun command to set the number of MPI tasks/node which determines the number of MPI tasks/GPU
specify the # of GPUs per node
use GPU styles in your input script :ul
The latter two steps can be done using the "-pk gpu" and "-sf gpu"
-"command-line switches"_Section_start.html#start_7 respectively. Or
+"command-line switches"_Section_start.html#start_6 respectively. Or
the effect of the "-pk" or "-sf" switches can be duplicated by adding
the "package gpu"_package.html or "suffix gpu"_suffix.html commands
respectively to your input script.
[Required hardware/software:]
To use this package, you currently need to have an NVIDIA GPU and
install the NVIDIA Cuda software on your system:
Check if you have an NVIDIA GPU: cat /proc/driver/nvidia/gpus/0/information
Go to http://www.nvidia.com/object/cuda_get.html
Install a driver and toolkit appropriate for your system (SDK is not necessary)
Run lammps/lib/gpu/nvc_get_devices (after building the GPU library, see below) to list supported devices and properties :ul
[Building LAMMPS with the GPU package:]
This requires two steps (a,b): build the GPU library, then build
LAMMPS with the GPU package.
You can do both these steps in one line, using the src/Make.py script,
-described in "Section 2.4"_Section_start.html#start_4 of the manual.
+described in "Section 4"_Section_packages.html of the manual.
Type "Make.py -h" for help. If run from the src directory, this
command will create src/lmp_gpu using src/MAKE/Makefile.mpi as the
starting Makefile.machine:
Make.py -p gpu -gpu mode=single arch=31 -o gpu -a lib-gpu file mpi :pre
Or you can follow these two (a,b) steps:
(a) Build the GPU library
The GPU library is in lammps/lib/gpu. Select a Makefile.machine (in
lib/gpu) appropriate for your system. You should pay special
attention to 3 settings in this makefile.
CUDA_HOME = needs to be where NVIDIA Cuda software is installed on your system
CUDA_ARCH = needs to be appropriate to your GPUs
CUDA_PREC = precision (double, mixed, single) you desire :ul
See lib/gpu/Makefile.linux.double for examples of the ARCH settings
for different GPU choices, e.g. Fermi vs Kepler. It also lists the
possible precision settings:
CUDA_PREC = -D_SINGLE_SINGLE # single precision for all calculations
CUDA_PREC = -D_DOUBLE_DOUBLE # double precision for all calculations
CUDA_PREC = -D_SINGLE_DOUBLE # accumulation of forces, etc, in double :pre
The last setting is the mixed mode referred to above. Note that your
GPU must support double precision to use either the 2nd or 3rd of
these settings.
To build the library, type:
make -f Makefile.machine :pre
If successful, it will produce the files libgpu.a and Makefile.lammps.
The latter file has 3 settings that need to be appropriate for the
paths and settings for the CUDA system software on your machine.
Makefile.lammps is a copy of the file specified by the EXTRAMAKE
setting in Makefile.machine. You can change EXTRAMAKE or create your
own Makefile.lammps.machine if needed.
Note that to change the precision of the GPU library, you need to
re-build the entire library. Do a "clean" first, e.g. "make -f
Makefile.linux clean", followed by the make command above.
(b) Build LAMMPS with the GPU package
cd lammps/src
make yes-gpu
make machine :pre
No additional compile/link flags are needed in Makefile.machine.
Note that if you change the GPU library precision (discussed above)
and rebuild the GPU library, then you also need to re-install the GPU
package and re-build LAMMPS, so that all affected files are
re-compiled and linked to the new GPU library.
[Run with the GPU package from the command line:]
The mpirun or mpiexec command sets the total number of MPI tasks used
by LAMMPS (one or multiple per compute node) and the number of MPI
tasks used per node. E.g. the mpirun command in MPICH does this via
its -np and -ppn switches. Ditto for OpenMPI via -np and -npernode.
When using the GPU package, you cannot assign more than one GPU to a
single MPI task. However multiple MPI tasks can share the same GPU,
and in many cases it will be more efficient to run this way. Likewise
it may be more efficient to use less MPI tasks/node than the available
# of CPU cores. Assignment of multiple MPI tasks to a GPU will happen
automatically if you create more MPI tasks/node than there are
GPUs/mode. E.g. with 8 MPI tasks/node and 2 GPUs, each GPU will be
shared by 4 MPI tasks.
-Use the "-sf gpu" "command-line switch"_Section_start.html#start_7,
+Use the "-sf gpu" "command-line switch"_Section_start.html#start_6,
which will automatically append "gpu" to styles that support it. Use
-the "-pk gpu Ng" "command-line switch"_Section_start.html#start_7 to
+the "-pk gpu Ng" "command-line switch"_Section_start.html#start_6 to
set Ng = # of GPUs/node to use.
lmp_machine -sf gpu -pk gpu 1 -in in.script # 1 MPI task uses 1 GPU
mpirun -np 12 lmp_machine -sf gpu -pk gpu 2 -in in.script # 12 MPI tasks share 2 GPUs on a single 16-core (or whatever) node
mpirun -np 48 -ppn 12 lmp_machine -sf gpu -pk gpu 2 -in in.script # ditto on 4 16-core nodes :pre
Note that if the "-sf gpu" switch is used, it also issues a default
"package gpu 1"_package.html command, which sets the number of
GPUs/node to 1.
Using the "-pk" switch explicitly allows for setting of the number of
GPUs/node to use and additional options. Its syntax is the same as
same as the "package gpu" command. See the "package"_package.html
command doc page for details, including the default values used for
all its options if it is not specified.
Note that the default for the "package gpu"_package.html command is to
set the Newton flag to "off" pairwise interactions. It does not
affect the setting for bonded interactions (LAMMPS default is "on").
The "off" setting for pairwise interaction is currently required for
GPU package pair styles.
[Or run with the GPU package by editing an input script:]
The discussion above for the mpirun/mpiexec command, MPI tasks/node,
and use of multiple MPI tasks/GPU is the same.
Use the "suffix gpu"_suffix.html command, or you can explicitly add an
"gpu" suffix to individual styles in your input script, e.g.
pair_style lj/cut/gpu 2.5 :pre
You must also use the "package gpu"_package.html command to enable the
GPU package, unless the "-sf gpu" or "-pk gpu" "command-line
-switches"_Section_start.html#start_7 were used. It specifies the
+switches"_Section_start.html#start_6 were used. It specifies the
number of GPUs/node to use, as well as other options.
[Speed-ups to expect:]
The performance of a GPU versus a multi-core CPU is a function of your
hardware, which pair style is used, the number of atoms/GPU, and the
precision used on the GPU (double, single, mixed).
See the "Benchmark page"_http://lammps.sandia.gov/bench.html of the
LAMMPS web site for performance of the GPU package on various
hardware, including the Titan HPC platform at ORNL.
You should also experiment with how many MPI tasks per GPU to use to
give the best performance for your problem and machine. This is also
a function of the problem size and the pair style being using.
Likewise, you should experiment with the precision setting for the GPU
library to see if single or mixed precision will give accurate
results, since they will typically be faster.
[Guidelines for best performance:]
Using multiple MPI tasks per GPU will often give the best performance,
as allowed my most multi-core CPU/GPU configurations. :ulb,l
If the number of particles per MPI task is small (e.g. 100s of
particles), it can be more efficient to run with fewer MPI tasks per
GPU, even if you do not use all the cores on the compute node. :l
The "package gpu"_package.html command has several options for tuning
performance. Neighbor lists can be built on the GPU or CPU. Force
calculations can be dynamically balanced across the CPU cores and
GPUs. GPU-specific settings can be made which can be optimized
for different hardware. See the "packakge"_package.html command
doc page for details. :l
As described by the "package gpu"_package.html command, GPU
accelerated pair styles can perform computations asynchronously with
CPU computations. The "Pair" time reported by LAMMPS will be the
maximum of the time required to complete the CPU pair style
computations and the time required to complete the GPU pair style
computations. Any time spent for GPU-enabled pair styles for
computations that run simultaneously with "bond"_bond_style.html,
"angle"_angle_style.html, "dihedral"_dihedral_style.html,
"improper"_improper_style.html, and "long-range"_kspace_style.html
calculations will not be included in the "Pair" time. :l
When the {mode} setting for the package gpu command is force/neigh,
the time for neighbor list calculations on the GPU will be added into
the "Pair" time, not the "Neigh" time. An additional breakdown of the
times required for various tasks on the GPU (data copy, neighbor
calculations, force computations, etc) are output only with the LAMMPS
screen output (not in the log file) at the end of each run. These
timings represent total time spent on the GPU for each routine,
regardless of asynchronous CPU calculations. :l
The output section "GPU Time Info (average)" reports "Max Mem / Proc".
This is the maximum memory used at one time on the GPU for data
storage by a single MPI process. :l
:ule
[Restrictions:]
None.
diff --git a/doc/src/accelerate_intel.txt b/doc/src/accelerate_intel.txt
index 155e29e36..74ae9d9a4 100644
--- a/doc/src/accelerate_intel.txt
+++ b/doc/src/accelerate_intel.txt
@@ -1,517 +1,517 @@
"Previous Section"_Section_packages.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
"Return to Section accelerate overview"_Section_accelerate.html
5.3.2 USER-INTEL package :h5
The USER-INTEL package is maintained by Mike Brown at Intel
Corporation. It provides two methods for accelerating simulations,
depending on the hardware you have. The first is acceleration on
Intel CPUs by running in single, mixed, or double precision with
vectorization. The second is acceleration on Intel Xeon Phi
coprocessors via offloading neighbor list and non-bonded force
calculations to the Phi. The same C++ code is used in both cases.
When offloading to a coprocessor from a CPU, the same routine is run
twice, once on the CPU and once with an offload flag. This allows
LAMMPS to run on the CPU cores and coprocessor cores simultaneously.
[Currently Available USER-INTEL Styles:]
Angle Styles: charmm, harmonic :ulb,l
Bond Styles: fene, harmonic :l
Dihedral Styles: charmm, harmonic, opls :l
Fixes: nve, npt, nvt, nvt/sllod :l
Improper Styles: cvff, harmonic :l
Pair Styles: buck/coul/cut, buck/coul/long, buck, eam, gayberne,
charmm/coul/long, lj/cut, lj/cut/coul/long, lj/long/coul/long, sw, tersoff :l
K-Space Styles: pppm, pppm/disp :l
:ule
[Speed-ups to expect:]
The speedups will depend on your simulation, the hardware, which
styles are used, the number of atoms, and the floating-point
precision mode. Performance improvements are shown compared to
LAMMPS {without using other acceleration packages} as these are
under active development (and subject to performance changes). The
measurements were performed using the input files available in
the src/USER-INTEL/TEST directory with the provided run script.
These are scalable in size; the results given are with 512K
particles (524K for Liquid Crystal). Most of the simulations are
standard LAMMPS benchmarks (indicated by the filename extension in
parenthesis) with modifications to the run length and to add a
warmup run (for use with offload benchmarks).
:c,image(JPG/user_intel.png)
Results are speedups obtained on Intel Xeon E5-2697v4 processors
(code-named Broadwell) and Intel Xeon Phi 7250 processors
(code-named Knights Landing) with "June 2017" LAMMPS built with
Intel Parallel Studio 2017 update 2. Results are with 1 MPI task
per physical core. See {src/USER-INTEL/TEST/README} for the raw
simulation rates and instructions to reproduce.
:line
[Accuracy and order of operations:]
In most molecular dynamics software, parallelization parameters
(# of MPI, OpenMP, and vectorization) can change the results due
to changing the order of operations with finite-precision
calculations. The USER-INTEL package is deterministic. This means
that the results should be reproducible from run to run with the
{same} parallel configurations and when using determinstic
libraries or library settings (MPI, OpenMP, FFT). However, there
are differences in the USER-INTEL package that can change the
order of operations compared to LAMMPS without acceleration:
Neighbor lists can be created in a different order :ulb,l
Bins used for sorting atoms can be oriented differently :l
The default stencil order for PPPM is 7. By default, LAMMPS will
calculate other PPPM parameters to fit the desired acuracy with
this order :l
The {newton} setting applies to all atoms, not just atoms shared
between MPI tasks :l
Vectorization can change the order for adding pairwise forces :l
:ule
The precision mode (described below) used with the USER-INTEL
package can change the {accuracy} of the calculations. For the
default {mixed} precision option, calculations between pairs or
triplets of atoms are performed in single precision, intended to
be within the inherent error of MD simulations. All accumulation
is performed in double precision to prevent the error from growing
with the number of atoms in the simulation. {Single} precision
mode should not be used without appropriate validation.
:line
[Quick Start for Experienced Users:]
LAMMPS should be built with the USER-INTEL package installed.
Simulations should be run with 1 MPI task per physical {core},
not {hardware thread}.
Edit src/MAKE/OPTIONS/Makefile.intel_cpu_intelmpi as necessary. :ulb,l
Set the environment variable KMP_BLOCKTIME=0 :l
"-pk intel 0 omp $t -sf intel" added to LAMMPS command-line :l
$t should be 2 for Intel Xeon CPUs and 2 or 4 for Intel Xeon Phi :l
For some of the simple 2-body potentials without long-range
electrostatics, performance and scalability can be better with
the "newton off" setting added to the input script :l
For simulations on higher node counts, add "processors * * * grid
numa" to the beginning of the input script for better scalability :l
If using {kspace_style pppm} in the input script, add
"kspace_modify diff ad" for better performance :l
:ule
For Intel Xeon Phi CPUs:
Runs should be performed using MCDRAM. :ulb,l
:ule
For simulations using {kspace_style pppm} on Intel CPUs
supporting AVX-512:
Add "kspace_modify diff ad" to the input script :ulb,l
The command-line option should be changed to
"-pk intel 0 omp $r lrt yes -sf intel" where $r is the number of
threads minus 1. :l
Do not use thread affinity (set KMP_AFFINITY=none) :l
The "newton off" setting may provide better scalability :l
:ule
For Intel Xeon Phi coprocessors (Offload):
Edit src/MAKE/OPTIONS/Makefile.intel_coprocessor as necessary :ulb,l
"-pk intel N omp 1" added to command-line where N is the number of
coprocessors per node. :l
:ule
:line
[Required hardware/software:]
In order to use offload to coprocessors, an Intel Xeon Phi
coprocessor and an Intel compiler are required. For this, the
recommended version of the Intel compiler is 14.0.1.106 or
versions 15.0.2.044 and higher.
Although any compiler can be used with the USER-INTEL package,
currently, vectorization directives are disabled by default when
not using Intel compilers due to lack of standard support and
observations of decreased performance. The OpenMP standard now
supports directives for vectorization and we plan to transition the
code to this standard once it is available in most compilers. We
expect this to allow improved performance and support with other
compilers.
For Intel Xeon Phi x200 series processors (code-named Knights
Landing), there are multiple configuration options for the hardware.
For best performance, we recommend that the MCDRAM is configured in
"Flat" mode and with the cluster mode set to "Quadrant" or "SNC4".
"Cache" mode can also be used, although the performance might be
slightly lower.
[Notes about Simultaneous Multithreading:]
Modern CPUs often support Simultaneous Multithreading (SMT). On
Intel processors, this is called Hyper-Threading (HT) technology.
SMT is hardware support for running multiple threads efficiently on
a single core. {Hardware threads} or {logical cores} are often used
to refer to the number of threads that are supported in hardware.
For example, the Intel Xeon E5-2697v4 processor is described
as having 36 cores and 72 threads. This means that 36 MPI processes
or OpenMP threads can run simultaneously on separate cores, but that
up to 72 MPI processes or OpenMP threads can be running on the CPU
without costly operating system context switches.
Molecular dynamics simulations will often run faster when making use
of SMT. If a thread becomes stalled, for example because it is
waiting on data that has not yet arrived from memory, another thread
can start running so that the CPU pipeline is still being used
efficiently. Although benefits can be seen by launching a MPI task
for every hardware thread, for multinode simulations, we recommend
that OpenMP threads are used for SMT instead, either with the
USER-INTEL package, "USER-OMP package"_accelerate_omp.html, or
"KOKKOS package"_accelerate_kokkos.html. In the example above, up
to 36X speedups can be observed by using all 36 physical cores with
LAMMPS. By using all 72 hardware threads, an additional 10-30%
performance gain can be achieved.
The BIOS on many platforms allows SMT to be disabled, however, we do
not recommend this on modern processors as there is little to no
benefit for any software package in most cases. The operating system
will report every hardware thread as a separate core allowing one to
determine the number of hardware threads available. On Linux systems,
this information can normally be obtained with:
cat /proc/cpuinfo :pre
[Building LAMMPS with the USER-INTEL package:]
NOTE: See the src/USER-INTEL/README file for additional flags that
might be needed for best performance on Intel server processors
code-named "Skylake".
The USER-INTEL package must be installed into the source directory:
make yes-user-intel :pre
Several example Makefiles for building with the Intel compiler are
included with LAMMPS in the src/MAKE/OPTIONS/ directory:
Makefile.intel_cpu_intelmpi # Intel Compiler, Intel MPI, No Offload
Makefile.knl # Intel Compiler, Intel MPI, No Offload
Makefile.intel_cpu_mpich # Intel Compiler, MPICH, No Offload
Makefile.intel_cpu_openpmi # Intel Compiler, OpenMPI, No Offload
Makefile.intel_coprocessor # Intel Compiler, Intel MPI, Offload :pre
Makefile.knl is identical to Makefile.intel_cpu_intelmpi except that
it explicitly specifies that vectorization should be for Intel
Xeon Phi x200 processors making it easier to cross-compile. For
users with recent installations of Intel Parallel Studio, the
process can be as simple as:
make yes-user-intel
source /opt/intel/parallel_studio_xe_2016.3.067/psxevars.sh
# or psxevars.csh for C-shell
make intel_cpu_intelmpi :pre
Alternatively, the build can be accomplished with the src/Make.py
-script, described in "Section 2.4"_Section_start.html#start_4 of the
+script, described in "Section 4"_Section_packages.html of the
manual. Type "Make.py -h" for help. For an example:
Make.py -v -p intel omp -intel cpu -a file intel_cpu_intelmpi :pre
Note that if you build with support for a Phi coprocessor, the same
binary can be used on nodes with or without coprocessors installed.
However, if you do not have coprocessors on your system, building
without offload support will produce a smaller binary.
The general requirements for Makefiles with the USER-INTEL package
are as follows. "-DLAMMPS_MEMALIGN=64" is required for CCFLAGS. When
using Intel compilers, "-restrict" is required and "-qopenmp" is
highly recommended for CCFLAGS and LINKFLAGS. LIB should include
"-ltbbmalloc". For builds supporting offload, "-DLMP_INTEL_OFFLOAD"
is required for CCFLAGS and "-qoffload" is required for LINKFLAGS.
Other recommended CCFLAG options for best performance are
"-O2 -fno-alias -ansi-alias -qoverride-limits fp-model fast=2
-no-prec-div". The Make.py command will add all of these
automatically.
NOTE: The vectorization and math capabilities can differ depending on
the CPU. For Intel compilers, the "-x" flag specifies the type of
processor for which to optimize. "-xHost" specifies that the compiler
should build for the processor used for compiling. For Intel Xeon Phi
x200 series processors, this option is "-xMIC-AVX512". For fourth
generation Intel Xeon (v4/Broadwell) processors, "-xCORE-AVX2" should
be used. For older Intel Xeon processors, "-xAVX" will perform best
in general for the different simulations in LAMMPS. The default
in most of the example Makefiles is to use "-xHost", however this
should not be used when cross-compiling.
[Running LAMMPS with the USER-INTEL package:]
Running LAMMPS with the USER-INTEL package is similar to normal use
with the exceptions that one should 1) specify that LAMMPS should use
the USER-INTEL package, 2) specify the number of OpenMP threads, and
3) optionally specify the specific LAMMPS styles that should use the
USER-INTEL package. 1) and 2) can be performed from the command-line
or by editing the input script. 3) requires editing the input script.
Advanced performance tuning options are also described below to get
the best performance.
When running on a single node (including runs using offload to a
coprocessor), best performance is normally obtained by using 1 MPI
task per physical core and additional OpenMP threads with SMT. For
Intel Xeon processors, 2 OpenMP threads should be used for SMT.
For Intel Xeon Phi CPUs, 2 or 4 OpenMP threads should be used
(best choice depends on the simulation). In cases where the user
specifies that LRT mode is used (described below), 1 or 3 OpenMP
threads should be used. For multi-node runs, using 1 MPI task per
physical core will often perform best, however, depending on the
machine and scale, users might get better performance by decreasing
the number of MPI tasks and using more OpenMP threads. For
performance, the product of the number of MPI tasks and OpenMP
threads should not exceed the number of available hardware threads in
almost all cases.
NOTE: Setting core affinity is often used to pin MPI tasks and OpenMP
threads to a core or group of cores so that memory access can be
uniform. Unless disabled at build time, affinity for MPI tasks and
OpenMP threads on the host (CPU) will be set by default on the host
{when using offload to a coprocessor}. In this case, it is unnecessary
to use other methods to control affinity (e.g. taskset, numactl,
I_MPI_PIN_DOMAIN, etc.). This can be disabled with the {no_affinity}
option to the "package intel"_package.html command or by disabling the
option at build time (by adding -DINTEL_OFFLOAD_NOAFFINITY to the
CCFLAGS line of your Makefile). Disabling this option is not
recommended, especially when running on a machine with Intel
Hyper-Threading technology disabled.
[Run with the USER-INTEL package from the command line:]
To enable USER-INTEL optimizations for all available styles used in
the input script, the "-sf intel"
-"command-line switch"_Section_start.html#start_7 can be used without
+"command-line switch"_Section_start.html#start_6 can be used without
any requirement for editing the input script. This switch will
automatically append "intel" to styles that support it. It also
invokes a default command: "package intel 1"_package.html. This
package command is used to set options for the USER-INTEL package.
The default package command will specify that USER-INTEL calculations
are performed in mixed precision, that the number of OpenMP threads
is specified by the OMP_NUM_THREADS environment variable, and that
if coprocessors are present and the binary was built with offload
support, that 1 coprocessor per node will be used with automatic
balancing of work between the CPU and the coprocessor.
You can specify different options for the USER-INTEL package by using
-the "-pk intel Nphi" "command-line switch"_Section_start.html#start_7
+the "-pk intel Nphi" "command-line switch"_Section_start.html#start_6
with keyword/value pairs as specified in the documentation. Here,
Nphi = # of Xeon Phi coprocessors/node (ignored without offload
support). Common options to the USER-INTEL package include {omp} to
override any OMP_NUM_THREADS setting and specify the number of OpenMP
threads, {mode} to set the floating-point precision mode, and
{lrt} to enable Long-Range Thread mode as described below. See the
"package intel"_package.html command for details, including the
default values used for all its options if not specified, and how to
set the number of OpenMP threads via the OMP_NUM_THREADS environment
variable if desired.
Examples (see documentation for your MPI/Machine for differences in
launching MPI applications):
mpirun -np 72 -ppn 36 lmp_machine -sf intel -in in.script # 2 nodes, 36 MPI tasks/node, $OMP_NUM_THREADS OpenMP Threads
mpirun -np 72 -ppn 36 lmp_machine -sf intel -in in.script -pk intel 0 omp 2 mode double # Don't use any coprocessors that might be available, use 2 OpenMP threads for each task, use double precision :pre
[Or run with the USER-INTEL package by editing an input script:]
As an alternative to adding command-line arguments, the input script
can be edited to enable the USER-INTEL package. This requires adding
the "package intel"_package.html command to the top of the input
script. For the second example above, this would be:
package intel 0 omp 2 mode double :pre
To enable the USER-INTEL package only for individual styles, you can
add an "intel" suffix to the individual style, e.g.:
pair_style lj/cut/intel 2.5 :pre
Alternatively, the "suffix intel"_suffix.html command can be added to
the input script to enable USER-INTEL styles for the commands that
follow in the input script.
[Tuning for Performance:]
NOTE: The USER-INTEL package will perform better with modifications
to the input script when "PPPM"_kspace_style.html is used:
"kspace_modify diff ad"_kspace_modify.html should be added to the
input script.
Long-Range Thread (LRT) mode is an option to the "package
intel"_package.html command that can improve performance when using
"PPPM"_kspace_style.html for long-range electrostatics on processors
with SMT. It generates an extra pthread for each MPI task. The thread
is dedicated to performing some of the PPPM calculations and MPI
communications. On Intel Xeon Phi x200 series CPUs, this will likely
always improve performance, even on a single node. On Intel Xeon
processors, using this mode might result in better performance when
using multiple nodes, depending on the machine. To use this mode,
specify that the number of OpenMP threads is one less than would
normally be used for the run and add the "lrt yes" option to the "-pk"
command-line suffix or "package intel" command. For example, if a run
would normally perform best with "-pk intel 0 omp 4", instead use
"-pk intel 0 omp 3 lrt yes". When using LRT, you should set the
environment variable "KMP_AFFINITY=none". LRT mode is not supported
when using offload.
NOTE: Changing the "newton"_newton.html setting to off can improve
performance and/or scalability for simple 2-body potentials such as
lj/cut or when using LRT mode on processors supporting AVX-512.
Not all styles are supported in the USER-INTEL package. You can mix
the USER-INTEL package with styles from the "OPT"_accelerate_opt.html
package or the "USER-OMP package"_accelerate_omp.html. Of course,
this requires that these packages were installed at build time. This
can performed automatically by using "-sf hybrid intel opt" or
"-sf hybrid intel omp" command-line options. Alternatively, the "opt"
and "omp" suffixes can be appended manually in the input script. For
the latter, the "package omp"_package.html command must be in the
input script or the "-pk omp Nt" "command-line
-switch"_Section_start.html#start_7 must be used where Nt is the
+switch"_Section_start.html#start_6 must be used where Nt is the
number of OpenMP threads. The number of OpenMP threads should not be
set differently for the different packages. Note that the "suffix
hybrid intel omp"_suffix.html command can also be used within the
input script to automatically append the "omp" suffix to styles when
USER-INTEL styles are not available.
NOTE: For simulations on higher node counts, add "processors * * *
grid numa"_processors.html" to the beginning of the input script for
better scalability.
When running on many nodes, performance might be better when using
fewer OpenMP threads and more MPI tasks. This will depend on the
simulation and the machine. Using the "verlet/split"_run_style.html
run style might also give better performance for simulations with
"PPPM"_kspace_style.html electrostatics. Note that this is an
alternative to LRT mode and the two cannot be used together.
Currently, when using Intel MPI with Intel Xeon Phi x200 series
CPUs, better performance might be obtained by setting the
environment variable "I_MPI_SHM_LMT=shm" for Linux kernels that do
not yet have full support for AVX-512. Runs on Intel Xeon Phi x200
series processors will always perform better using MCDRAM. Please
consult your system documentation for the best approach to specify
that MPI runs are performed in MCDRAM.
[Tuning for Offload Performance:]
The default settings for offload should give good performance.
When using LAMMPS with offload to Intel coprocessors, best performance
will typically be achieved with concurrent calculations performed on
both the CPU and the coprocessor. This is achieved by offloading only
a fraction of the neighbor and pair computations to the coprocessor or
using "hybrid"_pair_hybrid.html pair styles where only one style uses
the "intel" suffix. For simulations with long-range electrostatics or
bond, angle, dihedral, improper calculations, computation and data
transfer to the coprocessor will run concurrently with computations
and MPI communications for these calculations on the host CPU. This
is illustrated in the figure below for the rhodopsin protein benchmark
running on E5-2697v2 processors with a Intel Xeon Phi 7120p
coprocessor. In this plot, the vertical access is time and routines
running at the same time are running concurrently on both the host and
the coprocessor.
:c,image(JPG/offload_knc.png)
The fraction of the offloaded work is controlled by the {balance}
keyword in the "package intel"_package.html command. A balance of 0
runs all calculations on the CPU. A balance of 1 runs all
supported calculations on the coprocessor. A balance of 0.5 runs half
of the calculations on the coprocessor. Setting the balance to -1
(the default) will enable dynamic load balancing that continously
adjusts the fraction of offloaded work throughout the simulation.
Because data transfer cannot be timed, this option typically produces
results within 5 to 10 percent of the optimal fixed balance.
If running short benchmark runs with dynamic load balancing, adding a
short warm-up run (10-20 steps) will allow the load-balancer to find a
near-optimal setting that will carry over to additional runs.
The default for the "package intel"_package.html command is to have
all the MPI tasks on a given compute node use a single Xeon Phi
coprocessor. In general, running with a large number of MPI tasks on
each node will perform best with offload. Each MPI task will
automatically get affinity to a subset of the hardware threads
available on the coprocessor. For example, if your card has 61 cores,
with 60 cores available for offload and 4 hardware threads per core
(240 total threads), running with 24 MPI tasks per node will cause
each MPI task to use a subset of 10 threads on the coprocessor. Fine
tuning of the number of threads to use per MPI task or the number of
threads to use per core can be accomplished with keyword settings of
the "package intel"_package.html command.
The USER-INTEL package has two modes for deciding which atoms will be
handled by the coprocessor. This choice is controlled with the {ghost}
keyword of the "package intel"_package.html command. When set to 0,
ghost atoms (atoms at the borders between MPI tasks) are not offloaded
to the card. This allows for overlap of MPI communication of forces
with computation on the coprocessor when the "newton"_newton.html
setting is "on". The default is dependent on the style being used,
however, better performance may be achieved by setting this option
explicitly.
When using offload with CPU Hyper-Threading disabled, it may help
performance to use fewer MPI tasks and OpenMP threads than available
cores. This is due to the fact that additional threads are generated
internally to handle the asynchronous offload tasks.
If pair computations are being offloaded to an Intel Xeon Phi
coprocessor, a diagnostic line is printed to the screen (not to the
log file), during the setup phase of a run, indicating that offload
mode is being used and indicating the number of coprocessor threads
per MPI task. Additionally, an offload timing summary is printed at
the end of each run. When offloading, the frequency for "atom
sorting"_atom_modify.html is changed to 1 so that the per-atom data is
effectively sorted at every rebuild of the neighbor lists. All the
available coprocessor threads on each Phi will be divided among MPI
tasks, unless the {tptask} option of the "-pk intel" "command-line
-switch"_Section_start.html#start_7 is used to limit the coprocessor
+switch"_Section_start.html#start_6 is used to limit the coprocessor
threads per MPI task.
[Restrictions:]
When offloading to a coprocessor, "hybrid"_pair_hybrid.html styles
that require skip lists for neighbor builds cannot be offloaded.
Using "hybrid/overlay"_pair_hybrid.html is allowed. Only one intel
accelerated style may be used with hybrid styles.
"Special_bonds"_special_bonds.html exclusion lists are not currently
supported with offload, however, the same effect can often be
accomplished by setting cutoffs for excluded atom types to 0. None of
the pair styles in the USER-INTEL package currently support the
"inner", "middle", "outer" options for rRESPA integration via the
"run_style respa"_run_style.html command; only the "pair" option is
supported.
[References:]
Brown, W.M., Carrillo, J.-M.Y., Mishra, B., Gavhane, N., Thakker, F.M., De Kraker, A.R., Yamada, M., Ang, J.A., Plimpton, S.J., "Optimizing Classical Molecular Dynamics in LAMMPS," in Intel Xeon Phi Processor High Performance Programming: Knights Landing Edition, J. Jeffers, J. Reinders, A. Sodani, Eds. Morgan Kaufmann. :ulb,l
Brown, W. M., Semin, A., Hebenstreit, M., Khvostov, S., Raman, K., Plimpton, S.J. "Increasing Molecular Dynamics Simulation Rates with an 8-Fold Increase in Electrical Power Efficiency."_http://dl.acm.org/citation.cfm?id=3014915 2016 High Performance Computing, Networking, Storage and Analysis, SC16: International Conference (pp. 82-95). :l
Brown, W.M., Carrillo, J.-M.Y., Gavhane, N., Thakkar, F.M., Plimpton, S.J. Optimizing Legacy Molecular Dynamics Software with Directive-Based Offload. Computer Physics Communications. 2015. 195: p. 95-101. :l
:ule
diff --git a/doc/src/accelerate_kokkos.txt b/doc/src/accelerate_kokkos.txt
index 602c3191f..6ccd69584 100644
--- a/doc/src/accelerate_kokkos.txt
+++ b/doc/src/accelerate_kokkos.txt
@@ -1,496 +1,496 @@
"Previous Section"_Section_packages.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
"Return to Section accelerate overview"_Section_accelerate.html
5.3.3 KOKKOS package :h5
The KOKKOS package was developed primarily by Christian Trott (Sandia)
with contributions of various styles by others, including Sikandar
Mashayak (UIUC), Stan Moore (Sandia), and Ray Shan (Sandia). The
underlying Kokkos library was written primarily by Carter Edwards,
Christian Trott, and Dan Sunderland (all Sandia).
The KOKKOS package contains versions of pair, fix, and atom styles
that use data structures and macros provided by the Kokkos library,
which is included with LAMMPS in lib/kokkos.
The Kokkos library is part of
"Trilinos"_http://trilinos.sandia.gov/packages/kokkos and can also be
downloaded from "Github"_https://github.com/kokkos/kokkos. Kokkos is a
templated C++ library that provides two key abstractions for an
application like LAMMPS. First, it allows a single implementation of
an application kernel (e.g. a pair style) to run efficiently on
different kinds of hardware, such as a GPU, Intel Phi, or many-core
CPU.
The Kokkos library also provides data abstractions to adjust (at
compile time) the memory layout of basic data structures like 2d and
3d arrays and allow the transparent utilization of special hardware
load and store operations. Such data structures are used in LAMMPS to
store atom coordinates or forces or neighbor lists. The layout is
chosen to optimize performance on different platforms. Again this
functionality is hidden from the developer, and does not affect how
the kernel is coded.
These abstractions are set at build time, when LAMMPS is compiled with
the KOKKOS package installed. All Kokkos operations occur within the
context of an individual MPI task running on a single node of the
machine. The total number of MPI tasks used by LAMMPS (one or
multiple per compute node) is set in the usual manner via the mpirun
or mpiexec commands, and is independent of Kokkos.
Kokkos currently provides support for 3 modes of execution (per MPI
task). These are OpenMP (for many-core CPUs), Cuda (for NVIDIA GPUs),
and OpenMP (for Intel Phi). Note that the KOKKOS package supports
running on the Phi in native mode, not offload mode like the
USER-INTEL package supports. You choose the mode at build time to
produce an executable compatible with specific hardware.
Here is a quick overview of how to use the KOKKOS package
for CPU acceleration, assuming one or more 16-core nodes.
More details follow.
use a C++11 compatible compiler
make yes-kokkos
make mpi KOKKOS_DEVICES=OpenMP # build with the KOKKOS package
make kokkos_omp # or Makefile.kokkos_omp already has variable set
Make.py -v -p kokkos -kokkos omp -o mpi -a file mpi # or one-line build via Make.py :pre
mpirun -np 16 lmp_mpi -k on -sf kk -in in.lj # 1 node, 16 MPI tasks/node, no threads
mpirun -np 2 -ppn 1 lmp_mpi -k on t 16 -sf kk -in in.lj # 2 nodes, 1 MPI task/node, 16 threads/task
mpirun -np 2 lmp_mpi -k on t 8 -sf kk -in in.lj # 1 node, 2 MPI tasks/node, 8 threads/task
mpirun -np 32 -ppn 4 lmp_mpi -k on t 4 -sf kk -in in.lj # 8 nodes, 4 MPI tasks/node, 4 threads/task :pre
specify variables and settings in your Makefile.machine that enable OpenMP, GPU, or Phi support
include the KOKKOS package and build LAMMPS
enable the KOKKOS package and its hardware options via the "-k on" command-line switch use KOKKOS styles in your input script :ul
Here is a quick overview of how to use the KOKKOS package for GPUs,
assuming one or more nodes, each with 16 cores and a GPU. More
details follow.
discuss use of NVCC, which Makefiles to examine
use a C++11 compatible compiler
KOKKOS_DEVICES = Cuda, OpenMP
KOKKOS_ARCH = Kepler35
make yes-kokkos
make machine
Make.py -p kokkos -kokkos cuda arch=31 -o kokkos_cuda -a file kokkos_cuda :pre
mpirun -np 1 lmp_cuda -k on t 6 -sf kk -in in.lj # one MPI task, 6 threads on CPU
mpirun -np 4 -ppn 1 lmp_cuda -k on t 6 -sf kk -in in.lj # ditto on 4 nodes :pre
mpirun -np 2 lmp_cuda -k on t 8 g 2 -sf kk -in in.lj # two MPI tasks, 8 threads per CPU
mpirun -np 32 -ppn 2 lmp_cuda -k on t 8 g 2 -sf kk -in in.lj # ditto on 16 nodes :pre
Here is a quick overview of how to use the KOKKOS package
for the Intel Phi:
use a C++11 compatible compiler
KOKKOS_DEVICES = OpenMP
KOKKOS_ARCH = KNC
make yes-kokkos
make machine
Make.py -p kokkos -kokkos phi -o kokkos_phi -a file mpi :pre
host=MIC, Intel Phi with 61 cores (240 threads/phi via 4x hardware threading):
mpirun -np 1 lmp_g++ -k on t 240 -sf kk -in in.lj # 1 MPI task on 1 Phi, 1*240 = 240
mpirun -np 30 lmp_g++ -k on t 8 -sf kk -in in.lj # 30 MPI tasks on 1 Phi, 30*8 = 240
mpirun -np 12 lmp_g++ -k on t 20 -sf kk -in in.lj # 12 MPI tasks on 1 Phi, 12*20 = 240
mpirun -np 96 -ppn 12 lmp_g++ -k on t 20 -sf kk -in in.lj # ditto on 8 Phis :pre
[Required hardware/software:]
Kokkos support within LAMMPS must be built with a C++11 compatible
compiler. If using gcc, version 4.7.2 or later is required.
To build with Kokkos support for CPUs, your compiler must support the
OpenMP interface. You should have one or more multi-core CPUs so that
multiple threads can be launched by each MPI task running on a CPU.
To build with Kokkos support for NVIDIA GPUs, NVIDIA Cuda software
version 7.5 or later must be installed on your system. See the
discussion for the "GPU"_accelerate_gpu.html package for details of
how to check and do this.
NOTE: For good performance of the KOKKOS package on GPUs, you must
have Kepler generation GPUs (or later). The Kokkos library exploits
texture cache options not supported by Telsa generation GPUs (or
older).
To build with Kokkos support for Intel Xeon Phi coprocessors, your
sysmte must be configured to use them in "native" mode, not "offload"
mode like the USER-INTEL package supports.
[Building LAMMPS with the KOKKOS package:]
You must choose at build time whether to build for CPUs (OpenMP),
GPUs, or Phi.
You can do any of these in one line, using the src/Make.py script,
-described in "Section 2.4"_Section_start.html#start_4 of the manual.
+described in "Section 4"_Section_packages.html of the manual.
Type "Make.py -h" for help. If run from the src directory, these
commands will create src/lmp_kokkos_omp, lmp_kokkos_cuda, and
lmp_kokkos_phi. Note that the OMP and PHI options use
src/MAKE/Makefile.mpi as the starting Makefile.machine. The CUDA
option uses src/MAKE/OPTIONS/Makefile.kokkos_cuda.
The latter two steps can be done using the "-k on", "-pk kokkos" and
-"-sf kk" "command-line switches"_Section_start.html#start_7
+"-sf kk" "command-line switches"_Section_start.html#start_6
respectively. Or the effect of the "-pk" or "-sf" switches can be
duplicated by adding the "package kokkos"_package.html or "suffix
kk"_suffix.html commands respectively to your input script.
Or you can follow these steps:
CPU-only (run all-MPI or with OpenMP threading):
cd lammps/src
make yes-kokkos
make kokkos_omp :pre
CPU-only (only MPI, no threading):
cd lammps/src
make yes-kokkos
make kokkos_mpi :pre
Intel Xeon Phi (Intel Compiler, Intel MPI):
cd lammps/src
make yes-kokkos
make kokkos_phi :pre
CPUs and GPUs (with MPICH):
cd lammps/src
make yes-kokkos
make kokkos_cuda_mpich :pre
These examples set the KOKKOS-specific OMP, MIC, CUDA variables on the
make command line which requires a GNU-compatible make command. Try
"gmake" if your system's standard make complains.
NOTE: If you build using make line variables and re-build LAMMPS twice
with different KOKKOS options and the *same* target, e.g. g++ in the
first two examples above, then you *must* perform a "make clean-all"
or "make clean-machine" before each build. This is to force all the
KOKKOS-dependent files to be re-compiled with the new options.
NOTE: Currently, there are no precision options with the KOKKOS
package. All compilation and computation is performed in double
precision.
There are other allowed options when building with the KOKKOS package.
As above, they can be set either as variables on the make command line
or in Makefile.machine. This is the full list of options, including
those discussed above, Each takes a value shown below. The
default value is listed, which is set in the
lib/kokkos/Makefile.kokkos file.
#Default settings specific options
#Options: force_uvm,use_ldg,rdc
KOKKOS_DEVICES, values = {OpenMP}, {Serial}, {Pthreads}, {Cuda}, default = {OpenMP}
KOKKOS_ARCH, values = {KNC}, {SNB}, {HSW}, {Kepler}, {Kepler30}, {Kepler32}, {Kepler35}, {Kepler37}, {Maxwell}, {Maxwell50}, {Maxwell52}, {Maxwell53}, {ARMv8}, {BGQ}, {Power7}, {Power8}, default = {none}
KOKKOS_DEBUG, values = {yes}, {no}, default = {no}
KOKKOS_USE_TPLS, values = {hwloc}, {librt}, default = {none}
KOKKOS_CUDA_OPTIONS, values = {force_uvm}, {use_ldg}, {rdc} :ul
KOKKOS_DEVICE sets the parallelization method used for Kokkos code
(within LAMMPS). KOKKOS_DEVICES=OpenMP means that OpenMP will be
used. KOKKOS_DEVICES=Pthreads means that pthreads will be used.
KOKKOS_DEVICES=Cuda means an NVIDIA GPU running CUDA will be used.
If KOKKOS_DEVICES=Cuda, then the lo-level Makefile in the src/MAKE
directory must use "nvcc" as its compiler, via its CC setting. For
best performance its CCFLAGS setting should use -O3 and have a
KOKKOS_ARCH setting that matches the compute capability of your NVIDIA
hardware and software installation, e.g. KOKKOS_ARCH=Kepler30. Note
the minimal required compute capability is 2.0, but this will give
significantly reduced performance compared to Kepler generation GPUs
with compute capability 3.x. For the LINK setting, "nvcc" should not
be used; instead use g++ or another compiler suitable for linking C++
applications. Often you will want to use your MPI compiler wrapper
for this setting (i.e. mpicxx). Finally, the lo-level Makefile must
also have a "Compilation rule" for creating *.o files from *.cu files.
See src/Makefile.cuda for an example of a lo-level Makefile with all
of these settings.
KOKKOS_USE_TPLS=hwloc binds threads to hardware cores, so they do not
migrate during a simulation. KOKKOS_USE_TPLS=hwloc should always be
used if running with KOKKOS_DEVICES=Pthreads for pthreads. It is not
necessary for KOKKOS_DEVICES=OpenMP for OpenMP, because OpenMP
provides alternative methods via environment variables for binding
threads to hardware cores. More info on binding threads to cores is
given in "Section 5.3"_Section_accelerate.html#acc_3.
KOKKOS_ARCH=KNC enables compiler switches needed when compiling for an
Intel Phi processor.
KOKKOS_USE_TPLS=librt enables use of a more accurate timer mechanism
on most Unix platforms. This library is not available on all
platforms.
KOKKOS_DEBUG is only useful when developing a Kokkos-enabled style
within LAMMPS. KOKKOS_DEBUG=yes enables printing of run-time
debugging information that can be useful. It also enables runtime
bounds checking on Kokkos data structures.
KOKKOS_CUDA_OPTIONS are additional options for CUDA.
For more information on Kokkos see the Kokkos programmers' guide here:
/lib/kokkos/doc/Kokkos_PG.pdf.
[Run with the KOKKOS package from the command line:]
The mpirun or mpiexec command sets the total number of MPI tasks used
by LAMMPS (one or multiple per compute node) and the number of MPI
tasks used per node. E.g. the mpirun command in MPICH does this via
its -np and -ppn switches. Ditto for OpenMPI via -np and -npernode.
When using KOKKOS built with host=OMP, you need to choose how many
OpenMP threads per MPI task will be used (via the "-k" command-line
switch discussed below). Note that the product of MPI tasks * OpenMP
threads/task should not exceed the physical number of cores (on a
node), otherwise performance will suffer.
When using the KOKKOS package built with device=CUDA, you must use
exactly one MPI task per physical GPU.
When using the KOKKOS package built with host=MIC for Intel Xeon Phi
coprocessor support you need to insure there are one or more MPI tasks
per coprocessor, and choose the number of coprocessor threads to use
per MPI task (via the "-k" command-line switch discussed below). The
product of MPI tasks * coprocessor threads/task should not exceed the
maximum number of threads the coprocessor is designed to run,
otherwise performance will suffer. This value is 240 for current
generation Xeon Phi(TM) chips, which is 60 physical cores * 4
threads/core. Note that with the KOKKOS package you do not need to
specify how many Phi coprocessors there are per node; each
coprocessors is simply treated as running some number of MPI tasks.
You must use the "-k on" "command-line
-switch"_Section_start.html#start_7 to enable the KOKKOS package. It
+switch"_Section_start.html#start_6 to enable the KOKKOS package. It
takes additional arguments for hardware settings appropriate to your
system. Those arguments are "documented
-here"_Section_start.html#start_7. The two most commonly used
+here"_Section_start.html#start_6. The two most commonly used
options are:
-k on t Nt g Ng :pre
The "t Nt" option applies to host=OMP (even if device=CUDA) and
host=MIC. For host=OMP, it specifies how many OpenMP threads per MPI
task to use with a node. For host=MIC, it specifies how many Xeon Phi
threads per MPI task to use within a node. The default is Nt = 1.
Note that for host=OMP this is effectively MPI-only mode which may be
fine. But for host=MIC you will typically end up using far less than
all the 240 available threads, which could give very poor performance.
The "g Ng" option applies to device=CUDA. It specifies how many GPUs
per compute node to use. The default is 1, so this only needs to be
specified is you have 2 or more GPUs per compute node.
The "-k on" switch also issues a "package kokkos" command (with no
additional arguments) which sets various KOKKOS options to default
values, as discussed on the "package"_package.html command doc page.
-Use the "-sf kk" "command-line switch"_Section_start.html#start_7,
+Use the "-sf kk" "command-line switch"_Section_start.html#start_6,
which will automatically append "kk" to styles that support it. Use
-the "-pk kokkos" "command-line switch"_Section_start.html#start_7 if
+the "-pk kokkos" "command-line switch"_Section_start.html#start_6 if
you wish to change any of the default "package kokkos"_package.html
optionns set by the "-k on" "command-line
-switch"_Section_start.html#start_7.
+switch"_Section_start.html#start_6.
Note that the default for the "package kokkos"_package.html command is
to use "full" neighbor lists and set the Newton flag to "off" for both
pairwise and bonded interactions. This typically gives fastest
performance. If the "newton"_newton.html command is used in the input
script, it can override the Newton flag defaults.
However, when running in MPI-only mode with 1 thread per MPI task, it
will typically be faster to use "half" neighbor lists and set the
Newton flag to "on", just as is the case for non-accelerated pair
styles. You can do this with the "-pk" "command-line
-switch"_Section_start.html#start_7.
+switch"_Section_start.html#start_6.
[Or run with the KOKKOS package by editing an input script:]
The discussion above for the mpirun/mpiexec command and setting
appropriate thread and GPU values for host=OMP or host=MIC or
device=CUDA are the same.
You must still use the "-k on" "command-line
-switch"_Section_start.html#start_7 to enable the KOKKOS package, and
+switch"_Section_start.html#start_6 to enable the KOKKOS package, and
specify its additional arguments for hardware options appropriate to
your system, as documented above.
Use the "suffix kk"_suffix.html command, or you can explicitly add a
"kk" suffix to individual styles in your input script, e.g.
pair_style lj/cut/kk 2.5 :pre
You only need to use the "package kokkos"_package.html command if you
wish to change any of its option defaults, as set by the "-k on"
-"command-line switch"_Section_start.html#start_7.
+"command-line switch"_Section_start.html#start_6.
[Speed-ups to expect:]
The performance of KOKKOS running in different modes is a function of
your hardware, which KOKKOS-enable styles are used, and the problem
size.
Generally speaking, the following rules of thumb apply:
When running on CPUs only, with a single thread per MPI task,
performance of a KOKKOS style is somewhere between the standard
(un-accelerated) styles (MPI-only mode), and those provided by the
USER-OMP package. However the difference between all 3 is small (less
than 20%). :ulb,l
When running on CPUs only, with multiple threads per MPI task,
performance of a KOKKOS style is a bit slower than the USER-OMP
package. :l
When running large number of atoms per GPU, KOKKOS is typically faster
than the GPU package. :l
When running on Intel Xeon Phi, KOKKOS is not as fast as
the USER-INTEL package, which is optimized for that hardware. :l
:ule
See the "Benchmark page"_http://lammps.sandia.gov/bench.html of the
LAMMPS web site for performance of the KOKKOS package on different
hardware.
[Guidelines for best performance:]
Here are guidline for using the KOKKOS package on the different
hardware configurations listed above.
Many of the guidelines use the "package kokkos"_package.html command
See its doc page for details and default settings. Experimenting with
its options can provide a speed-up for specific calculations.
[Running on a multi-core CPU:]
If N is the number of physical cores/node, then the number of MPI
tasks/node * number of threads/task should not exceed N, and should
typically equal N. Note that the default threads/task is 1, as set by
the "t" keyword of the "-k" "command-line
-switch"_Section_start.html#start_7. If you do not change this, no
+switch"_Section_start.html#start_6. If you do not change this, no
additional parallelism (beyond MPI) will be invoked on the host
CPU(s).
You can compare the performance running in different modes:
run with 1 MPI task/node and N threads/task
run with N MPI tasks/node and 1 thread/task
run with settings in between these extremes :ul
Examples of mpirun commands in these modes are shown above.
When using KOKKOS to perform multi-threading, it is important for
performance to bind both MPI tasks to physical cores, and threads to
physical cores, so they do not migrate during a simulation.
If you are not certain MPI tasks are being bound (check the defaults
for your MPI installation), binding can be forced with these flags:
OpenMPI 1.8: mpirun -np 2 -bind-to socket -map-by socket ./lmp_openmpi ...
Mvapich2 2.0: mpiexec -np 2 -bind-to socket -map-by socket ./lmp_mvapich ... :pre
For binding threads with the KOKKOS OMP option, use thread affinity
environment variables to force binding. With OpenMP 3.1 (gcc 4.7 or
later, intel 12 or later) setting the environment variable
OMP_PROC_BIND=true should be sufficient. For binding threads with the
KOKKOS pthreads option, compile LAMMPS the KOKKOS HWLOC=yes option
(see "this section"_Section_packages.html#KOKKOS of the manual for
details).
[Running on GPUs:]
Insure the -arch setting in the machine makefile you are using,
e.g. src/MAKE/Makefile.cuda, is correct for your GPU hardware/software.
(see "this section"_Section_packages.html#KOKKOS of the manual for
details).
The -np setting of the mpirun command should set the number of MPI
tasks/node to be equal to the # of physical GPUs on the node.
-Use the "-k" "command-line switch"_Section_commands.html#start_7 to
+Use the "-k" "command-line switch"_Section_commands.html#start_6 to
specify the number of GPUs per node, and the number of threads per MPI
task. 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 * number of
threads/task should not exceed N. With one GPU (and one MPI task) it
may be faster to use less than all the available cores, by setting
threads/task to a smaller value. This is because using all the cores
on a dual-socket node will incur extra cost to copy memory from the
2nd socket to the GPU.
Examples of mpirun commands that follow these rules are shown above.
NOTE: When using a GPU, you will achieve the best performance if your
input script does not use any fix or compute styles which are not yet
Kokkos-enabled. This allows data to stay on the GPU for multiple
timesteps, without being copied back to the host CPU. Invoking a
non-Kokkos fix or compute, or performing I/O for
"thermo"_thermo_style.html or "dump"_dump.html output will cause data
to be copied back to the CPU.
You cannot yet assign multiple MPI tasks to the same GPU with the
KOKKOS package. We plan to support this in the future, similar to the
GPU package in LAMMPS.
You cannot yet use both the host (multi-threaded) and device (GPU)
together to compute pairwise interactions with the KOKKOS package. We
hope to support this in the future, similar to the GPU package in
LAMMPS.
[Running on an Intel Phi:]
Kokkos only uses Intel Phi processors in their "native" mode, i.e.
not hosted by a CPU.
As illustrated above, build LAMMPS with OMP=yes (the default) and
MIC=yes. The latter insures code is correctly compiled for the Intel
Phi. The OMP setting means OpenMP will be used for parallelization on
the Phi, which is currently the best option within Kokkos. In the
future, other options may be added.
Current-generation Intel Phi chips have either 61 or 57 cores. One
core should be excluded for running the OS, leaving 60 or 56 cores.
Each core is hyperthreaded, so there are effectively N = 240 (4*60) or
N = 224 (4*56) cores to run on.
The -np setting of the mpirun command sets the number of MPI
tasks/node. The "-k on t Nt" command-line switch sets the number of
threads/task as Nt. The product of these 2 values should be N, i.e.
240 or 224. Also, the number of threads/task should be a multiple of
4 so that logical threads from more than one MPI task do not run on
the same physical core.
Examples of mpirun commands that follow these rules are shown above.
[Restrictions:]
As noted above, if using GPUs, the number of MPI tasks per compute
node should equal to the number of GPUs per compute node. In the
future Kokkos will support assigning multiple MPI tasks to a single
GPU.
Currently Kokkos does not support AMD GPUs due to limits in the
available backend programming models. Specifically, Kokkos requires
extensive C++ support from the Kernel language. This is expected to
change in the future.
diff --git a/doc/src/accelerate_omp.txt b/doc/src/accelerate_omp.txt
index c8dd34386..81b7a5adc 100644
--- a/doc/src/accelerate_omp.txt
+++ b/doc/src/accelerate_omp.txt
@@ -1,187 +1,187 @@
"Previous Section"_Section_packages.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
"Return to Section 5 overview"_Section_accelerate.html
5.3.4 USER-OMP package :h5
The USER-OMP package was developed by Axel Kohlmeyer at Temple
University. It provides multi-threaded versions of most pair styles,
nearly all bonded styles (bond, angle, dihedral, improper), several
Kspace styles, and a few fix styles. The package currently uses the
OpenMP interface for multi-threading.
Here is a quick overview of how to use the USER-OMP package, assuming
one or more 16-core nodes. More details follow.
use -fopenmp with CCFLAGS and LINKFLAGS in Makefile.machine
make yes-user-omp
make mpi # build with USER-OMP package, if settings added to Makefile.mpi
make omp # or Makefile.omp already has settings
Make.py -v -p omp -o mpi -a file mpi # or one-line build via Make.py :pre
lmp_mpi -sf omp -pk omp 16 < in.script # 1 MPI task, 16 threads
mpirun -np 4 lmp_mpi -sf omp -pk omp 4 -in in.script # 4 MPI tasks, 4 threads/task
mpirun -np 32 -ppn 4 lmp_mpi -sf omp -pk omp 4 -in in.script # 8 nodes, 4 MPI tasks/node, 4 threads/task :pre
[Required hardware/software:]
Your compiler must support the OpenMP interface. You should have one
or more multi-core CPUs so that multiple threads can be launched by
each MPI task running on a CPU.
[Building LAMMPS with the USER-OMP package:]
The lines above illustrate how to include/build with the USER-OMP
package in two steps, using the "make" command. Or how to do it with
one command via the src/Make.py script, described in "Section
-2.4"_Section_start.html#start_4 of the manual. Type "Make.py -h" for
+4"_Section_packages.html of the manual. Type "Make.py -h" for
help.
Note that the CCFLAGS and LINKFLAGS settings in Makefile.machine must
include "-fopenmp". Likewise, if you use an Intel compiler, the
CCFLAGS setting must include "-restrict". The Make.py command will
add these automatically.
[Run with the USER-OMP package from the command line:]
The mpirun or mpiexec command sets the total number of MPI tasks used
by LAMMPS (one or multiple per compute node) and the number of MPI
tasks used per node. E.g. the mpirun command in MPICH does this via
its -np and -ppn switches. Ditto for OpenMPI via -np and -npernode.
You need to choose how many OpenMP threads per MPI task will be used
by the USER-OMP package. Note that the product of MPI tasks *
threads/task should not exceed the physical number of cores (on a
node), otherwise performance will suffer.
As in the lines above, use the "-sf omp" "command-line
-switch"_Section_start.html#start_7, which will automatically append
+switch"_Section_start.html#start_6, which will automatically append
"omp" to styles that support it. The "-sf omp" switch also issues a
default "package omp 0"_package.html command, which will set the
number of threads per MPI task via the OMP_NUM_THREADS environment
variable.
You can also use the "-pk omp Nt" "command-line
-switch"_Section_start.html#start_7, to explicitly set Nt = # of OpenMP
+switch"_Section_start.html#start_6, to explicitly set Nt = # of OpenMP
threads per MPI task to use, as well as additional options. Its
syntax is the same as the "package omp"_package.html command whose doc
page gives details, including the default values used if it is not
specified. It also gives more details on how to set the number of
threads via the OMP_NUM_THREADS environment variable.
[Or run with the USER-OMP package by editing an input script:]
The discussion above for the mpirun/mpiexec command, MPI tasks/node,
and threads/MPI task is the same.
Use the "suffix omp"_suffix.html command, or you can explicitly add an
"omp" suffix to individual styles in your input script, e.g.
pair_style lj/cut/omp 2.5 :pre
You must also use the "package omp"_package.html command to enable the
USER-OMP package. When you do this you also specify how many threads
per MPI task to use. The command doc page explains other options and
how to set the number of threads via the OMP_NUM_THREADS environment
variable.
[Speed-ups to expect:]
Depending on which styles are accelerated, you should look for a
reduction in the "Pair time", "Bond time", "KSpace time", and "Loop
time" values printed at the end of a run.
You may see a small performance advantage (5 to 20%) when running a
USER-OMP style (in serial or parallel) with a single thread per MPI
task, versus running standard LAMMPS with its standard un-accelerated
styles (in serial or all-MPI parallelization with 1 task/core). This
is because many of the USER-OMP styles contain similar optimizations
to those used in the OPT package, described in "Section
5.3.5"_accelerate_opt.html.
With multiple threads/task, the optimal choice of number of MPI
tasks/node and OpenMP threads/task can vary a lot and should always be
tested via benchmark runs for a specific simulation running on a
specific machine, paying attention to guidelines discussed in the next
sub-section.
A description of the multi-threading strategy used in the USER-OMP
package and some performance examples are "presented
here"_http://sites.google.com/site/akohlmey/software/lammps-icms/lammps-icms-tms2011-talk.pdf?attredirects=0&d=1
[Guidelines for best performance:]
For many problems on current generation CPUs, running the USER-OMP
package with a single thread/task is faster than running with multiple
threads/task. This is because the MPI parallelization in LAMMPS is
often more efficient than multi-threading as implemented in the
USER-OMP package. The parallel efficiency (in a threaded sense) also
varies for different USER-OMP styles.
Using multiple threads/task can be more effective under the following
circumstances:
Individual compute nodes have a significant number of CPU cores but
the CPU itself has limited memory bandwidth, e.g. for Intel Xeon 53xx
(Clovertown) and 54xx (Harpertown) quad-core processors. Running one
MPI task per CPU core will result in significant performance
degradation, so that running with 4 or even only 2 MPI tasks per node
is faster. Running in hybrid MPI+OpenMP mode will reduce the
inter-node communication bandwidth contention in the same way, but
offers an additional speedup by utilizing the otherwise idle CPU
cores. :ulb,l
The interconnect used for MPI communication does not provide
sufficient bandwidth for a large number of MPI tasks per node. For
example, this applies to running over gigabit ethernet or on Cray XT4
or XT5 series supercomputers. As in the aforementioned case, this
effect worsens when using an increasing number of nodes. :l
The system has a spatially inhomogeneous particle density which does
not map well to the "domain decomposition scheme"_processors.html or
"load-balancing"_balance.html options that LAMMPS provides. This is
because multi-threading achives parallelism over the number of
particles, not via their distribution in space. :l
A machine is being used in "capability mode", i.e. near the point
where MPI parallelism is maxed out. For example, this can happen when
using the "PPPM solver"_kspace_style.html for long-range
electrostatics on large numbers of nodes. The scaling of the KSpace
calculation (see the "kspace_style"_kspace_style.html command) becomes
the performance-limiting factor. Using multi-threading allows less
MPI tasks to be invoked and can speed-up the long-range solver, while
increasing overall performance by parallelizing the pairwise and
bonded calculations via OpenMP. Likewise additional speedup can be
sometimes be achived by increasing the length of the Coulombic cutoff
and thus reducing the work done by the long-range solver. Using the
"run_style verlet/split"_run_style.html command, which is compatible
with the USER-OMP package, is an alternative way to reduce the number
of MPI tasks assigned to the KSpace calculation. :l
:ule
Additional performance tips are as follows:
The best parallel efficiency from {omp} styles is typically achieved
when there is at least one MPI task per physical CPU chip, i.e. socket
or die. :ulb,l
It is usually most efficient to restrict threading to a single
socket, i.e. use one or more MPI task per socket. :l
NOTE: By default, several current MPI implementations use a processor
affinity setting that restricts each MPI task to a single CPU core.
Using multi-threading in this mode will force all threads to share the
one core and thus is likely to be counterproductive. Instead, binding
MPI tasks to a (multi-core) socket, should solve this issue. :l
:ule
[Restrictions:]
None.
diff --git a/doc/src/accelerate_opt.txt b/doc/src/accelerate_opt.txt
index 704321ca0..5a2a5eac0 100644
--- a/doc/src/accelerate_opt.txt
+++ b/doc/src/accelerate_opt.txt
@@ -1,71 +1,71 @@
"Previous Section"_Section_packages.html - "LAMMPS WWW Site"_lws -
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
"Return to Section accelerate overview"_Section_accelerate.html
5.3.5 OPT package :h5
The OPT package was developed by James Fischer (High Performance
Technologies), David Richie, and Vincent Natoli (Stone Ridge
Technologies). It contains a handful of pair styles whose compute()
methods were rewritten in C++ templated form to reduce the overhead
due to if tests and other conditional code.
Here is a quick overview of how to use the OPT package. More details
follow.
make yes-opt
make mpi # build with the OPT package
Make.py -v -p opt -o mpi -a file mpi # or one-line build via Make.py :pre
lmp_mpi -sf opt -in in.script # run in serial
mpirun -np 4 lmp_mpi -sf opt -in in.script # run in parallel :pre
[Required hardware/software:]
None.
[Building LAMMPS with the OPT package:]
The lines above illustrate how to build LAMMPS with the OPT package in
two steps, using the "make" command. Or how to do it with one command
via the src/Make.py script, described in "Section
-2.4"_Section_start.html#start_4 of the manual. Type "Make.py -h" for
+4"_Section_packages.html of the manual. Type "Make.py -h" for
help.
Note that if you use an Intel compiler to build with the OPT package,
the CCFLAGS setting in your Makefile.machine must include "-restrict".
The Make.py command will add this automatically.
[Run with the OPT package from the command line:]
As in the lines above, use the "-sf opt" "command-line
-switch"_Section_start.html#start_7, which will automatically append
+switch"_Section_start.html#start_6, which will automatically append
"opt" to styles that support it.
[Or run with the OPT package by editing an input script:]
Use the "suffix opt"_suffix.html command, or you can explicitly add an
"opt" suffix to individual styles in your input script, e.g.
pair_style lj/cut/opt 2.5 :pre
[Speed-ups to expect:]
You should see a reduction in the "Pair time" value printed at the end
of a run. On most machines for reasonable problem sizes, it will be a
5 to 20% savings.
[Guidelines for best performance:]
Just try out an OPT pair style to see how it performs.
[Restrictions:]
None.
diff --git a/doc/src/angle_charmm.txt b/doc/src/angle_charmm.txt
index a02e60425..7ff7ef8fd 100644
--- a/doc/src/angle_charmm.txt
+++ b/doc/src/angle_charmm.txt
@@ -1,90 +1,90 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
angle_style charmm command :h3
angle_style charmm/intel command :h3
angle_style charmm/kk command :h3
angle_style charmm/omp command :h3
[Syntax:]
angle_style charmm :pre
[Examples:]
angle_style charmm
angle_coeff 1 300.0 107.0 50.0 3.0 :pre
[Description:]
The {charmm} angle style uses the potential
:c,image(Eqs/angle_charmm.jpg)
with an additional Urey_Bradley term based on the distance {r} between
the 1st and 3rd atoms in the angle. K, theta0, Kub, and Rub are
coefficients defined for each angle type.
See "(MacKerell)"_#angle-MacKerell for a description of the CHARMM force
field.
The following coefficients must be defined for each angle type via the
"angle_coeff"_angle_coeff.html command as in the example above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands:
K (energy/radian^2)
theta0 (degrees)
K_ub (energy/distance^2)
r_ub (distance) :ul
Theta0 is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of K are in energy/radian^2.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
MOLECULE package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info on packages.
[Related commands:]
"angle_coeff"_angle_coeff.html
[Default:] none
:line
:link(angle-MacKerell)
[(MacKerell)] MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field,
Fischer, Gao, Guo, Ha, et al, J Phys Chem, 102, 3586 (1998).
diff --git a/doc/src/angle_class2.txt b/doc/src/angle_class2.txt
index 74f2544cd..71a508d69 100644
--- a/doc/src/angle_class2.txt
+++ b/doc/src/angle_class2.txt
@@ -1,120 +1,120 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
angle_style class2 command :h3
angle_style class2/omp command :h3
angle_style class2/kk command :h3
[Syntax:]
angle_style class2 :pre
[Examples:]
angle_style class2
angle_coeff * 75.0
angle_coeff 1 bb 10.5872 1.0119 1.5228
angle_coeff * ba 3.6551 24.895 1.0119 1.5228 :pre
[Description:]
The {class2} angle style uses the potential
:c,image(Eqs/angle_class2.jpg)
where Ea is the angle term, Ebb is a bond-bond term, and Eba is a
bond-angle term. Theta0 is the equilibrium angle and r1 and r2 are
the equilibrium bond lengths.
See "(Sun)"_#angle-Sun for a description of the COMPASS class2 force field.
Coefficients for the Ea, Ebb, and Eba formulas must be defined for
each angle type via the "angle_coeff"_angle_coeff.html command as in
the example above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands.
These are the 4 coefficients for the Ea formula:
theta0 (degrees)
K2 (energy/radian^2)
K3 (energy/radian^3)
K4 (energy/radian^4) :ul
Theta0 is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of the various K are in per-radian.
For the Ebb formula, each line in a "angle_coeff"_angle_coeff.html
command in the input script lists 4 coefficients, the first of which
is "bb" to indicate they are BondBond coefficients. In a data file,
these coefficients should be listed under a "BondBond Coeffs" heading
and you must leave out the "bb", i.e. only list 3 coefficients after
the angle type.
bb
M (energy/distance^2)
r1 (distance)
r2 (distance) :ul
For the Eba formula, each line in a "angle_coeff"_angle_coeff.html
command in the input script lists 5 coefficients, the first of which
is "ba" to indicate they are BondAngle coefficients. In a data file,
these coefficients should be listed under a "BondAngle Coeffs" heading
and you must leave out the "ba", i.e. only list 4 coefficients after
the angle type.
ba
N1 (energy/distance^2)
N2 (energy/distance^2)
r1 (distance)
r2 (distance) :ul
The theta0 value in the Eba formula is not specified, since it is the
same value from the Ea formula.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This angle style can only be used if LAMMPS was built with the CLASS2
package. See the "Making LAMMPS"_Section_start.html#start_3 section
for more info on packages.
[Related commands:]
"angle_coeff"_angle_coeff.html
[Default:] none
:line
:link(angle-Sun)
[(Sun)] Sun, J Phys Chem B 102, 7338-7364 (1998).
diff --git a/doc/src/angle_cosine.txt b/doc/src/angle_cosine.txt
index 4fb2ccaf7..c0ce3c930 100644
--- a/doc/src/angle_cosine.txt
+++ b/doc/src/angle_cosine.txt
@@ -1,71 +1,71 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
angle_style cosine command :h3
angle_style cosine/omp command :h3
[Syntax:]
angle_style cosine :pre
[Examples:]
angle_style cosine
angle_coeff * 75.0 :pre
[Description:]
The {cosine} angle style uses the potential
:c,image(Eqs/angle_cosine.jpg)
where K is defined for each angle type.
The following coefficients must be defined for each angle type via the
"angle_coeff"_angle_coeff.html command as in the example above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands:
K (energy) :ul
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
MOLECULE package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info on packages.
[Related commands:]
"angle_coeff"_angle_coeff.html
[Default:] none
diff --git a/doc/src/angle_cosine_delta.txt b/doc/src/angle_cosine_delta.txt
index 6ab214508..830fd6db5 100644
--- a/doc/src/angle_cosine_delta.txt
+++ b/doc/src/angle_cosine_delta.txt
@@ -1,77 +1,77 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
angle_style cosine/delta command :h3
angle_style cosine/delta/omp command :h3
[Syntax:]
angle_style cosine/delta :pre
[Examples:]
angle_style cosine/delta
angle_coeff 2*4 75.0 100.0 :pre
[Description:]
The {cosine/delta} angle style uses the potential
:c,image(Eqs/angle_cosine_delta.jpg)
where theta0 is the equilibrium value of the angle, and K is a
prefactor. Note that the usual 1/2 factor is included in K.
The following coefficients must be defined for each angle type via the
"angle_coeff"_angle_coeff.html command as in the example above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands:
K (energy)
theta0 (degrees) :ul
Theta0 is specified in degrees, but LAMMPS converts it to radians
internally.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
MOLECULE package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info on packages.
[Related commands:]
"angle_coeff"_angle_coeff.html, "angle_style
cosine/squared"_angle_cosine_squared.html
[Default:] none
diff --git a/doc/src/angle_cosine_periodic.txt b/doc/src/angle_cosine_periodic.txt
index c6cd57e41..b5c53b1b0 100644
--- a/doc/src/angle_cosine_periodic.txt
+++ b/doc/src/angle_cosine_periodic.txt
@@ -1,90 +1,90 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
angle_style cosine/periodic command :h3
angle_style cosine/periodic/omp command :h3
[Syntax:]
angle_style cosine/periodic :pre
[Examples:]
angle_style cosine/periodic
angle_coeff * 75.0 1 6 :pre
[Description:]
The {cosine/periodic} angle style uses the following potential, which
is commonly used in the "DREIDING"_Section_howto.html#howto_4 force
field, particularly for organometallic systems where {n} = 4 might be
used for an octahedral complex and {n} = 3 might be used for a
trigonal center:
:c,image(Eqs/angle_cosine_periodic.jpg)
where C, B and n are coefficients defined for each angle type.
See "(Mayo)"_#cosine-Mayo for a description of the DREIDING force field
The following coefficients must be defined for each angle type via the
"angle_coeff"_angle_coeff.html command as in the example above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands:
C (energy)
B = 1 or -1
n = 1, 2, 3, 4, 5 or 6 for periodicity :ul
Note that the prefactor C is specified and not the overall force
constant K = C / n^2. When B = 1, it leads to a minimum for the
linear geometry. When B = -1, it leads to a maximum for the linear
geometry.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
MOLECULE package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info on packages.
[Related commands:]
"angle_coeff"_angle_coeff.html
[Default:] none
:line
:link(cosine-Mayo)
[(Mayo)] Mayo, Olfason, Goddard III, J Phys Chem, 94, 8897-8909
(1990).
diff --git a/doc/src/angle_cosine_shift.txt b/doc/src/angle_cosine_shift.txt
index dc1a29a86..6ed9fe215 100644
--- a/doc/src/angle_cosine_shift.txt
+++ b/doc/src/angle_cosine_shift.txt
@@ -1,75 +1,75 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
angle_style cosine/shift command :h3
angle_style cosine/shift/omp command :h3
[Syntax:]
angle_style cosine/shift :pre
[Examples:]
angle_style cosine/shift
angle_coeff * 10.0 45.0 :pre
[Description:]
The {cosine/shift} angle style uses the potential
:c,image(Eqs/angle_cosine_shift.jpg)
where theta0 is the equilibrium angle. The potential is bounded
between -Umin and zero. In the neighborhood of the minimum E=- Umin +
Umin/4(theta-theta0)^2 hence the spring constant is umin/2.
The following coefficients must be defined for each angle type via the
"angle_coeff"_angle_coeff.html command as in the example above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands:
umin (energy)
theta (angle) :ul
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
USER-MISC package. See the "Making LAMMPS"_Section_start.html#start_3
section for more info on packages.
[Related commands:]
"angle_coeff"_angle_coeff.html,
"angle_cosine_shift_exp"_angle_cosine_shift_exp.html
[Default:] none
diff --git a/doc/src/angle_cosine_shift_exp.txt b/doc/src/angle_cosine_shift_exp.txt
index 48af5ba76..44a68c108 100644
--- a/doc/src/angle_cosine_shift_exp.txt
+++ b/doc/src/angle_cosine_shift_exp.txt
@@ -1,88 +1,88 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
angle_style cosine/shift/exp command :h3
angle_style cosine/shift/exp/omp command :h3
[Syntax:]
angle_style cosine/shift/exp :pre
[Examples:]
angle_style cosine/shift/exp
angle_coeff * 10.0 45.0 2.0 :pre
[Description:]
The {cosine/shift/exp} angle style uses the potential
:c,image(Eqs/angle_cosine_shift_exp.jpg)
where Umin, theta, and a are defined for each angle type.
The potential is bounded between \[-Umin:0\] and the minimum is
located at the angle theta0. The a parameter can be both positive or
negative and is used to control the spring constant at the
equilibrium.
The spring constant is given by k = A exp(A) Umin / \[2 (Exp(a)-1)\].
For a > 3, k/Umin = a/2 to better than 5% relative error. For negative
values of the a parameter, the spring constant is essentially zero,
and anharmonic terms takes over. The potential is furthermore well
behaved in the limit a -> 0, where it has been implemented to linear
order in a for a < 0.001. In this limit the potential reduces to the
cosineshifted potential.
The following coefficients must be defined for each angle type via the
"angle_coeff"_angle_coeff.html command as in the example above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands:
umin (energy)
theta (angle)
A (real number) :ul
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
USER-MISC package. See the "Making LAMMPS"_Section_start.html#start_3
section for more info on packages.
[Related commands:]
"angle_coeff"_angle_coeff.html,
"angle_cosine_shift"_angle_cosine_shift.html,
"dihedral_cosine_shift_exp"_dihedral_cosine_shift_exp.html
[Default:] none
diff --git a/doc/src/angle_cosine_squared.txt b/doc/src/angle_cosine_squared.txt
index 23e1b150a..065cdad54 100644
--- a/doc/src/angle_cosine_squared.txt
+++ b/doc/src/angle_cosine_squared.txt
@@ -1,76 +1,76 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
angle_style cosine/squared command :h3
angle_style cosine/squared/omp command :h3
[Syntax:]
angle_style cosine/squared :pre
[Examples:]
angle_style cosine/squared
angle_coeff 2*4 75.0 100.0 :pre
[Description:]
The {cosine/squared} angle style uses the potential
:c,image(Eqs/angle_cosine_squared.jpg)
where theta0 is the equilibrium value of the angle, and K is a
prefactor. Note that the usual 1/2 factor is included in K.
The following coefficients must be defined for each angle type via the
"angle_coeff"_angle_coeff.html command as in the example above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands:
K (energy)
theta0 (degrees) :ul
Theta0 is specified in degrees, but LAMMPS converts it to radians
internally.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
MOLECULE package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info on packages.
[Related commands:]
"angle_coeff"_angle_coeff.html
[Default:] none
diff --git a/doc/src/angle_fourier.txt b/doc/src/angle_fourier.txt
index f58ae8e4f..da39e7cf3 100644
--- a/doc/src/angle_fourier.txt
+++ b/doc/src/angle_fourier.txt
@@ -1,72 +1,72 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
angle_style fourier command :h3
angle_style fourier/omp command :h3
[Syntax:]
angle_style fourier :pre
[Examples:]
angle_style fourier
angle_coeff 75.0 1.0 1.0 1.0
[Description:]
The {fourier} angle style uses the potential
:c,image(Eqs/angle_fourier.jpg)
The following coefficients must be defined for each angle type via the
"angle_coeff"_angle_coeff.html command as in the example above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands:
K (energy)
C0 (real)
C1 (real)
C2 (real) :ul
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
USER_MISC package. See the "Making LAMMPS"_Section_start.html#start_3
section for more info on packages.
[Related commands:]
"angle_coeff"_angle_coeff.html
[Default:] none
diff --git a/doc/src/angle_fourier_simple.txt b/doc/src/angle_fourier_simple.txt
index 9da8ffed2..5adda6cb3 100644
--- a/doc/src/angle_fourier_simple.txt
+++ b/doc/src/angle_fourier_simple.txt
@@ -1,71 +1,71 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
angle_style fourier/simple command :h3
angle_style fourier/simple/omp command :h3
[Syntax:]
angle_style fourier/simple :pre
[Examples:]
angle_style fourier/simple
angle_coeff 100.0 -1.0 1.0
[Description:]
The {fourier/simple} angle style uses the potential
:c,image(Eqs/angle_fourier_simple.jpg)
The following coefficients must be defined for each angle type via the
"angle_coeff"_angle_coeff.html command as in the example above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands:
K (energy)
c (real)
n (real) :ul
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
USER_MISC package. See the "Making LAMMPS"_Section_start.html#start_3
section for more info on packages.
[Related commands:]
"angle_coeff"_angle_coeff.html
[Default:] none
diff --git a/doc/src/angle_harmonic.txt b/doc/src/angle_harmonic.txt
index 12ee80521..4c7476396 100644
--- a/doc/src/angle_harmonic.txt
+++ b/doc/src/angle_harmonic.txt
@@ -1,78 +1,78 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
angle_style harmonic command :h3
angle_style harmonic/intel command :h3
angle_style harmonic/kk command :h3
angle_style harmonic/omp command :h3
[Syntax:]
angle_style harmonic :pre
[Examples:]
angle_style harmonic
angle_coeff 1 300.0 107.0 :pre
[Description:]
The {harmonic} angle style uses the potential
:c,image(Eqs/angle_harmonic.jpg)
where theta0 is the equilibrium value of the angle, and K is a
prefactor. Note that the usual 1/2 factor is included in K.
The following coefficients must be defined for each angle type via the
"angle_coeff"_angle_coeff.html command as in the example above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands:
K (energy/radian^2)
theta0 (degrees) :ul
Theta0 is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of K are in energy/radian^2.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
MOLECULE package. See the "Making LAMMPS"_Section_start.html#start_3
section for more info on packages.
[Related commands:]
"angle_coeff"_angle_coeff.html
[Default:] none
diff --git a/doc/src/angle_quartic.txt b/doc/src/angle_quartic.txt
index fea2eb9e0..f7640bdfb 100644
--- a/doc/src/angle_quartic.txt
+++ b/doc/src/angle_quartic.txt
@@ -1,78 +1,78 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
angle_style quartic command :h3
angle_style quartic/omp command :h3
[Syntax:]
angle_style quartic :pre
[Examples:]
angle_style quartic
angle_coeff 1 129.1948 56.8726 -25.9442 -14.2221 :pre
[Description:]
The {quartic} angle style uses the potential
:c,image(Eqs/angle_quartic.jpg)
where theta0 is the equilibrium value of the angle, and K is a
prefactor. Note that the usual 1/2 factor is included in K.
The following coefficients must be defined for each angle type via the
"angle_coeff"_angle_coeff.html command as in the example above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands:
theta0 (degrees)
K2 (energy/radian^2)
K3 (energy/radian^3)
K4 (energy/radian^4) :ul
Theta0 is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of K are in energy/radian^2.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
USER_MISC package. See the "Making LAMMPS"_Section_start.html#start_3
section for more info on packages.
[Related commands:]
"angle_coeff"_angle_coeff.html
[Default:] none
diff --git a/doc/src/angle_table.txt b/doc/src/angle_table.txt
index 61dd7b041..bd6e167bd 100644
--- a/doc/src/angle_table.txt
+++ b/doc/src/angle_table.txt
@@ -1,157 +1,157 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
angle_style table command :h3
angle_style table/omp command :h3
[Syntax:]
angle_style table style N :pre
style = {linear} or {spline} = method of interpolation
N = use N values in table :ul
[Examples:]
angle_style table linear 1000
angle_coeff 3 file.table ENTRY1 :pre
[Description:]
Style {table} creates interpolation tables of length {N} from angle
potential and derivative values listed in a file(s) as a function of
angle The files are read by the "angle_coeff"_angle_coeff.html
command.
The interpolation tables are created by fitting cubic splines to the
file values and interpolating energy and derivative values at each of
{N} angles. During a simulation, these tables are used to interpolate
energy and force values on individual atoms as needed. The
interpolation is done in one of 2 styles: {linear} or {spline}.
For the {linear} style, the angle is used to find 2 surrounding table
values from which an energy or its derivative is computed by linear
interpolation.
For the {spline} style, a cubic spline coefficients are computed and
stored at each of the {N} values in the table. The angle is used to
find the appropriate set of coefficients which are used to evaluate a
cubic polynomial which computes the energy or derivative.
The following coefficients must be defined for each angle type via the
"angle_coeff"_angle_coeff.html command as in the example above.
filename
keyword :ul
The filename specifies a file containing tabulated energy and
derivative values. The keyword specifies a section of the file. The
format of this file is described below.
:line
The format of a tabulated file is as follows (without the
parenthesized comments):
# Angle potential for harmonic (one or more comment or blank lines) :pre
HAM (keyword is the first text on line)
N 181 FP 0 0 EQ 90.0 (N, FP, EQ parameters)
(blank line)
N 181 FP 0 0 (N, FP parameters)
1 0.0 200.5 2.5 (index, angle, energy, derivative)
2 1.0 198.0 2.5
...
181 180.0 0.0 0.0 :pre
A section begins with a non-blank line whose 1st character is not a
"#"; blank lines or lines starting with "#" can be used as comments
between sections. The first line begins with a keyword which
identifies the section. The line can contain additional text, but the
initial text must match the argument specified in the
"angle_coeff"_angle_coeff.html command. The next line lists (in any
order) one or more parameters for the table. Each parameter is a
keyword followed by one or more numeric values.
The parameter "N" is required and its value is the number of table
entries that follow. Note that this may be different than the {N}
specified in the "angle_style table"_angle_style.html command. Let
Ntable = {N} in the angle_style command, and Nfile = "N" in the
tabulated file. What LAMMPS does is a preliminary interpolation by
creating splines using the Nfile tabulated values as nodal points. It
uses these to interpolate as needed to generate energy and derivative
values at Ntable different points. The resulting tables of length
Ntable are then used as described above, when computing energy and
force for individual angles and their atoms. This means that if you
want the interpolation tables of length Ntable to match exactly what
is in the tabulated file (with effectively no preliminary
interpolation), you should set Ntable = Nfile.
The "FP" parameter is optional. If used, it is followed by two values
fplo and fphi, which are the 2nd derivatives at the innermost and
outermost angle settings. These values are needed by the spline
construction routines. If not specified by the "FP" parameter, they
are estimated (less accurately) by the first two and last two
derivative values in the table.
The "EQ" parameter is also optional. If used, it is followed by a the
equilibrium angle value, which is used, for example, by the "fix
shake"_fix_shake.html command. If not used, the equilibrium angle is
set to 180.0.
Following a blank line, the next N lines list the tabulated values.
On each line, the 1st value is the index from 1 to N, the 2nd value is
the angle value (in degrees), the 3rd value is the energy (in energy
units), and the 4th is -dE/d(theta) (also in energy units). The 3rd
term is the energy of the 3-atom configuration for the specified
angle. The last term is the derivative of the energy with respect to
the angle (in degrees, not radians). Thus the units of the last term
are still energy, not force. The angle values must increase from one
line to the next. The angle values must also begin with 0.0 and end
with 180.0, i.e. span the full range of possible angles.
Note that one file can contain many sections, each with a tabulated
potential. LAMMPS reads the file section by section until it finds
one that matches the specified keyword.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
MOLECULE package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info on packages.
[Related commands:]
"angle_coeff"_angle_coeff.html
[Default:] none
diff --git a/doc/src/balance.txt b/doc/src/balance.txt
index 79728d656..da6f59900 100644
--- a/doc/src/balance.txt
+++ b/doc/src/balance.txt
@@ -1,518 +1,518 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
balance command :h3
[Syntax:]
balance thresh style args ... keyword args ... :pre
thresh = imbalance threshold that must be exceeded to perform a re-balance :ulb,l
one style/arg pair can be used (or multiple for {x},{y},{z}) :l
style = {x} or {y} or {z} or {shift} or {rcb} :l
{x} args = {uniform} or Px-1 numbers between 0 and 1
{uniform} = evenly spaced cuts between processors in x dimension
numbers = Px-1 ascending values between 0 and 1, Px - # of processors in x dimension
{x} can be specified together with {y} or {z}
{y} args = {uniform} or Py-1 numbers between 0 and 1
{uniform} = evenly spaced cuts between processors in y dimension
numbers = Py-1 ascending values between 0 and 1, Py - # of processors in y dimension
{y} can be specified together with {x} or {z}
{z} args = {uniform} or Pz-1 numbers between 0 and 1
{uniform} = evenly spaced cuts between processors in z dimension
numbers = Pz-1 ascending values between 0 and 1, Pz - # of processors in z dimension
{z} can be specified together with {x} or {y}
{shift} args = dimstr Niter stopthresh
dimstr = sequence of letters containing "x" or "y" or "z", each not more than once
Niter = # of times to iterate within each dimension of dimstr sequence
stopthresh = stop balancing when this imbalance threshold is reached
{rcb} args = none :pre
zero or more keyword/arg pairs may be appended :l
keyword = {weight} or {out} :l
{weight} style args = use weighted particle counts for the balancing
{style} = {group} or {neigh} or {time} or {var} or {store}
{group} args = Ngroup group1 weight1 group2 weight2 ...
Ngroup = number of groups with assigned weights
group1, group2, ... = group IDs
weight1, weight2, ... = corresponding weight factors
{neigh} factor = compute weight based on number of neighbors
factor = scaling factor (> 0)
{time} factor = compute weight based on time spend computing
factor = scaling factor (> 0)
{var} name = take weight from atom-style variable
name = name of the atom-style variable
{store} name = store weight in custom atom property defined by "fix property/atom"_fix_property_atom.html command
name = atom property name (without d_ prefix)
{out} arg = filename
filename = write each processor's sub-domain to a file :pre
:ule
[Examples:]
balance 0.9 x uniform y 0.4 0.5 0.6
balance 1.2 shift xz 5 1.1
balance 1.0 shift xz 5 1.1
balance 1.1 rcb
balance 1.0 shift x 10 1.1 weight group 2 fast 0.5 slow 2.0
balance 1.0 shift x 10 1.1 weight time 0.8 weight neigh 0.5 weight store balance
balance 1.0 shift x 20 1.0 out tmp.balance :pre
[Description:]
This command adjusts the size and shape of processor sub-domains
within the simulation box, to attempt to balance the number of atoms
or particles and thus indirectly the computational cost (load) more
evenly across processors. The load balancing is "static" in the sense
that this command performs the balancing once, before or between
simulations. The processor sub-domains will then remain static during
the subsequent run. To perform "dynamic" balancing, see the "fix
balance"_fix_balance.html command, which can adjust processor
sub-domain sizes and shapes on-the-fly during a "run"_run.html.
Load-balancing is typically most useful if the particles in the
simulation box have a spatially-varying density distribution or when
the computational cost varies significantly between different
particles. E.g. a model of a vapor/liquid interface, or a solid with
an irregular-shaped geometry containing void regions, or "hybrid pair
style simulations"_pair_hybrid.html which combine pair styles with
different computational cost. In these cases, the LAMMPS default of
dividing the simulation box volume into a regular-spaced grid of 3d
bricks, with one equal-volume sub-domain per processor, may assign
numbers of particles per processor in a way that the computational
effort varies significantly. This can lead to poor performance when
the simulation is run in parallel.
The balancing can be performed with or without per-particle weighting.
With no weighting, the balancing attempts to assign an equal number of
particles to each processor. With weighting, the balancing attempts
to assign an equal aggregate computational weight to each processor,
which typically induces a different number of atoms assigned to each
processor. Details on the various weighting options and examples for
how they can be used are "given below"_#weighted_balance.
Note that the "processors"_processors.html command allows some control
over how the box volume is split across processors. Specifically, for
a Px by Py by Pz grid of processors, it allows choice of Px, Py, and
Pz, subject to the constraint that Px * Py * Pz = P, the total number
of processors. This is sufficient to achieve good load-balance for
some problems on some processor counts. However, all the processor
sub-domains will still have the same shape and same volume.
The requested load-balancing operation is only performed if the
current "imbalance factor" in particles owned by each processor
exceeds the specified {thresh} parameter. The imbalance factor is
defined as the maximum number of particles (or weight) owned by any
processor, divided by the average number of particles (or weight) per
processor. Thus an imbalance factor of 1.0 is perfect balance.
As an example, for 10000 particles running on 10 processors, if the
most heavily loaded processor has 1200 particles, then the factor is
1.2, meaning there is a 20% imbalance. Note that a re-balance can be
forced even if the current balance is perfect (1.0) be specifying a
{thresh} < 1.0.
NOTE: Balancing is performed even if the imbalance factor does not
exceed the {thresh} parameter if a "grid" style is specified when the
current partitioning is "tiled". The meaning of "grid" vs "tiled" is
explained below. This is to allow forcing of the partitioning to
"grid" so that the "comm_style brick"_comm_style.html command can then
be used to replace a current "comm_style tiled"_comm_style.html
setting.
When the balance command completes, it prints statistics about the
result, including the change in the imbalance factor and the change in
the maximum number of particles on any processor. For "grid" methods
(defined below) that create a logical 3d grid of processors, the
positions of all cutting planes in each of the 3 dimensions (as
fractions of the box length) are also printed.
NOTE: This command attempts to minimize the imbalance factor, as
defined above. But depending on the method a perfect balance (1.0)
may not be achieved. For example, "grid" methods (defined below) that
create a logical 3d grid cannot achieve perfect balance for many
irregular distributions of particles. Likewise, if a portion of the
system is a perfect lattice, e.g. the initial system is generated by
the "create_atoms"_create_atoms.html command, then "grid" methods may
be unable to achieve exact balance. This is because entire lattice
planes will be owned or not owned by a single processor.
NOTE: The imbalance factor is also an estimate of the maximum speed-up
you can hope to achieve by running a perfectly balanced simulation
versus an imbalanced one. In the example above, the 10000 particle
simulation could run up to 20% faster if it were perfectly balanced,
versus when imbalanced. However, computational cost is not strictly
proportional to particle count, and changing the relative size and
shape of processor sub-domains may lead to additional computational
and communication overheads, e.g. in the PPPM solver used via the
"kspace_style"_kspace_style.html command. Thus you should benchmark
the run times of a simulation before and after balancing.
:line
The method used to perform a load balance is specified by one of the
listed styles (or more in the case of {x},{y},{z}), which are
described in detail below. There are 2 kinds of styles.
The {x}, {y}, {z}, and {shift} styles are "grid" methods which produce
a logical 3d grid of processors. They operate by changing the cutting
planes (or lines) between processors in 3d (or 2d), to adjust the
volume (area in 2d) assigned to each processor, as in the following 2d
diagram where processor sub-domains are shown and particles are
colored by the processor that owns them. The leftmost diagram is the
default partitioning of the simulation box across processors (one
sub-box for each of 16 processors); the middle diagram is after a
"grid" method has been applied.
:image(JPG/balance_uniform_small.jpg,JPG/balance_uniform.jpg),image(JPG/balance_nonuniform_small.jpg,JPG/balance_nonuniform.jpg),image(JPG/balance_rcb_small.jpg,JPG/balance_rcb.jpg)
:c
The {rcb} style is a "tiling" method which does not produce a logical
3d grid of processors. Rather it tiles the simulation domain with
rectangular sub-boxes of varying size and shape in an irregular
fashion so as to have equal numbers of particles (or weight) in each
sub-box, as in the rightmost diagram above.
The "grid" methods can be used with either of the
"comm_style"_comm_style.html command options, {brick} or {tiled}. The
"tiling" methods can only be used with "comm_style
tiled"_comm_style.html. Note that it can be useful to use a "grid"
method with "comm_style tiled"_comm_style.html to return the domain
partitioning to a logical 3d grid of processors so that "comm_style
brick" can afterwords be specified for subsequent "run"_run.html
commands.
When a "grid" method is specified, the current domain partitioning can
be either a logical 3d grid or a tiled partitioning. In the former
case, the current logical 3d grid is used as a starting point and
changes are made to improve the imbalance factor. In the latter case,
the tiled partitioning is discarded and a logical 3d grid is created
with uniform spacing in all dimensions. This becomes the starting
point for the balancing operation.
When a "tiling" method is specified, the current domain partitioning
("grid" or "tiled") is ignored, and a new partitioning is computed
from scratch.
:line
The {x}, {y}, and {z} styles invoke a "grid" method for balancing, as
described above. Note that any or all of these 3 styles can be
specified together, one after the other, but they cannot be used with
any other style. This style adjusts the position of cutting planes
between processor sub-domains in specific dimensions. Only the
specified dimensions are altered.
The {uniform} argument spaces the planes evenly, as in the left
diagrams above. The {numeric} argument requires listing Ps-1 numbers
that specify the position of the cutting planes. This requires
knowing Ps = Px or Py or Pz = the number of processors assigned by
LAMMPS to the relevant dimension. This assignment is made (and the
Px, Py, Pz values printed out) when the simulation box is created by
the "create_box" or "read_data" or "read_restart" command and is
influenced by the settings of the "processors"_processors.html
command.
Each of the numeric values must be between 0 and 1, and they must be
listed in ascending order. They represent the fractional position of
the cutting place. The left (or lower) edge of the box is 0.0, and
the right (or upper) edge is 1.0. Neither of these values is
specified. Only the interior Ps-1 positions are specified. Thus is
there are 2 processors in the x dimension, you specify a single value
such as 0.75, which would make the left processor's sub-domain 3x
larger than the right processor's sub-domain.
:line
The {shift} style invokes a "grid" method for balancing, as
described above. It changes the positions of cutting planes between
processors in an iterative fashion, seeking to reduce the imbalance
factor, similar to how the "fix balance shift"_fix_balance.html
command operates.
The {dimstr} argument is a string of characters, each of which must be
an "x" or "y" or "z". Eacn character can appear zero or one time,
since there is no advantage to balancing on a dimension more than
once. You should normally only list dimensions where you expect there
to be a density variation in the particles.
Balancing proceeds by adjusting the cutting planes in each of the
dimensions listed in {dimstr}, one dimension at a time. For a single
dimension, the balancing operation (described below) is iterated on up
to {Niter} times. After each dimension finishes, the imbalance factor
is re-computed, and the balancing operation halts if the {stopthresh}
criterion is met.
A rebalance operation in a single dimension is performed using a
recursive multisectioning algorithm, where the position of each
cutting plane (line in 2d) in the dimension is adjusted independently.
This is similar to a recursive bisectioning for a single value, except
that the bounds used for each bisectioning take advantage of
information from neighboring cuts if possible. At each iteration, the
count of particles on either side of each plane is tallied. If the
counts do not match the target value for the plane, the position of
the cut is adjusted to be halfway between a low and high bound. The
low and high bounds are adjusted on each iteration, using new count
information, so that they become closer together over time. Thus as
the recursion progresses, the count of particles on either side of the
plane gets closer to the target value.
Once the rebalancing is complete and final processor sub-domains
assigned, particles are migrated to their new owning processor, and
the balance procedure ends.
NOTE: At each rebalance operation, the bisectioning for each cutting
plane (line in 2d) typically starts with low and high bounds separated
by the extent of a processor's sub-domain in one dimension. The size
of this bracketing region shrinks by 1/2 every iteration. Thus if
{Niter} is specified as 10, the cutting plane will typically be
positioned to 1 part in 1000 accuracy (relative to the perfect target
position). For {Niter} = 20, it will be accurate to 1 part in a
million. Thus there is no need ot set {Niter} to a large value.
LAMMPS will check if the threshold accuracy is reached (in a
dimension) is less iterations than {Niter} and exit early. However,
{Niter} should also not be set too small, since it will take roughly
the same number of iterations to converge even if the cutting plane is
initially close to the target value.
:line
The {rcb} style invokes a "tiled" method for balancing, as described
above. It performs a recursive coordinate bisectioning (RCB) of the
simulation domain. The basic idea is as follows.
The simulation domain is cut into 2 boxes by an axis-aligned cut in
one of the dimensions, leaving one new sub-box on either side of the
cut. Which dimension is chosen for the cut depends on the particle
(weight) distribution within the parent box. Normally the longest
dimension of the box is cut, but if all (or most) of the particles are
at one end of the box, a cut may be performed in another dimension to
induce sub-boxes that are more cube-ish (3d) or square-ish (2d) in
shape.
After the cut is made, all the processors are also partitioned into 2
groups, half assigned to the box on the lower side of the cut, and
half to the box on the upper side. (If the processor count is odd,
one side gets an extra processor.) The cut is positioned so that the
number of (weighted) particles in the lower box is exactly the number
that the processors assigned to that box should own for load balance
to be perfect. This also makes load balance for the upper box
perfect. The positioning of the cut is done iteratively, by a
bisectioning method (median search). Note that counting particles on
either side of the cut requires communication between all processors
at each iteration.
That is the procedure for the first cut. Subsequent cuts are made
recursively, in exactly the same manner. The subset of processors
assigned to each box make a new cut in one dimension of that box,
splitting the box, the subset of processors, and the particles in the
box in two. The recursion continues until every processor is assigned
a sub-box of the entire simulation domain, and owns the (weighted)
particles in that sub-box.
:line
This sub-section describes how to perform weighted load balancing
using the {weight} keyword. :link(weighted_balance)
By default, all particles have a weight of 1.0, which means each
particle is assumed to require the same amount of computation during a
timestep. There are, however, scenarios where this is not a good
assumption. Measuring the computational cost for each particle
accurately would be impractical and slow down the computation.
Instead the {weight} keyword implements several ways to influence the
per-particle weights empirically by properties readily available or
using the user's knowledge of the system. Note that the absolute
value of the weights are not important; only their relative ratios
affect which particle is assigned to which processor. A particle with
a weight of 2.5 is assumed to require 5x more computational than a
particle with a weight of 0.5. For all the options below the weight
assigned to a particle must be a positive value; an error will be be
generated if a weight is <= 0.0.
Below is a list of possible weight options with a short description of
their usage and some example scenarios where they might be applicable.
It is possible to apply multiple weight flags and the weightings they
induce will be combined through multiplication. Most of the time,
however, it is sufficient to use just one method.
The {group} weight style assigns weight factors to specified
"groups"_group.html of particles. The {group} style keyword is
followed by the number of groups, then pairs of group IDs and the
corresponding weight factor. If a particle belongs to none of the
specified groups, its weight is not changed. If it belongs to
multiple groups, its weight is the product of the weight factors.
This weight style is useful in combination with pair style
"hybrid"_pair_hybrid.html, e.g. when combining a more costly manybody
potential with a fast pair-wise potential. It is also useful when
using "run_style respa"_run_style.html where some portions of the
system have many bonded interactions and others none. It assumes that
the computational cost for each group remains constant over time.
This is a purely empirical weighting, so a series test runs to tune
the assigned weight factors for optimal performance is recommended.
The {neigh} weight style assigns the same weight to each particle
owned by a processor based on the total count of neighbors in the
neighbor list owned by that processor. The motivation is that more
neighbors means a higher computational cost. The style does not use
neighbors per atom to assign a unique weight to each atom, because
that value can vary depending on how the neighbor list is built.
The {factor} setting is applied as an overall scale factor to the
{neigh} weights which allows adjustment of their impact on the
balancing operation. The specified {factor} value must be positive.
A value > 1.0 will increase the weights so that the ratio of max
weight to min weight increases by {factor}. A value < 1.0 will
decrease the weights so that the ratio of max weight to min weight
decreases by {factor}. In both cases the intermediate weight values
increase/decrease proportionally as well. A value = 1.0 has no effect
on the {neigh} weights. As a rule of thumb, we have found a {factor}
of about 0.8 often results in the best performance, since the number
of neighbors is likely to overestimate the ideal weight.
This weight style is useful for systems where there are different
cutoffs used for different pairs of interactions, or the density
fluctuates, or a large number of particles are in the vicinity of a
wall, or a combination of these effects. If a simulation uses
multiple neighbor lists, this weight style will use the first suitable
neighbor list it finds. It will not request or compute a new list. A
warning will be issued if there is no suitable neighbor list available
or if it is not current, e.g. if the balance command is used before a
"run"_run.html or "minimize"_minimize.html command is used, in which
case the neighbor list may not yet have been built. In this case no
weights are computed. Inserting a "run 0 post no"_run.html command
before issuing the {balance} command, may be a workaround for this
case, as it will induce the neighbor list to be built.
The {time} weight style uses "timer data"_timer.html to estimate
weights. It assigns the same weight to each particle owned by a
processor based on the total computational time spent by that
processor. See details below on what time window is used. It uses
the same timing information as is used for the "MPI task timing
-breakdown"_Section_start.html#start_8, namely, for sections {Pair},
+breakdown"_Section_start.html#start_7, namely, for sections {Pair},
{Bond}, {Kspace}, and {Neigh}. The time spent in those portions of
the timestep are measured for each MPI rank, summed, then divided by
the number of particles owned by that processor. I.e. the weight is
an effective CPU time/particle averaged over the particles on that
processor.
The {factor} setting is applied as an overall scale factor to the
{time} weights which allows adjustment of their impact on the
balancing operation. The specified {factor} value must be positive.
A value > 1.0 will increase the weights so that the ratio of max
weight to min weight increases by {factor}. A value < 1.0 will
decrease the weights so that the ratio of max weight to min weight
decreases by {factor}. In both cases the intermediate weight values
increase/decrease proportionally as well. A value = 1.0 has no effect
on the {time} weights. As a rule of thumb, effective values to use
are typically between 0.5 and 1.2. Note that the timer quantities
mentioned above can be affected by communication which occurs in the
middle of the operations, e.g. pair styles with intermediate exchange
of data witin the force computation, and likewise for KSpace solves.
When using the {time} weight style with the {balance} command, the
timing data is taken from the preceding run command, i.e. the timings
are for the entire previous run. For the {fix balance} command the
timing data is for only the timesteps since the last balancing
operation was performed. If timing information for the required
sections is not available, e.g. at the beginning of a run, or when the
"timer"_timer.html command is set to either {loop} or {off}, a warning
is issued. In this case no weights are computed.
NOTE: The {time} weight style is the most generic option, and should
be tried first, unless the {group} style is easily applicable.
However, since the computed cost function is averaged over all
particles on a processor, the weights may not be highly accurate.
This style can also be effective as a secondary weight in combination
with either {group} or {neigh} to offset some of inaccuracies in
either of those heuristics.
The {var} weight style assigns per-particle weights by evaluating an
"atom-style variable"_variable.html specified by {name}. This is
provided as a more flexible alternative to the {group} weight style,
allowing definition of a more complex heuristics based on information
(global and per atom) available inside of LAMMPS. For example,
atom-style variables can reference the position of a particle, its
velocity, the volume of its Voronoi cell, etc.
The {store} weight style does not compute a weight factor. Instead it
stores the current accumulated weights in a custom per-atom property
specified by {name}. This must be a property defined as {d_name} via
the "fix property/atom"_fix_property_atom.html command. Note that
these custom per-atom properties can be output in a "dump"_dump.html
file, so this is a way to examine, debug, or visualize the
per-particle weights computed during the load-balancing operation.
:line
The {out} keyword writes a text file to the specified {filename} with
the results of the balancing operation. The file contains the bounds
of the sub-domain for each processor after the balancing operation
completes. The format of the file is compatible with the
"Pizza.py"_pizza {mdump} tool which has support for manipulating and
visualizing mesh files. An example is shown here for a balancing by 4
processors for a 2d problem:
ITEM: TIMESTEP
0
ITEM: NUMBER OF NODES
16
ITEM: BOX BOUNDS
0 10
0 10
0 10
ITEM: NODES
1 1 0 0 0
2 1 5 0 0
3 1 5 5 0
4 1 0 5 0
5 1 5 0 0
6 1 10 0 0
7 1 10 5 0
8 1 5 5 0
9 1 0 5 0
10 1 5 5 0
11 1 5 10 0
12 1 10 5 0
13 1 5 5 0
14 1 10 5 0
15 1 10 10 0
16 1 5 10 0
ITEM: TIMESTEP
0
ITEM: NUMBER OF SQUARES
4
ITEM: SQUARES
1 1 1 2 3 4
2 1 5 6 7 8
3 1 9 10 11 12
4 1 13 14 15 16 :pre
The coordinates of all the vertices are listed in the NODES section, 5
per processor. Note that the 4 sub-domains share vertices, so there
will be duplicate nodes in the list.
The "SQUARES" section lists the node IDs of the 4 vertices in a
rectangle for each processor (1 to 4).
For a 3d problem, the syntax is similar with 8 vertices listed for
each processor, instead of 4, and "SQUARES" replaced by "CUBES".
:line
[Restrictions:]
For 2d simulations, the {z} style cannot be used. Nor can a "z"
appear in {dimstr} for the {shift} style.
[Related commands:]
"group"_group.html, "processors"_processors.html,
"fix balance"_fix_balance.html
[Default:] none
diff --git a/doc/src/bond_class2.txt b/doc/src/bond_class2.txt
index aa0541238..9687a6316 100644
--- a/doc/src/bond_class2.txt
+++ b/doc/src/bond_class2.txt
@@ -1,82 +1,82 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
bond_style class2 command :h3
bond_style class2/omp command :h3
bond_style class2/kk command :h3
[Syntax:]
bond_style class2 :pre
[Examples:]
bond_style class2
bond_coeff 1 1.0 100.0 80.0 80.0 :pre
[Description:]
The {class2} bond style uses the potential
:c,image(Eqs/bond_class2.jpg)
where r0 is the equilibrium bond distance.
See "(Sun)"_#bond-Sun for a description of the COMPASS class2 force field.
The following coefficients must be defined for each bond type via the
"bond_coeff"_bond_coeff.html command as in the example above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands:
R0 (distance)
K2 (energy/distance^2)
K3 (energy/distance^3)
K4 (energy/distance^4) :ul
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This bond style can only be used if LAMMPS was built with the CLASS2
package. See the "Making LAMMPS"_Section_start.html#start_3 section
for more info on packages.
[Related commands:]
"bond_coeff"_bond_coeff.html, "delete_bonds"_delete_bonds.html
[Default:] none
:line
:link(bond-Sun)
[(Sun)] Sun, J Phys Chem B 102, 7338-7364 (1998).
diff --git a/doc/src/bond_fene.txt b/doc/src/bond_fene.txt
index 80d2a805c..9050c3bf5 100644
--- a/doc/src/bond_fene.txt
+++ b/doc/src/bond_fene.txt
@@ -1,89 +1,89 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
bond_style fene command :h3
bond_style fene/intel command :h3
bond_style fene/kk command :h3
bond_style fene/omp command :h3
[Syntax:]
bond_style fene :pre
[Examples:]
bond_style fene
bond_coeff 1 30.0 1.5 1.0 1.0 :pre
[Description:]
The {fene} bond style uses the potential
:c,image(Eqs/bond_fene.jpg)
to define a finite extensible nonlinear elastic (FENE) potential
"(Kremer)"_#fene-Kremer, used for bead-spring polymer models. The first
term is attractive, the 2nd Lennard-Jones term is repulsive. The
first term extends to R0, the maximum extent of the bond. The 2nd
term is cutoff at 2^(1/6) sigma, the minimum of the LJ potential.
The following coefficients must be defined for each bond type via the
"bond_coeff"_bond_coeff.html command as in the example above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands:
K (energy/distance^2)
R0 (distance)
epsilon (energy)
sigma (distance) :ul
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This bond style can only be used if LAMMPS was built with the
MOLECULE package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info on packages.
You typically should specify "special_bonds fene"_special_bonds.html
or "special_bonds lj/coul 0 1 1"_special_bonds.html to use this bond
style. LAMMPS will issue a warning it that's not the case.
[Related commands:]
"bond_coeff"_bond_coeff.html, "delete_bonds"_delete_bonds.html
[Default:] none
:line
:link(fene-Kremer)
[(Kremer)] Kremer, Grest, J Chem Phys, 92, 5057 (1990).
diff --git a/doc/src/bond_fene_expand.txt b/doc/src/bond_fene_expand.txt
index 3908c16a7..ff687444a 100644
--- a/doc/src/bond_fene_expand.txt
+++ b/doc/src/bond_fene_expand.txt
@@ -1,92 +1,92 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
bond_style fene/expand command :h3
bond_style fene/expand/omp command :h3
[Syntax:]
bond_style fene/expand :pre
[Examples:]
bond_style fene/expand
bond_coeff 1 30.0 1.5 1.0 1.0 0.5 :pre
[Description:]
The {fene/expand} bond style uses the potential
:c,image(Eqs/bond_fene_expand.jpg)
to define a finite extensible nonlinear elastic (FENE) potential
"(Kremer)"_#feneexpand-Kremer, used for bead-spring polymer models. The first
term is attractive, the 2nd Lennard-Jones term is repulsive.
The {fene/expand} bond style is similar to {fene} except that an extra
shift factor of delta (positive or negative) is added to {r} to
effectively change the bead size of the bonded atoms. The first term
now extends to R0 + delta and the 2nd term is cutoff at 2^(1/6) sigma
+ delta.
The following coefficients must be defined for each bond type via the
"bond_coeff"_bond_coeff.html command as in the example above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands:
K (energy/distance^2)
R0 (distance)
epsilon (energy)
sigma (distance)
delta (distance) :ul
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This bond style can only be used if LAMMPS was built with the
MOLECULE package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info on packages.
You typically should specify "special_bonds fene"_special_bonds.html
or "special_bonds lj/coul 0 1 1"_special_bonds.html to use this bond
style. LAMMPS will issue a warning it that's not the case.
[Related commands:]
"bond_coeff"_bond_coeff.html, "delete_bonds"_delete_bonds.html
[Default:] none
:line
:link(feneexpand-Kremer)
[(Kremer)] Kremer, Grest, J Chem Phys, 92, 5057 (1990).
diff --git a/doc/src/bond_harmonic.txt b/doc/src/bond_harmonic.txt
index 1cbd897da..c18a7e0fd 100644
--- a/doc/src/bond_harmonic.txt
+++ b/doc/src/bond_harmonic.txt
@@ -1,75 +1,75 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
bond_style harmonic command :h3
bond_style harmonic/intel command :h3
bond_style harmonic/kk command :h3
bond_style harmonic/omp command :h3
[Syntax:]
bond_style harmonic :pre
[Examples:]
bond_style harmonic
bond_coeff 5 80.0 1.2 :pre
[Description:]
The {harmonic} bond style uses the potential
:c,image(Eqs/bond_harmonic.jpg)
where r0 is the equilibrium bond distance. Note that the usual 1/2
factor is included in K.
The following coefficients must be defined for each bond type via the
"bond_coeff"_bond_coeff.html command as in the example above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands:
K (energy/distance^2)
r0 (distance) :ul
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This bond style can only be used if LAMMPS was built with the
MOLECULE package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info on packages.
[Related commands:]
"bond_coeff"_bond_coeff.html, "delete_bonds"_delete_bonds.html
[Default:] none
diff --git a/doc/src/bond_harmonic_shift.txt b/doc/src/bond_harmonic_shift.txt
index 8cb2d2ce7..bf3b3c115 100644
--- a/doc/src/bond_harmonic_shift.txt
+++ b/doc/src/bond_harmonic_shift.txt
@@ -1,77 +1,77 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
bond_style harmonic/shift command :h3
bond_style harmonic/shift/omp command :h3
[Syntax:]
bond_style harmonic/shift :pre
[Examples:]
bond_style harmonic/shift
bond_coeff 5 10.0 0.5 1.0 :pre
[Description:]
The {harmonic/shift} bond style is a shifted harmonic bond that uses
the potential
:c,image(Eqs/bond_harmonic_shift.jpg)
where r0 is the equilibrium bond distance, and rc the critical distance.
The potential is -Umin at r0 and zero at rc. The spring constant is
k = Umin / \[ 2 (r0-rc)^2\].
The following coefficients must be defined for each bond type via the
"bond_coeff"_bond_coeff.html command as in the example above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands:
Umin (energy) :ul
r0 (distance) :ul
rc (distance) :ul
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This bond style can only be used if LAMMPS was built with the
USER-MISC package. See the "Making LAMMPS"_Section_start.html#start_3
section for more info on packages.
[Related commands:]
"bond_coeff"_bond_coeff.html, "delete_bonds"_delete_bonds.html,
"bond_harmonic"_bond_harmonic.html
[Default:] none
diff --git a/doc/src/bond_harmonic_shift_cut.txt b/doc/src/bond_harmonic_shift_cut.txt
index 836d6afda..1918ce00b 100644
--- a/doc/src/bond_harmonic_shift_cut.txt
+++ b/doc/src/bond_harmonic_shift_cut.txt
@@ -1,78 +1,78 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
bond_style harmonic/shift/cut command :h3
bond_style harmonic/shift/cut/omp command :h3
[Syntax:]
bond_style harmonic/shift/cut :pre
[Examples:]
bond_style harmonic/shift/cut
bond_coeff 5 10.0 0.5 1.0 :pre
[Description:]
The {harmonic/shift/cut} bond style is a shifted harmonic bond that
uses the potential
:c,image(Eqs/bond_harmonic_shift_cut.jpg)
where r0 is the equilibrium bond distance, and rc the critical distance.
The bond potential is zero for distances r > rc. The potential is -Umin
at r0 and zero at rc. The spring constant is k = Umin / \[ 2 (r0-rc)^2\].
The following coefficients must be defined for each bond type via the
"bond_coeff"_bond_coeff.html command as in the example above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands:
Umin (energy)
r0 (distance)
rc (distance) :ul
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This bond style can only be used if LAMMPS was built with the
USER-MISC package. See the "Making LAMMPS"_Section_start.html#start_3
section for more info on packages.
[Related commands:]
"bond_coeff"_bond_coeff.html, "delete_bonds"_delete_bonds.html,
"bond_harmonic"_bond_harmonic.html,
"bond_harmonic_shift"_bond_harmonic_shift.html
[Default:] none
diff --git a/doc/src/bond_morse.txt b/doc/src/bond_morse.txt
index 12e51f9be..4f6a32e34 100644
--- a/doc/src/bond_morse.txt
+++ b/doc/src/bond_morse.txt
@@ -1,74 +1,74 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
bond_style morse command :h3
bond_style morse/omp command :h3
[Syntax:]
bond_style morse :pre
[Examples:]
bond_style morse
bond_coeff 5 1.0 2.0 1.2 :pre
[Description:]
The {morse} bond style uses the potential
:c,image(Eqs/bond_morse.jpg)
where r0 is the equilibrium bond distance, alpha is a stiffness
parameter, and D determines the depth of the potential well.
The following coefficients must be defined for each bond type via the
"bond_coeff"_bond_coeff.html command as in the example above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands:
D (energy)
alpha (inverse distance)
r0 (distance) :ul
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This bond style can only be used if LAMMPS was built with the
MOLECULE package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info on packages.
[Related commands:]
"bond_coeff"_bond_coeff.html, "delete_bonds"_delete_bonds.html
[Default:] none
diff --git a/doc/src/bond_nonlinear.txt b/doc/src/bond_nonlinear.txt
index ac9f3369c..434af6250 100644
--- a/doc/src/bond_nonlinear.txt
+++ b/doc/src/bond_nonlinear.txt
@@ -1,79 +1,79 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
bond_style nonlinear command :h3
bond_style nonlinear/omp command :h3
[Syntax:]
bond_style nonlinear :pre
[Examples:]
bond_style nonlinear
bond_coeff 2 100.0 1.1 1.4 :pre
[Description:]
The {nonlinear} bond style uses the potential
:c,image(Eqs/bond_nonlinear.jpg)
to define an anharmonic spring "(Rector)"_#Rector of equilibrium
length r0 and maximum extension lamda.
The following coefficients must be defined for each bond type via the
"bond_coeff"_bond_coeff.html command as in the example above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands:
epsilon (energy)
r0 (distance)
lamda (distance) :ul
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This bond style can only be used if LAMMPS was built with the
MOLECULE package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info on packages.
[Related commands:]
"bond_coeff"_bond_coeff.html, "delete_bonds"_delete_bonds.html
[Default:] none
:line
:link(Rector)
[(Rector)] Rector, Van Swol, Henderson, Molecular Physics, 82, 1009 (1994).
diff --git a/doc/src/bond_quartic.txt b/doc/src/bond_quartic.txt
index e61f4f034..4dc7ad4a3 100644
--- a/doc/src/bond_quartic.txt
+++ b/doc/src/bond_quartic.txt
@@ -1,113 +1,113 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
bond_style quartic command :h3
bond_style quartic/omp command :h3
[Syntax:]
bond_style quartic :pre
[Examples:]
bond_style quartic
bond_coeff 2 1200 -0.55 0.25 1.3 34.6878 :pre
[Description:]
The {quartic} bond style uses the potential
:c,image(Eqs/bond_quartic.jpg)
to define a bond that can be broken as the simulation proceeds (e.g.
due to a polymer being stretched). The sigma and epsilon used in the
LJ portion of the formula are both set equal to 1.0 by LAMMPS.
The following coefficients must be defined for each bond type via the
"bond_coeff"_bond_coeff.html command as in the example above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands:
K (energy/distance^4)
B1 (distance)
B2 (distance)
Rc (distance)
U0 (energy) :ul
This potential was constructed to mimic the FENE bond potential for
coarse-grained polymer chains. When monomers with sigma = epsilon =
1.0 are used, the following choice of parameters gives a quartic
potential that looks nearly like the FENE potential: K = 1200, B1 =
-0.55, B2 = 0.25, Rc = 1.3, and U0 = 34.6878. Different parameters
can be specified using the "bond_coeff"_bond_coeff.html command, but
you will need to choose them carefully so they form a suitable bond
potential.
Rc is the cutoff length at which the bond potential goes smoothly to a
local maximum. If a bond length ever becomes > Rc, LAMMPS "breaks"
the bond, which means two things. First, the bond potential is turned
off by setting its type to 0, and is no longer computed. Second, a
pairwise interaction between the two atoms is turned on, since they
are no longer bonded.
LAMMPS does the second task via a computational sleight-of-hand. It
subtracts the pairwise interaction as part of the bond computation.
When the bond breaks, the subtraction stops. For this to work, the
pairwise interaction must always be computed by the
"pair_style"_pair_style.html command, whether the bond is broken or
not. This means that "special_bonds"_special_bonds.html must be set
to 1,1,1, as indicated as a restriction below.
Note that when bonds are dumped to a file via the "dump
local"_dump.html command, bonds with type 0 are not included. The
"delete_bonds"_delete_bonds.html command can also be used to query the
status of broken bonds or permanently delete them, e.g.:
delete_bonds all stats
delete_bonds all bond 0 remove :pre
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This bond style can only be used if LAMMPS was built with the
MOLECULE package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info on packages.
The {quartic} style requires that "special_bonds"_special_bonds.html
parameters be set to 1,1,1. Three- and four-body interactions (angle,
dihedral, etc) cannot be used with {quartic} bonds.
[Related commands:]
"bond_coeff"_bond_coeff.html, "delete_bonds"_delete_bonds.html
[Default:] none
diff --git a/doc/src/bond_table.txt b/doc/src/bond_table.txt
index cb096fba1..906d3e5d7 100644
--- a/doc/src/bond_table.txt
+++ b/doc/src/bond_table.txt
@@ -1,154 +1,154 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
bond_style table command :h3
bond_style table/omp command :h3
[Syntax:]
bond_style table style N :pre
style = {linear} or {spline} = method of interpolation
N = use N values in table :ul
[Examples:]
bond_style table linear 1000
bond_coeff 1 file.table ENTRY1 :pre
[Description:]
Style {table} creates interpolation tables of length {N} from bond
potential and force values listed in a file(s) as a function of bond
length. The files are read by the "bond_coeff"_bond_coeff.html
command.
The interpolation tables are created by fitting cubic splines to the
file values and interpolating energy and force values at each of {N}
distances. During a simulation, these tables are used to interpolate
energy and force values as needed. The interpolation is done in one
of 2 styles: {linear} or {spline}.
For the {linear} style, the bond length is used to find 2 surrounding
table values from which an energy or force is computed by linear
interpolation.
For the {spline} style, a cubic spline coefficients are computed and
stored at each of the {N} values in the table. The bond length is
used to find the appropriate set of coefficients which are used to
evaluate a cubic polynomial which computes the energy or force.
The following coefficients must be defined for each bond type via the
"bond_coeff"_bond_coeff.html command as in the example above.
filename
keyword :ul
The filename specifies a file containing tabulated energy and force
values. The keyword specifies a section of the file. The format of
this file is described below.
:line
The format of a tabulated file is as follows (without the
parenthesized comments):
# Bond potential for harmonic (one or more comment or blank lines) :pre
HAM (keyword is the first text on line)
N 101 FP 0 0 EQ 0.5 (N, FP, EQ parameters)
(blank line)
1 0.00 338.0000 1352.0000 (index, bond-length, energy, force)
2 0.01 324.6152 1324.9600
...
101 1.00 338.0000 -1352.0000 :pre
A section begins with a non-blank line whose 1st character is not a
"#"; blank lines or lines starting with "#" can be used as comments
between sections. The first line begins with a keyword which
identifies the section. The line can contain additional text, but the
initial text must match the argument specified in the
"bond_coeff"_bond_coeff.html command. The next line lists (in any
order) one or more parameters for the table. Each parameter is a
keyword followed by one or more numeric values.
The parameter "N" is required and its value is the number of table
entries that follow. Note that this may be different than the {N}
specified in the "bond_style table"_bond_style.html command. Let
Ntable = {N} in the bond_style command, and Nfile = "N" in the
tabulated file. What LAMMPS does is a preliminary interpolation by
creating splines using the Nfile tabulated values as nodal points. It
uses these to interpolate as needed to generate energy and force
values at Ntable different points. The resulting tables of length
Ntable are then used as described above, when computing energy and
force for individual bond lengths. This means that if you want the
interpolation tables of length Ntable to match exactly what is in the
tabulated file (with effectively no preliminary interpolation), you
should set Ntable = Nfile.
The "FP" parameter is optional. If used, it is followed by two values
fplo and fphi, which are the derivatives of the force at the innermost
and outermost bond lengths. These values are needed by the spline
construction routines. If not specified by the "FP" parameter, they
are estimated (less accurately) by the first two and last two force
values in the table.
The "EQ" parameter is also optional. If used, it is followed by a the
equilibrium bond length, which is used, for example, by the "fix
shake"_fix_shake.html command. If not used, the equilibrium bond
length is to the distance in the table with the lowest potential energy.
Following a blank line, the next N lines list the tabulated values.
On each line, the 1st value is the index from 1 to N, the 2nd value is
the bond length r (in distance units), the 3rd value is the energy (in
energy units), and the 4th is the force (in force units). The bond
lengths must range from a LO value to a HI value, and increase from
one line to the next. If the actual bond length is ever smaller than
the LO value or larger than the HI value, then the bond energy and
force is evaluated as if the bond were the LO or HI length.
Note that one file can contain many sections, each with a tabulated
potential. LAMMPS reads the file section by section until it finds
one that matches the specified keyword.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This bond style can only be used if LAMMPS was built with the
MOLECULE package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info on packages.
[Related commands:]
"bond_coeff"_bond_coeff.html, "delete_bonds"_delete_bonds.html
[Default:] none
diff --git a/doc/src/compute_pressure.txt b/doc/src/compute_pressure.txt
index 292e779f7..f0691ad20 100644
--- a/doc/src/compute_pressure.txt
+++ b/doc/src/compute_pressure.txt
@@ -1,154 +1,154 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
compute pressure command :h3
[Syntax:]
compute ID group-ID pressure temp-ID keyword ... :pre
ID, group-ID are documented in "compute"_compute.html command
pressure = style name of this compute command
temp-ID = ID of compute that calculates temperature, can be NULL if not needed
zero or more keywords may be appended
keyword = {ke} or {pair} or {bond} or {angle} or {dihedral} or {improper} or {kspace} or {fix} or {virial} :ul
[Examples:]
compute 1 all pressure thermo_temp
compute 1 all pressure NULL pair bond :pre
[Description:]
Define a computation that calculates the pressure of the entire system
of atoms. The specified group must be "all". See the "compute
stress/atom"_compute_stress_atom.html command if you want per-atom
pressure (stress). These per-atom values could be summed for a group
of atoms via the "compute reduce"_compute_reduce.html command.
The pressure is computed by the formula
:c,image(Eqs/pressure.jpg)
where N is the number of atoms in the system (see discussion of DOF
below), Kb is the Boltzmann constant, T is the temperature, d is the
dimensionality of the system (2 or 3 for 2d/3d), and V is the system
volume (or area in 2d). The second term is the virial, equal to
-dU/dV, computed for all pairwise as well as 2-body, 3-body, 4-body,
manybody, and long-range interactions, where r_i and f_i are the
position and force vector of atom i, and the black dot indicates a dot
product. When periodic boundary conditions are used, N' necessarily
includes periodic image (ghost) atoms outside the central box, and the
position and force vectors of ghost atoms are thus included in the
summation. When periodic boundary conditions are not used, N' = N =
the number of atoms in the system. "Fixes"_fix.html that impose
constraints (e.g. the "fix shake"_fix_shake.html command) also
contribute to the virial term.
A symmetric pressure tensor, stored as a 6-element vector, is also
calculated by this compute. The 6 components of the vector are
ordered xx, yy, zz, xy, xz, yz. The equation for the I,J components
(where I and J = x,y,z) is similar to the above formula, except that
the first term uses components of the kinetic energy tensor and the
second term uses components of the virial tensor:
:c,image(Eqs/pressure_tensor.jpg)
If no extra keywords are listed, the entire equations above are
calculated. This includes a kinetic energy (temperature) term and the
virial as the sum of pair, bond, angle, dihedral, improper, kspace
(long-range), and fix contributions to the force on each atom. If any
extra keywords are listed, then only those components are summed to
compute temperature or ke and/or the virial. The {virial} keyword
means include all terms except the kinetic energy {ke}.
Details of how LAMMPS computes the virial efficiently for the entire
system, including for manybody potentials and accounting for the
effects of periodic boundary conditions are discussed in
"(Thompson)"_#Thompson1.
The temperature and kinetic energy tensor is not calculated by this
compute, but rather by the temperature compute specified with the
command. If the kinetic energy is not included in the pressure, than
the temperature compute is not used and can be specified as NULL.
Normally the temperature compute used by compute pressure should
calculate the temperature of all atoms for consistency with the virial
term, but any compute style that calculates temperature can be used,
e.g. one that excludes frozen atoms or other degrees of freedom.
Note that if desired the specified temperature compute can be one that
subtracts off a bias to calculate a temperature using only the thermal
velocity of the atoms, e.g. by subtracting a background streaming
velocity. See the doc pages for individual "compute
commands"_compute.html to determine which ones include a bias.
Also note that the N in the first formula above is really
degrees-of-freedom divided by d = dimensionality, where the DOF value
is calculated by the temperature compute. See the various "compute
temperature"_compute.html styles for details.
A compute of this style with the ID of "thermo_press" is created when
LAMMPS starts up, as if this command were in the input script:
compute thermo_press all pressure thermo_temp :pre
where "thermo_temp" is the ID of a similarly defined compute of style
"temp". See the "thermo_style" command for more details.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Output info:]
This compute calculates a global scalar (the pressure) and a global
vector of length 6 (pressure tensor), which can be accessed by indices
1-6. These values can be used by any command that uses global scalar
or vector values from a compute as input. See "this
section"_Section_howto.html#howto_15 for an overview of LAMMPS output
options.
The scalar and vector values calculated by this compute are
"intensive". The scalar and vector values will be in pressure
"units"_units.html.
[Restrictions:] none
[Related commands:]
"compute temp"_compute_temp.html, "compute
stress/atom"_compute_stress_atom.html,
"thermo_style"_thermo_style.html,
[Default:] none
:line
:link(Thompson1)
[(Thompson)] Thompson, Plimpton, Mattson, J Chem Phys, 131, 154107 (2009).
diff --git a/doc/src/compute_temp.txt b/doc/src/compute_temp.txt
index 0bd2d4b12..b88be79e2 100644
--- a/doc/src/compute_temp.txt
+++ b/doc/src/compute_temp.txt
@@ -1,113 +1,113 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
compute temp command :h3
compute temp/kk command :h3
[Syntax:]
compute ID group-ID temp :pre
ID, group-ID are documented in "compute"_compute.html command
temp = style name of this compute command :ul
[Examples:]
compute 1 all temp
compute myTemp mobile temp :pre
[Description:]
Define a computation that calculates the temperature of a group of
atoms. A compute of this style can be used by any command that
computes a temperature, e.g. "thermo_modify"_thermo_modify.html, "fix
temp/rescale"_fix_temp_rescale.html, "fix npt"_fix_nh.html, etc.
The temperature is calculated by the formula KE = dim/2 N k T, where
KE = total kinetic energy of the group of atoms (sum of 1/2 m v^2),
dim = 2 or 3 = dimensionality of the simulation, N = number of atoms
in the group, k = Boltzmann constant, and T = temperature.
A kinetic energy tensor, stored as a 6-element vector, is also
calculated by this compute for use in the computation of a pressure
tensor. The formula for the components of the tensor is the same as
the above formula, except that v^2 is replaced by vx*vy for the xy
component, etc. The 6 components of the vector are ordered xx, yy,
zz, xy, xz, yz.
The number of atoms contributing to the temperature is assumed to be
constant for the duration of the run; use the {dynamic} option of the
"compute_modify"_compute_modify.html command if this is not the case.
This compute subtracts out degrees-of-freedom due to fixes that
constrain molecular motion, such as "fix shake"_fix_shake.html and
"fix rigid"_fix_rigid.html. This means the temperature of groups of
atoms that include these constraints will be computed correctly. If
needed, the subtracted degrees-of-freedom can be altered using the
{extra} option of the "compute_modify"_compute_modify.html command.
A compute of this style with the ID of "thermo_temp" is created when
LAMMPS starts up, as if this command were in the input script:
compute thermo_temp all temp :pre
See the "thermo_style" command for more details.
See "this howto section"_Section_howto.html#howto_16 of the manual for
a discussion of different ways to compute temperature and perform
thermostatting.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Output info:]
This compute calculates a global scalar (the temperature) and a global
vector of length 6 (KE tensor), which can be accessed by indices 1-6.
These values can be used by any command that uses global scalar or
vector values from a compute as input. See "this
section"_Section_howto.html#howto_15 for an overview of LAMMPS output
options.
The scalar value calculated by this compute is "intensive". The
vector values are "extensive".
The scalar value will be in temperature "units"_units.html. The
vector values will be in energy "units"_units.html.
[Restrictions:] none
[Related commands:]
"compute temp/partial"_compute_temp_partial.html, "compute
temp/region"_compute_temp_region.html, "compute
pressure"_compute_pressure.html
[Default:] none
diff --git a/doc/src/compute_temp_partial.txt b/doc/src/compute_temp_partial.txt
index 163a00af5..fe2420b4e 100644
--- a/doc/src/compute_temp_partial.txt
+++ b/doc/src/compute_temp_partial.txt
@@ -1,120 +1,120 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
compute temp/partial command :h3
[Syntax:]
compute ID group-ID temp/partial xflag yflag zflag :pre
ID, group-ID are documented in "compute"_compute.html command
temp/partial = style name of this compute command
xflag,yflag,zflag = 0/1 for whether to exclude/include this dimension :ul
[Examples:]
compute newT flow temp/partial 1 1 0 :pre
[Description:]
Define a computation that calculates the temperature of a group of
atoms, after excluding one or more velocity components. A compute of
this style can be used by any command that computes a temperature,
e.g. "thermo_modify"_thermo_modify.html, "fix
temp/rescale"_fix_temp_rescale.html, "fix npt"_fix_nh.html, etc.
The temperature is calculated by the formula KE = dim/2 N k T, where
KE = total kinetic energy of the group of atoms (sum of 1/2 m v^2),
dim = dimensionality of the simulation, N = number of atoms in the
group, k = Boltzmann constant, and T = temperature. The calculation
of KE excludes the x, y, or z dimensions if xflag, yflag, or zflag =
0. The dim parameter is adjusted to give the correct number of
degrees of freedom.
A kinetic energy tensor, stored as a 6-element vector, is also
calculated by this compute for use in the calculation of a pressure
tensor. The formula for the components of the tensor is the same as
the above formula, except that v^2 is replaced by vx*vy for the xy
component, etc. The 6 components of the vector are ordered xx, yy,
zz, xy, xz, yz.
The number of atoms contributing to the temperature is assumed to be
constant for the duration of the run; use the {dynamic} option of the
"compute_modify"_compute_modify.html command if this is not the case.
The removal of velocity components by this fix is essentially
computing the temperature after a "bias" has been removed from the
velocity of the atoms. If this compute is used with a fix command
that performs thermostatting then this bias will be subtracted from
each atom, thermostatting of the remaining thermal velocity will be
performed, and the bias will be added back in. Thermostatting fixes
that work in this way include "fix nvt"_fix_nh.html, "fix
temp/rescale"_fix_temp_rescale.html, "fix
temp/berendsen"_fix_temp_berendsen.html, and "fix
langevin"_fix_langevin.html.
This compute subtracts out degrees-of-freedom due to fixes that
constrain molecular motion, such as "fix shake"_fix_shake.html and
"fix rigid"_fix_rigid.html. This means the temperature of groups of
atoms that include these constraints will be computed correctly. If
needed, the subtracted degrees-of-freedom can be altered using the
{extra} option of the "compute_modify"_compute_modify.html command.
See "this howto section"_Section_howto.html#howto_16 of the manual for
a discussion of different ways to compute temperature and perform
thermostatting.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Output info:]
This compute calculates a global scalar (the temperature) and a global
vector of length 6 (KE tensor), which can be accessed by indices 1-6.
These values can be used by any command that uses global scalar or
vector values from a compute as input. See "this
section"_Section_howto.html#howto_15 for an overview of LAMMPS output
options.
The scalar value calculated by this compute is "intensive". The
vector values are "extensive".
The scalar value will be in temperature "units"_units.html. The
vector values will be in energy "units"_units.html.
[Restrictions:] none
[Related commands:]
"compute temp"_compute_temp.html, "compute
temp/region"_compute_temp_region.html, "compute
pressure"_compute_pressure.html
[Default:] none
diff --git a/doc/src/dihedral_charmm.txt b/doc/src/dihedral_charmm.txt
index 73dc67cde..06abe054e 100644
--- a/doc/src/dihedral_charmm.txt
+++ b/doc/src/dihedral_charmm.txt
@@ -1,167 +1,167 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
dihedral_style charmm command :h3
dihedral_style charmm/intel command :h3
dihedral_style charmm/kk command :h3
dihedral_style charmm/omp command :h3
dihedral_style charmmfsw command :h3
[Syntax:]
dihedral_style style :pre
style = {charmm} or {charmmfsw} :ul
[Examples:]
dihedral_style charmm
dihedral_style charmmfsw
dihedral_coeff 1 0.2 1 180 1.0
dihedral_coeff 2 1.8 1 0 1.0
dihedral_coeff 1 3.1 2 180 0.5 :pre
[Description:]
The {charmm} and {charmmfsw} dihedral styles use the potential
:c,image(Eqs/dihedral_charmm.jpg)
See "(MacKerell)"_#dihedral-MacKerell for a description of the CHARMM
force field. This dihedral style can also be used for the AMBER force
field (see comment on weighting factors below). See
"(Cornell)"_#dihedral-Cornell for a description of the AMBER force
field.
NOTE: The newer {charmmfsw} style was released in March 2017. We
recommend it be used instead of the older {charmm} style when running
a simulation with the CHARMM force field, either with long-range
Coulombics or a Coulomb cutoff, via the "pair_style
lj/charmmfsw/coul/long"_pair_charmm.html and "pair_style
lj/charmmfsw/coul/charmmfsh"_pair_charmm.html commands respectively.
Otherwise the older {charmm} style is fine to use. See the discussion
below and more details on the "pair_style charmm"_pair_charmm.html doc
page.
The following coefficients must be defined for each dihedral type via the
"dihedral_coeff"_dihedral_coeff.html command as in the example above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands:
K (energy)
n (integer >= 0)
d (integer value of degrees)
weighting factor (1.0, 0.5, or 0.0) :ul
The weighting factor is required to correct for double counting
pairwise non-bonded Lennard-Jones interactions in cyclic systems or
when using the CHARMM dihedral style with non-CHARMM force fields.
With the CHARMM dihedral style, interactions between the 1st and 4th
atoms in a dihedral are skipped during the normal non-bonded force
computation and instead evaluated as part of the dihedral using
special epsilon and sigma values specified with the
"pair_coeff"_pair_charmm.html command of pair styles that contain
"lj/charmm" (e.g. "pair_style lj/charmm/coul/long"_pair_charmm.html)
In 6-membered rings, the same 1-4 interaction would be computed twice
(once for the clockwise 1-4 pair in dihedral 1-2-3-4 and once in the
counterclockwise dihedral 1-6-5-4) and thus the weighting factor has
to be 0.5 in this case. In 4-membered or 5-membered rings, the 1-4
dihedral also is counted as a 1-2 or 1-3 interaction when going around
the ring in the opposite direction and thus the weighting factor is
0.0, as the 1-2 and 1-3 exclusions take precedence.
Note that this dihedral weighting factor is unrelated to the scaling
factor specified by the "special bonds"_special_bonds.html command
which applies to all 1-4 interactions in the system. For CHARMM force
fields, the special_bonds 1-4 interaction scaling factor should be set
to 0.0. Since the corresponding 1-4 non-bonded interactions are
computed with the dihedral. This means that if any of the weighting
factors defined as dihedral coefficients (4th coeff above) are
non-zero, then you must use a pair style with "lj/charmm" and set the
special_bonds 1-4 scaling factor to 0.0 (which is the
default). Otherwise 1-4 non-bonded interactions in dihedrals will be
computed twice.
For simulations using the CHARMM force field with a Coulomb cutoff,
the difference between the {charmm} and {charmmfsw} styles is in the
computation of the 1-4 non-bond interactions, though only if the
distance between the two atoms is within the switching region of the
pairwise potential defined by the corresponding CHARMM pair style,
i.e. within the outer cutoff specified for the pair style. The
{charmmfsw} style should only be used when using the corresponding
"pair_style lj/charmmfsw/coul/charmmfsw"_pair_charmm.html or
"pair_style lj/charmmfsw/coul/long"_pair_charmm.html commands. Use
the {charmm} style with the older "pair_style"_pair_charmm.html
commands that have just "charmm" in their style name. See the
discussion on the "CHARMM pair_style"_pair_charmm.html doc page for
details.
Note that for AMBER force fields, which use pair styles with "lj/cut",
the special_bonds 1-4 scaling factor should be set to the AMBER
defaults (1/2 and 5/6) and all the dihedral weighting factors (4th
coeff above) must be set to 0.0. In this case, you can use any pair
style you wish, since the dihedral does not need any Lennard-Jones
parameter information and will not compute any 1-4 non-bonded
interactions. Likewise the {charmm} or {charmmfsw} styles are
identical in this case since no 1-4 non-bonded interactions are
computed.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
When using run_style "respa"_run_style.html, these dihedral styles
must be assigned to the same r-RESPA level as {pair} or {outer}.
When used in combination with CHARMM pair styles, the 1-4
"special_bonds"_special_bonds.html scaling factors must be set to 0.0.
Otherwise non-bonded contributions for these 1-4 pairs will be
computed multiple times.
These dihedral styles can only be used if LAMMPS was built with the
MOLECULE package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info on packages.
[Related commands:]
"dihedral_coeff"_dihedral_coeff.html
[Default:] none
:line
:link(dihedral-Cornell)
[(Cornell)] Cornell, Cieplak, Bayly, Gould, Merz, Ferguson,
Spellmeyer, Fox, Caldwell, Kollman, JACS 117, 5179-5197 (1995).
:link(dihedral-MacKerell)
[(MacKerell)] MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field,
Fischer, Gao, Guo, Ha, et al, J Phys Chem B, 102, 3586 (1998).
diff --git a/doc/src/dihedral_class2.txt b/doc/src/dihedral_class2.txt
index 91ab6f373..cb9fc72c2 100644
--- a/doc/src/dihedral_class2.txt
+++ b/doc/src/dihedral_class2.txt
@@ -1,179 +1,179 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
dihedral_style class2 command :h3
dihedral_style class2/omp command :h3
dihedral_style class2/kk command :h3
[Syntax:]
dihedral_style class2 :pre
[Examples:]
dihedral_style class2
dihedral_coeff 1 100 75 100 70 80 60
dihedral_coeff * mbt 3.5945 0.1704 -0.5490 1.5228
dihedral_coeff * ebt 0.3417 0.3264 -0.9036 0.1368 0.0 -0.8080 1.0119 1.1010
dihedral_coeff 2 at 0.0 -0.1850 -0.7963 -2.0220 0.0 -0.3991 110.2453 105.1270
dihedral_coeff * aat -13.5271 110.2453 105.1270
dihedral_coeff * bb13 0.0 1.0119 1.1010 :pre
[Description:]
The {class2} dihedral style uses the potential
:c,image(Eqs/dihedral_class2.jpg)
where Ed is the dihedral term, Embt is a middle-bond-torsion term,
Eebt is an end-bond-torsion term, Eat is an angle-torsion term, Eaat
is an angle-angle-torsion term, and Ebb13 is a bond-bond-13 term.
Theta1 and theta2 are equilibrium angles and r1 r2 r3 are equilibrium
bond lengths.
See "(Sun)"_#dihedral-Sun for a description of the COMPASS class2 force field.
Coefficients for the Ed, Embt, Eebt, Eat, Eaat, and Ebb13 formulas
must be defined for each dihedral type via the
"dihedral_coeff"_dihedral_coeff.html command as in the example above,
or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands.
These are the 6 coefficients for the Ed formula:
K1 (energy)
phi1 (degrees)
K2 (energy)
phi2 (degrees)
K3 (energy)
phi3 (degrees) :ul
For the Embt formula, each line in a
"dihedral_coeff"_dihedral_coeff.html command in the input script lists
5 coefficients, the first of which is "mbt" to indicate they are
MiddleBondTorsion coefficients. In a data file, these coefficients
should be listed under a "MiddleBondTorsion Coeffs" heading and you
must leave out the "mbt", i.e. only list 4 coefficients after the
dihedral type.
mbt
A1 (energy/distance)
A2 (energy/distance)
A3 (energy/distance)
r2 (distance) :ul
For the Eebt formula, each line in a
"dihedral_coeff"_dihedral_coeff.html command in the input script lists
9 coefficients, the first of which is "ebt" to indicate they are
EndBondTorsion coefficients. In a data file, these coefficients
should be listed under a "EndBondTorsion Coeffs" heading and you must
leave out the "ebt", i.e. only list 8 coefficients after the dihedral
type.
ebt
B1 (energy/distance)
B2 (energy/distance)
B3 (energy/distance)
C1 (energy/distance)
C2 (energy/distance)
C3 (energy/distance)
r1 (distance)
r3 (distance) :ul
For the Eat formula, each line in a
"dihedral_coeff"_dihedral_coeff.html command in the input script lists
9 coefficients, the first of which is "at" to indicate they are
AngleTorsion coefficients. In a data file, these coefficients should
be listed under a "AngleTorsion Coeffs" heading and you must leave out
the "at", i.e. only list 8 coefficients after the dihedral type.
at
D1 (energy/radian)
D2 (energy/radian)
D3 (energy/radian)
E1 (energy/radian)
E2 (energy/radian)
E3 (energy/radian)
theta1 (degrees)
theta2 (degrees) :ul
Theta1 and theta2 are specified in degrees, but LAMMPS converts them
to radians internally; hence the units of D and E are in
energy/radian.
For the Eaat formula, each line in a
"dihedral_coeff"_dihedral_coeff.html command in the input script lists
4 coefficients, the first of which is "aat" to indicate they are
AngleAngleTorsion coefficients. In a data file, these coefficients
should be listed under a "AngleAngleTorsion Coeffs" heading and you
must leave out the "aat", i.e. only list 3 coefficients after the
dihedral type.
aat
M (energy/radian^2)
theta1 (degrees)
theta2 (degrees) :ul
Theta1 and theta2 are specified in degrees, but LAMMPS converts them
to radians internally; hence the units of M are in energy/radian^2.
For the Ebb13 formula, each line in a
"dihedral_coeff"_dihedral_coeff.html command in the input script lists
4 coefficients, the first of which is "bb13" to indicate they are
BondBond13 coefficients. In a data file, these coefficients should be
listed under a "BondBond13 Coeffs" heading and you must leave out the
"bb13", i.e. only list 3 coefficients after the dihedral type.
bb13
N (energy/distance^2)
r1 (distance)
r3 (distance) :ul
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This dihedral style can only be used if LAMMPS was built with the
CLASS2 package. See the "Making LAMMPS"_Section_start.html#start_3
section for more info on packages.
[Related commands:]
"dihedral_coeff"_dihedral_coeff.html
[Default:] none
:line
:link(dihedral-Sun)
[(Sun)] Sun, J Phys Chem B 102, 7338-7364 (1998).
diff --git a/doc/src/dihedral_cosine_shift_exp.txt b/doc/src/dihedral_cosine_shift_exp.txt
index 89614a3fd..715682aff 100644
--- a/doc/src/dihedral_cosine_shift_exp.txt
+++ b/doc/src/dihedral_cosine_shift_exp.txt
@@ -1,86 +1,86 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
dihedral_style cosine/shift/exp command :h3
dihedral_style cosine/shift/exp/omp command :h3
[Syntax:]
dihedral_style cosine/shift/exp :pre
[Examples:]
dihedral_style cosine/shift/exp
dihedral_coeff 1 10.0 45.0 2.0 :pre
[Description:]
The {cosine/shift/exp} dihedral style uses the potential
:c,image(Eqs/dihedral_cosine_shift_exp.jpg)
where Umin, theta, and a are defined for each dihedral type.
The potential is bounded between \[-Umin:0\] and the minimum is located
at the angle theta0. The a parameter can be both positive or negative
and is used to control the spring constant at the equilibrium.
The spring constant is given by k=a exp(a) Umin/ \[2 (Exp(a)-1)\].
For a>3 k/Umin = a/2 to better than 5% relative error. For negative
values of the a parameter, the spring constant is essentially zero,
and anharmonic terms takes over. The potential is furthermore well
behaved in the limit a->0, where it has been implemented to linear
order in a for a < 0.001.
The following coefficients must be defined for each dihedral type via
the "dihedral_coeff"_dihedral_coeff.html command as in the example
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands:
umin (energy)
theta (angle)
A (real number) :ul
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This dihedral style can only be used if LAMMPS was built with the
USER-MISC package. See the "Making LAMMPS"_Section_start.html#start_3
section for more info on packages.
[Related commands:]
"dihedral_coeff"_dihedral_coeff.html,
"angle_cosine_shift_exp"_angle_cosine_shift_exp.html
[Default:] none
diff --git a/doc/src/dihedral_fourier.txt b/doc/src/dihedral_fourier.txt
index 5682309b8..da892b59d 100644
--- a/doc/src/dihedral_fourier.txt
+++ b/doc/src/dihedral_fourier.txt
@@ -1,77 +1,77 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
dihedral_style fourier command :h3
dihedral_style fourier/omp command :h3
[Syntax:]
dihedral_style fourier :pre
[Examples:]
dihedral_style fourier
dihedral_coeff 1 3 -0.846200 3 0.0 7.578800 1 0 0.138000 2 -180.0 :pre
[Description:]
The {fourier} dihedral style uses the potential:
:c,image(Eqs/dihedral_fourier.jpg)
The following coefficients must be defined for each dihedral type via the
"dihedral_coeff"_dihedral_coeff.html command as in the example above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands:
m (integer >=1)
K1 (energy)
n1 (integer >= 0)
d1 (degrees)
\[...\]
Km (energy)
nm (integer >= 0)
dm (degrees) :ul
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
USER_MISC package. See the "Making LAMMPS"_Section_start.html#start_3
section for more info on packages.
[Related commands:]
"dihedral_coeff"_dihedral_coeff.html
[Default:] none
diff --git a/doc/src/dihedral_harmonic.txt b/doc/src/dihedral_harmonic.txt
index c763dcce2..d9a48ff38 100644
--- a/doc/src/dihedral_harmonic.txt
+++ b/doc/src/dihedral_harmonic.txt
@@ -1,86 +1,86 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
dihedral_style harmonic command :h3
dihedral_style harmonic/intel command :h3
dihedral_style harmonic/omp command :h3
[Syntax:]
dihedral_style harmonic :pre
[Examples:]
dihedral_style harmonic
dihedral_coeff 1 80.0 1 2 :pre
[Description:]
The {harmonic} dihedral style uses the potential
:c,image(Eqs/dihedral_harmonic.jpg)
The following coefficients must be defined for each dihedral type via the
"dihedral_coeff"_dihedral_coeff.html command as in the example above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands:
K (energy)
d (+1 or -1)
n (integer >= 0) :ul
NOTE: Here are important points to take note of when defining LAMMPS
dihedral coefficients for the harmonic style, so that they are
compatible with how harmonic dihedrals are defined by other force
fields:
The LAMMPS convention is that the trans position = 180 degrees, while
in some force fields trans = 0 degrees. :ulb,l
Some force fields reverse the sign convention on {d}. :l
Some force fields let {n} be positive or negative which corresponds to
{d} = 1 or -1 for the harmonic style. :l
:ule
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This dihedral style can only be used if LAMMPS was built with the
MOLECULE package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info on packages.
[Related commands:]
"dihedral_coeff"_dihedral_coeff.html
[Default:] none
diff --git a/doc/src/dihedral_helix.txt b/doc/src/dihedral_helix.txt
index fced983db..1e907557b 100644
--- a/doc/src/dihedral_helix.txt
+++ b/doc/src/dihedral_helix.txt
@@ -1,84 +1,84 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
dihedral_style helix command :h3
dihedral_style helix/omp command :h3
[Syntax:]
dihedral_style helix :pre
[Examples:]
dihedral_style helix
dihedral_coeff 1 80.0 100.0 40.0 :pre
[Description:]
The {helix} dihedral style uses the potential
:c,image(Eqs/dihedral_helix.jpg)
This coarse-grain dihedral potential is described in "(Guo)"_#Guo.
For dihedral angles in the helical region, the energy function is
represented by a standard potential consisting of three minima, one
corresponding to the trans (t) state and the other to gauche states
(g+ and g-). The paper describes how the A,B,C parameters are chosen
so as to balance secondary (largely driven by local interactions) and
tertiary structure (driven by long-range interactions).
The following coefficients must be defined for each dihedral type via the
"dihedral_coeff"_dihedral_coeff.html command as in the example above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands:
A (energy)
B (energy)
C (energy) :ul
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This dihedral style can only be used if LAMMPS was built with the
MOLECULE package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info on packages.
[Related commands:]
"dihedral_coeff"_dihedral_coeff.html
[Default:] none
:line
:link(Guo)
[(Guo)] Guo and Thirumalai, Journal of Molecular Biology, 263, 323-43 (1996).
diff --git a/doc/src/dihedral_multi_harmonic.txt b/doc/src/dihedral_multi_harmonic.txt
index 5774a6768..7d3c2ea08 100644
--- a/doc/src/dihedral_multi_harmonic.txt
+++ b/doc/src/dihedral_multi_harmonic.txt
@@ -1,73 +1,73 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
dihedral_style multi/harmonic command :h3
dihedral_style multi/harmonic/omp command :h3
[Syntax:]
dihedral_style multi/harmonic :pre
[Examples:]
dihedral_style multi/harmonic
dihedral_coeff 1 20 20 20 20 20 :pre
[Description:]
The {multi/harmonic} dihedral style uses the potential
:c,image(Eqs/dihedral_multi_harmonic.jpg)
The following coefficients must be defined for each dihedral type via the
"dihedral_coeff"_dihedral_coeff.html command as in the example above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands:
A1 (energy)
A2 (energy)
A3 (energy)
A4 (energy)
A5 (energy) :ul
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This dihedral style can only be used if LAMMPS was built with the
MOLECULE package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info on packages.
[Related commands:]
"dihedral_coeff"_dihedral_coeff.html
[Default:] none
diff --git a/doc/src/dihedral_nharmonic.txt b/doc/src/dihedral_nharmonic.txt
index 0df28a05d..8392d8389 100644
--- a/doc/src/dihedral_nharmonic.txt
+++ b/doc/src/dihedral_nharmonic.txt
@@ -1,73 +1,73 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
dihedral_style nharmonic command :h3
dihedral_style nharmonic/omp command :h3
[Syntax:]
dihedral_style nharmonic :pre
[Examples:]
dihedral_style nharmonic
dihedral_coeff 3 10.0 20.0 30.0 :pre
[Description:]
The {nharmonic} dihedral style uses the potential:
:c,image(Eqs/dihedral_nharmonic.jpg)
The following coefficients must be defined for each dihedral type via the
"dihedral_coeff"_dihedral_coeff.html command as in the example above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands:
n (integer >=1)
A1 (energy)
A2 (energy)
...
An (energy) :ul
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
USER_MISC package. See the "Making LAMMPS"_Section_start.html#start_3
section for more info on packages.
[Related commands:]
"dihedral_coeff"_dihedral_coeff.html
[Default:] none
diff --git a/doc/src/dihedral_opls.txt b/doc/src/dihedral_opls.txt
index afcc5d351..d1a6ba3ff 100644
--- a/doc/src/dihedral_opls.txt
+++ b/doc/src/dihedral_opls.txt
@@ -1,86 +1,86 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
dihedral_style opls command :h3
dihedral_style opls/intel command :h3
dihedral_style opls/kk command :h3
dihedral_style opls/omp command :h3
[Syntax:]
dihedral_style opls :pre
[Examples:]
dihedral_style opls
dihedral_coeff 1 1.740 -0.157 0.279 0.00 # CT-CT-CT-CT
dihedral_coeff 2 0.000 0.000 0.366 0.000 # CT-CT-CT-HC
dihedral_coeff 3 0.000 0.000 0.318 0.000 # HC-CT-CT-HC :pre
[Description:]
The {opls} dihedral style uses the potential
:c,image(Eqs/dihedral_opls.jpg)
Note that the usual 1/2 factor is not included in the K values.
This dihedral potential is used in the OPLS force field and is
described in "(Watkins)"_#Watkins.
The following coefficients must be defined for each dihedral type via the
"dihedral_coeff"_dihedral_coeff.html command as in the example above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands:
K1 (energy)
K2 (energy)
K3 (energy)
K4 (energy) :ul
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This dihedral style can only be used if LAMMPS was built with the
MOLECULE package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info on packages.
[Related commands:]
"dihedral_coeff"_dihedral_coeff.html
[Default:] none
:line
:link(Watkins)
[(Watkins)] Watkins and Jorgensen, J Phys Chem A, 105, 4118-4125 (2001).
diff --git a/doc/src/dihedral_quadratic.txt b/doc/src/dihedral_quadratic.txt
index 526b469f6..ca2f5aed4 100644
--- a/doc/src/dihedral_quadratic.txt
+++ b/doc/src/dihedral_quadratic.txt
@@ -1,75 +1,75 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
dihedral_style quadratic command :h3
dihedral_style quadratic/omp command :h3
[Syntax:]
dihedral_style quadratic :pre
[Examples:]
dihedral_style quadratic
dihedral_coeff 100.0 80.0 :pre
[Description:]
The {quadratic} dihedral style uses the potential:
:c,image(Eqs/dihedral_quadratic.jpg)
This dihedral potential can be used to keep a dihedral in a predefined
value (cis=zero, right-hand convention is used).
The following coefficients must be defined for each dihedral type via
the "dihedral_coeff"_dihedral_coeff.html command as in the example
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands:
K (energy/radian^2)
phi0 (degrees) :ul
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
USER_MISC package. See the "Making LAMMPS"_Section_start.html#start_3
section for more info on packages.
[Related commands:]
"dihedral_coeff"_dihedral_coeff.html
[Default:] none
diff --git a/doc/src/echo.txt b/doc/src/echo.txt
index 8ef8ad05f..3141c7a71 100644
--- a/doc/src/echo.txt
+++ b/doc/src/echo.txt
@@ -1,38 +1,38 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
echo command :h3
[Syntax:]
echo style :pre
style = {none} or {screen} or {log} or {both} :ul
[Examples:]
echo both
echo log :pre
[Description:]
This command determines whether LAMMPS echoes each input script
command to the screen and/or log file as it is read and processed. If
an input script has errors, it can be useful to look at echoed output
to see the last command processed.
-The "command-line switch"_Section_start.html#start_5 -echo can be used
+The "command-line switch"_Section_start.html#start_6 -echo can be used
in place of this command.
[Restrictions:] none
[Related commands:] none
[Default:]
echo log :pre
diff --git a/doc/src/fix_addforce.txt b/doc/src/fix_addforce.txt
index da9f98a6d..1cc0a1533 100644
--- a/doc/src/fix_addforce.txt
+++ b/doc/src/fix_addforce.txt
@@ -1,176 +1,176 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix addforce command :h3
[Syntax:]
fix ID group-ID addforce fx fy fz keyword value ... :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
addforce = style name of this fix command :l
fx,fy,fz = force component values (force units) :l
any of fx,fy,fz can be a variable (see below) :pre
zero or more keyword/value pairs may be appended to args :l
keyword = {every} or {region} or {energy} :l
{every} value = Nevery
Nevery = add force every this many timesteps
{region} value = region-ID
region-ID = ID of region atoms must be in to have added force
{energy} value = v_name
v_name = variable with name that calculates the potential energy of each atom in the added force field :pre
:ule
[Examples:]
fix kick flow addforce 1.0 0.0 0.0
fix kick flow addforce 1.0 0.0 v_oscillate
fix ff boundary addforce 0.0 0.0 v_push energy v_espace :pre
[Description:]
Add fx,fy,fz to the corresponding component of force for each atom in
the group. This command can be used to give an additional push to
atoms in a simulation, such as for a simulation of Poiseuille flow in
a channel.
Any of the 3 quantities defining the force components can be specified
as an equal-style or atom-style "variable"_variable.html, namely {fx},
{fy}, {fz}. If the value is a variable, it should be specified as
v_name, where name is the variable name. In this case, the variable
will be evaluated each timestep, and its value(s) used to determine
the force component.
Equal-style variables can specify formulas with various mathematical
functions, and include "thermo_style"_thermo_style.html command
keywords for the simulation box parameters and timestep and elapsed
time. Thus it is easy to specify a time-dependent force field.
Atom-style variables can specify the same formulas as equal-style
variables but can also include per-atom values, such as atom
coordinates. Thus it is easy to specify a spatially-dependent force
field with optional time-dependence as well.
If the {every} keyword is used, the {Nevery} setting determines how
often the forces are applied. The default value is 1, for every
timestep.
If the {region} keyword is used, the atom must also be in the
specified geometric "region"_region.html in order to have force added
to it.
:line
Adding a force to atoms implies a change in their potential energy as
they move due to the applied force field. For dynamics via the "run"
command, this energy can be optionally added to the system's potential
energy for thermodynamic output (see below). For energy minimization
via the "minimize" command, this energy must be added to the system's
potential energy to formulate a self-consistent minimization problem
(see below).
The {energy} keyword is not allowed if the added force is a constant
vector F = (fx,fy,fz), with all components defined as numeric
constants and not as variables. This is because LAMMPS can compute
the energy for each atom directly as E = -x dot F = -(x*fx + y*fy +
z*fz), so that -Grad(E) = F.
The {energy} keyword is optional if the added force is defined with
one or more variables, and if you are performing dynamics via the
"run"_run.html command. If the keyword is not used, LAMMPS will set
the energy to 0.0, which is typically fine for dynamics.
The {energy} keyword is required if the added force is defined with
one or more variables, and you are performing energy minimization via
the "minimize" command. The keyword specifies the name of an
atom-style "variable"_variable.html which is used to compute the
energy of each atom as function of its position. Like variables used
for {fx}, {fy}, {fz}, the energy variable is specified as v_name,
where name is the variable name.
Note that when the {energy} keyword is used during an energy
minimization, you must insure that the formula defined for the
atom-style "variable"_variable.html is consistent with the force
variable formulas, i.e. that -Grad(E) = F. For example, if the force
were a spring-like F = kx, then the energy formula should be E =
-0.5kx^2. If you don't do this correctly, the minimization will not
converge properly.
:line
Styles with a suffix are functionally the same as the corresponding
style without the suffix. They have been optimized to run faster,
depending on your available hardware, as discussed in
"Section 5"_Section_accelerate.html of the manual. The
accelerated styles take the same arguments and should produce the same
results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html.
The "fix_modify"_fix_modify.html {energy} option is supported by this
fix to add the potential "energy" inferred by the added force to the
system's potential energy as part of "thermodynamic
output"_thermo_style.html. This is a fictitious quantity but is
needed so that the "minimize"_minimize.html command can include the
forces added by this fix in a consistent manner. I.e. there is a
decrease in potential energy when atoms move in the direction of the
added force.
The "fix_modify"_fix_modify.html {respa} option is supported by this
fix. This allows to set at which level of the "r-RESPA"_run_style.html
integrator the fix is adding its forces. Default is the outermost
level.
This fix computes a global scalar and a global 3-vector of forces,
which can be accessed by various "output
commands"_Section_howto.html#howto_15. The scalar is the potential
energy discussed above. The vector is the total force on the group of
atoms before the forces on individual atoms are changed by the fix.
The scalar and vector values calculated by this fix are "extensive".
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command.
The forces due to this fix are imposed during an energy minimization,
invoked by the "minimize"_minimize.html command. You should not
specify force components with a variable that has time-dependence for
use with a minimizer, since the minimizer increments the timestep as
the iteration count during the minimization.
NOTE: If you want the fictitious potential energy associated with the
added forces to be included in the total potential energy of the
system (the quantity being minimized), you MUST enable the
"fix_modify"_fix_modify.html {energy} option for this fix.
[Restrictions:] none
[Related commands:]
"fix setforce"_fix_setforce.html, "fix aveforce"_fix_aveforce.html
[Default:]
The option default for the every keyword is every = 1.
diff --git a/doc/src/fix_aveforce.txt b/doc/src/fix_aveforce.txt
index d980e9a21..5d7dec3e6 100644
--- a/doc/src/fix_aveforce.txt
+++ b/doc/src/fix_aveforce.txt
@@ -1,118 +1,118 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix aveforce command :h3
[Syntax:]
fix ID group-ID aveforce fx fy fz keyword value ... :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
aveforce = style name of this fix command :l
fx,fy,fz = force component values (force units) :l
any of fx,fy,fz can be a variable (see below) :pre
zero or more keyword/value pairs may be appended to args :l
keyword = {region} :l
{region} value = region-ID
region-ID = ID of region atoms must be in to have added force :pre
:ule
[Examples:]
fix pressdown topwall aveforce 0.0 -1.0 0.0
fix 2 bottomwall aveforce NULL -1.0 0.0 region top
fix 2 bottomwall aveforce NULL -1.0 v_oscillate region top :pre
[Description:]
Apply an additional external force to a group of atoms in such a way
that every atom experiences the same force. This is useful for
pushing on wall or boundary atoms so that the structure of the wall
does not change over time.
The existing force is averaged for the group of atoms, component by
component. The actual force on each atom is then set to the average
value plus the component specified in this command. This means each
atom in the group receives the same force.
Any of the fx,fy,fz values can be specified as NULL which means the
force in that dimension is not changed. Note that this is not the
same as specifying a 0.0 value, since that sets all forces to the same
average value without adding in any additional force.
Any of the 3 quantities defining the force components can be specified
as an equal-style "variable"_variable.html, namely {fx}, {fy}, {fz}.
If the value is a variable, it should be specified as v_name, where
name is the variable name. In this case, the variable will be
evaluated each timestep, and its value used to determine the average
force.
Equal-style variables can specify formulas with various mathematical
functions, and include "thermo_style"_thermo_style.html command
keywords for the simulation box parameters and timestep and elapsed
time. Thus it is easy to specify a time-dependent average force.
If the {region} keyword is used, the atom must also be in the
specified geometric "region"_region.html in order to have force added
to it.
:line
Styles with a suffix are functionally the same as the corresponding
style without the suffix. They have been optimized to run faster,
depending on your available hardware, as discussed in
"Section 5"_Section_accelerate.html of the manual. The
accelerated styles take the same arguments and should produce the same
results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html.
The "fix_modify"_fix_modify.html {respa} option is supported by this
fix. This allows to set at which level of the "r-RESPA"_run_style.html
integrator the fix is adding its forces. Default is the outermost level.
This fix computes a global 3-vector of forces, which can be accessed
by various "output commands"_Section_howto.html#howto_15. This is the
total force on the group of atoms before the forces on individual
atoms are changed by the fix. The vector values calculated by this
fix are "extensive".
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command.
The forces due to this fix are imposed during an energy minimization,
invoked by the "minimize"_minimize.html command. You should not
specify force components with a variable that has time-dependence for
use with a minimizer, since the minimizer increments the timestep as
the iteration count during the minimization.
[Restrictions:] none
[Related commands:]
"fix setforce"_fix_setforce.html, "fix addforce"_fix_addforce.html
[Default:] none
diff --git a/doc/src/fix_deform.txt b/doc/src/fix_deform.txt
index d3254eece..63d872ede 100644
--- a/doc/src/fix_deform.txt
+++ b/doc/src/fix_deform.txt
@@ -1,596 +1,596 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix deform command :h3
fix deform/kk command :h3
[Syntax:]
fix ID group-ID deform N parameter args ... keyword value ... :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
deform = style name of this fix command :l
N = perform box deformation every this many timesteps :l
one or more parameter/arg pairs may be appended :l
parameter = {x} or {y} or {z} or {xy} or {xz} or {yz}
{x}, {y}, {z} args = style value(s)
style = {final} or {delta} or {scale} or {vel} or {erate} or {trate} or {volume} or {wiggle} or {variable}
{final} values = lo hi
lo hi = box boundaries at end of run (distance units)
{delta} values = dlo dhi
dlo dhi = change in box boundaries at end of run (distance units)
{scale} values = factor
factor = multiplicative factor for change in box length at end of run
{vel} value = V
V = change box length at this velocity (distance/time units),
effectively an engineering strain rate
{erate} value = R
R = engineering strain rate (1/time units)
{trate} value = R
R = true strain rate (1/time units)
{volume} value = none = adjust this dim to preserve volume of system
{wiggle} values = A Tp
A = amplitude of oscillation (distance units)
Tp = period of oscillation (time units)
{variable} values = v_name1 v_name2
v_name1 = variable with name1 for box length change as function of time
v_name2 = variable with name2 for change rate as function of time
{xy}, {xz}, {yz} args = style value
style = {final} or {delta} or {vel} or {erate} or {trate} or {wiggle}
{final} value = tilt
tilt = tilt factor at end of run (distance units)
{delta} value = dtilt
dtilt = change in tilt factor at end of run (distance units)
{vel} value = V
V = change tilt factor at this velocity (distance/time units),
effectively an engineering shear strain rate
{erate} value = R
R = engineering shear strain rate (1/time units)
{trate} value = R
R = true shear strain rate (1/time units)
{wiggle} values = A Tp
A = amplitude of oscillation (distance units)
Tp = period of oscillation (time units)
{variable} values = v_name1 v_name2
v_name1 = variable with name1 for tilt change as function of time
v_name2 = variable with name2 for change rate as function of time :pre
zero or more keyword/value pairs may be appended :l
keyword = {remap} or {flip} or {units} :l
{remap} value = {x} or {v} or {none}
x = remap coords of atoms in group into deforming box
v = remap velocities of all atoms when they cross periodic boundaries
none = no remapping of x or v
{flip} value = {yes} or {no}
allow or disallow box flips when it becomes highly skewed
{units} value = {lattice} or {box}
lattice = distances are defined in lattice units
box = distances are defined in simulation box units :pre
:ule
[Examples:]
fix 1 all deform 1 x final 0.0 9.0 z final 0.0 5.0 units box
fix 1 all deform 1 x trate 0.1 y volume z volume
fix 1 all deform 1 xy erate 0.001 remap v
fix 1 all deform 10 y delta -0.5 0.5 xz vel 1.0 :pre
[Description:]
Change the volume and/or shape of the simulation box during a dynamics
run. Orthogonal simulation boxes have 3 adjustable parameters
(x,y,z). Triclinic (non-orthogonal) simulation boxes have 6
adjustable parameters (x,y,z,xy,xz,yz). Any or all of them can be
adjusted independently and simultaneously by this command. This fix
can be used to perform non-equilibrium MD (NEMD) simulations of a
continuously strained system. See the "fix
nvt/sllod"_fix_nvt_sllod.html and "compute
temp/deform"_compute_temp_deform.html commands for more details.
For the {x}, {y}, {z} parameters, the associated dimension cannot be
shrink-wrapped. For the {xy}, {yz}, {xz} parameters, the associated
2nd dimension cannot be shrink-wrapped. Dimensions not varied by this
command can be periodic or non-periodic. Dimensions corresponding to
unspecified parameters can also be controlled by a "fix
npt"_fix_nh.html or "fix nph"_fix_nh.html command.
The size and shape of the simulation box at the beginning of the
simulation run were either specified by the
"create_box"_create_box.html or "read_data"_read_data.html or
"read_restart"_read_restart.html command used to setup the simulation
initially if it is the first run, or they are the values from the end
of the previous run. The "create_box"_create_box.html, "read
data"_read_data.html, and "read_restart"_read_restart.html commands
specify whether the simulation box is orthogonal or non-orthogonal
(triclinic) and explain the meaning of the xy,xz,yz tilt factors. If
fix deform changes the xy,xz,yz tilt factors, then the simulation box
must be triclinic, even if its initial tilt factors are 0.0.
As described below, the desired simulation box size and shape at the
end of the run are determined by the parameters of the fix deform
command. Every Nth timestep during the run, the simulation box is
expanded, contracted, or tilted to ramped values between the initial
and final values.
:line
For the {x}, {y}, and {z} parameters, this is the meaning of their
styles and values.
The {final}, {delta}, {scale}, {vel}, and {erate} styles all change
the specified dimension of the box via "constant displacement" which
is effectively a "constant engineering strain rate". This means the
box dimension changes linearly with time from its initial to final
value.
For style {final}, the final lo and hi box boundaries of a dimension
are specified. The values can be in lattice or box distance units.
See the discussion of the units keyword below.
For style {delta}, plus or minus changes in the lo/hi box boundaries
of a dimension are specified. The values can be in lattice or box
distance units. See the discussion of the units keyword below.
For style {scale}, a multiplicative factor to apply to the box length
of a dimension is specified. For example, if the initial box length
is 10, and the factor is 1.1, then the final box length will be 11. A
factor less than 1.0 means compression.
For style {vel}, a velocity at which the box length changes is
specified in units of distance/time. This is effectively a "constant
engineering strain rate", where rate = V/L0 and L0 is the initial box
length. The distance can be in lattice or box distance units. See
the discussion of the units keyword below. For example, if the
initial box length is 100 Angstroms, and V is 10 Angstroms/psec, then
after 10 psec, the box length will have doubled. After 20 psec, it
will have tripled.
The {erate} style changes a dimension of the box at a "constant
engineering strain rate". The units of the specified strain rate are
1/time. See the "units"_units.html command for the time units
associated with different choices of simulation units,
e.g. picoseconds for "metal" units). Tensile strain is unitless and
is defined as delta/L0, where L0 is the original box length and delta
is the change relative to the original length. The box length L as a
function of time will change as
L(t) = L0 (1 + erate*dt) :pre
where dt is the elapsed time (in time units). Thus if {erate} R is
specified as 0.1 and time units are picoseconds, this means the box
length will increase by 10% of its original length every picosecond.
I.e. strain after 1 psec = 0.1, strain after 2 psec = 0.2, etc. R =
-0.01 means the box length will shrink by 1% of its original length
every picosecond. Note that for an "engineering" rate the change is
based on the original box length, so running with R = 1 for 10
picoseconds expands the box length by a factor of 11 (strain of 10),
which is different that what the {trate} style would induce.
The {trate} style changes a dimension of the box at a "constant true
strain rate". Note that this is not an "engineering strain rate", as
the other styles are. Rather, for a "true" rate, the rate of change
is constant, which means the box dimension changes non-linearly with
time from its initial to final value. The units of the specified
strain rate are 1/time. See the "units"_units.html command for the
time units associated with different choices of simulation units,
e.g. picoseconds for "metal" units). Tensile strain is unitless and
is defined as delta/L0, where L0 is the original box length and delta
is the change relative to the original length.
The box length L as a function of time will change as
L(t) = L0 exp(trate*dt) :pre
where dt is the elapsed time (in time units). Thus if {trate} R is
specified as ln(1.1) and time units are picoseconds, this means the
box length will increase by 10% of its current (not original) length
every picosecond. I.e. strain after 1 psec = 0.1, strain after 2 psec
= 0.21, etc. R = ln(2) or ln(3) means the box length will double or
triple every picosecond. R = ln(0.99) means the box length will
shrink by 1% of its current length every picosecond. Note that for a
"true" rate the change is continuous and based on the current length,
so running with R = ln(2) for 10 picoseconds does not expand the box
length by a factor of 11 as it would with {erate}, but by a factor of
1024 since the box length will double every picosecond.
Note that to change the volume (or cross-sectional area) of the
simulation box at a constant rate, you can change multiple dimensions
via {erate} or {trate}. E.g. to double the box volume in a picosecond
picosecond, you could set "x erate M", "y erate M", "z erate M", with
M = pow(2,1/3) - 1 = 0.26, since if each box dimension grows by 26%,
the box volume doubles. Or you could set "x trate M", "y trate M", "z
trate M", with M = ln(1.26) = 0.231, and the box volume would double
every picosecond.
The {volume} style changes the specified dimension in such a way that
the box volume remains constant while other box dimensions are changed
explicitly via the styles discussed above. For example, "x scale 1.1
y scale 1.1 z volume" will shrink the z box length as the x,y box
lengths increase, to keep the volume constant (product of x,y,z
lengths). If "x scale 1.1 z volume" is specified and parameter {y} is
unspecified, then the z box length will shrink as x increases to keep
the product of x,z lengths constant. If "x scale 1.1 y volume z
volume" is specified, then both the y,z box lengths will shrink as x
increases to keep the volume constant (product of x,y,z lengths). In
this case, the y,z box lengths shrink so as to keep their relative
aspect ratio constant.
For solids or liquids, note that when one dimension of the box is
expanded via fix deform (i.e. tensile strain), it may be physically
undesirable to hold the other 2 box lengths constant (unspecified by
fix deform) since that implies a density change. Using the {volume}
style for those 2 dimensions to keep the box volume constant may make
more physical sense, but may also not be correct for materials and
potentials whose Poisson ratio is not 0.5. An alternative is to use
"fix npt aniso"_fix_nh.html with zero applied pressure on those 2
dimensions, so that they respond to the tensile strain dynamically.
The {wiggle} style oscillates the specified box length dimension
sinusoidally with the specified amplitude and period. I.e. the box
length L as a function of time is given by
L(t) = L0 + A sin(2*pi t/Tp) :pre
where L0 is its initial length. If the amplitude A is a positive
number the box initially expands, then contracts, etc. If A is
negative then the box initially contracts, then expands, etc. The
amplitude can be in lattice or box distance units. See the discussion
of the units keyword below.
The {variable} style changes the specified box length dimension by
evaluating a variable, which presumably is a function of time. The
variable with {name1} must be an "equal-style variable"_variable.html
and should calculate a change in box length in units of distance.
Note that this distance is in box units, not lattice units; see the
discussion of the {units} keyword below. The formula associated with
variable {name1} can reference the current timestep. Note that it
should return the "change" in box length, not the absolute box length.
This means it should evaluate to 0.0 when invoked on the initial
timestep of the run following the definition of fix deform. It should
evaluate to a value > 0.0 to dilate the box at future times, or a
value < 0.0 to compress the box.
The variable {name2} must also be an "equal-style
variable"_variable.html and should calculate the rate of box length
change, in units of distance/time, i.e. the time-derivative of the
{name1} variable. This quantity is used internally by LAMMPS to reset
atom velocities when they cross periodic boundaries. It is computed
internally for the other styles, but you must provide it when using an
arbitrary variable.
Here is an example of using the {variable} style to perform the same
box deformation as the {wiggle} style formula listed above, where we
assume that the current timestep = 0.
variable A equal 5.0
variable Tp equal 10.0
variable displace equal "v_A * sin(2*PI * step*dt/v_Tp)"
variable rate equal "2*PI*v_A/v_Tp * cos(2*PI * step*dt/v_Tp)"
fix 2 all deform 1 x variable v_displace v_rate remap v :pre
For the {scale}, {vel}, {erate}, {trate}, {volume}, {wiggle}, and
{variable} styles, the box length is expanded or compressed around its
mid point.
:line
For the {xy}, {xz}, and {yz} parameters, this is the meaning of their
styles and values. Note that changing the tilt factors of a triclinic
box does not change its volume.
The {final}, {delta}, {vel}, and {erate} styles all change the shear
strain at a "constant engineering shear strain rate". This means the
tilt factor changes linearly with time from its initial to final
value.
For style {final}, the final tilt factor is specified. The value
can be in lattice or box distance units. See the discussion of the
units keyword below.
For style {delta}, a plus or minus change in the tilt factor is
specified. The value can be in lattice or box distance units. See
the discussion of the units keyword below.
For style {vel}, a velocity at which the tilt factor changes is
specified in units of distance/time. This is effectively an
"engineering shear strain rate", where rate = V/L0 and L0 is the
initial box length perpendicular to the direction of shear. The
distance can be in lattice or box distance units. See the discussion
of the units keyword below. For example, if the initial tilt factor
is 5 Angstroms, and the V is 10 Angstroms/psec, then after 1 psec, the
tilt factor will be 15 Angstroms. After 2 psec, it will be 25
Angstroms.
The {erate} style changes a tilt factor at a "constant engineering
shear strain rate". The units of the specified shear strain rate are
1/time. See the "units"_units.html command for the time units
associated with different choices of simulation units,
e.g. picoseconds for "metal" units). Shear strain is unitless and is
defined as offset/length, where length is the box length perpendicular
to the shear direction (e.g. y box length for xy deformation) and
offset is the displacement distance in the shear direction (e.g. x
direction for xy deformation) from the unstrained orientation.
The tilt factor T as a function of time will change as
T(t) = T0 + L0*erate*dt :pre
where T0 is the initial tilt factor, L0 is the original length of the
box perpendicular to the shear direction (e.g. y box length for xy
deformation), and dt is the elapsed time (in time units). Thus if
{erate} R is specified as 0.1 and time units are picoseconds, this
means the shear strain will increase by 0.1 every picosecond. I.e. if
the xy shear strain was initially 0.0, then strain after 1 psec = 0.1,
strain after 2 psec = 0.2, etc. Thus the tilt factor would be 0.0 at
time 0, 0.1*ybox at 1 psec, 0.2*ybox at 2 psec, etc, where ybox is the
original y box length. R = 1 or 2 means the tilt factor will increase
by 1 or 2 every picosecond. R = -0.01 means a decrease in shear
strain by 0.01 every picosecond.
The {trate} style changes a tilt factor at a "constant true shear
strain rate". Note that this is not an "engineering shear strain
rate", as the other styles are. Rather, for a "true" rate, the rate
of change is constant, which means the tilt factor changes
non-linearly with time from its initial to final value. The units of
the specified shear strain rate are 1/time. See the
"units"_units.html command for the time units associated with
different choices of simulation units, e.g. picoseconds for "metal"
units). Shear strain is unitless and is defined as offset/length,
where length is the box length perpendicular to the shear direction
(e.g. y box length for xy deformation) and offset is the displacement
distance in the shear direction (e.g. x direction for xy deformation)
from the unstrained orientation.
The tilt factor T as a function of time will change as
T(t) = T0 exp(trate*dt) :pre
where T0 is the initial tilt factor and dt is the elapsed time (in
time units). Thus if {trate} R is specified as ln(1.1) and time units
are picoseconds, this means the shear strain or tilt factor will
increase by 10% every picosecond. I.e. if the xy shear strain was
initially 0.1, then strain after 1 psec = 0.11, strain after 2 psec =
0.121, etc. R = ln(2) or ln(3) means the tilt factor will double or
triple every picosecond. R = ln(0.99) means the tilt factor will
shrink by 1% every picosecond. Note that the change is continuous, so
running with R = ln(2) for 10 picoseconds does not change the tilt
factor by a factor of 10, but by a factor of 1024 since it doubles
every picosecond. Note that the initial tilt factor must be non-zero
to use the {trate} option.
Note that shear strain is defined as the tilt factor divided by the
perpendicular box length. The {erate} and {trate} styles control the
tilt factor, but assume the perpendicular box length remains constant.
If this is not the case (e.g. it changes due to another fix deform
parameter), then this effect on the shear strain is ignored.
The {wiggle} style oscillates the specified tilt factor sinusoidally
with the specified amplitude and period. I.e. the tilt factor T as a
function of time is given by
T(t) = T0 + A sin(2*pi t/Tp) :pre
where T0 is its initial value. If the amplitude A is a positive
number the tilt factor initially becomes more positive, then more
negative, etc. If A is negative then the tilt factor initially
becomes more negative, then more positive, etc. The amplitude can be
in lattice or box distance units. See the discussion of the units
keyword below.
The {variable} style changes the specified tilt factor by evaluating a
variable, which presumably is a function of time. The variable with
{name1} must be an "equal-style variable"_variable.html and should
calculate a change in tilt in units of distance. Note that this
distance is in box units, not lattice units; see the discussion of the
{units} keyword below. The formula associated with variable {name1}
can reference the current timestep. Note that it should return the
"change" in tilt factor, not the absolute tilt factor. This means it
should evaluate to 0.0 when invoked on the initial timestep of the run
following the definition of fix deform.
The variable {name2} must also be an "equal-style
variable"_variable.html and should calculate the rate of tilt change,
in units of distance/time, i.e. the time-derivative of the {name1}
variable. This quantity is used internally by LAMMPS to reset atom
velocities when they cross periodic boundaries. It is computed
internally for the other styles, but you must provide it when using an
arbitrary variable.
Here is an example of using the {variable} style to perform the same
box deformation as the {wiggle} style formula listed above, where we
assume that the current timestep = 0.
variable A equal 5.0
variable Tp equal 10.0
variable displace equal "v_A * sin(2*PI * step*dt/v_Tp)"
variable rate equal "2*PI*v_A/v_Tp * cos(2*PI * step*dt/v_Tp)"
fix 2 all deform 1 xy variable v_displace v_rate remap v :pre
:line
All of the tilt styles change the xy, xz, yz tilt factors during a
simulation. In LAMMPS, tilt factors (xy,xz,yz) for triclinic boxes
are normally bounded by half the distance of the parallel box length.
See the discussion of the {flip} keyword below, to allow this bound to
be exceeded, if desired.
For example, if xlo = 2 and xhi = 12, then the x box length is 10 and
the xy tilt factor must be between -5 and 5. Similarly, both xz and
yz must be between -(xhi-xlo)/2 and +(yhi-ylo)/2. Note that this is
not a limitation, since if the maximum tilt factor is 5 (as in this
example), then configurations with tilt = ..., -15, -5, 5, 15, 25,
... are all equivalent.
To obey this constraint and allow for large shear deformations to be
applied via the {xy}, {xz}, or {yz} parameters, the following
algorithm is used. If {prd} is the associated parallel box length (10
in the example above), then if the tilt factor exceeds the accepted
range of -5 to 5 during the simulation, then the box is flipped to the
other limit (an equivalent box) and the simulation continues. Thus
for this example, if the initial xy tilt factor was 0.0 and "xy final
100.0" was specified, then during the simulation the xy tilt factor
would increase from 0.0 to 5.0, the box would be flipped so that the
tilt factor becomes -5.0, the tilt factor would increase from -5.0 to
5.0, the box would be flipped again, etc. The flip occurs 10 times
and the final tilt factor at the end of the simulation would be 0.0.
During each flip event, atoms are remapped into the new box in the
appropriate manner.
The one exception to this rule is if the 1st dimension in the tilt
factor (x for xy) is non-periodic. In that case, the limits on the
tilt factor are not enforced, since flipping the box in that dimension
does not change the atom positions due to non-periodicity. In this
mode, if you tilt the system to extreme angles, the simulation will
simply become inefficient due to the highly skewed simulation box.
:line
Each time the box size or shape is changed, the {remap} keyword
determines whether atom positions are remapped to the new box. If
{remap} is set to {x} (the default), atoms in the fix group are
remapped; otherwise they are not. Note that their velocities are not
changed, just their positions are altered. If {remap} is set to {v},
then any atom in the fix group that crosses a periodic boundary will
have a delta added to its velocity equal to the difference in
velocities between the lo and hi boundaries. Note that this velocity
difference can include tilt components, e.g. a delta in the x velocity
when an atom crosses the y periodic boundary. If {remap} is set to
{none}, then neither of these remappings take place.
Conceptually, setting {remap} to {x} forces the atoms to deform via an
affine transformation that exactly matches the box deformation. This
setting is typically appropriate for solids. Note that though the
atoms are effectively "moving" with the box over time, it is not due
to their having a velocity that tracks the box change, but only due to
the remapping. By contrast, setting {remap} to {v} is typically
appropriate for fluids, where you want the atoms to respond to the
change in box size/shape on their own and acquire a velocity that
matches the box change, so that their motion will naturally track the
box without explicit remapping of their coordinates.
NOTE: When non-equilibrium MD (NEMD) simulations are performed using
this fix, the option "remap v" should normally be used. This is
because "fix nvt/sllod"_fix_nvt_sllod.html adjusts the atom positions
and velocities to induce a velocity profile that matches the changing
box size/shape. Thus atom coordinates should NOT be remapped by fix
deform, but velocities SHOULD be when atoms cross periodic boundaries,
since that is consistent with maintaining the velocity profile already
created by fix nvt/sllod. LAMMPS will warn you if the {remap} setting
is not consistent with fix nvt/sllod.
NOTE: For non-equilibrium MD (NEMD) simulations using "remap v" it is
usually desirable that the fluid (or flowing material, e.g. granular
particles) stream with a velocity profile consistent with the
deforming box. As mentioned above, using a thermostat such as "fix
nvt/sllod"_fix_nvt_sllod.html or "fix lavgevin"_fix_langevin.html
(with a bias provided by "compute
temp/deform"_compute_temp_deform.html), will typically accomplish
that. If you do not use a thermostat, then there is no driving force
pushing the atoms to flow in a manner consistent with the deforming
box. E.g. for a shearing system the box deformation velocity may vary
from 0 at the bottom to 10 at the top of the box. But the stream
velocity profile of the atoms may vary from -5 at the bottom to +5 at
the top. You can monitor these effects using the "fix
ave/chunk"_fix_ave_chunk.html, "compute
temp/deform"_compute_temp_deform.html, and "compute
temp/profile"_compute_temp_profile.html commands. One way to induce
atoms to stream consistent with the box deformation is to give them an
initial velocity profile, via the "velocity ramp"_velocity.html
command, that matches the box deformation rate. This also typically
helps the system come to equilibrium more quickly, even if a
thermostat is used.
NOTE: If a "fix rigid"_fix_rigid.html is defined for rigid bodies, and
{remap} is set to {x}, then the center-of-mass coordinates of rigid
bodies will be remapped to the changing simulation box. This will be
done regardless of whether atoms in the rigid bodies are in the fix
deform group or not. The velocity of the centers of mass are not
remapped even if {remap} is set to {v}, since "fix
nvt/sllod"_fix_nvt_sllod.html does not currently do anything special
for rigid particles. If you wish to perform a NEMD simulation of
rigid particles, you can either thermostat them independently or
include a background fluid and thermostat the fluid via "fix
nvt/sllod"_fix_nvt_sllod.html.
The {flip} keyword allows the tilt factors for a triclinic box to
exceed half the distance of the parallel box length, as discussed
above. If the {flip} value is set to {yes}, the bound is enforced by
flipping the box when it is exceeded. If the {flip} value is set to
{no}, the tilt will continue to change without flipping. Note that if
you apply large deformations, this means the box shape can tilt
dramatically LAMMPS will run less efficiently, due to the large volume
of communication needed to acquire ghost atoms around a processor's
irregular-shaped sub-domain. For extreme values of tilt, LAMMPS may
also lose atoms and generate an error.
The {units} keyword determines the meaning of the distance units used
to define various arguments. A {box} value selects standard distance
units as defined by the "units"_units.html command, e.g. Angstroms for
units = real or metal. A {lattice} value means the distance units are
in lattice spacings. The "lattice"_lattice.html command must have
been previously used to define the lattice spacing. Note that the
units choice also affects the {vel} style parameters since it is
defined in terms of distance/time. Also note that the units keyword
does not affect the {variable} style. You should use the {xlat},
{ylat}, {zlat} keywords of the "thermo_style"_thermo_style.html
command if you want to include lattice spacings in a variable formula.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
[Restart, fix_modify, output, run start/stop, minimize info:]
This fix will restore the initial box settings from "binary restart
files"_restart.html, which allows the fix to be properly continue
deformation, when using the start/stop options of the "run"_run.html
command. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various "output
commands"_Section_howto.html#howto_15.
This fix can perform deformation over multiple runs, using the {start}
and {stop} keywords of the "run"_run.html command. See the
"run"_run.html command for details of how to do this.
This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
You cannot apply x, y, or z deformations to a dimension that is
shrink-wrapped via the "boundary"_boundary.html command.
You cannot apply xy, yz, or xz deformations to a 2nd dimension (y in
xy) that is shrink-wrapped via the "boundary"_boundary.html command.
[Related commands:]
"change_box"_change_box.html
[Default:]
The option defaults are remap = x, flip = yes, and units = lattice.
diff --git a/doc/src/fix_enforce2d.txt b/doc/src/fix_enforce2d.txt
index 1dce62003..5d04e9667 100644
--- a/doc/src/fix_enforce2d.txt
+++ b/doc/src/fix_enforce2d.txt
@@ -1,68 +1,68 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix enforce2d command :h3
[Syntax:]
fix ID group-ID enforce2d :pre
ID, group-ID are documented in "fix"_fix.html command
enforce2d = style name of this fix command :ul
[Examples:]
fix 5 all enforce2d :pre
[Description:]
Zero out the z-dimension velocity and force on each atom in the group.
This is useful when running a 2d simulation to insure that atoms do
not move from their initial z coordinate.
:line
Styles with a suffix are functionally the same as the corresponding
style without the suffix. They have been optimized to run faster,
depending on your available hardware, as discussed in
"Section 5"_Section_accelerate.html of the manual. The
accelerated styles take the same arguments and should produce the same
results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various "output
commands"_Section_howto.html#howto_15. No parameter of this fix can
be used with the {start/stop} keywords of the "run"_run.html command.
The forces due to this fix are imposed during an energy minimization,
invoked by the "minimize"_minimize.html command.
[Restrictions:] none
[Related commands:] none
[Default:] none
diff --git a/doc/src/fix_freeze.txt b/doc/src/fix_freeze.txt
index 6a4f6c2fc..a63ee4cb3 100644
--- a/doc/src/fix_freeze.txt
+++ b/doc/src/fix_freeze.txt
@@ -1,87 +1,87 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix freeze command :h3
[Syntax:]
fix ID group-ID freeze :pre
ID, group-ID are documented in "fix"_fix.html command
freeze = style name of this fix command :ul
[Examples:]
fix 2 bottom freeze :pre
[Description:]
Zero out the force and torque on a granular particle. This is useful
for preventing certain particles from moving in a simulation. The
"granular pair styles"_pair_gran.html also detect if this fix has been
defined and compute interactions between frozen and non-frozen
particles appropriately, as if the frozen particle has infinite mass.
A similar functionality for normal (point) particles can be obtained
using "fix setforce"_fix_setforce.html.
:line
Styles with a suffix are functionally the same as the corresponding
style without the suffix. They have been optimized to run faster,
depending on your available hardware, as discussed in
"Section 5"_Section_accelerate.html of the manual. The
accelerated styles take the same arguments and should produce the same
results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix.
This fix computes a global 3-vector of forces, which can be accessed
by various "output commands"_Section_howto.html#howto_15. This is the
total force on the group of atoms before the forces on individual
atoms are changed by the fix. The vector values calculated by this
fix are "extensive".
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.
[Restrictions:]
This fix is part of the GRANULAR package. It is only enabled if
LAMMPS was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
There can only be a single freeze fix defined. This is because other
the "granular pair styles"_pair_gran.html treat frozen particles
differently and need to be able to reference a single group to which
this fix is applied.
[Related commands:]
"atom_style sphere"_atom_style.html, "fix setforce"_fix_setforce.html
[Default:] none
diff --git a/doc/src/fix_gravity.txt b/doc/src/fix_gravity.txt
index 2cf1665c3..dae8ac5ed 100644
--- a/doc/src/fix_gravity.txt
+++ b/doc/src/fix_gravity.txt
@@ -1,144 +1,144 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix gravity command :h3
fix gravity/omp command :h3
[Syntax:]
fix ID group gravity magnitude style args :pre
ID, group are documented in "fix"_fix.html command :ulb,l
gravity = style name of this fix command :l
magnitude = size of acceleration (force/mass units) :l
magnitude can be a variable (see below) :l
style = {chute} or {spherical} or {gradient} or {vector} :l
{chute} args = angle
angle = angle in +x away from -z or -y axis in 3d/2d (in degrees)
angle can be a variable (see below)
{spherical} args = phi theta
phi = azimuthal angle from +x axis (in degrees)
theta = angle from +z or +y axis in 3d/2d (in degrees)
phi or theta can be a variable (see below)
{vector} args = x y z
x y z = vector direction to apply the acceleration
x or y or z can be a variable (see below) :pre
:ule
[Examples:]
fix 1 all gravity 1.0 chute 24.0
fix 1 all gravity v_increase chute 24.0
fix 1 all gravity 1.0 spherical 0.0 -180.0
fix 1 all gravity 10.0 spherical v_phi v_theta
fix 1 all gravity 100.0 vector 1 1 0 :pre
[Description:]
Impose an additional acceleration on each particle in the group. This
fix is typically used with granular systems to include a "gravity"
term acting on the macroscopic particles. More generally, it can
represent any kind of driving field, e.g. a pressure gradient inducing
a Poiseuille flow in a fluid. Note that this fix operates differently
than the "fix addforce"_fix_addforce.html command. The addforce fix
adds the same force to each atom, independent of its mass. This
command imparts the same acceleration to each atom (force/mass).
The {magnitude} of the acceleration is specified in force/mass units.
For granular systems (LJ units) this is typically 1.0. See the
"units"_units.html command for details.
Style {chute} is typically used for simulations of chute flow where
the specified {angle} is the chute angle, with flow occurring in the +x
direction. For 3d systems, the tilt is away from the z axis; for 2d
systems, the tilt is away from the y axis.
Style {spherical} allows an arbitrary 3d direction to be specified for
the acceleration vector. {Phi} and {theta} are defined in the usual
spherical coordinates. Thus for acceleration acting in the -z
direction, {theta} would be 180.0 (or -180.0). {Theta} = 90.0 and
{phi} = -90.0 would mean acceleration acts in the -y direction. For
2d systems, {phi} is ignored and {theta} is an angle in the xy plane
where {theta} = 0.0 is the y-axis.
Style {vector} imposes an acceleration in the vector direction given
by (x,y,z). Only the direction of the vector is important; it's
length is ignored. For 2d systems, the {z} component is ignored.
Any of the quantities {magnitude}, {angle}, {phi}, {theta}, {x}, {y},
{z} which define the gravitational magnitude and direction, can be
specified as an equal-style "variable"_variable.html. If the value is
a variable, it should be specified as v_name, where name is the
variable name. In this case, the variable will be evaluated each
timestep, and its value used to determine the quantity. You should
insure that the variable calculates a result in the appropriate units,
e.g. force/mass or degrees.
Equal-style variables can specify formulas with various mathematical
functions, and include "thermo_style"_thermo_style.html command
keywords for the simulation box parameters and timestep and elapsed
time. Thus it is easy to specify a time-dependent gravitational
field.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html.
The "fix_modify"_fix_modify.html {energy} option is supported by this
fix to add the gravitational potential energy of the system to the
system's potential energy as part of "thermodynamic
output"_thermo_style.html.
The "fix_modify"_fix_modify.html {respa} option is supported by this
fix. This allows to set at which level of the "r-RESPA"_run_style.html
integrator the fix is adding its forces. Default is the outermost level.
This fix computes a global scalar which can be accessed by various
"output commands"_Section_howto.html#howto_15. This scalar is the
gravitational potential energy of the particles in the defined field,
namely mass * (g dot x) for each particles, where x and mass are the
particles position and mass, and g is the gravitational field. The
scalar value calculated by this fix is "extensive".
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.
[Restrictions:] none
[Related commands:]
"atom_style sphere"_atom_style.html, "fix addforce"_fix_addforce.html
[Default:] none
diff --git a/doc/src/fix_langevin.txt b/doc/src/fix_langevin.txt
index 534d83f6a..93c73f5a5 100644
--- a/doc/src/fix_langevin.txt
+++ b/doc/src/fix_langevin.txt
@@ -1,344 +1,344 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix langevin command :h3
fix langevin/kk command :h3
[Syntax:]
fix ID group-ID langevin Tstart Tstop damp seed keyword values ... :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
langevin = style name of this fix command :l
Tstart,Tstop = desired temperature at start/end of run (temperature units) :l
Tstart can be a variable (see below) :l
damp = damping parameter (time units) :l
seed = random number seed to use for white noise (positive integer) :l
zero or more keyword/value pairs may be appended :l
keyword = {angmom} or {omega} or {scale} or {tally} or {zero} :l
{angmom} value = {no} or factor
{no} = do not thermostat rotational degrees of freedom via the angular momentum
factor = do thermostat rotational degrees of freedom via the angular momentum and apply numeric scale factor as discussed below
{gjf} value = {no} or {yes}
{no} = use standard formulation
{yes} = use Gronbech-Jensen/Farago formulation
{omega} value = {no} or {yes}
{no} = do not thermostat rotational degrees of freedom via the angular velocity
{yes} = do thermostat rotational degrees of freedom via the angular velocity
{scale} values = type ratio
type = atom type (1-N)
ratio = factor by which to scale the damping coefficient
{tally} value = {no} or {yes}
{no} = do not tally the energy added/subtracted to atoms
{yes} = do tally the energy added/subtracted to atoms
{zero} value = {no} or {yes}
{no} = do not set total random force to zero
{yes} = set total random force to zero :pre
:ule
[Examples:]
fix 3 boundary langevin 1.0 1.0 1000.0 699483
fix 1 all langevin 1.0 1.1 100.0 48279 scale 3 1.5
fix 1 all langevin 1.0 1.1 100.0 48279 angmom 3.333 :pre
[Description:]
Apply a Langevin thermostat as described in "(Schneider)"_#Schneider1
to a group of atoms which models an interaction with a background
implicit solvent. Used with "fix nve"_fix_nve.html, this command
performs Brownian dynamics (BD), since the total force on each atom
will have the form:
F = Fc + Ff + Fr
Ff = - (m / damp) v
Fr is proportional to sqrt(Kb T m / (dt damp)) :pre
Fc is the conservative force computed via the usual inter-particle
interactions ("pair_style"_pair_style.html,
"bond_style"_bond_style.html, etc).
The Ff and Fr terms are added by this fix on a per-particle basis.
See the "pair_style dpd/tstat"_pair_dpd.html command for a
thermostatting option that adds similar terms on a pairwise basis to
pairs of interacting particles.
Ff is a frictional drag or viscous damping term proportional to the
particle's velocity. The proportionality constant for each atom is
computed as m/damp, where m is the mass of the particle and damp is
the damping factor specified by the user.
Fr is a force due to solvent atoms at a temperature T randomly bumping
into the particle. As derived from the fluctuation/dissipation
theorem, its magnitude as shown above is proportional to sqrt(Kb T m /
dt damp), where Kb is the Boltzmann constant, T is the desired
temperature, m is the mass of the particle, dt is the timestep size,
and damp is the damping factor. Random numbers are used to randomize
the direction and magnitude of this force as described in
"(Dunweg)"_#Dunweg1, where a uniform random number is used (instead of
a Gaussian random number) for speed.
Note that unless you use the {omega} or {angmom} keywords, the
thermostat effect of this fix is applied to only the translational
degrees of freedom for the particles, which is an important
consideration for finite-size particles, which have rotational degrees
of freedom, are being thermostatted. The translational degrees of
freedom can also have a bias velocity removed from them before
thermostatting takes place; see the description below.
NOTE: Unlike the "fix nvt"_fix_nh.html command which performs
Nose/Hoover thermostatting AND time integration, this fix does NOT
perform time integration. It only modifies forces to effect
thermostatting. Thus you must use a separate time integration fix,
like "fix nve"_fix_nve.html to actually update the velocities and
positions of atoms using the modified forces. Likewise, this fix
should not normally be used on atoms that also have their temperature
controlled by another fix - e.g. by "fix nvt"_fix_nh.html or "fix
temp/rescale"_fix_temp_rescale.html commands.
See "this howto section"_Section_howto.html#howto_16 of the manual for
a discussion of different ways to compute temperature and perform
thermostatting.
The desired temperature at each timestep is a ramped value during the
run from {Tstart} to {Tstop}.
{Tstart} can be specified as an equal-style or atom-style
"variable"_variable.html. In this case, the {Tstop} setting is
ignored. If the value is a variable, it should be specified as
v_name, where name is the variable name. In this case, the variable
will be evaluated each timestep, and its value used to determine the
target temperature.
Equal-style variables can specify formulas with various mathematical
functions, and include "thermo_style"_thermo_style.html command
keywords for the simulation box parameters and timestep and elapsed
time. Thus it is easy to specify a time-dependent temperature.
Atom-style variables can specify the same formulas as equal-style
variables but can also include per-atom values, such as atom
coordinates. Thus it is easy to specify a spatially-dependent
temperature with optional time-dependence as well.
Like other fixes that perform thermostatting, this fix can be used
with "compute commands"_compute.html that remove a "bias" from the
atom velocities. E.g. removing the center-of-mass velocity from a
group of atoms or removing the x-component of velocity from the
calculation. This is not done by default, but only if the
"fix_modify"_fix_modify.html command is used to assign a temperature
compute to this fix that includes such a bias term. See the doc pages
for individual "compute commands"_compute.html to determine which ones
include a bias. In this case, the thermostat works in the following
manner: bias is removed from each atom, thermostatting is performed on
the remaining thermal degrees of freedom, and the bias is added back
in.
The {damp} parameter is specified in time units and determines how
rapidly the temperature is relaxed. For example, a value of 100.0
means to relax the temperature in a timespan of (roughly) 100 time
units (tau or fmsec or psec - see the "units"_units.html command).
The damp factor can be thought of as inversely related to the
viscosity of the solvent. I.e. a small relaxation time implies a
hi-viscosity solvent and vice versa. See the discussion about gamma
and viscosity in the documentation for the "fix
viscous"_fix_viscous.html command for more details.
The random # {seed} must be a positive integer. A Marsaglia random
number generator is used. Each processor uses the input seed to
generate its own unique seed and its own stream of random numbers.
Thus the dynamics of the system will not be identical on two runs on
different numbers of processors.
:line
The keyword/value option pairs are used in the following ways.
The keyword {angmom} and {omega} keywords enable thermostatting of
rotational degrees of freedom in addition to the usual translational
degrees of freedom. This can only be done for finite-size particles.
A simulation using atom_style sphere defines an omega for finite-size
spheres. A simulation using atom_style ellipsoid defines a finite
size and shape for aspherical particles and an angular momentum.
The Langevin formulas for thermostatting the rotational degrees of
freedom are the same as those above, where force is replaced by
torque, m is replaced by the moment of inertia I, and v is replaced by
omega (which is derived from the angular momentum in the case of
aspherical particles).
The rotational temperature of the particles can be monitored by the
"compute temp/sphere"_compute_temp_sphere.html and "compute
temp/asphere"_compute_temp_asphere.html commands with their rotate
options.
For the {omega} keyword there is also a scale factor of 10.0/3.0 that
is applied as a multiplier on the Ff (damping) term in the equation
above and of sqrt(10.0/3.0) as a multiplier on the Fr term. This does
not affect the thermostatting behaviour of the Langevin formalism but
insures that the randomized rotational diffusivity of spherical
particles is correct.
For the {angmom} keyword a similar scale factor is needed which is
10.0/3.0 for spherical particles, but is anisotropic for aspherical
particles (e.g. ellipsoids). Currently LAMMPS only applies an
isotropic scale factor, and you can choose its magnitude as the
specified value of the {angmom} keyword. If your aspherical particles
are (nearly) spherical than a value of 10.0/3.0 = 3.333 is a good
choice. If they are highly aspherical, a value of 1.0 is as good a
choice as any, since the effects on rotational diffusivity of the
particles will be incorrect regardless. Note that for any reasonable
scale factor, the thermostatting effect of the {angmom} keyword on the
rotational temperature of the aspherical particles should still be
valid.
The keyword {scale} allows the damp factor to be scaled up or down by
the specified factor for atoms of that type. This can be useful when
different atom types have different sizes or masses. It can be used
multiple times to adjust damp for several atom types. Note that
specifying a ratio of 2 increases the relaxation time which is
equivalent to the solvent's viscosity acting on particles with 1/2 the
diameter. This is the opposite effect of scale factors used by the
"fix viscous"_fix_viscous.html command, since the damp factor in fix
{langevin} is inversely related to the gamma factor in fix {viscous}.
Also note that the damping factor in fix {langevin} includes the
particle mass in Ff, unlike fix {viscous}. Thus the mass and size of
different atom types should be accounted for in the choice of ratio
values.
The keyword {tally} enables the calculation of the cumulative energy
added/subtracted to the atoms as they are thermostatted. Effectively
it is the energy exchanged between the infinite thermal reservoir and
the particles. As described below, this energy can then be printed
out or added to the potential energy of the system to monitor energy
conservation.
NOTE: this accumulated energy does NOT include kinetic energy removed
by the {zero} flag. LAMMPS will print a warning when both options are
active.
The keyword {zero} can be used to eliminate drift due to the
thermostat. Because the random forces on different atoms are
independent, they do not sum exactly to zero. As a result, this fix
applies a small random force to the entire system, and the
center-of-mass of the system undergoes a slow random walk. If the
keyword {zero} is set to {yes}, the total random force is set exactly
to zero by subtracting off an equal part of it from each atom in the
group. As a result, the center-of-mass of a system with zero initial
momentum will not drift over time.
The keyword {gjf} can be used to run the "Gronbech-Jensen/Farago
"_#Gronbech-Jensen time-discretization of the Langevin model. As
described in the papers cited below, the purpose of this method is to
enable longer timesteps to be used (up to the numerical stability
limit of the integrator), while still producing the correct Boltzmann
distribution of atom positions. It is implemented within LAMMPS, by
changing how the random force is applied so that it is composed of
the average of two random forces representing half-contributions from
the previous and current time intervals.
In common with all methods based on Verlet integration, the
discretized velocities generated by this method in conjunction with
velocity-Verlet time integration are not exactly conjugate to the
positions. As a result the temperature (computed from the discretized
velocities) will be systematically lower than the target temperature,
by a small amount which grows with the timestep. Nonetheless, the
distribution of atom positions will still be consistent with the
target temperature.
As an example of using the {gjf} keyword, for molecules containing C-H
bonds, configurational properties generated with dt = 2.5 fs and tdamp
= 100 fs are indistinguishable from dt = 0.5 fs. Because the velocity
distribution systematically decreases with increasing timestep, the
method should not be used to generate properties that depend on the
velocity distribution, such as the velocity autocorrelation function
(VACF). In this example, the velocity distribution at dt = 2.5fs
generates an average temperature of 220 K, instead of 300 K.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html. Because the state of the random number generator
is not saved in restart files, this means you cannot do "exact"
restarts with this fix, where the simulation continues on the same as
if no restart had taken place. However, in a statistical sense, a
restarted simulation should produce the same behavior.
The "fix_modify"_fix_modify.html {temp} option is supported by this
fix. You can use it to assign a temperature "compute"_compute.html
you have defined to this fix which will be used in its thermostatting
procedure, as described above. For consistency, the group used by
this fix and by the compute should be the same.
The "fix_modify"_fix_modify.html {energy} option is supported by this
fix to add the energy change induced by Langevin thermostatting to the
system's potential energy as part of "thermodynamic
output"_thermo_style.html. Note that use of this option requires
setting the {tally} keyword to {yes}.
This fix computes a global scalar which can be accessed by various
"output commands"_Section_howto.html#howto_15. The scalar is the
cumulative energy change due to this fix. The scalar value
calculated by this fix is "extensive". Note that calculation of this
quantity requires setting the {tally} keyword to {yes}.
This fix can ramp its target temperature over multiple runs, using the
{start} and {stop} keywords of the "run"_run.html command. See the
"run"_run.html command for details of how to do this.
This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:] none
[Related commands:]
"fix nvt"_fix_nh.html, "fix temp/rescale"_fix_temp_rescale.html, "fix
viscous"_fix_viscous.html, "fix nvt"_fix_nh.html, "pair_style
dpd/tstat"_pair_dpd.html
[Default:]
The option defaults are angmom = no, omega = no, scale = 1.0 for all
types, tally = no, zero = no, gjf = no.
:line
:link(Dunweg1)
[(Dunweg)] Dunweg and Paul, Int J of Modern Physics C, 2, 817-27 (1991).
:link(Schneider1)
[(Schneider)] Schneider and Stoll, Phys Rev B, 17, 1302 (1978).
:link(Gronbech-Jensen)
[(Gronbech-Jensen)] Gronbech-Jensen and Farago, Mol Phys, 111, 983
(2013); Gronbech-Jensen, Hayre, and Farago, Comp Phys Comm,
185, 524 (2014)
diff --git a/doc/src/fix_momentum.txt b/doc/src/fix_momentum.txt
index 4f94e2a85..bcf4465fb 100644
--- a/doc/src/fix_momentum.txt
+++ b/doc/src/fix_momentum.txt
@@ -1,98 +1,98 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix momentum command :h3
fix momentum/kk command :h3
[Syntax:]
fix ID group-ID momentum N keyword values ... :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
momentum = style name of this fix command :l
N = adjust the momentum every this many timesteps
one or more keyword/value pairs may be appended :l
keyword = {linear} or {angular} or {rescale} :l
{linear} values = xflag yflag zflag
xflag,yflag,zflag = 0/1 to exclude/include each dimension
{angular} values = none :pre
{rescale} values = none :pre
:ule
[Examples:]
fix 1 all momentum 1 linear 1 1 0
fix 1 all momentum 1 linear 1 1 1 rescale
fix 1 all momentum 100 linear 1 1 1 angular :pre
[Description:]
Zero the linear and/or angular momentum of the group of atoms every N
timesteps by adjusting the velocities of the atoms. One (or both) of
the {linear} or {angular} keywords must be specified.
If the {linear} keyword is used, the linear momentum is zeroed by
subtracting the center-of-mass velocity of the group from each atom.
This does not change the relative velocity of any pair of atoms. One
or more dimensions can be excluded from this operation by setting the
corresponding flag to 0.
If the {angular} keyword is used, the angular momentum is zeroed by
subtracting a rotational component from each atom.
This command can be used to insure the entire collection of atoms (or
a subset of them) does not drift or rotate during the simulation due
to random perturbations (e.g. "fix langevin"_fix_langevin.html
thermostatting).
The {rescale} keyword enables conserving the kinetic energy of the group
of atoms by rescaling the velocities after the momentum was removed.
Note that the "velocity"_velocity.html command can be used to create
initial velocities with zero aggregate linear and/or angular momentum.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various "output
commands"_Section_howto.html#howto_15. 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.
[Restrictions:] none
[Related commands:]
"fix recenter"_fix_recenter.html, "velocity"_velocity.html
[Default:] none
diff --git a/doc/src/fix_nh.txt b/doc/src/fix_nh.txt
index c1cc3e560..8fa30ac22 100644
--- a/doc/src/fix_nh.txt
+++ b/doc/src/fix_nh.txt
@@ -1,642 +1,642 @@
<"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix nvt command :h3
fix nvt/intel command :h3
fix nvt/kk command :h3
fix nvt/omp command :h3
fix npt command :h3
fix npt/intel command :h3
fix npt/kk command :h3
fix npt/omp command :h3
fix nph command :h3
fix nph/kk command :h3
fix nph/omp command :h3
[Syntax:]
fix ID group-ID style_name keyword value ... :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
style_name = {nvt} or {npt} or {nph} :l
one or more keyword/value pairs may be appended :l
keyword = {temp} or {iso} or {aniso} or {tri} or {x} or {y} or {z} or {xy} or {yz} or {xz} or {couple} or {tchain} or {pchain} or {mtk} or {tloop} or {ploop} or {nreset} or {drag} or {dilate} or {scalexy} or {scaleyz} or {scalexz} or {flip} or {fixedpoint} or {update}
{temp} values = Tstart Tstop Tdamp
Tstart,Tstop = external temperature at start/end of run
Tdamp = temperature damping parameter (time units)
{iso} or {aniso} or {tri} values = Pstart Pstop Pdamp
Pstart,Pstop = scalar external pressure at start/end of run (pressure units)
Pdamp = pressure damping parameter (time units)
{x} or {y} or {z} or {xy} or {yz} or {xz} values = Pstart Pstop Pdamp
Pstart,Pstop = external stress tensor component at start/end of run (pressure units)
Pdamp = stress damping parameter (time units)
{couple} = {none} or {xyz} or {xy} or {yz} or {xz}
{tchain} value = N
N = length of thermostat chain (1 = single thermostat)
{pchain} values = N
N length of thermostat chain on barostat (0 = no thermostat)
{mtk} value = {yes} or {no} = add in MTK adjustment term or not
{tloop} value = M
M = number of sub-cycles to perform on thermostat
{ploop} value = M
M = number of sub-cycles to perform on barostat thermostat
{nreset} value = reset reference cell every this many timesteps
{drag} value = Df
Df = drag factor added to barostat/thermostat (0.0 = no drag)
{dilate} value = dilate-group-ID
dilate-group-ID = only dilate atoms in this group due to barostat volume changes
{scalexy} value = {yes} or {no} = scale xy with ly
{scaleyz} value = {yes} or {no} = scale yz with lz
{scalexz} value = {yes} or {no} = scale xz with lz
{flip} value = {yes} or {no} = allow or disallow box flips when it becomes highly skewed
{fixedpoint} values = x y z
x,y,z = perform barostat dilation/contraction around this point (distance units)
{update} value = {dipole} or {dipole/dlm}
dipole = update dipole orientation (only for sphere variants)
dipole/dlm = use DLM integrator to update dipole orientation (only for sphere variants) :pre
:ule
[Examples:]
fix 1 all nvt temp 300.0 300.0 100.0
fix 1 water npt temp 300.0 300.0 100.0 iso 0.0 0.0 1000.0
fix 2 jello npt temp 300.0 300.0 100.0 tri 5.0 5.0 1000.0
fix 2 ice nph x 1.0 1.0 0.5 y 2.0 2.0 0.5 z 3.0 3.0 0.5 yz 0.1 0.1 0.5 xz 0.2 0.2 0.5 xy 0.3 0.3 0.5 nreset 1000 :pre
[Description:]
These commands perform time integration on Nose-Hoover style
non-Hamiltonian equations of motion which are designed to generate
positions and velocities sampled from the canonical (nvt),
isothermal-isobaric (npt), and isenthalpic (nph) ensembles. This
updates the position and velocity for atoms in the group each
timestep.
The thermostatting and barostatting is achieved by adding some dynamic
variables which are coupled to the particle velocities
(thermostatting) and simulation domain dimensions (barostatting). In
addition to basic thermostatting and barostatting, these fixes can
also create a chain of thermostats coupled to the particle thermostat,
and another chain of thermostats coupled to the barostat
variables. The barostat can be coupled to the overall box volume, or
to individual dimensions, including the {xy}, {xz} and {yz} tilt
dimensions. The external pressure of the barostat can be specified as
either a scalar pressure (isobaric ensemble) or as components of a
symmetric stress tensor (constant stress ensemble). When used
correctly, the time-averaged temperature and stress tensor of the
particles will match the target values specified by Tstart/Tstop and
Pstart/Pstop.
The equations of motion used are those of Shinoda et al in
"(Shinoda)"_#nh-Shinoda, which combine the hydrostatic equations of
Martyna, Tobias and Klein in "(Martyna)"_#nh-Martyna with the strain
energy proposed by Parrinello and Rahman in
"(Parrinello)"_#nh-Parrinello. The time integration schemes closely
follow the time-reversible measure-preserving Verlet and rRESPA
integrators derived by Tuckerman et al in "(Tuckerman)"_#nh-Tuckerman.
:line
The thermostat parameters for fix styles {nvt} and {npt} is specified
using the {temp} keyword. Other thermostat-related keywords are
{tchain}, {tloop} and {drag}, which are discussed below.
The thermostat is applied to only the translational degrees of freedom
for the particles. The translational degrees of freedom can also have
a bias velocity removed before thermostatting takes place; see the
description below. The desired temperature at each timestep is a
ramped value during the run from {Tstart} to {Tstop}. The {Tdamp}
parameter is specified in time units and determines how rapidly the
temperature is relaxed. For example, a value of 10.0 means to relax
the temperature in a timespan of (roughly) 10 time units (e.g. tau or
fmsec or psec - see the "units"_units.html command). The atoms in the
fix group are the only ones whose velocities and positions are updated
by the velocity/position update portion of the integration.
NOTE: A Nose-Hoover thermostat will not work well for arbitrary values
of {Tdamp}. If {Tdamp} is too small, the temperature can fluctuate
wildly; if it is too large, the temperature will take a very long time
to equilibrate. A good choice for many models is a {Tdamp} of around
100 timesteps. Note that this is NOT the same as 100 time units for
most "units"_units.html settings.
:line
The barostat parameters for fix styles {npt} and {nph} is specified
using one or more of the {iso}, {aniso}, {tri}, {x}, {y}, {z}, {xy},
{xz}, {yz}, and {couple} keywords. These keywords give you the
ability to specify all 6 components of an external stress tensor, and
to couple various of these components together so that the dimensions
they represent are varied together during a constant-pressure
simulation.
Other barostat-related keywords are {pchain}, {mtk}, {ploop},
{nreset}, {drag}, and {dilate}, which are discussed below.
Orthogonal simulation boxes have 3 adjustable dimensions (x,y,z).
Triclinic (non-orthogonal) simulation boxes have 6 adjustable
dimensions (x,y,z,xy,xz,yz). The "create_box"_create_box.html, "read
data"_read_data.html, and "read_restart"_read_restart.html commands
specify whether the simulation box is orthogonal or non-orthogonal
(triclinic) and explain the meaning of the xy,xz,yz tilt factors.
The target pressures for each of the 6 components of the stress tensor
can be specified independently via the {x}, {y}, {z}, {xy}, {xz}, {yz}
keywords, which correspond to the 6 simulation box dimensions. For
each component, the external pressure or tensor component at each
timestep is a ramped value during the run from {Pstart} to {Pstop}.
If a target pressure is specified for a component, then the
corresponding box dimension will change during a simulation. For
example, if the {y} keyword is used, the y-box length will change. If
the {xy} keyword is used, the xy tilt factor will change. A box
dimension will not change if that component is not specified, although
you have the option to change that dimension via the "fix
deform"_fix_deform.html command.
Note that in order to use the {xy}, {xz}, or {yz} keywords, the
simulation box must be triclinic, even if its initial tilt factors are
0.0.
For all barostat keywords, the {Pdamp} parameter operates like the
{Tdamp} parameter, determining the time scale on which pressure is
relaxed. For example, a value of 10.0 means to relax the pressure in
a timespan of (roughly) 10 time units (e.g. tau or fmsec or psec - see
the "units"_units.html command).
NOTE: A Nose-Hoover barostat will not work well for arbitrary values
of {Pdamp}. If {Pdamp} is too small, the pressure and volume can
fluctuate wildly; if it is too large, the pressure will take a very
long time to equilibrate. A good choice for many models is a {Pdamp}
of around 1000 timesteps. However, note that {Pdamp} is specified in
time units, and that timesteps are NOT the same as time units for most
"units"_units.html settings.
Regardless of what atoms are in the fix group (the only atoms which
are time integrated), a global pressure or stress tensor is computed
for all atoms. Similarly, when the size of the simulation box is
changed, all atoms are re-scaled to new positions, unless the keyword
{dilate} is specified with a {dilate-group-ID} for a group that
represents a subset of the atoms. This can be useful, for example, to
leave the coordinates of atoms in a solid substrate unchanged and
controlling the pressure of a surrounding fluid. This option should
be used with care, since it can be unphysical to dilate some atoms and
not others, because it can introduce large, instantaneous
displacements between a pair of atoms (one dilated, one not) that are
far from the dilation origin. Also note that for atoms not in the fix
group, a separate time integration fix like "fix nve"_fix_nve.html or
"fix nvt"_fix_nh.html can be used on them, independent of whether they
are dilated or not.
:line
The {couple} keyword allows two or three of the diagonal components of
the pressure tensor to be "coupled" together. The value specified
with the keyword determines which are coupled. For example, {xz}
means the {Pxx} and {Pzz} components of the stress tensor are coupled.
{Xyz} means all 3 diagonal components are coupled. Coupling means two
things: the instantaneous stress will be computed as an average of the
corresponding diagonal components, and the coupled box dimensions will
be changed together in lockstep, meaning coupled dimensions will be
dilated or contracted by the same percentage every timestep. The
{Pstart}, {Pstop}, {Pdamp} parameters for any coupled dimensions must
be identical. {Couple xyz} can be used for a 2d simulation; the {z}
dimension is simply ignored.
:line
The {iso}, {aniso}, and {tri} keywords are simply shortcuts that are
equivalent to specifying several other keywords together.
The keyword {iso} means couple all 3 diagonal components together when
pressure is computed (hydrostatic pressure), and dilate/contract the
dimensions together. Using "iso Pstart Pstop Pdamp" is the same as
specifying these 4 keywords:
x Pstart Pstop Pdamp
y Pstart Pstop Pdamp
z Pstart Pstop Pdamp
couple xyz :pre
The keyword {aniso} means {x}, {y}, and {z} dimensions are controlled
independently using the {Pxx}, {Pyy}, and {Pzz} components of the
stress tensor as the driving forces, and the specified scalar external
pressure. Using "aniso Pstart Pstop Pdamp" is the same as specifying
these 4 keywords:
x Pstart Pstop Pdamp
y Pstart Pstop Pdamp
z Pstart Pstop Pdamp
couple none :pre
The keyword {tri} means {x}, {y}, {z}, {xy}, {xz}, and {yz} dimensions
are controlled independently using their individual stress components
as the driving forces, and the specified scalar pressure as the
external normal stress. Using "tri Pstart Pstop Pdamp" is the same as
specifying these 7 keywords:
x Pstart Pstop Pdamp
y Pstart Pstop Pdamp
z Pstart Pstop Pdamp
xy 0.0 0.0 Pdamp
yz 0.0 0.0 Pdamp
xz 0.0 0.0 Pdamp
couple none :pre
:line
In some cases (e.g. for solids) the pressure (volume) and/or
temperature of the system can oscillate undesirably when a Nose/Hoover
barostat and thermostat is applied. The optional {drag} keyword will
damp these oscillations, although it alters the Nose/Hoover equations.
A value of 0.0 (no drag) leaves the Nose/Hoover formalism unchanged.
A non-zero value adds a drag term; the larger the value specified, the
greater the damping effect. Performing a short run and monitoring the
pressure and temperature is the best way to determine if the drag term
is working. Typically a value between 0.2 to 2.0 is sufficient to
damp oscillations after a few periods. Note that use of the drag
keyword will interfere with energy conservation and will also change
the distribution of positions and velocities so that they do not
correspond to the nominal NVT, NPT, or NPH ensembles.
An alternative way to control initial oscillations is to use chain
thermostats. The keyword {tchain} determines the number of thermostats
in the particle thermostat. A value of 1 corresponds to the original
Nose-Hoover thermostat. The keyword {pchain} specifies the number of
thermostats in the chain thermostatting the barostat degrees of
freedom. A value of 0 corresponds to no thermostatting of the
barostat variables.
The {mtk} keyword controls whether or not the correction terms due to
Martyna, Tuckerman, and Klein are included in the equations of motion
"(Martyna)"_#nh-Martyna. Specifying {no} reproduces the original
Hoover barostat, whose volume probability distribution function
differs from the true NPT and NPH ensembles by a factor of 1/V. Hence
using {yes} is more correct, but in many cases the difference is
negligible.
The keyword {tloop} can be used to improve the accuracy of integration
scheme at little extra cost. The initial and final updates of the
thermostat variables are broken up into {tloop} substeps, each of
length {dt}/{tloop}. This corresponds to using a first-order
Suzuki-Yoshida scheme "(Tuckerman)"_#nh-Tuckerman. The keyword {ploop}
does the same thing for the barostat thermostat.
The keyword {nreset} controls how often the reference dimensions used
to define the strain energy are reset. If this keyword is not used,
or is given a value of zero, then the reference dimensions are set to
those of the initial simulation domain and are never changed. If the
simulation domain changes significantly during the simulation, then
the final average pressure tensor will differ significantly from the
specified values of the external stress tensor. A value of {nstep}
means that every {nstep} timesteps, the reference dimensions are set
to those of the current simulation domain.
The {scaleyz}, {scalexz}, and {scalexy} keywords control whether or
not the corresponding tilt factors are scaled with the associated box
dimensions when barostatting triclinic periodic cells. The default
values {yes} will turn on scaling, which corresponds to adjusting the
linear dimensions of the cell while preserving its shape. Choosing
{no} ensures that the tilt factors are not scaled with the box
dimensions. See below for restrictions and default values in different
situations. In older versions of LAMMPS, scaling of tilt factors was
not performed. The old behavior can be recovered by setting all three
scale keywords to {no}.
The {flip} keyword allows the tilt factors for a triclinic box to
exceed half the distance of the parallel box length, as discussed
below. If the {flip} value is set to {yes}, the bound is enforced by
flipping the box when it is exceeded. If the {flip} value is set to
{no}, the tilt will continue to change without flipping. Note that if
applied stress induces large deformations (e.g. in a liquid), this
means the box shape can tilt dramatically and LAMMPS will run less
efficiently, due to the large volume of communication needed to
acquire ghost atoms around a processor's irregular-shaped sub-domain.
For extreme values of tilt, LAMMPS may also lose atoms and generate an
error.
The {fixedpoint} keyword specifies the fixed point for barostat volume
changes. By default, it is the center of the box. Whatever point is
chosen will not move during the simulation. For example, if the lower
periodic boundaries pass through (0,0,0), and this point is provided
to {fixedpoint}, then the lower periodic boundaries will remain at
(0,0,0), while the upper periodic boundaries will move twice as
far. In all cases, the particle trajectories are unaffected by the
chosen value, except for a time-dependent constant translation of
positions.
If the {update} keyword is used with the {dipole} value, then the
orientation of the dipole moment of each particle is also updated
during the time integration. This option should be used for models
where a dipole moment is assigned to finite-size particles,
e.g. spheroids via use of the "atom_style hybrid sphere
dipole"_atom_style.html command.
The default dipole orientation integrator can be changed to the
Dullweber-Leimkuhler-McLachlan integration scheme
"(Dullweber)"_#nh-Dullweber when using {update} with the value
{dipole/dlm}. This integrator is symplectic and time-reversible,
giving better energy conservation and allows slightly longer timesteps
at only a small additional computational cost.
:line
NOTE: Using a barostat coupled to tilt dimensions {xy}, {xz}, {yz} can
sometimes result in arbitrarily large values of the tilt dimensions,
i.e. a dramatically deformed simulation box. LAMMPS allows the tilt
factors to grow a small amount beyond the normal limit of half the box
length (0.6 times the box length), and then performs a box "flip" to
an equivalent periodic cell. See the discussion of the {flip} keyword
above, to allow this bound to be exceeded, if desired.
The flip operation is described in more detail in the doc page for
"fix deform"_fix_deform.html. Both the barostat dynamics and the atom
trajectories are unaffected by this operation. However, if a tilt
factor is incremented by a large amount (1.5 times the box length) on
a single timestep, LAMMPS can not accomodate this event and will
terminate the simulation with an error. This error typically indicates
that there is something badly wrong with how the simulation was
constructed, such as specifying values of {Pstart} that are too far
from the current stress value, or specifying a timestep that is too
large. Triclinic barostatting should be used with care. This also is
true for other barostat styles, although they tend to be more
forgiving of insults. In particular, it is important to recognize that
equilibrium liquids can not support a shear stress and that
equilibrium solids can not support shear stresses that exceed the
yield stress.
One exception to this rule is if the 1st dimension in the tilt factor
(x for xy) is non-periodic. In that case, the limits on the tilt
factor are not enforced, since flipping the box in that dimension does
not change the atom positions due to non-periodicity. In this mode,
if you tilt the system to extreme angles, the simulation will simply
become inefficient due to the highly skewed simulation box.
NOTE: Unlike the "fix temp/berendsen"_fix_temp_berendsen.html command
which performs thermostatting but NO time integration, these fixes
perform thermostatting/barostatting AND time integration. Thus you
should not use any other time integration fix, such as "fix
nve"_fix_nve.html on atoms to which this fix is applied. Likewise,
fix nvt and fix npt should not normally be used on atoms that also
have their temperature controlled by another fix - e.g. by "fix
langevin"_fix_nh.html or "fix temp/rescale"_fix_temp_rescale.html
commands.
See "this howto section"_Section_howto.html#howto_16 of the manual for
a discussion of different ways to compute temperature and perform
thermostatting and barostatting.
:line
These fixes compute a temperature and pressure each timestep. To do
this, the fix creates its own computes of style "temp" and "pressure",
as if one of these two sets of commands had been issued:
compute fix-ID_temp group-ID temp
compute fix-ID_press group-ID pressure fix-ID_temp :pre
compute fix-ID_temp all temp
compute fix-ID_press all pressure fix-ID_temp :pre
See the "compute temp"_compute_temp.html and "compute
pressure"_compute_pressure.html commands for details. Note that the
IDs of the new computes are the fix-ID + underscore + "temp" or fix_ID
+ underscore + "press". For fix nvt, the group for the new computes
is the same as the fix group. For fix nph and fix npt, the group for
the new computes is "all" since pressure is computed for the entire
system.
Note that these are NOT the computes used by thermodynamic output (see
the "thermo_style"_thermo_style.html command) with ID = {thermo_temp}
and {thermo_press}. This means you can change the attributes of this
fix's temperature or pressure via the
"compute_modify"_compute_modify.html command or print this temperature
or pressure during thermodynamic output via the "thermo_style
custom"_thermo_style.html command using the appropriate compute-ID.
It also means that changing attributes of {thermo_temp} or
{thermo_press} will have no effect on this fix.
Like other fixes that perform thermostatting, fix nvt and fix npt can
be used with "compute commands"_compute.html that calculate a
temperature after removing a "bias" from the atom velocities.
E.g. removing the center-of-mass velocity from a group of atoms or
only calculating temperature on the x-component of velocity or only
calculating temperature for atoms in a geometric region. This is not
done by default, but only if the "fix_modify"_fix_modify.html command
is used to assign a temperature compute to this fix that includes such
a bias term. See the doc pages for individual "compute
commands"_compute.html to determine which ones include a bias. In
this case, the thermostat works in the following manner: the current
temperature is calculated taking the bias into account, bias is
removed from each atom, thermostatting is performed on the remaining
thermal degrees of freedom, and the bias is added back in.
:line
These fixes can be used with either the {verlet} or {respa}
"integrators"_run_style.html. When using one of the barostat fixes
with {respa}, LAMMPS uses an integrator constructed
according to the following factorization of the Liouville propagator
(for two rRESPA levels):
:c,image(Eqs/fix_nh1.jpg)
This factorization differs somewhat from that of Tuckerman et al, in
that the barostat is only updated at the outermost rRESPA level,
whereas Tuckerman's factorization requires splitting the pressure into
pieces corresponding to the forces computed at each rRESPA level. In
theory, the latter method will exhibit better numerical stability. In
practice, because Pdamp is normally chosen to be a large multiple of
the outermost rRESPA timestep, the barostat dynamics are not the
limiting factor for numerical stability. Both factorizations are
time-reversible and can be shown to preserve the phase space measure
of the underlying non-Hamiltonian equations of motion.
NOTE: This implementation has been shown to conserve linear momentum
up to machine precision under NVT dynamics. Under NPT dynamics,
for a system with zero initial total linear momentum, the total
momentum fluctuates close to zero. It may occasionally undergo brief
excursions to non-negligible values, before returning close to zero.
Over long simulations, this has the effect of causing the center-of-mass
to undergo a slow random walk. This can be mitigated by resetting
the momentum at infrequent intervals using the
"fix momentum"_fix_momentum.html command.
:line
The fix npt and fix nph commands can be used with rigid bodies or
mixtures of rigid bodies and non-rigid particles (e.g. solvent). But
there are also "fix rigid/npt"_fix_rigid.html and "fix
rigid/nph"_fix_rigid.html commands, which are typically a more natural
choice. See the doc page for those commands for more discussion of
the various ways to do this.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restart, fix_modify, output, run start/stop, minimize info:]
These fixes writes the state of all the thermostat and barostat
variables to "binary restart files"_restart.html. See the
"read_restart"_read_restart.html command for info on how to re-specify
a fix in an input script that reads a restart file, so that the
operation of the fix continues in an uninterrupted fashion.
The "fix_modify"_fix_modify.html {temp} and {press} options are
supported by these fixes. You can use them to assign a
"compute"_compute.html you have defined to this fix which will be used
in its thermostatting or barostatting procedure, as described above.
If you do this, note that the kinetic energy derived from the compute
temperature should be consistent with the virial term computed using
all atoms for the pressure. LAMMPS will warn you if you choose to
compute temperature on a subset of atoms.
NOTE: If both the {temp} and {press} keywords are used in a single
thermo_modify command (or in two separate commands), then the order in
which the keywords are specified is important. Note that a "pressure
compute"_compute_pressure.html defines its own temperature compute as
an argument when it is specified. The {temp} keyword will override
this (for the pressure compute being used by fix npt), but only if the
{temp} keyword comes after the {press} keyword. If the {temp} keyword
comes before the {press} keyword, then the new pressure compute
specified by the {press} keyword will be unaffected by the {temp}
setting.
The "fix_modify"_fix_modify.html {energy} option is supported by these
fixes to add the energy change induced by Nose/Hoover thermostatting
and barostatting to the system's potential energy as part of
"thermodynamic output"_thermo_style.html.
These fixes compute a global scalar and a global vector of quantities,
which can be accessed by various "output
commands"_Section_howto.html#howto_15. The scalar value calculated by
these fixes is "extensive"; the vector values are "intensive".
The scalar is the cumulative energy change due to the fix.
The vector stores internal Nose/Hoover thermostat and barostat
variables. The number and meaning of the vector values depends on
which fix is used and the settings for keywords {tchain} and {pchain},
which specify the number of Nose/Hoover chains for the thermostat and
barostat. If no thermostatting is done, then {tchain} is 0. If no
barostatting is done, then {pchain} is 0. In the following list,
"ndof" is 0, 1, 3, or 6, and is the number of degrees of freedom in
the barostat. Its value is 0 if no barostat is used, else its value
is 6 if any off-diagonal stress tensor component is barostatted, else
its value is 1 if {couple xyz} is used or {couple xy} for a 2d
simulation, otherwise its value is 3.
The order of values in the global vector and their meaning is as
follows. The notation means there are tchain values for eta, followed
by tchain for eta_dot, followed by ndof for omega, etc:
eta\[tchain\] = particle thermostat displacements (unitless)
eta_dot\[tchain\] = particle thermostat velocities (1/time units)
omega\[ndof\] = barostat displacements (unitless)
omega_dot\[ndof\] = barostat velocities (1/time units)
etap\[pchain\] = barostat thermostat displacements (unitless)
etap_dot\[pchain\] = barostat thermostat velocities (1/time units)
PE_eta\[tchain\] = potential energy of each particle thermostat displacement (energy units)
KE_eta_dot\[tchain\] = kinetic energy of each particle thermostat velocity (energy units)
PE_omega\[ndof\] = potential energy of each barostat displacement (energy units)
KE_omega_dot\[ndof\] = kinetic energy of each barostat velocity (energy units)
PE_etap\[pchain\] = potential energy of each barostat thermostat displacement (energy units)
KE_etap_dot\[pchain\] = kinetic energy of each barostat thermostat velocity (energy units)
PE_strain\[1\] = scalar strain energy (energy units) :ul
These fixes can ramp their external temperature and pressure over
multiple runs, using the {start} and {stop} keywords of the
"run"_run.html command. See the "run"_run.html command for details of
how to do this.
These fixes are not invoked during "energy
minimization"_minimize.html.
:line
[Restrictions:]
{X}, {y}, {z} cannot be barostatted if the associated dimension is not
periodic. {Xy}, {xz}, and {yz} can only be barostatted if the
simulation domain is triclinic and the 2nd dimension in the keyword
({y} dimension in {xy}) is periodic. {Z}, {xz}, and {yz}, cannot be
barostatted for 2D simulations. The "create_box"_create_box.html,
"read data"_read_data.html, and "read_restart"_read_restart.html
commands specify whether the simulation box is orthogonal or
non-orthogonal (triclinic) and explain the meaning of the xy,xz,yz
tilt factors.
For the {temp} keyword, the final Tstop cannot be 0.0 since it would
make the external T = 0.0 at some timestep during the simulation which
is not allowed in the Nose/Hoover formulation.
The {scaleyz yes} and {scalexz yes} keyword/value pairs can not be used
for 2D simulations. {scaleyz yes}, {scalexz yes}, and {scalexy yes} options
can only be used if the 2nd dimension in the keyword is periodic,
and if the tilt factor is not coupled to the barostat via keywords
{tri}, {yz}, {xz}, and {xy}.
These fixes can be used with dynamic groups as defined by the
"group"_group.html command. Likewise they can be used with groups to
which atoms are added or deleted over time, e.g. a deposition
simulation. However, the conservation properties of the thermostat
and barostat are defined for systems with a static set of atoms. You
may observe odd behavior if the atoms in a group vary dramatically
over time or the atom count becomes very small.
[Related commands:]
"fix nve"_fix_nve.html, "fix_modify"_fix_modify.html,
"run_style"_run_style.html
[Default:]
The keyword defaults are tchain = 3, pchain = 3, mtk = yes, tloop =
ploop = 1, nreset = 0, drag = 0.0, dilate = all, couple = none,
scaleyz = scalexz = scalexy = yes if periodic in 2nd dimension and
not coupled to barostat, otherwise no.
:line
:link(nh-Martyna)
[(Martyna)] Martyna, Tobias and Klein, J Chem Phys, 101, 4177 (1994).
:link(nh-Parrinello)
[(Parrinello)] Parrinello and Rahman, J Appl Phys, 52, 7182 (1981).
:link(nh-Tuckerman)
[(Tuckerman)] Tuckerman, Alejandre, Lopez-Rendon, Jochim, and
Martyna, J Phys A: Math Gen, 39, 5629 (2006).
:link(nh-Shinoda)
[(Shinoda)] Shinoda, Shiga, and Mikami, Phys Rev B, 69, 134103 (2004).
:link(nh-Dullweber)
[(Dullweber)] Dullweber, Leimkuhler and McLachlan, J Chem Phys, 107,
5840 (1997).
diff --git a/doc/src/fix_nph_asphere.txt b/doc/src/fix_nph_asphere.txt
index 3d151a724..8c35b6a1a 100644
--- a/doc/src/fix_nph_asphere.txt
+++ b/doc/src/fix_nph_asphere.txt
@@ -1,153 +1,153 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix nph/asphere command :h3
fix nph/asphere/omp command :h3
[Syntax:]
fix ID group-ID nph/asphere args keyword value ... :pre
ID, group-ID are documented in "fix"_fix.html command
nph/asphere = style name of this fix command
additional barostat related keyword/value pairs from the "fix nph"_fix_nh.html command can be appended :ul
[Examples:]
fix 1 all nph/asphere iso 0.0 0.0 1000.0
fix 2 all nph/asphere x 5.0 5.0 1000.0
fix 2 all nph/asphere x 5.0 5.0 1000.0 drag 0.2
fix 2 water nph/asphere aniso 0.0 0.0 1000.0 dilate partial :pre
[Description:]
Perform constant NPH integration to update position, velocity,
orientation, and angular velocity each timestep for aspherical or
ellipsoidal particles in the group using a Nose/Hoover pressure
barostat. P is pressure; H is enthalpy. This creates a system
trajectory consistent with the isenthalpic ensemble.
This fix differs from the "fix nph"_fix_nh.html command, which assumes
point particles and only updates their position and velocity.
Additional parameters affecting the barostat are specified by keywords
and values documented with the "fix nph"_fix_nh.html command. See,
for example, discussion of the {aniso}, and {dilate} keywords.
The particles in the fix group are the only ones whose velocities and
positions are updated by the velocity/position update portion of the
NPH integration.
Regardless of what particles are in the fix group, a global pressure is
computed for all particles. Similarly, when the size of the simulation
box is changed, all particles are re-scaled to new positions, unless the
keyword {dilate} is specified with a value of {partial}, in which case
only the particles in the fix group are re-scaled. The latter can be
useful for leaving the coordinates of particles in a solid substrate
unchanged and controlling the pressure of a surrounding fluid.
:line
This fix computes a temperature and pressure each timestep. To do
this, the fix creates its own computes of style "temp/asphere" and
"pressure", as if these commands had been issued:
compute fix-ID_temp all temp/asphere
compute fix-ID_press all pressure fix-ID_temp :pre
See the "compute temp/asphere"_compute_temp_asphere.html and "compute
pressure"_compute_pressure.html commands for details. Note that the
IDs of the new computes are the fix-ID + underscore + "temp" or fix_ID
+ underscore + "press", and the group for the new computes is "all"
since pressure is computed for the entire system.
Note that these are NOT the computes used by thermodynamic output (see
the "thermo_style"_thermo_style.html command) with ID = {thermo_temp}
and {thermo_press}. This means you can change the attributes of this
fix's temperature or pressure via the
"compute_modify"_compute_modify.html command or print this temperature
or pressure during thermodynamic output via the "thermo_style
custom"_thermo_style.html command using the appropriate compute-ID.
It also means that changing attributes of {thermo_temp} or
{thermo_press} will have no effect on this fix.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
[Restart, fix_modify, output, run start/stop, minimize info:]
This fix writes the state of the Nose/Hoover barostat to "binary
restart files"_restart.html. See the "read_restart"_read_restart.html
command for info on how to re-specify a fix in an input script that
reads a restart file, so that the operation of the fix continues in an
uninterrupted fashion.
The "fix_modify"_fix_modify.html {temp} and {press} options are
supported by this fix. You can use them to assign a
"compute"_compute.html you have defined to this fix which will be used
in its thermostatting or barostatting procedure. If you do this, note
that the kinetic energy derived from the compute temperature should be
consistent with the virial term computed using all atoms for the
pressure. LAMMPS will warn you if you choose to compute temperature
on a subset of atoms.
The "fix_modify"_fix_modify.html {energy} option is supported by this
fix to add the energy change induced by Nose/Hoover barostatting to
the system's potential energy as part of "thermodynamic
output"_thermo_style.html.
This fix computes the same global scalar and global vector of
quantities as does the "fix nph"_fix_nh.html command.
This fix can ramp its target pressure over multiple runs, using the
{start} and {stop} keywords of the "run"_run.html command. See the
"run"_run.html command for details of how to do this.
This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
This fix is part of the ASPHERE package. It is only enabled if LAMMPS
was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
This fix requires that atoms store torque and angular momentum and a
quaternion as defined by the "atom_style ellipsoid"_atom_style.html
command.
All particles in the group must be finite-size. They cannot be point
particles, but they can be aspherical or spherical as defined by their
shape attribute.
[Related commands:]
"fix nph"_fix_nh.html, "fix nve_asphere"_fix_nve_asphere.html, "fix
nvt_asphere"_fix_nvt_asphere.html, "fix
npt_asphere"_fix_npt_asphere.html, "fix_modify"_fix_modify.html
[Default:] none
diff --git a/doc/src/fix_nph_body.txt b/doc/src/fix_nph_body.txt
index 3a273be59..1e590f1cb 100644
--- a/doc/src/fix_nph_body.txt
+++ b/doc/src/fix_nph_body.txt
@@ -1,148 +1,148 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix nph/body command :h3
[Syntax:]
fix ID group-ID nph/body args keyword value ... :pre
ID, group-ID are documented in "fix"_fix.html command
nph/body = style name of this fix command
additional barostat related keyword/value pairs from the "fix nph"_fix_nh.html command can be appended :ul
[Examples:]
fix 1 all nph/body iso 0.0 0.0 1000.0
fix 2 all nph/body x 5.0 5.0 1000.0
fix 2 all nph/body x 5.0 5.0 1000.0 drag 0.2
fix 2 water nph/body aniso 0.0 0.0 1000.0 dilate partial :pre
[Description:]
Perform constant NPH integration to update position, velocity,
orientation, and angular velocity each timestep for body
particles in the group using a Nose/Hoover pressure
barostat. P is pressure; H is enthalpy. This creates a system
trajectory consistent with the isenthalpic ensemble.
This fix differs from the "fix nph"_fix_nh.html command, which assumes
point particles and only updates their position and velocity.
Additional parameters affecting the barostat are specified by keywords
and values documented with the "fix nph"_fix_nh.html command. See,
for example, discussion of the {aniso}, and {dilate} keywords.
The particles in the fix group are the only ones whose velocities and
positions are updated by the velocity/position update portion of the
NPH integration.
Regardless of what particles are in the fix group, a global pressure is
computed for all particles. Similarly, when the size of the simulation
box is changed, all particles are re-scaled to new positions, unless the
keyword {dilate} is specified with a value of {partial}, in which case
only the particles in the fix group are re-scaled. The latter can be
useful for leaving the coordinates of particles in a solid substrate
unchanged and controlling the pressure of a surrounding fluid.
:line
This fix computes a temperature and pressure each timestep. To do
this, the fix creates its own computes of style "temp/body" and
"pressure", as if these commands had been issued:
compute fix-ID_temp all temp/body
compute fix-ID_press all pressure fix-ID_temp :pre
See the "compute temp/body"_compute_temp_body.html and "compute
pressure"_compute_pressure.html commands for details. Note that the
IDs of the new computes are the fix-ID + underscore + "temp" or fix_ID
+ underscore + "press", and the group for the new computes is "all"
since pressure is computed for the entire system.
Note that these are NOT the computes used by thermodynamic output (see
the "thermo_style"_thermo_style.html command) with ID = {thermo_temp}
and {thermo_press}. This means you can change the attributes of this
fix's temperature or pressure via the
"compute_modify"_compute_modify.html command or print this temperature
or pressure during thermodynamic output via the "thermo_style
custom"_thermo_style.html command using the appropriate compute-ID.
It also means that changing attributes of {thermo_temp} or
{thermo_press} will have no effect on this fix.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
[Restart, fix_modify, output, run start/stop, minimize info:]
This fix writes the state of the Nose/Hoover barostat to "binary
restart files"_restart.html. See the "read_restart"_read_restart.html
command for info on how to re-specify a fix in an input script that
reads a restart file, so that the operation of the fix continues in an
uninterrupted fashion.
The "fix_modify"_fix_modify.html {temp} and {press} options are
supported by this fix. You can use them to assign a
"compute"_compute.html you have defined to this fix which will be used
in its thermostatting or barostatting procedure. If you do this, note
that the kinetic energy derived from the compute temperature should be
consistent with the virial term computed using all atoms for the
pressure. LAMMPS will warn you if you choose to compute temperature
on a subset of atoms.
The "fix_modify"_fix_modify.html {energy} option is supported by this
fix to add the energy change induced by Nose/Hoover barostatting to
the system's potential energy as part of "thermodynamic
output"_thermo_style.html.
This fix computes the same global scalar and global vector of
quantities as does the "fix nph"_fix_nh.html command.
This fix can ramp its target pressure over multiple runs, using the
{start} and {stop} keywords of the "run"_run.html command. See the
"run"_run.html command for details of how to do this.
This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
This fix is part of the BODY package. It is only enabled if LAMMPS
was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
This fix requires that atoms store torque and angular momentum and a
quaternion as defined by the "atom_style body"_atom_style.html
command.
[Related commands:]
"fix nph"_fix_nh.html, "fix nve_body"_fix_nve_body.html, "fix
nvt_body"_fix_nvt_body.html, "fix
npt_body"_fix_npt_body.html, "fix_modify"_fix_modify.html
[Default:] none
diff --git a/doc/src/fix_nph_sphere.txt b/doc/src/fix_nph_sphere.txt
index 9258f40c7..62b45edfd 100644
--- a/doc/src/fix_nph_sphere.txt
+++ b/doc/src/fix_nph_sphere.txt
@@ -1,160 +1,160 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix nph/sphere command :h3
fix nph/sphere/omp command :h3
[Syntax:]
fix ID group-ID nph/sphere args keyword value ... :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
nph/sphere = style name of this fix command :l
keyword = {disc} :l
{disc} value = none = treat particles as 2d discs, not spheres :pre
additional barostat related keyword/value pairs from the "fix nph"_fix_nh.html command can be appended :l,ule
[Examples:]
fix 1 all nph/sphere iso 0.0 0.0 1000.0
fix 2 all nph/sphere x 5.0 5.0 1000.0
fix 2 all nph/sphere x 5.0 5.0 1000.0 disc
fix 2 all nph/sphere x 5.0 5.0 1000.0 drag 0.2
fix 2 water nph/sphere aniso 0.0 0.0 1000.0 dilate partial :pre
[Description:]
Perform constant NPH integration to update position, velocity, and
angular velocity each timestep for finite-size spherical particles in
the group using a Nose/Hoover pressure barostat. P is pressure; H is
enthalpy. This creates a system trajectory consistent with the
isenthalpic ensemble.
This fix differs from the "fix nph"_fix_nh.html command, which assumes
point particles and only updates their position and velocity.
If the {disc} keyword is used, then each particle is treated as a 2d
disc (circle) instead of as a sphere. This is only possible for 2d
simulations, as defined by the "dimension"_dimension.html keyword.
The only difference between discs and spheres in this context is their
moment of inertia, as used in the time integration.
Additional parameters affecting the barostat are specified by keywords
and values documented with the "fix nph"_fix_nh.html command. See,
for example, discussion of the {aniso}, and {dilate} keywords.
The particles in the fix group are the only ones whose velocities and
positions are updated by the velocity/position update portion of the
NPH integration.
Regardless of what particles are in the fix group, a global pressure is
computed for all particles. Similarly, when the size of the simulation
box is changed, all particles are re-scaled to new positions, unless the
keyword {dilate} is specified with a value of {partial}, in which case
only the particles in the fix group are re-scaled. The latter can be
useful for leaving the coordinates of particles in a solid substrate
unchanged and controlling the pressure of a surrounding fluid.
:line
This fix computes a temperature and pressure each timestep. To do
this, the fix creates its own computes of style "temp/sphere" and
"pressure", as if these commands had been issued:
compute fix-ID_temp all temp/sphere
compute fix-ID_press all pressure fix-ID_temp :pre
See the "compute temp/sphere"_compute_temp_sphere.html and "compute
pressure"_compute_pressure.html commands for details. Note that the
IDs of the new computes are the fix-ID + underscore + "temp" or fix_ID
+ underscore + "press", and the group for the new computes is "all"
since pressure is computed for the entire system.
Note that these are NOT the computes used by thermodynamic output (see
the "thermo_style"_thermo_style.html command) with ID = {thermo_temp}
and {thermo_press}. This means you can change the attributes of this
fix's temperature or pressure via the
"compute_modify"_compute_modify.html command or print this temperature
or pressure during thermodynamic output via the "thermo_style
custom"_thermo_style.html command using the appropriate compute-ID.
It also means that changing attributes of {thermo_temp} or
{thermo_press} will have no effect on this fix.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
[Restart, fix_modify, output, run start/stop, minimize info:]
This fix writes the state of the Nose/Hoover barostat to "binary
restart files"_restart.html. See the "read_restart"_read_restart.html
command for info on how to re-specify a fix in an input script that
reads a restart file, so that the operation of the fix continues in an
uninterrupted fashion.
The "fix_modify"_fix_modify.html {temp} and {press} options are
supported by this fix. You can use them to assign a
"compute"_compute.html you have defined to this fix which will be used
in its thermostatting or barostatting procedure. If you do this, note
that the kinetic energy derived from the compute temperature should be
consistent with the virial term computed using all atoms for the
pressure. LAMMPS will warn you if you choose to compute temperature
on a subset of atoms.
The "fix_modify"_fix_modify.html {energy} option is supported by this
fix to add the energy change induced by Nose/Hoover barostatting to
the system's potential energy as part of "thermodynamic
output"_thermo_style.html.
This fix computes the same global scalar and global vector of
quantities as does the "fix nph"_fix_nh.html command.
This fix can ramp its target pressure over multiple runs, using the
{start} and {stop} keywords of the "run"_run.html command. See the
"run"_run.html command for details of how to do this.
This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
This fix requires that atoms store torque and angular velocity (omega)
and a radius as defined by the "atom_style sphere"_atom_style.html
command.
All particles in the group must be finite-size spheres. They cannot
be point particles.
Use of the {disc} keyword is only allowed for 2d simulations, as
defined by the "dimension"_dimension.html keyword.
[Related commands:]
"fix nph"_fix_nh.html, "fix nve_sphere"_fix_nve_sphere.html, "fix
nvt_sphere"_fix_nvt_sphere.html, "fix npt_sphere"_fix_npt_sphere.html,
"fix_modify"_fix_modify.html
[Default:] none
diff --git a/doc/src/fix_nphug.txt b/doc/src/fix_nphug.txt
index ef3ffc495..292e46f94 100644
--- a/doc/src/fix_nphug.txt
+++ b/doc/src/fix_nphug.txt
@@ -1,229 +1,229 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix nphug command :h3
fix nphug/omp command :h3
[Syntax:]
fix ID group-ID nphug keyword value ... :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
one or more keyword value pairs may be appended
keyword = {temp} or {iso} or {aniso} or {tri} or {x} or {y} or {z} or {couple} or {tchain} or {pchain} or {mtk} or {tloop} or {ploop} or {nreset} or {drag} or {dilate} or {scaleyz} or {scalexz} or {scalexy}
{temp} values = Value1 Value2 Tdamp
Value1, Value2 = Nose-Hoover target temperatures, ignored by Hugoniostat
Tdamp = temperature damping parameter (time units)
{iso} or {aniso} or {tri} values = Pstart Pstop Pdamp
Pstart,Pstop = scalar external pressures, must be equal (pressure units)
Pdamp = pressure damping parameter (time units)
{x} or {y} or {z} or {xy} or {yz} or {xz} values = Pstart Pstop Pdamp
Pstart,Pstop = external stress tensor components, must be equal (pressure units)
Pdamp = stress damping parameter (time units)
{couple} = {none} or {xyz} or {xy} or {yz} or {xz}
{tchain} value = length of thermostat chain (1 = single thermostat)
{pchain} values = length of thermostat chain on barostat (0 = no thermostat)
{mtk} value = {yes} or {no} = add in MTK adjustment term or not
{tloop} value = number of sub-cycles to perform on thermostat
{ploop} value = number of sub-cycles to perform on barostat thermostat
{nreset} value = reset reference cell every this many timesteps
{drag} value = drag factor added to barostat/thermostat (0.0 = no drag)
{dilate} value = {all} or {partial}
{scaleyz} value = {yes} or {no} = scale yz with lz
{scalexz} value = {yes} or {no} = scale xz with lz
{scalexy} value = {yes} or {no} = scale xy with ly :pre
:ule
[Examples:]
fix myhug all nphug temp 1.0 1.0 10.0 z 40.0 40.0 70.0
fix myhug all nphug temp 1.0 1.0 10.0 iso 40.0 40.0 70.0 drag 200.0 tchain 1 pchain 0 :pre
[Description:]
This command is a variant of the Nose-Hoover
"fix npt"_fix_nh.html fix style.
It performs time integration of the Hugoniostat equations
of motion developed by Ravelo et al. "(Ravelo)"_#Ravelo1.
These equations compress the system to a state with average
axial stress or pressure equal to the specified target value
and that satisfies the Rankine-Hugoniot (RH)
jump conditions for steady shocks.
The compression can be performed
either
hydrostatically (using keyword {iso}, {aniso}, or {tri}) or uniaxially
(using keywords {x}, {y}, or {z}). In the hydrostatic case,
the cell dimensions change dynamically so that the average axial stress
in all three directions converges towards the specified target value.
In the uniaxial case, the chosen cell dimension changes dynamically
so that the average
axial stress in that direction converges towards the target value. The
other two cell dimensions are kept fixed (zero lateral strain).
This leads to the following additional restrictions on the keywords:
One and only one of the following keywords should be used: {iso}, {aniso}, {tri}, {x}, {y}, {z}
The specified initial and final target pressures must be the same.
The keywords {xy}, {xz}, {yz} may not be used.
The only admissible value for the couple keyword is {xyz}, which has the same effect as keyword {iso}
The {temp} keyword must be used to specify the time constant for kinetic energy relaxation, but initial and final target temperature values are ignored. :ul
Essentially, a Hugoniostat simulation is an NPT simulation in which the
user-specified target temperature is replaced with a time-dependent
target temperature Tt obtained from the following equation:
:c,image(Eqs/fix_nphug.jpg)
where T and Tt are the instantaneous and target temperatures,
P and P0 are the instantaneous and reference pressures or axial stresses,
depending on whether hydrostatic or uniaxial compression is being
performed, V and V0 are the instantaneous and reference volumes,
E and E0 are the instantaneous and reference internal energy (potential
plus kinetic), Ndof is the number of degrees of freedom used in the
definition of temperature, and kB is the Boltzmann constant. Delta is the
negative deviation of the instantaneous temperature from the target temperature.
When the system reaches a stable equilibrium, the value of Delta should
fluctuate about zero.
The values of E0, V0, and P0 are the instantaneous values at the start of
the simulation. These can be overridden using the fix_modify keywords {e0},
{v0}, and {p0} described below.
:line
NOTE: Unlike the "fix temp/berendsen"_fix_temp_berendsen.html command
which performs thermostatting but NO time integration, this fix
performs thermostatting/barostatting AND time integration. Thus you
should not use any other time integration fix, such as "fix
nve"_fix_nve.html on atoms to which this fix is applied. Likewise,
this fix should not be used on atoms that have their temperature
controlled by another fix - e.g. by "fix langevin"_fix_nh.html or "fix
temp/rescale"_fix_temp_rescale.html commands.
:line
This fix computes a temperature and pressure at each timestep. To do
this, the fix creates its own computes of style "temp" and "pressure",
as if one of these two sets of commands had been issued:
compute fix-ID_temp group-ID temp
compute fix-ID_press group-ID pressure fix-ID_temp :pre
compute fix-ID_temp all temp
compute fix-ID_press all pressure fix-ID_temp :pre
See the "compute temp"_compute_temp.html and "compute
pressure"_compute_pressure.html commands for details. Note that the
IDs of the new computes are the fix-ID + underscore + "temp" or fix_ID
+ underscore + "press". The group for
the new computes is "all" since pressure is computed for the entire
system.
Note that these are NOT the computes used by thermodynamic output (see
the "thermo_style"_thermo_style.html command) with ID = {thermo_temp}
and {thermo_press}. This means you can change the attributes of this
fix's temperature or pressure via the
"compute_modify"_compute_modify.html command or print this temperature
or pressure during thermodynamic output via the "thermo_style
custom"_thermo_style.html command using the appropriate compute-ID.
It also means that changing attributes of {thermo_temp} or
{thermo_press} will have no effect on this fix.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restart, fix_modify, output, run start/stop, minimize info:]
This fix writes the values of E0, V0, and P0, as well as the
state of all the thermostat and barostat
variables to "binary restart files"_restart.html. See the
"read_restart"_read_restart.html command for info on how to re-specify
a fix in an input script that reads a restart file, so that the
operation of the fix continues in an uninterrupted fashion.
The "fix_modify"_fix_modify.html {e0}, {v0} and {p0} keywords
can be used to define the values of E0, V0, and P0. Note the
the values for {e0} and {v0} are extensive, and so must correspond
to the total energy and volume of the entire system, not energy and
volume per atom. If any of these quantities are not specified, then the
instantaneous value in the system at the start of the simulation is used.
The "fix_modify"_fix_modify.html {temp} and {press} options are
supported by these fixes. You can use them to assign a
"compute"_compute.html you have defined to this fix which will be used
in its thermostatting or barostatting procedure, as described above.
If you do this, note that the kinetic energy derived from the compute
temperature should be consistent with the virial term computed using
all atoms for the pressure. LAMMPS will warn you if you choose to
compute temperature on a subset of atoms.
The "fix_modify"_fix_modify.html {energy} option is supported by these
fixes to add the energy change induced by Nose/Hoover thermostatting
and barostatting to the system's potential energy as part of
"thermodynamic output"_thermo_style.html. Either way, this energy is *not*
included in the definition of internal energy E when calculating the value
of Delta in the above equation.
These fixes compute a global scalar and a global vector of quantities,
which can be accessed by various "output
commands"_Section_howto.html#howto_15. The scalar value calculated by
these fixes is "extensive"; the vector values are "intensive".
The scalar is the cumulative energy change due to the fix.
The vector stores three quantities unique to this fix (Delta, Us, and up),
followed by all the internal Nose/Hoover thermostat and barostat
variables defined for "fix npt"_fix_nh.html. Delta is the deviation
of the temperature from the target temperature, given by the above equation.
Us and up are the shock and particle velocity corresponding to a steady
shock calculated from the RH conditions. They have units of distance/time.
[Restrictions:]
This fix style is part of the SHOCK package. It is only enabled if
LAMMPS was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
All the usual restrictions for "fix npt"_fix_nh.html apply,
plus the additional ones mentioned above.
[Related commands:]
"fix msst"_fix_msst.html, "fix npt"_fix_nh.html, "fix_modify"_fix_modify.html
[Default:]
The keyword defaults are the same as those for "fix npt"_fix_nh.html
:line
:link(Ravelo1)
[(Ravelo)] Ravelo, Holian, Germann and Lomdahl, Phys Rev B, 70, 014103 (2004).
diff --git a/doc/src/fix_npt_asphere.txt b/doc/src/fix_npt_asphere.txt
index 8fe98f181..5f3979e36 100644
--- a/doc/src/fix_npt_asphere.txt
+++ b/doc/src/fix_npt_asphere.txt
@@ -1,177 +1,177 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix npt/asphere command :h3
fix npt/asphere/omp command :h3
[Syntax:]
fix ID group-ID npt/asphere keyword value ... :pre
ID, group-ID are documented in "fix"_fix.html command
npt/asphere = style name of this fix command
additional thermostat and barostat related keyword/value pairs from the "fix npt"_fix_nh.html command can be appended :ul
[Examples:]
fix 1 all npt/asphere temp 300.0 300.0 100.0 iso 0.0 0.0 1000.0
fix 2 all npt/asphere temp 300.0 300.0 100.0 x 5.0 5.0 1000.0
fix 2 all npt/asphere temp 300.0 300.0 100.0 x 5.0 5.0 1000.0 drag 0.2
fix 2 water npt/asphere temp 300.0 300.0 100.0 aniso 0.0 0.0 1000.0 dilate partial :pre
[Description:]
Perform constant NPT integration to update position, velocity,
orientation, and angular velocity each timestep for aspherical or
ellipsoidal particles in the group using a Nose/Hoover temperature
thermostat and Nose/Hoover pressure barostat. P is pressure; T is
temperature. This creates a system trajectory consistent with the
isothermal-isobaric ensemble.
This fix differs from the "fix npt"_fix_nh.html command, which
assumes point particles and only updates their position and velocity.
The thermostat is applied to both the translational and rotational
degrees of freedom for the aspherical particles, assuming a compute is
used which calculates a temperature that includes the rotational
degrees of freedom (see below). The translational degrees of freedom
can also have a bias velocity removed from them before thermostatting
takes place; see the description below.
Additional parameters affecting the thermostat and barostat are
specified by keywords and values documented with the "fix
npt"_fix_nh.html command. See, for example, discussion of the {temp},
{iso}, {aniso}, and {dilate} keywords.
The particles in the fix group are the only ones whose velocities and
positions are updated by the velocity/position update portion of the
NPT integration.
Regardless of what particles are in the fix group, a global pressure is
computed for all particles. Similarly, when the size of the simulation
box is changed, all particles are re-scaled to new positions, unless the
keyword {dilate} is specified with a value of {partial}, in which case
only the particles in the fix group are re-scaled. The latter can be
useful for leaving the coordinates of particles in a solid substrate
unchanged and controlling the pressure of a surrounding fluid.
:line
This fix computes a temperature and pressure each timestep. To do
this, the fix creates its own computes of style "temp/asphere" and
"pressure", as if these commands had been issued:
compute fix-ID_temp all temp/asphere
compute fix-ID_press all pressure fix-ID_temp :pre
See the "compute temp/asphere"_compute_temp_asphere.html and "compute
pressure"_compute_pressure.html commands for details. Note that the
IDs of the new computes are the fix-ID + underscore + "temp" or fix_ID
+ underscore + "press", and the group for the new computes is "all"
since pressure is computed for the entire system.
Note that these are NOT the computes used by thermodynamic output (see
the "thermo_style"_thermo_style.html command) with ID = {thermo_temp}
and {thermo_press}. This means you can change the attributes of this
fix's temperature or pressure via the
"compute_modify"_compute_modify.html command or print this temperature
or pressure during thermodynamic output via the "thermo_style
custom"_thermo_style.html command using the appropriate compute-ID.
It also means that changing attributes of {thermo_temp} or
{thermo_press} will have no effect on this fix.
Like other fixes that perform thermostatting, this fix can be used
with "compute commands"_compute.html that calculate a temperature
after removing a "bias" from the atom velocities. E.g. removing the
center-of-mass velocity from a group of atoms or only calculating
temperature on the x-component of velocity or only calculating
temperature for atoms in a geometric region. This is not done by
default, but only if the "fix_modify"_fix_modify.html command is used
to assign a temperature compute to this fix that includes such a bias
term. See the doc pages for individual "compute
commands"_compute.html to determine which ones include a bias. In
this case, the thermostat works in the following manner: the current
temperature is calculated taking the bias into account, bias is
removed from each atom, thermostatting is performed on the remaining
thermal degrees of freedom, and the bias is added back in.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
[Restart, fix_modify, output, run start/stop, minimize info:]
This fix writes the state of the Nose/Hoover thermostat and barostat
to "binary restart files"_restart.html. See the
"read_restart"_read_restart.html command for info on how to re-specify
a fix in an input script that reads a restart file, so that the
operation of the fix continues in an uninterrupted fashion.
The "fix_modify"_fix_modify.html {temp} and {press} options are
supported by this fix. You can use them to assign a
"compute"_compute.html you have defined to this fix which will be used
in its thermostatting or barostatting procedure. If you do this, note
that the kinetic energy derived from the compute temperature should be
consistent with the virial term computed using all atoms for the
pressure. LAMMPS will warn you if you choose to compute temperature
on a subset of atoms.
The "fix_modify"_fix_modify.html {energy} option is supported by this
fix to add the energy change induced by Nose/Hoover thermostatting and
barostatting to the system's potential energy as part of
"thermodynamic output"_thermo_style.html.
This fix computes the same global scalar and global vector of
quantities as does the "fix npt"_fix_nh.html command.
This fix can ramp its target temperature and pressure over multiple
runs, using the {start} and {stop} keywords of the "run"_run.html
command. See the "run"_run.html command for details of how to do
this.
This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
This fix is part of the ASPHERE package. It is only enabled if LAMMPS
was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
This fix requires that atoms store torque and angular momentum and a
quaternion as defined by the "atom_style ellipsoid"_atom_style.html
command.
All particles in the group must be finite-size. They cannot be point
particles, but they can be aspherical or spherical as defined by their
shape attribute.
[Related commands:]
"fix npt"_fix_nh.html, "fix nve_asphere"_fix_nve_asphere.html, "fix
nvt_asphere"_fix_nvt_asphere.html, "fix_modify"_fix_modify.html
[Default:] none
diff --git a/doc/src/fix_npt_body.txt b/doc/src/fix_npt_body.txt
index 772920df6..d89bf19db 100644
--- a/doc/src/fix_npt_body.txt
+++ b/doc/src/fix_npt_body.txt
@@ -1,172 +1,172 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix npt/body command :h3
[Syntax:]
fix ID group-ID npt/body keyword value ... :pre
ID, group-ID are documented in "fix"_fix.html command
npt/body = style name of this fix command
additional thermostat and barostat related keyword/value pairs from the "fix npt"_fix_nh.html command can be appended :ul
[Examples:]
fix 1 all npt/body temp 300.0 300.0 100.0 iso 0.0 0.0 1000.0
fix 2 all npt/body temp 300.0 300.0 100.0 x 5.0 5.0 1000.0
fix 2 all npt/body temp 300.0 300.0 100.0 x 5.0 5.0 1000.0 drag 0.2
fix 2 water npt/body temp 300.0 300.0 100.0 aniso 0.0 0.0 1000.0 dilate partial :pre
[Description:]
Perform constant NPT integration to update position, velocity,
orientation, and angular velocity each timestep for body
particles in the group using a Nose/Hoover temperature
thermostat and Nose/Hoover pressure barostat. P is pressure; T is
temperature. This creates a system trajectory consistent with the
isothermal-isobaric ensemble.
This fix differs from the "fix npt"_fix_nh.html command, which
assumes point particles and only updates their position and velocity.
The thermostat is applied to both the translational and rotational
degrees of freedom for the body particles, assuming a compute is
used which calculates a temperature that includes the rotational
degrees of freedom (see below). The translational degrees of freedom
can also have a bias velocity removed from them before thermostatting
takes place; see the description below.
Additional parameters affecting the thermostat and barostat are
specified by keywords and values documented with the "fix
npt"_fix_nh.html command. See, for example, discussion of the {temp},
{iso}, {aniso}, and {dilate} keywords.
The particles in the fix group are the only ones whose velocities and
positions are updated by the velocity/position update portion of the
NPT integration.
Regardless of what particles are in the fix group, a global pressure is
computed for all particles. Similarly, when the size of the simulation
box is changed, all particles are re-scaled to new positions, unless the
keyword {dilate} is specified with a value of {partial}, in which case
only the particles in the fix group are re-scaled. The latter can be
useful for leaving the coordinates of particles in a solid substrate
unchanged and controlling the pressure of a surrounding fluid.
:line
This fix computes a temperature and pressure each timestep. To do
this, the fix creates its own computes of style "temp/body" and
"pressure", as if these commands had been issued:
compute fix-ID_temp all temp/body
compute fix-ID_press all pressure fix-ID_temp :pre
See the "compute temp/body"_compute_temp_body.html and "compute
pressure"_compute_pressure.html commands for details. Note that the
IDs of the new computes are the fix-ID + underscore + "temp" or fix_ID
+ underscore + "press", and the group for the new computes is "all"
since pressure is computed for the entire system.
Note that these are NOT the computes used by thermodynamic output (see
the "thermo_style"_thermo_style.html command) with ID = {thermo_temp}
and {thermo_press}. This means you can change the attributes of this
fix's temperature or pressure via the
"compute_modify"_compute_modify.html command or print this temperature
or pressure during thermodynamic output via the "thermo_style
custom"_thermo_style.html command using the appropriate compute-ID.
It also means that changing attributes of {thermo_temp} or
{thermo_press} will have no effect on this fix.
Like other fixes that perform thermostatting, this fix can be used
with "compute commands"_compute.html that calculate a temperature
after removing a "bias" from the atom velocities. E.g. removing the
center-of-mass velocity from a group of atoms or only calculating
temperature on the x-component of velocity or only calculating
temperature for atoms in a geometric region. This is not done by
default, but only if the "fix_modify"_fix_modify.html command is used
to assign a temperature compute to this fix that includes such a bias
term. See the doc pages for individual "compute
commands"_compute.html to determine which ones include a bias. In
this case, the thermostat works in the following manner: the current
temperature is calculated taking the bias into account, bias is
removed from each atom, thermostatting is performed on the remaining
thermal degrees of freedom, and the bias is added back in.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
[Restart, fix_modify, output, run start/stop, minimize info:]
This fix writes the state of the Nose/Hoover thermostat and barostat
to "binary restart files"_restart.html. See the
"read_restart"_read_restart.html command for info on how to re-specify
a fix in an input script that reads a restart file, so that the
operation of the fix continues in an uninterrupted fashion.
The "fix_modify"_fix_modify.html {temp} and {press} options are
supported by this fix. You can use them to assign a
"compute"_compute.html you have defined to this fix which will be used
in its thermostatting or barostatting procedure. If you do this, note
that the kinetic energy derived from the compute temperature should be
consistent with the virial term computed using all atoms for the
pressure. LAMMPS will warn you if you choose to compute temperature
on a subset of atoms.
The "fix_modify"_fix_modify.html {energy} option is supported by this
fix to add the energy change induced by Nose/Hoover thermostatting and
barostatting to the system's potential energy as part of
"thermodynamic output"_thermo_style.html.
This fix computes the same global scalar and global vector of
quantities as does the "fix npt"_fix_nh.html command.
This fix can ramp its target temperature and pressure over multiple
runs, using the {start} and {stop} keywords of the "run"_run.html
command. See the "run"_run.html command for details of how to do
this.
This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
This fix is part of the BODY package. It is only enabled if LAMMPS
was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
This fix requires that atoms store torque and angular momentum and a
quaternion as defined by the "atom_style body"_atom_style.html
command.
[Related commands:]
"fix npt"_fix_nh.html, "fix nve_body"_fix_nve_body.html, "fix
nvt_body"_fix_nvt_body.html, "fix_modify"_fix_modify.html
[Default:] none
diff --git a/doc/src/fix_npt_sphere.txt b/doc/src/fix_npt_sphere.txt
index 24a8fede5..c4cf2cb08 100644
--- a/doc/src/fix_npt_sphere.txt
+++ b/doc/src/fix_npt_sphere.txt
@@ -1,186 +1,186 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix npt/sphere command :h3
fix npt/sphere/omp command :h3
[Syntax:]
fix ID group-ID npt/sphere keyword value ... :pre
ID, group-ID are documented in "fix"_fix.html command
npt/sphere = style name of this fix command
zero or more keyword/value pairs may be appended :l
keyword = {disc} :l
{disc} value = none = treat particles as 2d discs, not spheres :pre
additional thermostat and barostat related keyword/value pairs from the "fix npt"_fix_nh.html command can be appended :l,ule
[Examples:]
fix 1 all npt/sphere temp 300.0 300.0 100.0 iso 0.0 0.0 1000.0
fix 2 all npt/sphere temp 300.0 300.0 100.0 x 5.0 5.0 1000.0
fix 2 all npt/sphere temp 300.0 300.0 100.0 x 5.0 5.0 1000.0 disc
fix 2 all npt/sphere temp 300.0 300.0 100.0 x 5.0 5.0 1000.0 drag 0.2
fix 2 water npt/sphere temp 300.0 300.0 100.0 aniso 0.0 0.0 1000.0 dilate partial :pre
[Description:]
Perform constant NPT integration to update position, velocity, and
angular velocity each timestep for finite-sizex spherical particles in
the group using a Nose/Hoover temperature thermostat and Nose/Hoover
pressure barostat. P is pressure; T is temperature. This creates a
system trajectory consistent with the isothermal-isobaric ensemble.
This fix differs from the "fix npt"_fix_nh.html command, which
assumes point particles and only updates their position and velocity.
The thermostat is applied to both the translational and rotational
degrees of freedom for the spherical particles, assuming a compute is
used which calculates a temperature that includes the rotational
degrees of freedom (see below). The translational degrees of freedom
can also have a bias velocity removed from them before thermostatting
takes place; see the description below.
If the {disc} keyword is used, then each particle is treated as a 2d
disc (circle) instead of as a sphere. This is only possible for 2d
simulations, as defined by the "dimension"_dimension.html keyword.
The only difference between discs and spheres in this context is their
moment of inertia, as used in the time integration.
Additional parameters affecting the thermostat and barostat are
specified by keywords and values documented with the "fix
npt"_fix_nh.html command. See, for example, discussion of the {temp},
{iso}, {aniso}, and {dilate} keywords.
The particles in the fix group are the only ones whose velocities and
positions are updated by the velocity/position update portion of the
NPT integration.
Regardless of what particles are in the fix group, a global pressure is
computed for all particles. Similarly, when the size of the simulation
box is changed, all particles are re-scaled to new positions, unless the
keyword {dilate} is specified with a value of {partial}, in which case
only the particles in the fix group are re-scaled. The latter can be
useful for leaving the coordinates of particles in a solid substrate
unchanged and controlling the pressure of a surrounding fluid.
:line
This fix computes a temperature and pressure each timestep. To do
this, the fix creates its own computes of style "temp/sphere" and
"pressure", as if these commands had been issued:
compute fix-ID_temp all temp/sphere
compute fix-ID_press all pressure fix-ID_temp :pre
See the "compute temp/sphere"_compute_temp_sphere.html and "compute
pressure"_compute_pressure.html commands for details. Note that the
IDs of the new computes are the fix-ID + underscore + "temp" or fix_ID
+ underscore + "press", and the group for the new computes is "all"
since pressure is computed for the entire system.
Note that these are NOT the computes used by thermodynamic output (see
the "thermo_style"_thermo_style.html command) with ID = {thermo_temp}
and {thermo_press}. This means you can change the attributes of this
fix's temperature or pressure via the
"compute_modify"_compute_modify.html command or print this temperature
or pressure during thermodynamic output via the "thermo_style
custom"_thermo_style.html command using the appropriate compute-ID.
It also means that changing attributes of {thermo_temp} or
{thermo_press} will have no effect on this fix.
Like other fixes that perform thermostatting, this fix can be used
with "compute commands"_compute.html that calculate a temperature
after removing a "bias" from the atom velocities. E.g. removing the
center-of-mass velocity from a group of atoms or only calculating
temperature on the x-component of velocity or only calculating
temperature for atoms in a geometric region. This is not done by
default, but only if the "fix_modify"_fix_modify.html command is used
to assign a temperature compute to this fix that includes such a bias
term. See the doc pages for individual "compute
commands"_compute.html to determine which ones include a bias. In
this case, the thermostat works in the following manner: the current
temperature is calculated taking the bias into account, bias is
removed from each atom, thermostatting is performed on the remaining
thermal degrees of freedom, and the bias is added back in.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
[Restart, fix_modify, output, run start/stop, minimize info:]
This fix writes the state of the Nose/Hoover thermostat and barostat
to "binary restart files"_restart.html. See the
"read_restart"_read_restart.html command for info on how to re-specify
a fix in an input script that reads a restart file, so that the
operation of the fix continues in an uninterrupted fashion.
The "fix_modify"_fix_modify.html {temp} and {press} options are
supported by this fix. You can use them to assign a
"compute"_compute.html you have defined to this fix which will be used
in its thermostatting or barostatting procedure. If you do this, note
that the kinetic energy derived from the compute temperature should be
consistent with the virial term computed using all atoms for the
pressure. LAMMPS will warn you if you choose to compute temperature
on a subset of atoms.
The "fix_modify"_fix_modify.html {energy} option is supported by this
fix to add the energy change induced by Nose/Hoover thermostatting and
barostatting to the system's potential energy as part of
"thermodynamic output"_thermo_style.html.
This fix computes the same global scalar and global vector of
quantities as does the "fix npt"_fix_nh.html command.
This fix can ramp its target temperature and pressure over multiple
runs, using the {start} and {stop} keywords of the "run"_run.html
command. See the "run"_run.html command for details of how to do
this.
This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
This fix requires that atoms store torque and angular velocity (omega)
and a radius as defined by the "atom_style sphere"_atom_style.html
command.
All particles in the group must be finite-size spheres. They cannot
be point particles.
Use of the {disc} keyword is only allowed for 2d simulations, as
defined by the "dimension"_dimension.html keyword.
[Related commands:]
"fix npt"_fix_nh.html, "fix nve_sphere"_fix_nve_sphere.html, "fix
nvt_sphere"_fix_nvt_sphere.html, "fix
npt_asphere"_fix_npt_asphere.html, "fix_modify"_fix_modify.html
[Default:] none
diff --git a/doc/src/fix_nve.txt b/doc/src/fix_nve.txt
index 7ad830187..c04c17858 100644
--- a/doc/src/fix_nve.txt
+++ b/doc/src/fix_nve.txt
@@ -1,73 +1,73 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix nve command :h3
fix nve/intel command :h3
fix nve/kk command :h3
fix nve/omp command :h3
[Syntax:]
fix ID group-ID nve :pre
ID, group-ID are documented in "fix"_fix.html command
nve = style name of this fix command :ul
[Examples:]
fix 1 all nve :pre
[Description:]
Perform constant NVE integration to update position and velocity for
atoms in the group each timestep. V is volume; E is energy. This
creates a system trajectory consistent with the microcanonical
ensemble.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various "output
commands"_Section_howto.html#howto_15. 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.
[Restrictions:] none
[Related commands:]
"fix nvt"_fix_nh.html, "fix npt"_fix_nh.html
[Default:] none
diff --git a/doc/src/fix_nve_asphere.txt b/doc/src/fix_nve_asphere.txt
index 03846a255..1f31fb967 100644
--- a/doc/src/fix_nve_asphere.txt
+++ b/doc/src/fix_nve_asphere.txt
@@ -1,86 +1,86 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix nve/asphere command :h3
fix nve/asphere/intel command :h3
[Syntax:]
fix ID group-ID nve/asphere :pre
ID, group-ID are documented in "fix"_fix.html command
nve/asphere = style name of this fix command :ul
[Examples:]
fix 1 all nve/asphere :pre
[Description:]
Perform constant NVE integration to update position, velocity,
orientation, and angular velocity for aspherical particles in the
group each timestep. V is volume; E is energy. This creates a system
trajectory consistent with the microcanonical ensemble.
This fix differs from the "fix nve"_fix_nve.html command, which
assumes point particles and only updates their position and velocity.
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various "output
commands"_Section_howto.html#howto_15. 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.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This fix is part of the ASPHERE package. It is only enabled if LAMMPS
was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
This fix requires that atoms store torque and angular momentum and a
quaternion as defined by the "atom_style ellipsoid"_atom_style.html
command.
All particles in the group must be finite-size. They cannot be point
particles, but they can be aspherical or spherical as defined by their
shape attribute.
[Related commands:]
"fix nve"_fix_nve.html, "fix nve/sphere"_fix_nve_sphere.html
[Default:] none
diff --git a/doc/src/fix_nve_sphere.txt b/doc/src/fix_nve_sphere.txt
index f91a41f51..21dc6cba8 100644
--- a/doc/src/fix_nve_sphere.txt
+++ b/doc/src/fix_nve_sphere.txt
@@ -1,122 +1,122 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix nve/sphere command :h3
fix nve/sphere/omp command :h3
[Syntax:]
fix ID group-ID nve/sphere :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
nve/sphere = style name of this fix command :l
zero or more keyword/value pairs may be appended :l
keyword = {update} or {disc} :l
{update} value = {dipole} or {dipole/dlm}
dipole = update orientation of dipole moment during integration
dipole/dlm = use DLM integrator to update dipole orientation
{disc} value = none = treat particles as 2d discs, not spheres :pre
:ule
[Examples:]
fix 1 all nve/sphere
fix 1 all nve/sphere update dipole
fix 1 all nve/sphere disc
fix 1 all nve/sphere update dipole/dlm :pre
[Description:]
Perform constant NVE integration to update position, velocity, and
angular velocity for finite-size spherical particles in the group each
timestep. V is volume; E is energy. This creates a system trajectory
consistent with the microcanonical ensemble.
This fix differs from the "fix nve"_fix_nve.html command, which
assumes point particles and only updates their position and velocity.
If the {update} keyword is used with the {dipole} value, then the
orientation of the dipole moment of each particle is also updated
during the time integration. This option should be used for models
where a dipole moment is assigned to finite-size particles,
e.g. spheroids via use of the "atom_style hybrid sphere
dipole"_atom_style.html command.
The default dipole orientation integrator can be changed to the
Dullweber-Leimkuhler-McLachlan integration scheme
"(Dullweber)"_#nh-Dullweber when using {update} with the value
{dipole/dlm}. This integrator is symplectic and time-reversible,
giving better energy conservation and allows slightly longer timesteps
at only a small additional computational cost.
If the {disc} keyword is used, then each particle is treated as a 2d
disc (circle) instead of as a sphere. This is only possible for 2d
simulations, as defined by the "dimension"_dimension.html keyword.
The only difference between discs and spheres in this context is their
moment of inertia, as used in the time integration.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various "output
commands"_Section_howto.html#howto_15. 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.
[Restrictions:]
This fix requires that atoms store torque and angular velocity (omega)
and a radius as defined by the "atom_style sphere"_atom_style.html
command. If the {dipole} keyword is used, then they must also store a
dipole moment as defined by the "atom_style dipole"_atom_style.html
command.
All particles in the group must be finite-size spheres. They cannot
be point particles.
Use of the {disc} keyword is only allowed for 2d simulations, as
defined by the "dimension"_dimension.html keyword.
[Related commands:]
"fix nve"_fix_nve.html, "fix nve/asphere"_fix_nve_asphere.html
[Default:] none
:line
:link(nve-Dullweber)
[(Dullweber)] Dullweber, Leimkuhler and McLachlan, J Chem Phys, 107,
5840 (1997).
diff --git a/doc/src/fix_nvt_asphere.txt b/doc/src/fix_nvt_asphere.txt
index 77de1dea4..21b900f16 100644
--- a/doc/src/fix_nvt_asphere.txt
+++ b/doc/src/fix_nvt_asphere.txt
@@ -1,153 +1,153 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix nvt/asphere command :h3
fix nvt/asphere/omp command :h3
[Syntax:]
fix ID group-ID nvt/asphere keyword value ... :pre
ID, group-ID are documented in "fix"_fix.html command
nvt/asphere = style name of this fix command
additional thermostat related keyword/value pairs from the "fix nvt"_fix_nh.html command can be appended :ul
[Examples:]
fix 1 all nvt/asphere temp 300.0 300.0 100.0
fix 1 all nvt/asphere temp 300.0 300.0 100.0 drag 0.2 :pre
[Description:]
Perform constant NVT integration to update position, velocity,
orientation, and angular velocity each timestep for aspherical or
ellipsoidal particles in the group using a Nose/Hoover temperature
thermostat. V is volume; T is temperature. This creates a system
trajectory consistent with the canonical ensemble.
This fix differs from the "fix nvt"_fix_nh.html command, which
assumes point particles and only updates their position and velocity.
The thermostat is applied to both the translational and rotational
degrees of freedom for the aspherical particles, assuming a compute is
used which calculates a temperature that includes the rotational
degrees of freedom (see below). The translational degrees of freedom
can also have a bias velocity removed from them before thermostatting
takes place; see the description below.
Additional parameters affecting the thermostat are specified by
keywords and values documented with the "fix nvt"_fix_nh.html
command. See, for example, discussion of the {temp} and {drag}
keywords.
This fix computes a temperature each timestep. To do this, the fix
creates its own compute of style "temp/asphere", as if this command
had been issued:
compute fix-ID_temp group-ID temp/asphere :pre
See the "compute temp/asphere"_compute_temp_asphere.html command for
details. Note that the ID of the new compute is the fix-ID +
underscore + "temp", and the group for the new compute is the same as
the fix group.
Note that this is NOT the compute used by thermodynamic output (see
the "thermo_style"_thermo_style.html command) with ID = {thermo_temp}.
This means you can change the attributes of this fix's temperature
(e.g. its degrees-of-freedom) via the
"compute_modify"_compute_modify.html command or print this temperature
during thermodynamic output via the "thermo_style
custom"_thermo_style.html command using the appropriate compute-ID.
It also means that changing attributes of {thermo_temp} will have no
effect on this fix.
Like other fixes that perform thermostatting, this fix can be used
with "compute commands"_compute.html that calculate a temperature
after removing a "bias" from the atom velocities. E.g. removing the
center-of-mass velocity from a group of atoms or only calculating
temperature on the x-component of velocity or only calculating
temperature for atoms in a geometric region. This is not done by
default, but only if the "fix_modify"_fix_modify.html command is used
to assign a temperature compute to this fix that includes such a bias
term. See the doc pages for individual "compute
commands"_compute.html to determine which ones include a bias. In
this case, the thermostat works in the following manner: the current
temperature is calculated taking the bias into account, bias is
removed from each atom, thermostatting is performed on the remaining
thermal degrees of freedom, and the bias is added back in.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
[Restart, fix_modify, output, run start/stop, minimize info:]
This fix writes the state of the Nose/Hoover thermostat to "binary
restart files"_restart.html. See the "read_restart"_read_restart.html
command for info on how to re-specify a fix in an input script that
reads a restart file, so that the operation of the fix continues in an
uninterrupted fashion.
The "fix_modify"_fix_modify.html {temp} option is supported by this
fix. You can use it to assign a "compute"_compute.html you have
defined to this fix which will be used in its thermostatting
procedure.
The "fix_modify"_fix_modify.html {energy} option is supported by this
fix to add the energy change induced by Nose/Hoover thermostatting to
the system's potential energy as part of "thermodynamic
output"_thermo_style.html.
This fix computes the same global scalar and global vector of
quantities as does the "fix nvt"_fix_nh.html command.
This fix can ramp its target temperature over multiple runs, using the
{start} and {stop} keywords of the "run"_run.html command. See the
"run"_run.html command for details of how to do this.
This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
This fix is part of the ASPHERE package. It is only enabled if LAMMPS
was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
This fix requires that atoms store torque and angular momentum and a
quaternion as defined by the "atom_style ellipsoid"_atom_style.html
command.
All particles in the group must be finite-size. They cannot be point
particles, but they can be aspherical or spherical as defined by their
shape attribute.
[Related commands:]
"fix nvt"_fix_nh.html, "fix nve_asphere"_fix_nve_asphere.html, "fix
npt_asphere"_fix_npt_asphere.html, "fix_modify"_fix_modify.html
[Default:] none
diff --git a/doc/src/fix_nvt_body.txt b/doc/src/fix_nvt_body.txt
index 1f04b85c8..6a5e09ba7 100644
--- a/doc/src/fix_nvt_body.txt
+++ b/doc/src/fix_nvt_body.txt
@@ -1,148 +1,148 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix nvt/body command :h3
[Syntax:]
fix ID group-ID nvt/body keyword value ... :pre
ID, group-ID are documented in "fix"_fix.html command
nvt/body = style name of this fix command
additional thermostat related keyword/value pairs from the "fix nvt"_fix_nh.html command can be appended :ul
[Examples:]
fix 1 all nvt/body temp 300.0 300.0 100.0
fix 1 all nvt/body temp 300.0 300.0 100.0 drag 0.2 :pre
[Description:]
Perform constant NVT integration to update position, velocity,
orientation, and angular velocity each timestep for body
particles in the group using a Nose/Hoover temperature
thermostat. V is volume; T is temperature. This creates a system
trajectory consistent with the canonical ensemble.
This fix differs from the "fix nvt"_fix_nh.html command, which
assumes point particles and only updates their position and velocity.
The thermostat is applied to both the translational and rotational
degrees of freedom for the body particles, assuming a compute is
used which calculates a temperature that includes the rotational
degrees of freedom (see below). The translational degrees of freedom
can also have a bias velocity removed from them before thermostatting
takes place; see the description below.
Additional parameters affecting the thermostat are specified by
keywords and values documented with the "fix nvt"_fix_nh.html
command. See, for example, discussion of the {temp} and {drag}
keywords.
This fix computes a temperature each timestep. To do this, the fix
creates its own compute of style "temp/body", as if this command
had been issued:
compute fix-ID_temp group-ID temp/body :pre
See the "compute temp/body"_compute_temp_body.html command for
details. Note that the ID of the new compute is the fix-ID +
underscore + "temp", and the group for the new compute is the same as
the fix group.
Note that this is NOT the compute used by thermodynamic output (see
the "thermo_style"_thermo_style.html command) with ID = {thermo_temp}.
This means you can change the attributes of this fix's temperature
(e.g. its degrees-of-freedom) via the
"compute_modify"_compute_modify.html command or print this temperature
during thermodynamic output via the "thermo_style
custom"_thermo_style.html command using the appropriate compute-ID.
It also means that changing attributes of {thermo_temp} will have no
effect on this fix.
Like other fixes that perform thermostatting, this fix can be used
with "compute commands"_compute.html that calculate a temperature
after removing a "bias" from the atom velocities. E.g. removing the
center-of-mass velocity from a group of atoms or only calculating
temperature on the x-component of velocity or only calculating
temperature for atoms in a geometric region. This is not done by
default, but only if the "fix_modify"_fix_modify.html command is used
to assign a temperature compute to this fix that includes such a bias
term. See the doc pages for individual "compute
commands"_compute.html to determine which ones include a bias. In
this case, the thermostat works in the following manner: the current
temperature is calculated taking the bias into account, bias is
removed from each atom, thermostatting is performed on the remaining
thermal degrees of freedom, and the bias is added back in.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
[Restart, fix_modify, output, run start/stop, minimize info:]
This fix writes the state of the Nose/Hoover thermostat to "binary
restart files"_restart.html. See the "read_restart"_read_restart.html
command for info on how to re-specify a fix in an input script that
reads a restart file, so that the operation of the fix continues in an
uninterrupted fashion.
The "fix_modify"_fix_modify.html {temp} option is supported by this
fix. You can use it to assign a "compute"_compute.html you have
defined to this fix which will be used in its thermostatting
procedure.
The "fix_modify"_fix_modify.html {energy} option is supported by this
fix to add the energy change induced by Nose/Hoover thermostatting to
the system's potential energy as part of "thermodynamic
output"_thermo_style.html.
This fix computes the same global scalar and global vector of
quantities as does the "fix nvt"_fix_nh.html command.
This fix can ramp its target temperature over multiple runs, using the
{start} and {stop} keywords of the "run"_run.html command. See the
"run"_run.html command for details of how to do this.
This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
This fix is part of the BODY package. It is only enabled if LAMMPS
was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
This fix requires that atoms store torque and angular momentum and a
quaternion as defined by the "atom_style body"_atom_style.html
command.
[Related commands:]
"fix nvt"_fix_nh.html, "fix nve_body"_fix_nve_body.html, "fix
npt_body"_fix_npt_body.html, "fix_modify"_fix_modify.html
[Default:] none
diff --git a/doc/src/fix_nvt_sllod.txt b/doc/src/fix_nvt_sllod.txt
index 82631f22e..392dbc281 100644
--- a/doc/src/fix_nvt_sllod.txt
+++ b/doc/src/fix_nvt_sllod.txt
@@ -1,180 +1,180 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix nvt/sllod command :h3
fix nvt/sllod/intel command :h3
fix nvt/sllod/omp command :h3
[Syntax:]
fix ID group-ID nvt/sllod keyword value ... :pre
ID, group-ID are documented in "fix"_fix.html command
nvt/sllod = style name of this fix command
additional thermostat related keyword/value pairs from the "fix nvt"_fix_nh.html command can be appended :ul
[Examples:]
fix 1 all nvt/sllod temp 300.0 300.0 100.0
fix 1 all nvt/sllod temp 300.0 300.0 100.0 drag 0.2 :pre
[Description:]
Perform constant NVT integration to update positions and velocities
each timestep for atoms in the group using a Nose/Hoover temperature
thermostat. V is volume; T is temperature. This creates a system
trajectory consistent with the canonical ensemble.
This thermostat is used for a simulation box that is changing size
and/or shape, for example in a non-equilibrium MD (NEMD) simulation.
The size/shape change is induced by use of the "fix
deform"_fix_deform.html command, so each point in the simulation box
can be thought of as having a "streaming" velocity. This
position-dependent streaming velocity is subtracted from each atom's
actual velocity to yield a thermal velocity which is used for
temperature computation and thermostatting. For example, if the box
is being sheared in x, relative to y, then points at the bottom of the
box (low y) have a small x velocity, while points at the top of the
box (hi y) have a large x velocity. These velocities do not
contribute to the thermal "temperature" of the atom.
NOTE: "Fix deform"_fix_deform.html has an option for remapping either
atom coordinates or velocities to the changing simulation box. To use
fix nvt/sllod, fix deform should NOT remap atom positions, because fix
nvt/sllod adjusts the atom positions and velocities to create a
velocity profile that matches the changing box size/shape. Fix deform
SHOULD remap atom velocities when atoms cross periodic boundaries
since that is consistent with maintaining the velocity profile created
by fix nvt/sllod. LAMMPS will give an error if this setting is not
consistent.
The SLLOD equations of motion, originally proposed by Hoover and Ladd
(see "(Evans and Morriss)"_#Evans3), were proven to be equivalent to
Newton's equations of motion for shear flow by "(Evans and
Morriss)"_#Evans3. They were later shown to generate the desired
velocity gradient and the correct production of work by stresses for
all forms of homogeneous flow by "(Daivis and Todd)"_#Daivis. As
implemented in LAMMPS, they are coupled to a Nose/Hoover chain
thermostat in a velocity Verlet formulation, closely following the
implementation used for the "fix nvt"_fix_nh.html command.
Additional parameters affecting the thermostat are specified by
keywords and values documented with the "fix nvt"_fix_nh.html
command. See, for example, discussion of the {temp} and {drag}
keywords.
This fix computes a temperature each timestep. To do this, the fix
creates its own compute of style "temp/deform", as if this command had
been issued:
compute fix-ID_temp group-ID temp/deform :pre
See the "compute temp/deform"_compute_temp_deform.html command for
details. Note that the ID of the new compute is the fix-ID +
underscore + "temp", and the group for the new compute is the same as
the fix group.
Note that this is NOT the compute used by thermodynamic output (see
the "thermo_style"_thermo_style.html command) with ID = {thermo_temp}.
This means you can change the attributes of this fix's temperature
(e.g. its degrees-of-freedom) via the
"compute_modify"_compute_modify.html command or print this temperature
during thermodynamic output via the "thermo_style
custom"_thermo_style.html command using the appropriate compute-ID.
It also means that changing attributes of {thermo_temp} will have no
effect on this fix.
Like other fixes that perform thermostatting, this fix can be used
with "compute commands"_compute.html that calculate a temperature
after removing a "bias" from the atom velocities. E.g. removing the
center-of-mass velocity from a group of atoms or only calculating
temperature on the x-component of velocity or only calculating
temperature for atoms in a geometric region. This is not done by
default, but only if the "fix_modify"_fix_modify.html command is used
to assign a temperature compute to this fix that includes such a bias
term. See the doc pages for individual "compute
commands"_compute.html to determine which ones include a bias. In
this case, the thermostat works in the following manner: the current
temperature is calculated taking the bias into account, bias is
removed from each atom, thermostatting is performed on the remaining
thermal degrees of freedom, and the bias is added back in.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
[Restart, fix_modify, output, run start/stop, minimize info:]
This fix writes the state of the Nose/Hoover thermostat to "binary
restart files"_restart.html. See the "read_restart"_read_restart.html
command for info on how to re-specify a fix in an input script that
reads a restart file, so that the operation of the fix continues in an
uninterrupted fashion.
The "fix_modify"_fix_modify.html {temp} option is supported by this
fix. You can use it to assign a "compute"_compute.html you have
defined to this fix which will be used in its thermostatting
procedure.
The "fix_modify"_fix_modify.html {energy} option is supported by this
fix to add the energy change induced by Nose/Hoover thermostatting to
the system's potential energy as part of "thermodynamic
output"_thermo_style.html.
This fix computes the same global scalar and global vector of
quantities as does the "fix nvt"_fix_nh.html command.
This fix can ramp its target temperature over multiple runs, using the
{start} and {stop} keywords of the "run"_run.html command. See the
"run"_run.html command for details of how to do this.
This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
This fix works best without Nose-Hoover chain thermostats, i.e. using
tchain = 1. Setting tchain to larger values can result in poor
equilibration.
[Related commands:]
"fix nve"_fix_nve.html, "fix nvt"_fix_nh.html, "fix
temp/rescale"_fix_temp_rescale.html, "fix langevin"_fix_langevin.html,
"fix_modify"_fix_modify.html, "compute
temp/deform"_compute_temp_deform.html
[Default:]
Same as "fix nvt"_fix_nh.html, except tchain = 1.
:line
:link(Evans3)
[(Evans and Morriss)] Evans and Morriss, Phys Rev A, 30, 1528 (1984).
:link(Daivis)
[(Daivis and Todd)] Daivis and Todd, J Chem Phys, 124, 194103 (2006).
diff --git a/doc/src/fix_nvt_sphere.txt b/doc/src/fix_nvt_sphere.txt
index fa1c97bcc..ecf0922b7 100644
--- a/doc/src/fix_nvt_sphere.txt
+++ b/doc/src/fix_nvt_sphere.txt
@@ -1,162 +1,162 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix nvt/sphere command :h3
fix nvt/sphere/omp command :h3
[Syntax:]
fix ID group-ID nvt/sphere keyword value ... :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
nvt/sphere = style name of this fix command :l
zero or more keyword/value pairs may be appended :l
keyword = {disc} :l
{disc} value = none = treat particles as 2d discs, not spheres :pre
additional thermostat related keyword/value pairs from the "fix nvt"_fix_nh.html command can be appended :l,ule
[Examples:]
fix 1 all nvt/sphere temp 300.0 300.0 100.0
fix 1 all nvt/sphere temp 300.0 300.0 100.0 disc
fix 1 all nvt/sphere temp 300.0 300.0 100.0 drag 0.2 :pre
[Description:]
Perform constant NVT integration to update position, velocity, and
angular velocity each timestep for finite-size spherical particles in
the group using a Nose/Hoover temperature thermostat. V is volume; T
is temperature. This creates a system trajectory consistent with the
canonical ensemble.
This fix differs from the "fix nvt"_fix_nh.html command, which
assumes point particles and only updates their position and velocity.
The thermostat is applied to both the translational and rotational
degrees of freedom for the spherical particles, assuming a compute is
used which calculates a temperature that includes the rotational
degrees of freedom (see below). The translational degrees of freedom
can also have a bias velocity removed from them before thermostatting
takes place; see the description below.
If the {disc} keyword is used, then each particle is treated as a 2d
disc (circle) instead of as a sphere. This is only possible for 2d
simulations, as defined by the "dimension"_dimension.html keyword.
The only difference between discs and spheres in this context is their
moment of inertia, as used in the time integration.
Additional parameters affecting the thermostat are specified by
keywords and values documented with the "fix nvt"_fix_nh.html
command. See, for example, discussion of the {temp} and {drag}
keywords.
This fix computes a temperature each timestep. To do this, the fix
creates its own compute of style "temp/sphere", as if this command
had been issued:
compute fix-ID_temp group-ID temp/sphere :pre
See the "compute temp/sphere"_compute_temp_sphere.html command for
details. Note that the ID of the new compute is the fix-ID +
underscore + "temp", and the group for the new compute is the same as
the fix group.
Note that this is NOT the compute used by thermodynamic output (see
the "thermo_style"_thermo_style.html command) with ID = {thermo_temp}.
This means you can change the attributes of this fix's temperature
(e.g. its degrees-of-freedom) via the
"compute_modify"_compute_modify.html command or print this temperature
during thermodynamic output via the "thermo_style
custom"_thermo_style.html command using the appropriate compute-ID.
It also means that changing attributes of {thermo_temp} will have no
effect on this fix.
Like other fixes that perform thermostatting, this fix can be used
with "compute commands"_compute.html that calculate a temperature
after removing a "bias" from the atom velocities. E.g. removing the
center-of-mass velocity from a group of atoms or only calculating
temperature on the x-component of velocity or only calculating
temperature for atoms in a geometric region. This is not done by
default, but only if the "fix_modify"_fix_modify.html command is used
to assign a temperature compute to this fix that includes such a bias
term. See the doc pages for individual "compute
commands"_compute.html to determine which ones include a bias. In
this case, the thermostat works in the following manner: the current
temperature is calculated taking the bias into account, bias is
removed from each atom, thermostatting is performed on the remaining
thermal degrees of freedom, and the bias is added back in.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
[Restart, fix_modify, output, run start/stop, minimize info:]
This fix writes the state of the Nose/Hoover thermostat to "binary
restart files"_restart.html. See the "read_restart"_read_restart.html
command for info on how to re-specify a fix in an input script that
reads a restart file, so that the operation of the fix continues in an
uninterrupted fashion.
The "fix_modify"_fix_modify.html {temp} option is supported by this
fix. You can use it to assign a "compute"_compute.html you have
defined to this fix which will be used in its thermostatting
procedure.
The "fix_modify"_fix_modify.html {energy} option is supported by this
fix to add the energy change induced by Nose/Hoover thermostatting to
the system's potential energy as part of "thermodynamic
output"_thermo_style.html.
This fix computes the same global scalar and global vector of
quantities as does the "fix nvt"_fix_nh.html command.
This fix can ramp its target temperature over multiple runs, using the
{start} and {stop} keywords of the "run"_run.html command. See the
"run"_run.html command for details of how to do this.
This fix is not invoked during "energy minimization"_minimize.html.
[Restrictions:]
This fix requires that atoms store torque and angular velocity (omega)
and a radius as defined by the "atom_style sphere"_atom_style.html
command.
All particles in the group must be finite-size spheres. They cannot
be point particles.
Use of the {disc} keyword is only allowed for 2d simulations, as
defined by the "dimension"_dimension.html keyword.
[Related commands:]
"fix nvt"_fix_nh.html, "fix nve_sphere"_fix_nve_sphere.html, "fix
nvt_asphere"_fix_nvt_asphere.html, "fix
npt_sphere"_fix_npt_sphere.html, "fix_modify"_fix_modify.html
[Default:] none
diff --git a/doc/src/fix_qeq_comb.txt b/doc/src/fix_qeq_comb.txt
index 30c5003e7..7f8240412 100644
--- a/doc/src/fix_qeq_comb.txt
+++ b/doc/src/fix_qeq_comb.txt
@@ -1,132 +1,132 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix qeq/comb command :h3
fix qeq/comb/omp command :h3
[Syntax:]
fix ID group-ID qeq/comb Nevery precision keyword value ... :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
qeq/comb = style name of this fix command :l
Nevery = perform charge equilibration every this many steps :l
precision = convergence criterion for charge equilibration :l
zero or more keyword/value pairs may be appended :l
keyword = {file} :l
{file} value = filename
filename = name of file to write QEQ equilibration info to :pre
:ule
[Examples:]
fix 1 surface qeq/comb 10 0.0001 :pre
[Description:]
Perform charge equilibration (QeQ) in conjunction with the COMB
(Charge-Optimized Many-Body) potential as described in
"(COMB_1)"_#COMB_1 and "(COMB_2)"_#COMB_2. It performs the charge
equilibration portion of the calculation using the so-called QEq
method, whereby the charge on each atom is adjusted to minimize the
energy of the system. This fix can only be used with the COMB
potential; see the "fix qeq/reax"_fix_qeq_reax.html command for a QeQ
calculation that can be used with any potential.
Only charges on the atoms in the specified group are equilibrated.
The fix relies on the pair style (COMB in this case) to calculate the
per-atom electronegativity (effective force on the charges). An
electronegativity equalization calculation (or QEq) is performed in an
iterative fashion, which in parallel requires communication at each
iteration for processors to exchange charge information about nearby
atoms with each other. See "Rappe_and_Goddard"_#Rappe_and_Goddard and
"Rick_and_Stuart"_#Rick_and_Stuart for details.
During a run, charge equilibration is performed every {Nevery} time
steps. Charge equilibration is also always enforced on the first step
of each run. The {precision} argument controls the tolerance for the
difference in electronegativity for all atoms during charge
equilibration. {Precision} is a trade-off between the cost of
performing charge equilibration (more iterations) and accuracy.
If the {file} keyword is used, then information about each
equilibration calculation is written to the specified file.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html.
The "fix_modify"_fix_modify.html {respa} option is supported by this
fix. This allows to set at which level of the "r-RESPA"_run_style.html
integrator the fix is performing charge equilibration. Default is
the outermost level.
This fix produces a per-atom vector which can be accessed by various
"output commands"_Section_howto.html#howto_15. The vector stores the
gradient of the charge on each atom. The per-atom values be accessed
on any timestep.
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command.
This fix can be invoked during "energy minimization"_minimize.html.
[Restrictions:]
This fix command currently only supports "pair style {comb}"_pair_comb.html.
[Related commands:]
"pair_style comb"_pair_comb.html
[Default:]
No file output is performed.
:line
:link(COMB_1)
[(COMB_1)] J. Yu, S. B. Sinnott, S. R. Phillpot, Phys Rev B, 75, 085311 (2007),
:link(COMB_2)
[(COMB_2)] T.-R. Shan, B. D. Devine, T. W. Kemper, S. B. Sinnott, S. R.
Phillpot, Phys Rev B, 81, 125328 (2010).
:link(Rappe_and_Goddard)
[(Rappe_and_Goddard)] A. K. Rappe, W. A. Goddard, J Phys Chem 95, 3358
(1991).
:link(Rick_and_Stuart)
[(Rick_and_Stuart)] S. W. Rick, S. J. Stuart, B. J. Berne, J Chem Phys
101, 16141 (1994).
diff --git a/doc/src/fix_qeq_reax.txt b/doc/src/fix_qeq_reax.txt
index a1a19b736..18450c7cd 100644
--- a/doc/src/fix_qeq_reax.txt
+++ b/doc/src/fix_qeq_reax.txt
@@ -1,130 +1,130 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix qeq/reax command :h3
fix qeq/reax/kk command :h3
fix qeq/reax/omp command :h3
[Syntax:]
fix ID group-ID qeq/reax Nevery cutlo cuthi tolerance params args :pre
ID, group-ID are documented in "fix"_fix.html command
qeq/reax = style name of this fix command
Nevery = perform QEq every this many steps
cutlo,cuthi = lo and hi cutoff for Taper radius
tolerance = precision to which charges will be equilibrated
params = reax/c or a filename
args = {dual} (optional) :ul
[Examples:]
fix 1 all qeq/reax 1 0.0 10.0 1.0e-6 reax/c
fix 1 all qeq/reax 1 0.0 10.0 1.0e-6 param.qeq :pre
[Description:]
Perform the charge equilibration (QEq) method as described in "(Rappe
and Goddard)"_#Rappe2 and formulated in "(Nakano)"_#Nakano2. It is
typically used in conjunction with the ReaxFF force field model as
implemented in the "pair_style reax/c"_pair_reaxc.html command, but
it can be used with any potential in LAMMPS, so long as it defines and
uses charges on each atom. The "fix qeq/comb"_fix_qeq_comb.html
command should be used to perform charge equilibration with the "COMB
potential"_pair_comb.html. For more technical details about the
charge equilibration performed by fix qeq/reax, see the
"(Aktulga)"_#qeq-Aktulga paper.
The QEq method minimizes the electrostatic energy of the system by
adjusting the partial charge on individual atoms based on interactions
with their neighbors. It requires some parameters for each atom type.
If the {params} setting above is the word "reax/c", then these are
extracted from the "pair_style reax/c"_pair_reaxc.html command and
the ReaxFF force field file it reads in. If a file name is specified
for {params}, then the parameters are taken from the specified file
and the file must contain one line for each atom type. The latter
form must be used when performing QeQ with a non-ReaxFF potential.
Each line should be formatted as follows:
itype chi eta gamma :pre
where {itype} is the atom type from 1 to Ntypes, {chi} denotes the
electronegativity in eV, {eta} denotes the self-Coulomb
potential in eV, and {gamma} denotes the valence orbital
exponent. Note that these 3 quantities are also in the ReaxFF
potential file, except that eta is defined here as twice the eta value
in the ReaxFF file. Note that unlike the rest of LAMMPS, the units
of this fix are hard-coded to be A, eV, and electronic charge.
The optional {dual} keyword allows to perform the optimization
of the S and T matrices in parallel. This is only supported for
the {qeq/reax/omp} style. Otherwise they are processed separately.
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html. No global scalar or vector or per-atom
quantities are stored by this fix for access by various "output
commands"_Section_howto.html#howto_15. No parameter of this fix can
be used with the {start/stop} keywords of the "run"_run.html command.
This fix is invoked during "energy minimization"_minimize.html.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This fix is part of the USER-REAXC package. It is only enabled if
LAMMPS was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
This fix does not correctly handle interactions
involving multiple periodic images of the same atom. Hence, it should not
be used for periodic cell dimensions less than 10 angstroms.
[Related commands:]
"pair_style reax/c"_pair_reaxc.html
[Default:] none
:line
:link(Rappe2)
[(Rappe)] Rappe and Goddard III, Journal of Physical Chemistry, 95,
3358-3363 (1991).
:link(Nakano2)
[(Nakano)] Nakano, Computer Physics Communications, 104, 59-69 (1997).
:link(qeq-Aktulga)
[(Aktulga)] Aktulga, Fogarty, Pandit, Grama, Parallel Computing, 38,
245-259 (2012).
diff --git a/doc/src/fix_reax_bonds.txt b/doc/src/fix_reax_bonds.txt
index aadb0a9cb..54aa7faef 100644
--- a/doc/src/fix_reax_bonds.txt
+++ b/doc/src/fix_reax_bonds.txt
@@ -1,113 +1,113 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix reax/bonds command :h3
fix reax/c/bonds command :h3
fix reax/c/bonds/kk command :h3
[Syntax:]
fix ID group-ID reax/bonds Nevery filename :pre
ID, group-ID are documented in "fix"_fix.html command
reax/bonds = style name of this fix command
Nevery = output interval in timesteps
filename = name of output file :ul
[Examples:]
fix 1 all reax/bonds 100 bonds.tatb
fix 1 all reax/c/bonds 100 bonds.reaxc :pre
[Description:]
Write out the bond information computed by the ReaxFF potential
specified by "pair_style reax"_pair_reax.html or "pair_style
reax/c"_pair_reaxc.html in the exact same format as the original
stand-alone ReaxFF code of Adri van Duin. The bond information is
written to {filename} on timesteps that are multiples of {Nevery},
including timestep 0. For time-averaged chemical species analysis,
please see the "fix reaxc/c/species"_fix_reaxc_species.html command.
The format of the output file should be reasonably self-explanatory.
The meaning of the column header abbreviations is as follows:
id = atom id
type = atom type
nb = number of bonds
id_1 = atom id of first bond
id_nb = atom id of Nth bond
mol = molecule id
bo_1 = bond order of first bond
bo_nb = bond order of Nth bond
abo = atom bond order (sum of all bonds)
nlp = number of lone pairs
q = atomic charge :ul
If the filename ends with ".gz", the output file is written in gzipped
format. A gzipped dump file will be about 3x smaller than the text
version, but will also take longer to write.
:line
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various "output
commands"_Section_howto.html#howto_15. 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.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section_accelerate"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section_accelerate"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
The fix reax/bonds command requires that the "pair_style
reax"_pair_reax.html be invoked. This fix is part of the REAX
package. It is only enabled if LAMMPS was built with that package,
which also requires the REAX library be built and linked with LAMMPS.
The fix reax/c/bonds command requires that the "pair_style
reax/c"_pair_reaxc.html be invoked. This fix is part of the
USER-REAXC package. It is only enabled if LAMMPS was built with that
package. See the "Making LAMMPS"_Section_start.html#start_3 section
for more info.
To write gzipped bond files, you must compile LAMMPS with the
-DLAMMPS_GZIP option.
[Related commands:]
"pair_style reax"_pair_reax.html, "pair_style
reax/c"_pair_reaxc.html, "fix reax/c/species"_fix_reaxc_species.html
[Default:] none
diff --git a/doc/src/fix_reaxc_species.txt b/doc/src/fix_reaxc_species.txt
index 9a588356e..7c920791f 100644
--- a/doc/src/fix_reaxc_species.txt
+++ b/doc/src/fix_reaxc_species.txt
@@ -1,187 +1,187 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix reax/c/species command :h3
fix reax/c/species/kk command :h3
[Syntax:]
fix ID group-ID reax/c/species Nevery Nrepeat Nfreq filename keyword value ... :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
reax/c/species = style name of this command :l
Nevery = sample bond-order every this many timesteps :l
Nrepeat = # of bond-order samples used for calculating averages :l
Nfreq = calculate average bond-order every this many timesteps :l
filename = name of output file :l
zero or more keyword/value pairs may be appended :l
keyword = {cutoff} or {element} or {position} :l
{cutoff} value = I J Cutoff
I, J = atom types
Cutoff = Bond-order cutoff value for this pair of atom types
{element} value = Element1, Element2, ...
{position} value = posfreq filepos
posfreq = write position files every this many timestep
filepos = name of position output file :pre
:ule
[Examples:]
fix 1 all reax/c/species 10 10 100 species.out
fix 1 all reax/c/species 1 2 20 species.out cutoff 1 1 0.40 cutoff 1 2 0.55
fix 1 all reax/c/species 1 100 100 species.out element Au O H position 1000 AuOH.pos :pre
[Description:]
Write out the chemical species information computed by the ReaxFF
potential specified by "pair_style reax/c"_pair_reaxc.html.
Bond-order values (either averaged or instantaneous, depending on
value of {Nrepeat}) are used to determine chemical bonds. Every
{Nfreq} timesteps, chemical species information is written to
{filename} as a two line output. The first line is a header
containing labels. The second line consists of the following:
timestep, total number of molecules, total number of distinct species,
number of molecules of each species. In this context, "species" means
a unique molecule. The chemical formula of each species is given in
the first line.
If the filename ends with ".gz", the output file is written in gzipped
format. A gzipped dump file will be about 3x smaller than the text version,
but will also take longer to write.
Optional keyword {cutoff} can be assigned to change the minimum
bond-order values used in identifying chemical bonds between pairs of
atoms. Bond-order cutoffs should be carefully chosen, as bond-order
cutoffs that are too small may include too many bonds (which will
result in an error), while cutoffs that are too large will result in
fragmented molecules. The default cutoff of 0.3 usually gives good
results.
The optional keyword {element} can be used to specify the chemical
symbol printed for each LAMMPS atom type. The number of symbols must
match the number of LAMMPS atom types and each symbol must consist of
1 or 2 alphanumeric characters. Normally, these symbols should be
chosen to match the chemical identity of each LAMMPS atom type, as
specified using the "reax/c pair_coeff"_pair_reaxc.html command and
the ReaxFF force field file.
The optional keyword {position} writes center-of-mass positions of
each identified molecules to file {filepos} every {posfreq} timesteps.
The first line contains information on timestep, total number of
molecules, total number of distinct species, and box dimensions. The
second line is a header containing labels. From the third line
downward, each molecule writes a line of output containing the
following information: molecule ID, number of atoms in this molecule,
chemical formula, total charge, and center-of-mass xyz positions of
this molecule. The xyz positions are in fractional coordinates
relative to the box dimensions.
For the keyword {position}, the {filepos} is the name of the output
file. It can contain the wildcard character "*". If the "*"
character appears in {filepos}, then one file per snapshot is written
at {posfreq} and the "*" character is replaced with the timestep
value. For example, AuO.pos.* becomes AuO.pos.0, AuO.pos.1000, etc.
:line
The {Nevery}, {Nrepeat}, and {Nfreq} arguments specify on what
timesteps the bond-order values are sampled to get the average bond
order. The species analysis is performed using the average bond-order
on timesteps that are a multiple of {Nfreq}. The average is over
{Nrepeat} bond-order samples, computed in the preceding portion of the
simulation every {Nevery} timesteps. {Nfreq} must be a multiple of
{Nevery} and {Nevery} must be non-zero even if {Nrepeat} is 1.
Also, the timesteps
contributing to the average bond-order cannot overlap,
i.e. Nrepeat*Nevery can not exceed Nfreq.
For example, if Nevery=2, Nrepeat=6, and Nfreq=100, then bond-order
values on timesteps 90,92,94,96,98,100 will be used to compute the
average bond-order for the species analysis output on timestep 100.
:line
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix.
This fix computes both a global vector of length 2 and a per-atom
vector, either of which can be accessed by various "output
commands"_Section_howto.html#howto_15. The values in the global
vector are "intensive".
The 2 values in the global vector are as follows:
1 = total number of molecules
2 = total number of distinct species :ul
The per-atom vector stores the molecule ID for each atom as identified
by the fix. If an atom is not in a molecule, its ID will be 0.
For atoms in the same molecule, the molecule ID for all of them
will be the same and will be equal to the smallest atom ID of
any atom in the molecule.
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.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section_accelerate"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section_accelerate"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
The fix species currently only works with
"pair_style reax/c"_pair_reaxc.html and it requires that the "pair_style
reax/c"_pair_reaxc.html be invoked. This fix is part of the
USER-REAXC package. It is only enabled if LAMMPS was built with that
package. See the "Making LAMMPS"_Section_start.html#start_3 section
for more info.
To write gzipped species files, you must compile LAMMPS with the
-DLAMMPS_GZIP option.
It should be possible to extend it to other reactive pair_styles (such as
"rebo"_pair_airebo.html, "airebo"_pair_airebo.html,
"comb"_pair_comb.html, and "bop"_pair_bop.html), but this has not yet been done.
[Related commands:]
"pair_style reax/c"_pair_reaxc.html, "fix
reax/bonds"_fix_reax_bonds.html
[Default:]
The default values for bond-order cutoffs are 0.3 for all I-J pairs. The
default element symbols are C, H, O, N. Position files are not written
by default.
diff --git a/doc/src/fix_rigid.txt b/doc/src/fix_rigid.txt
index 87021b855..62969112f 100644
--- a/doc/src/fix_rigid.txt
+++ b/doc/src/fix_rigid.txt
@@ -1,822 +1,822 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix rigid command :h3
fix rigid/nve command :h3
fix rigid/nvt command :h3
fix rigid/npt command :h3
fix rigid/nph command :h3
fix rigid/small command :h3
fix rigid/nve/small command :h3
fix rigid/nvt/small command :h3
fix rigid/npt/small command :h3
fix rigid/nph/small command :h3
[Syntax:]
fix ID group-ID style bodystyle args keyword values ... :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
style = {rigid} or {rigid/nve} or {rigid/nvt} or {rigid/npt} or {rigid/nph} or {rigid/small} or {rigid/nve/small} or {rigid/nvt/small} or {rigid/npt/small} or {rigid/nph/small} :l
bodystyle = {single} or {molecule} or {group} :l
{single} args = none
{molecule} args = none
{group} args = N groupID1 groupID2 ...
N = # of groups
groupID1, groupID2, ... = list of N group IDs :pre
zero or more keyword/value pairs may be appended :l
keyword = {langevin} or {reinit} or {temp} or {iso} or {aniso} or {x} or {y} or {z} or {couple} or {tparam} or {pchain} or {dilate} or {force} or {torque} or {infile} :l
{langevin} values = Tstart Tstop Tperiod seed
Tstart,Tstop = desired temperature at start/stop of run (temperature units)
Tdamp = temperature damping parameter (time units)
seed = random number seed to use for white noise (positive integer)
{reinit} = {yes} or {no}
{temp} values = Tstart Tstop Tdamp
Tstart,Tstop = desired temperature at start/stop of run (temperature units)
Tdamp = temperature damping parameter (time units)
{iso} or {aniso} values = Pstart Pstop Pdamp
Pstart,Pstop = scalar external pressure at start/end of run (pressure units)
Pdamp = pressure damping parameter (time units)
{x} or {y} or {z} values = Pstart Pstop Pdamp
Pstart,Pstop = external stress tensor component at start/end of run (pressure units)
Pdamp = stress damping parameter (time units)
{couple} = {none} or {xyz} or {xy} or {yz} or {xz}
{tparam} values = Tchain Titer Torder
Tchain = length of Nose/Hoover thermostat chain
Titer = number of thermostat iterations performed
Torder = 3 or 5 = Yoshida-Suzuki integration parameters
{pchain} values = Pchain
Pchain = length of the Nose/Hoover thermostat chain coupled with the barostat
{dilate} value = dilate-group-ID
dilate-group-ID = only dilate atoms in this group due to barostat volume changes
{force} values = M xflag yflag zflag
M = which rigid body from 1-Nbody (see asterisk form below)
xflag,yflag,zflag = off/on if component of center-of-mass force is active
{torque} values = M xflag yflag zflag
M = which rigid body from 1-Nbody (see asterisk form below)
xflag,yflag,zflag = off/on if component of center-of-mass torque is active
{infile} filename
filename = file with per-body values of mass, center-of-mass, moments of inertia
{mol} value = template-ID
template-ID = ID of molecule template specified in a separate "molecule"_molecule.html command :pre
:ule
[Examples:]
fix 1 clump rigid single reinit yes
fix 1 clump rigid/small molecule
fix 1 clump rigid single force 1 off off on langevin 1.0 1.0 1.0 428984
fix 1 polychains rigid/nvt molecule temp 1.0 1.0 5.0 reinit no
fix 1 polychains rigid molecule force 1*5 off off off force 6*10 off off on
fix 1 polychains rigid/small molecule langevin 1.0 1.0 1.0 428984
fix 2 fluid rigid group 3 clump1 clump2 clump3 torque * off off off
fix 1 rods rigid/npt molecule temp 300.0 300.0 100.0 iso 0.5 0.5 10.0
fix 1 particles rigid/npt molecule temp 1.0 1.0 5.0 x 0.5 0.5 1.0 z 0.5 0.5 1.0 couple xz
fix 1 water rigid/nph molecule iso 0.5 0.5 1.0
fix 1 particles rigid/npt/small molecule temp 1.0 1.0 1.0 iso 0.5 0.5 1.0 :pre
[Description:]
Treat one or more sets of atoms as independent rigid bodies. This
means that each timestep the total force and torque on each rigid body
is computed as the sum of the forces and torques on its constituent
particles. The coordinates, velocities, and orientations of the atoms
in each body are then updated so that the body moves and rotates as a
single entity. This is implemented by creating internal data structures
for each rigid body and performing time integration on these data
structures. Positions, velocities, and orientations of the constituent
particles are regenerated from the rigid body data structures in every
time step. This restricts which operations and fixes can be applied to
rigid bodies. See below for a detailed discussion.
Examples of large rigid bodies are a colloidal particle, or portions
of a biomolecule such as a protein.
Example of small rigid bodies are patchy nanoparticles, such as those
modeled in "this paper"_#Zhang1 by Sharon Glotzer's group, clumps of
granular particles, lipid molecules consiting of one or more point
dipoles connected to other spheroids or ellipsoids, irregular
particles built from line segments (2d) or triangles (3d), and
coarse-grain models of nano or colloidal particles consisting of a
small number of constituent particles. Note that the "fix
shake"_fix_shake.html command can also be used to rigidify small
molecules of 2, 3, or 4 atoms, e.g. water molecules. That fix treats
the constituent atoms as point masses.
These fixes also update the positions and velocities of the atoms in
each rigid body via time integration, in the NVE, NVT, NPT, or NPH
ensemble, as described below.
There are two main variants of this fix, fix rigid and fix
rigid/small. The NVE/NVT/NPT/NHT versions belong to one of the two
variants, as their style names indicate.
NOTE: Not all of the {bodystyle} options and keyword/value options are
available for both the {rigid} and {rigid/small} variants. See
details below.
The {rigid} styles are typically the best choice for a system with a
small number of large rigid bodies, each of which can extend across
the domain of many processors. It operates by creating a single
global list of rigid bodies, which all processors contribute to.
MPI_Allreduce operations are performed each timestep to sum the
contributions from each processor to the force and torque on all the
bodies. This operation will not scale well in parallel if large
numbers of rigid bodies are simulated.
The {rigid/small} styles are typically best for a system with a large
number of small rigid bodies. Each body is assigned to the atom
closest to the geometrical center of the body. The fix operates using
local lists of rigid bodies owned by each processor and information is
exchanged and summed via local communication between neighboring
processors when ghost atom info is accumulated.
NOTE: To use the {rigid/small} styles the ghost atom cutoff must be
large enough to span the distance between the atom that owns the body
and every other atom in the body. This distance value is printed out
when the rigid bodies are defined. If the
"pair_style"_pair_style.html cutoff plus neighbor skin does not span
this distance, then you should use the "comm_modify
cutoff"_comm_modify.html command with a setting epsilon larger than
the distance.
Which of the two variants is faster for a particular problem is hard
to predict. The best way to decide is to perform a short test run.
Both variants should give identical numerical answers for short runs.
Long runs should give statistically similar results, but round-off
differences may accumulate to produce divergent trajectories.
NOTE: You should not update the atoms in rigid bodies via other
time-integration fixes (e.g. "fix nve"_fix_nve.html, "fix
nvt"_fix_nh.html, "fix npt"_fix_nh.html, "fix move"_fix_move.html),
or you will have conflicting updates to positions and velocities
resulting in unphysical behavior in most cases. When performing a hybrid
simulation with some atoms in rigid bodies, and some not, a separate
time integration fix like "fix nve"_fix_nve.html or "fix
nvt"_fix_nh.html should be used for the non-rigid particles.
NOTE: These fixes are overkill if you simply want to hold a collection
of atoms stationary or have them move with a constant velocity. A
simpler way to hold atoms stationary is to not include those atoms in
your time integration fix. E.g. use "fix 1 mobile nve" instead of
"fix 1 all nve", where "mobile" is the group of atoms that you want to
move. You can move atoms with a constant velocity by assigning them
an initial velocity (via the "velocity"_velocity.html command),
setting the force on them to 0.0 (via the "fix
setforce"_fix_setforce.html command), and integrating them as usual
(e.g. via the "fix nve"_fix_nve.html command).
IMPORTANT NOTE: The aggregate properties of each rigid body are
calculated at the start of a simulation run and are maintained in
internal data structures. The properties include the position and
velocity of the center-of-mass of the body, its moments of inertia, and
its angular momentum. This is done using the properties of the
constituent atoms of the body at that point in time (or see the {infile}
keyword option). Thereafter, changing these properties of individual
atoms in the body will have no effect on a rigid body's dynamics, unless
they effect any computation of per-atom forces or torques. If the
keyword {reinit} is set to {yes} (the default), the rigid body data
structures will be recreated at the beginning of each {run} command;
if the keyword {reinit} is set to {no}, the rigid body data structures
will be built only at the very first {run} command and maintained for
as long as the rigid fix is defined. For example, you might think you
could displace the atoms in a body or add a large velocity to each atom
in a body to make it move in a desired direction before a 2nd run is
performed, using the "set"_set.html or
"displace_atoms"_displace_atoms.html or "velocity"_velocity.html
commands. But these commands will not affect the internal attributes
of the body unless {reinit} is set to {yes}. With {reinit} set to {no}
(or using the {infile} option, which implies {reinit} {no}) the position
and velocity of individual atoms in the body will be reset when time
integration starts again.
:line
Each rigid body must have two or more atoms. An atom can belong to at
most one rigid body. Which atoms are in which bodies can be defined
via several options.
NOTE: With the {rigid/small} styles, which require that {bodystyle} be
specified as {molecule}, you can define a system that has no rigid
bodies initially. This is useful when you are using the {mol} keyword
in conjunction with another fix that is adding rigid bodies on-the-fly
as molecules, such as "fix deposit"_fix_deposit.html or "fix
pour"_fix_pour.html.
For bodystyle {single} the entire fix group of atoms is treated as one
rigid body. This option is only allowed for the {rigid} styles.
For bodystyle {molecule}, atoms are grouped into rigid bodies by their
respective molecule IDs: each set of atoms in the fix group with the
same molecule ID is treated as a different rigid body. This option is
allowed for both the {rigid} and {rigid/small} styles. Note that
atoms with a molecule ID = 0 will be treated as a single rigid body.
For a system with atomic solvent (typically this is atoms with
molecule ID = 0) surrounding rigid bodies, this may not be what you
want. Thus you should be careful to use a fix group that only
includes atoms you want to be part of rigid bodies.
For bodystyle {group}, each of the listed groups is treated as a
separate rigid body. Only atoms that are also in the fix group are
included in each rigid body. This option is only allowed for the
{rigid} styles.
NOTE: To compute the initial center-of-mass position and other
properties of each rigid body, the image flags for each atom in the
body are used to "unwrap" the atom coordinates. Thus you must insure
that these image flags are consistent so that the unwrapping creates a
valid rigid body (one where the atoms are close together),
particularly if the atoms in a single rigid body straddle a periodic
boundary. This means the input data file or restart file must define
the image flags for each atom consistently or that you have used the
"set"_set.html command to specify them correctly. If a dimension is
non-periodic then the image flag of each atom must be 0 in that
dimension, else an error is generated.
The {force} and {torque} keywords discussed next are only allowed for
the {rigid} styles.
By default, each rigid body is acted on by other atoms which induce an
external force and torque on its center of mass, causing it to
translate and rotate. Components of the external center-of-mass force
and torque can be turned off by the {force} and {torque} keywords.
This may be useful if you wish a body to rotate but not translate, or
vice versa, or if you wish it to rotate or translate continuously
unaffected by interactions with other particles. Note that if you
expect a rigid body not to move or rotate by using these keywords, you
must insure its initial center-of-mass translational or angular
velocity is 0.0. Otherwise the initial translational or angular
momentum the body has will persist.
An xflag, yflag, or zflag set to {off} means turn off the component of
force of torque in that dimension. A setting of {on} means turn on
the component, which is the default. Which rigid body(s) the settings
apply to is determined by the first argument of the {force} and
{torque} keywords. It can be an integer M from 1 to Nbody, where
Nbody is the number of rigid bodies defined. A wild-card asterisk can
be used in place of, or in conjunction with, the M argument to set the
flags for multiple rigid bodies. This takes the form "*" or "*n" or
"n*" or "m*n". If N = the number of rigid bodies, then an asterisk
with no numeric values means all bodies from 1 to N. A leading
asterisk means all bodies from 1 to n (inclusive). A trailing
asterisk means all bodies from n to N (inclusive). A middle asterisk
means all types from m to n (inclusive). Note that you can use the
{force} or {torque} keywords as many times as you like. If a
particular rigid body has its component flags set multiple times, the
settings from the final keyword are used.
NOTE: For computational efficiency, you may wish to turn off pairwise
and bond interactions within each rigid body, as they no longer
contribute to the motion. The "neigh_modify
exclude"_neigh_modify.html and "delete_bonds"_delete_bonds.html
commands are used to do this. If the rigid bodies have strongly
overlapping atoms, you may need to turn off these interactions to
avoid numerical problems due to large equal/opposite intra-body forces
swamping the contribution of small inter-body forces.
For computational efficiency, you should typically define one fix
rigid or fix rigid/small command which includes all the desired rigid
bodies. LAMMPS will allow multiple rigid fixes to be defined, but it
is more expensive.
:line
The constituent particles within a rigid body can be point particles
(the default in LAMMPS) or finite-size particles, such as spheres or
ellipsoids or line segments or triangles. See the "atom_style sphere
and ellipsoid and line and tri"_atom_style.html commands for more
details on these kinds of particles. Finite-size particles contribute
differently to the moment of inertia of a rigid body than do point
particles. Finite-size particles can also experience torque (e.g. due
to "frictional granular interactions"_pair_gran.html) and have an
orientation. These contributions are accounted for by these fixes.
Forces between particles within a body do not contribute to the
external force or torque on the body. Thus for computational
efficiency, you may wish to turn off pairwise and bond interactions
between particles within each rigid body. The "neigh_modify
exclude"_neigh_modify.html and "delete_bonds"_delete_bonds.html
commands are used to do this. For finite-size particles this also
means the particles can be highly overlapped when creating the rigid
body.
:line
The {rigid}, {rigid/nve}, {rigid/small}, and {rigid/small/nve} styles
perform constant NVE time integration. They are referred to below as
the 4 NVE rigid styles. The only difference is that the {rigid} and
{rigid/small} styles use an integration technique based on Richardson
iterations. The {rigid/nve} and {rigid/small/nve} styles uses the
methods described in the paper by "Miller"_#Miller3, which are thought
to provide better energy conservation than an iterative approach.
The {rigid/nvt} and {rigid/nvt/small} styles performs constant NVT
integration using a Nose/Hoover thermostat with chains as described
originally in "(Hoover)"_#Hoover and "(Martyna)"_#Martyna2, which
thermostats both the translational and rotational degrees of freedom
of the rigid bodies. They are referred to below as the 2 NVT rigid
styles. The rigid-body algorithm used by {rigid/nvt} is described in
the paper by "Kamberaj"_#Kamberaj.
The {rigid/npt}, {rigid/nph}, {rigid/npt/small}, and {rigid/nph/small}
styles perform constant NPT or NPH integration using a Nose/Hoover
barostat with chains. They are referred to below as the 4 NPT and NPH
rigid styles. For the NPT case, the same Nose/Hoover thermostat is
also used as with {rigid/nvt} and {rigid/nvt/small}.
The barostat parameters are specified using one or more of the {iso},
{aniso}, {x}, {y}, {z} and {couple} keywords. These keywords give you
the ability to specify 3 diagonal components of the external stress
tensor, and to couple these components together so that the dimensions
they represent are varied together during a constant-pressure
simulation. The effects of these keywords are similar to those
defined in "fix npt/nph"_fix_nh.html
NOTE: Currently the {rigid/npt}, {rigid/nph}, {rigid/npt/small}, and
{rigid/nph/small} styles do not support triclinic (non-orthogonal)
boxes.
The target pressures for each of the 6 components of the stress tensor
can be specified independently via the {x}, {y}, {z} keywords, which
correspond to the 3 simulation box dimensions. For each component,
the external pressure or tensor component at each timestep is a ramped
value during the run from {Pstart} to {Pstop}. If a target pressure is
specified for a component, then the corresponding box dimension will
change during a simulation. For example, if the {y} keyword is used,
the y-box length will change. A box dimension will not change if that
component is not specified, although you have the option to change
that dimension via the "fix deform"_fix_deform.html command.
For all barostat keywords, the {Pdamp} parameter operates like the
{Tdamp} parameter, determining the time scale on which pressure is
relaxed. For example, a value of 10.0 means to relax the pressure in
a timespan of (roughly) 10 time units (e.g. tau or fmsec or psec - see
the "units"_units.html command).
Regardless of what atoms are in the fix group (the only atoms which
are time integrated), a global pressure or stress tensor is computed
for all atoms. Similarly, when the size of the simulation box is
changed, all atoms are re-scaled to new positions, unless the keyword
{dilate} is specified with a {dilate-group-ID} for a group that
represents a subset of the atoms. This can be useful, for example, to
leave the coordinates of atoms in a solid substrate unchanged and
controlling the pressure of a surrounding fluid. Another example is a
system consisting of rigid bodies and point particles where the
barostat is only coupled with the rigid bodies. This option should be
used with care, since it can be unphysical to dilate some atoms and
not others, because it can introduce large, instantaneous
displacements between a pair of atoms (one dilated, one not) that are
far from the dilation origin.
The {couple} keyword allows two or three of the diagonal components of
the pressure tensor to be "coupled" together. The value specified
with the keyword determines which are coupled. For example, {xz}
means the {Pxx} and {Pzz} components of the stress tensor are coupled.
{Xyz} means all 3 diagonal components are coupled. Coupling means two
things: the instantaneous stress will be computed as an average of the
corresponding diagonal components, and the coupled box dimensions will
be changed together in lockstep, meaning coupled dimensions will be
dilated or contracted by the same percentage every timestep. The
{Pstart}, {Pstop}, {Pdamp} parameters for any coupled dimensions must
be identical. {Couple xyz} can be used for a 2d simulation; the {z}
dimension is simply ignored.
The {iso} and {aniso} keywords are simply shortcuts that are
equivalent to specifying several other keywords together.
The keyword {iso} means couple all 3 diagonal components together when
pressure is computed (hydrostatic pressure), and dilate/contract the
dimensions together. Using "iso Pstart Pstop Pdamp" is the same as
specifying these 4 keywords:
x Pstart Pstop Pdamp
y Pstart Pstop Pdamp
z Pstart Pstop Pdamp
couple xyz :pre
The keyword {aniso} means {x}, {y}, and {z} dimensions are controlled
independently using the {Pxx}, {Pyy}, and {Pzz} components of the
stress tensor as the driving forces, and the specified scalar external
pressure. Using "aniso Pstart Pstop Pdamp" is the same as specifying
these 4 keywords:
x Pstart Pstop Pdamp
y Pstart Pstop Pdamp
z Pstart Pstop Pdamp
couple none :pre
:line
The keyword/value option pairs are used in the following ways.
The {reinit} keyword determines, whether the rigid body properties
are reinitialized between run commands. With the option {yes} (the
default) this is done, with the option {no} this is not done. Turning
off the reinitialization can be helpful to protect rigid bodies against
unphysical manipulations between runs or when properties cannot be
easily recomputed (e.g. when read from a file). When using the {infile}
keyword, the {reinit} option is automatically set to {no}.
The {langevin} and {temp} and {tparam} keywords perform thermostatting
of the rigid bodies, altering both their translational and rotational
degrees of freedom. What is meant by "temperature" of a collection of
rigid bodies and how it can be monitored via the fix output is
discussed below.
The {langevin} keyword applies a Langevin thermostat to the constant
NVE time integration performed by any of the 4 NVE rigid styles:
{rigid}, {rigid/nve}, {rigid/small}, {rigid/small/nve}. It cannot be
used with the 2 NVT rigid styles: {rigid/nvt}, {rigid/small/nvt}. The
desired temperature at each timestep is a ramped value during the run
from {Tstart} to {Tstop}. The {Tdamp} parameter is specified in time
units and determines how rapidly the temperature is relaxed. For
example, a value of 100.0 means to relax the temperature in a timespan
of (roughly) 100 time units (tau or fmsec or psec - see the
"units"_units.html command). The random # {seed} must be a positive
integer.
The way that Langevin thermostatting operates is explained on the "fix
langevin"_fix_langevin.html doc page. If you wish to simply viscously
damp the rotational motion without thermostatting, you can set
{Tstart} and {Tstop} to 0.0, which means only the viscous drag term in
the Langevin thermostat will be applied. See the discussion on the
"fix viscous"_fix_viscous.html doc page for details.
NOTE: When the {langevin} keyword is used with fix rigid versus fix
rigid/small, different dynamics will result for parallel runs. This
is because of the way random numbers are used in the two cases. The
dynamics for the two cases should be statistically similar, but will
not be identical, even for a single timestep.
The {temp} and {tparam} keywords apply a Nose/Hoover thermostat to the
NVT time integration performed by the 2 NVT rigid styles. They cannot
be used with the 4 NVE rigid styles. The desired temperature at each
timestep is a ramped value during the run from {Tstart} to {Tstop}.
The {Tdamp} parameter is specified in time units and determines how
rapidly the temperature is relaxed. For example, a value of 100.0
means to relax the temperature in a timespan of (roughly) 100 time
units (tau or fmsec or psec - see the "units"_units.html command).
Nose/Hoover chains are used in conjunction with this thermostat. The
{tparam} keyword can optionally be used to change the chain settings
used. {Tchain} is the number of thermostats in the Nose Hoover chain.
This value, along with {Tdamp} can be varied to dampen undesirable
oscillations in temperature that can occur in a simulation. As a rule
of thumb, increasing the chain length should lead to smaller
oscillations. The keyword {pchain} specifies the number of
thermostats in the chain thermostatting the barostat degrees of
freedom.
NOTE: There are alternate ways to thermostat a system of rigid bodies.
You can use "fix langevin"_fix_langevin.html to treat the individual
particles in the rigid bodies as effectively immersed in an implicit
solvent, e.g. a Brownian dynamics model. For hybrid systems with both
rigid bodies and solvent particles, you can thermostat only the
solvent particles that surround one or more rigid bodies by
appropriate choice of groups in the compute and fix commands for
temperature and thermostatting. The solvent interactions with the
rigid bodies should then effectively thermostat the rigid body
temperature as well without use of the Langevin or Nose/Hoover options
associated with the fix rigid commands.
:line
The {mol} keyword can only be used with the {rigid/small} styles. It
must be used when other commands, such as "fix
deposit"_fix_deposit.html or "fix pour"_fix_pour.html, add rigid
bodies on-the-fly during a simulation. You specify a {template-ID}
previously defined using the "molecule"_molecule.html command, which
reads a file that defines the molecule. You must use the same
{template-ID} that the other fix which is adding rigid bodies uses.
The coordinates, atom types, atom diameters, center-of-mass, and
moments of inertia can be specified in the molecule file. See the
"molecule"_molecule.html command for details. The only settings
required to be in this file are the coordinates and types of atoms in
the molecule, in which case the molecule command calculates the other
quantities itself.
Note that these other fixes create new rigid bodies, in addition to
those defined initially by this fix via the {bodystyle} setting.
Also note that when using the {mol} keyword, extra restart information
about all rigid bodies is written out whenever a restart file is
written out. See the NOTE in the next section for details.
:line
The {infile} keyword allows a file of rigid body attributes to be read
in from a file, rather then having LAMMPS compute them. There are 5
such attributes: the total mass of the rigid body, its center-of-mass
position, its 6 moments of inertia, its center-of-mass velocity, and
the 3 image flags of the center-of-mass position. For rigid bodies
consisting of point particles or non-overlapping finite-size
particles, LAMMPS can compute these values accurately. However, for
rigid bodies consisting of finite-size particles which overlap each
other, LAMMPS will ignore the overlaps when computing these 4
attributes. The amount of error this induces depends on the amount of
overlap. To avoid this issue, the values can be pre-computed
(e.g. using Monte Carlo integration).
The format of the file is as follows. Note that the file does not
have to list attributes for every rigid body integrated by fix rigid.
Only bodies which the file specifies will have their computed
attributes overridden. The file can contain initial blank lines or
comment lines starting with "#" which are ignored. The first
non-blank, non-comment line should list N = the number of lines to
follow. The N successive lines contain the following information:
ID1 masstotal xcm ycm zcm ixx iyy izz ixy ixz iyz vxcm vycm vzcm lx ly lz ixcm iycm izcm
ID2 masstotal xcm ycm zcm ixx iyy izz ixy ixz iyz vxcm vycm vzcm lx ly lz ixcm iycm izcm
...
IDN masstotal xcm ycm zcm ixx iyy izz ixy ixz iyz vxcm vycm vzcm lx ly lz ixcm iycm izcm :pre
The rigid body IDs are all positive integers. For the {single}
bodystyle, only an ID of 1 can be used. For the {group} bodystyle,
IDs from 1 to Ng can be used where Ng is the number of specified
groups. For the {molecule} bodystyle, use the molecule ID for the
atoms in a specific rigid body as the rigid body ID.
The masstotal and center-of-mass coordinates (xcm,ycm,zcm) are
self-explanatory. The center-of-mass should be consistent with what
is calculated for the position of the rigid body with all its atoms
unwrapped by their respective image flags. If this produces a
center-of-mass that is outside the simulation box, LAMMPS wraps it
back into the box.
The 6 moments of inertia (ixx,iyy,izz,ixy,ixz,iyz) should be the
values consistent with the current orientation of the rigid body
around its center of mass. The values are with respect to the
simulation box XYZ axes, not with respect to the principal axes of the
rigid body itself. LAMMPS performs the latter calculation internally.
The (vxcm,vycm,vzcm) values are the velocity of the center of mass.
The (lx,ly,lz) values are the angular momentum of the body. The
(vxcm,vycm,vzcm) and (lx,ly,lz) values can simply be set to 0 if you
wish the body to have no initial motion.
The (ixcm,iycm,izcm) values are the image flags of the center of mass
of the body. For periodic dimensions, they specify which image of the
simulation box the body is considered to be in. An image of 0 means
it is inside the box as defined. A value of 2 means add 2 box lengths
to get the true value. A value of -1 means subtract 1 box length to
get the true value. LAMMPS updates these flags as the rigid bodies
cross periodic boundaries during the simulation.
NOTE: If you use the {infile} or {mol} keywords and write restart
files during a simulation, then each time a restart file is written,
the fix also write an auxiliary restart file with the name
rfile.rigid, where "rfile" is the name of the restart file,
e.g. tmp.restart.10000 and tmp.restart.10000.rigid. This auxiliary
file is in the same format described above. Thus it can be used in a
new input script that restarts the run and re-specifies a rigid fix
using an {infile} keyword and the appropriate filename. Note that the
auxiliary file will contain one line for every rigid body, even if the
original file only listed a subset of the rigid bodies.
:line
If you use a "temperature compute"_compute.html with a group that
includes particles in rigid bodies, the degrees-of-freedom removed by
each rigid body are accounted for in the temperature (and pressure)
computation, but only if the temperature group includes all the
particles in a particular rigid body.
A 3d rigid body has 6 degrees of freedom (3 translational, 3
rotational), except for a collection of point particles lying on a
straight line, which has only 5, e.g a dimer. A 2d rigid body has 3
degrees of freedom (2 translational, 1 rotational).
NOTE: You may wish to explicitly subtract additional
degrees-of-freedom if you use the {force} and {torque} keywords to
eliminate certain motions of one or more rigid bodies. LAMMPS does
not do this automatically.
The rigid body contribution to the pressure of the system (virial) is
also accounted for by this fix.
:line
If your simulation is a hybrid model with a mixture of rigid bodies
and non-rigid particles (e.g. solvent) there are several ways these
rigid fixes can be used in tandem with "fix nve"_fix_nve.html, "fix
nvt"_fix_nh.html, "fix npt"_fix_nh.html, and "fix nph"_fix_nh.html.
If you wish to perform NVE dynamics (no thermostatting or
barostatting), use one of 4 NVE rigid styles to integrate the rigid
bodies, and "fix nve"_fix_nve.html to integrate the non-rigid
particles.
If you wish to perform NVT dynamics (thermostatting, but no
barostatting), you can use one of the 2 NVT rigid styles for the rigid
bodies, and any thermostatting fix for the non-rigid particles ("fix
nvt"_fix_nh.html, "fix langevin"_fix_langevin.html, "fix
temp/berendsen"_fix_temp_berendsen.html). You can also use one of the
4 NVE rigid styles for the rigid bodies and thermostat them using "fix
langevin"_fix_langevin.html on the group that contains all the
particles in the rigid bodies. The net force added by "fix
langevin"_fix_langevin.html to each rigid body effectively thermostats
its translational center-of-mass motion. Not sure how well it does at
thermostatting its rotational motion.
If you with to perform NPT or NPH dynamics (barostatting), you cannot
use both "fix npt"_fix_nh.html and the NPT or NPH rigid styles. This
is because there can only be one fix which monitors the global
pressure and changes the simulation box dimensions. So you have 3
choices:
Use one of the 4 NPT or NPH styles for the rigid bodies. Use the
{dilate} all option so that it will dilate the positions of the
non-rigid particles as well. Use "fix nvt"_fix_nh.html (or any other
thermostat) for the non-rigid particles. :ulb,l
Use "fix npt"_fix_nh.html for the group of non-rigid particles. Use
the {dilate} all option so that it will dilate the center-of-mass
positions of the rigid bodies as well. Use one of the 4 NVE or 2 NVT
rigid styles for the rigid bodies. :l
Use "fix press/berendsen"_fix_press_berendsen.html to compute the
pressure and change the box dimensions. Use one of the 4 NVE or 2 NVT
rigid styles for the rigid bodies. Use "fix nvt"_fix_nh.html (or any
other thermostat) for the non-rigid particles. :l
:ule
In all case, the rigid bodies and non-rigid particles both contribute
to the global pressure and the box is scaled the same by any of the
barostatting fixes.
You could even use the 2nd and 3rd options for a non-hybrid simulation
consisting of only rigid bodies, assuming you give "fix
npt"_fix_nh.html an empty group, though it's an odd thing to do. The
barostatting fixes ("fix npt"_fix_nh.html and "fix
press/berensen"_fix_press_berendsen.html) will monitor the pressure
and change the box dimensions, but not time integrate any particles.
The integration of the rigid bodies will be performed by fix
rigid/nvt.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about the 4 NVE rigid styles is written to "binary
restart files"_restart.html. The exception is if the {infile} or
{mol} keyword is used, in which case an auxiliary file is written out
with rigid body information each time a restart file is written, as
explained above for the {infile} keyword. For the 2 NVT rigid styles,
the state of the Nose/Hoover thermostat is written to "binary restart
files"_restart.html. Ditto for the 4 NPT and NPH rigid styles, and
the state of the Nose/Hoover barostat. See the
"read_restart"_read_restart.html command for info on how to re-specify
a fix in an input script that reads a restart file, so that the
operation of the fix continues in an uninterrupted fashion.
The "fix_modify"_fix_modify.html {energy} option is supported by the 6
NVT, NPT, NPH rigid styles to add the energy change induced by the
thermostatting to the system's potential energy as part of
"thermodynamic output"_thermo_style.html.
The "fix_modify"_fix_modify.html {temp} and {press} options are
supported by the 4 NPT and NPH rigid styles to change the computes
used to calculate the instantaneous pressure tensor. Note that the 2
NVT rigid fixes do not use any external compute to compute
instantaneous temperature.
The 2 NVE rigid fixes compute a global scalar which can be accessed by
various "output commands"_Section_howto.html#howto_15. The scalar
value calculated by these fixes is "intensive". The scalar is the
current temperature of the collection of rigid bodies. This is
averaged over all rigid bodies and their translational and rotational
degrees of freedom. The translational energy of a rigid body is 1/2 m
v^2, where m = total mass of the body and v = the velocity of its
center of mass. The rotational energy of a rigid body is 1/2 I w^2,
where I = the moment of inertia tensor of the body and w = its angular
velocity. Degrees of freedom constrained by the {force} and {torque}
keywords are removed from this calculation, but only for the {rigid}
and {rigid/nve} fixes.
The 6 NVT, NPT, NPH rigid fixes compute a global scalar which can be
accessed by various "output commands"_Section_howto.html#howto_15.
The scalar value calculated by these fixes is "extensive". The scalar
is the cumulative energy change due to the thermostatting and
barostatting the fix performs.
All of the {rigid} styles (not the {rigid/small} styles) compute a
global array of values which can be accessed by various "output
commands"_Section_howto.html#howto_15. Similar information about the
bodies defined by the {rigid/small} styles can be accessed via the
"compute rigid/local"_compute_rigid_local.html command.
The number of rows in the array is equal to the number of rigid
bodies. The number of columns is 15. Thus for each rigid body, 15
values are stored: the xyz coords of the center of mass (COM), the xyz
components of the COM velocity, the xyz components of the force acting
on the COM, the xyz components of the torque acting on the COM, and
the xyz image flags of the COM.
The center of mass (COM) for each body is similar to unwrapped
coordinates written to a dump file. It will always be inside (or
slightly outside) the simulation box. The image flags have the same
meaning as image flags for atom positions (see the "dump" command).
This means you can calculate the unwrapped COM by applying the image
flags to the COM, the same as when unwrapped coordinates are written
to a dump file.
The force and torque values in the array are not affected by the
{force} and {torque} keywords in the fix rigid command; they reflect
values before any changes are made by those keywords.
The ordering of the rigid bodies (by row in the array) is as follows.
For the {single} keyword there is just one rigid body. For the
{molecule} keyword, the bodies are ordered by ascending molecule ID.
For the {group} keyword, the list of group IDs determines the ordering
of bodies.
The array values calculated by these fixes are "intensive", meaning
they are independent of the number of atoms in the simulation.
No parameter of these fixes can be used with the {start/stop} keywords
of the "run"_run.html command. These fixes are not invoked during
"energy minimization"_minimize.html.
:line
[Restrictions:]
These fixes are all part of the RIGID package. It is only enabled if
LAMMPS was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
Assigning a temperature via the "velocity create"_velocity.html
command to a system with "rigid bodies"_fix_rigid.html may not have
the desired outcome for two reasons. First, the velocity command can
be invoked before the rigid-body fix is invoked or initialized and the
number of adjusted degrees of freedom (DOFs) is known. Thus it is not
possible to compute the target temperature correctly. Second, the
assigned velocities may be partially canceled when constraints are
first enforced, leading to a different temperature than desired. A
workaround for this is to perform a "run 0"_run.html command, which
insures all DOFs are accounted for properly, and then rescale the
temperature to the desired value before performing a simulation. For
example:
velocity all create 300.0 12345
run 0 # temperature may not be 300K
velocity all scale 300.0 # now it should be :pre
[Related commands:]
"delete_bonds"_delete_bonds.html, "neigh_modify"_neigh_modify.html
exclude, "fix shake"_fix_shake.html
[Default:]
The option defaults are force * on on on and torque * on on on,
meaning all rigid bodies are acted on by center-of-mass force and
torque. Also Tchain = Pchain = 10, Titer = 1, Torder = 3, reinit = yes.
:line
:link(Hoover)
[(Hoover)] Hoover, Phys Rev A, 31, 1695 (1985).
:link(Kamberaj)
[(Kamberaj)] Kamberaj, Low, Neal, J Chem Phys, 122, 224114 (2005).
:link(Martyna2)
[(Martyna)] Martyna, Klein, Tuckerman, J Chem Phys, 97, 2635 (1992);
Martyna, Tuckerman, Tobias, Klein, Mol Phys, 87, 1117.
:link(Miller3)
[(Miller)] Miller, Eleftheriou, Pattnaik, Ndirango, and Newns,
J Chem Phys, 116, 8649 (2002).
:link(Zhang1)
[(Zhang)] Zhang, Glotzer, Nanoletters, 4, 1407-1413 (2004).
diff --git a/doc/src/fix_setforce.txt b/doc/src/fix_setforce.txt
index 90766fc5b..f5be0f93a 100644
--- a/doc/src/fix_setforce.txt
+++ b/doc/src/fix_setforce.txt
@@ -1,126 +1,126 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix setforce command :h3
fix setforce/kk command :h3
[Syntax:]
fix ID group-ID setforce fx fy fz keyword value ... :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
setforce = style name of this fix command :l
fx,fy,fz = force component values :l
any of fx,fy,fz can be a variable (see below) :l
zero or more keyword/value pairs may be appended to args :l
keyword = {region} :l
{region} value = region-ID
region-ID = ID of region atoms must be in to have added force :pre
:ule
[Examples:]
fix freeze indenter setforce 0.0 0.0 0.0
fix 2 edge setforce NULL 0.0 0.0
fix 2 edge setforce NULL 0.0 v_oscillate :pre
[Description:]
Set each component of force on each atom in the group to the specified
values fx,fy,fz. This erases all previously computed forces on the
atom, though additional fixes could add new forces. This command can
be used to freeze certain atoms in the simulation by zeroing their
force, either for running dynamics or performing an energy
minimization. For dynamics, this assumes their initial velocity is
also zero.
Any of the fx,fy,fz values can be specified as NULL which means do not
alter the force component in that dimension.
Any of the 3 quantities defining the force components can be specified
as an equal-style or atom-style "variable"_variable.html, namely {fx},
{fy}, {fz}. If the value is a variable, it should be specified as
v_name, where name is the variable name. In this case, the variable
will be evaluated each timestep, and its value used to determine the
force component.
Equal-style variables can specify formulas with various mathematical
functions, and include "thermo_style"_thermo_style.html command
keywords for the simulation box parameters and timestep and elapsed
time. Thus it is easy to specify a time-dependent force field.
Atom-style variables can specify the same formulas as equal-style
variables but can also include per-atom values, such as atom
coordinates. Thus it is easy to specify a spatially-dependent force
field with optional time-dependence as well.
If the {region} keyword is used, the atom must also be in the
specified geometric "region"_region.html in order to have force added
to it.
:line
Styles with a r {kk} suffix are functionally the same as the
corresponding style without the suffix. They have been optimized to
run faster, depending on your available hardware, as discussed in
"Section 5"_Section_accelerate.html of the manual. The
accelerated styles take the same arguments and should produce the same
results, except for round-off and precision issues.
The region keyword is also supported by Kokkos, but a Kokkos-enabled
region must be used. See the region "region"_region.html command for
more information.
These accelerated styles are part of the r Kokkos package. They are
only enabled if LAMMPS was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html.
The "fix_modify"_fix_modify.html {respa} option is supported by
this fix. This allows to set at which level of the "r-RESPA"_run_style.html
integrator the fix is setting the forces to the desired values; on all
other levels, the force is set to 0.0 for the atoms in the fix group,
so that setforce values are not counted multiple times. Default is to
to override forces at the outermost level.
This fix computes a global 3-vector of forces, which can be accessed
by various "output commands"_Section_howto.html#howto_15. This is the
total force on the group of atoms before the forces on individual
atoms are changed by the fix. The vector values calculated by this
fix are "extensive".
No parameter of this fix can be used with the {start/stop} keywords of
the "run"_run.html command.
The forces due to this fix are imposed during an energy minimization,
invoked by the "minimize"_minimize.html command, but you cannot set
forces to any value besides zero when performing a minimization. Use
the "fix addforce"_fix_addforce.html command if you want to apply a
non-zero force to atoms during a minimization.
[Restrictions:] none
[Related commands:]
"fix addforce"_fix_addforce.html, "fix aveforce"_fix_aveforce.html
[Default:] none
diff --git a/doc/src/fix_shake.txt b/doc/src/fix_shake.txt
index 8b26aaa87..c187b17c6 100644
--- a/doc/src/fix_shake.txt
+++ b/doc/src/fix_shake.txt
@@ -1,227 +1,227 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix shake command :h3
fix rattle command :h3
[Syntax:]
fix ID group-ID style tol iter N constraint values ... keyword value ... :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
style = shake or rattle = style name of this fix command :l
tol = accuracy tolerance of SHAKE solution :l
iter = max # of iterations in each SHAKE solution :l
N = print SHAKE statistics every this many timesteps (0 = never) :l
one or more constraint/value pairs are appended :l
constraint = {b} or {a} or {t} or {m} :l
{b} values = one or more bond types
{a} values = one or more angle types
{t} values = one or more atom types
{m} value = one or more mass values :pre
zero or more keyword/value pairs may be appended :l
keyword = {mol} :l
{mol} value = template-ID
template-ID = ID of molecule template specified in a separate "molecule"_molecule.html command :pre
:ule
[Examples:]
fix 1 sub shake 0.0001 20 10 b 4 19 a 3 5 2
fix 1 sub shake 0.0001 20 10 t 5 6 m 1.0 a 31
fix 1 sub shake 0.0001 20 10 t 5 6 m 1.0 a 31 mol myMol
fix 1 sub rattle 0.0001 20 10 t 5 6 m 1.0 a 31
fix 1 sub rattle 0.0001 20 10 t 5 6 m 1.0 a 31 mol myMol :pre
[Description:]
Apply bond and angle constraints to specified bonds and angles in the
simulation by either the SHAKE or RATTLE algorithms. This typically
enables a longer timestep.
[SHAKE vs RATTLE:]
The SHAKE algorithm was invented for schemes such as standard Verlet
timestepping, where only the coordinates are integrated and the
velocities are approximated as finite differences to the trajectories
("Ryckaert et al. (1977)"_#Ryckaert). If the velocities are
integrated explicitly, as with velocity Verlet which is what LAMMPS
uses as an integration method, a second set of constraining forces is
required in order to eliminate velocity components along the bonds
("Andersen (1983)"_#Andersen3).
In order to formulate individual constraints for SHAKE and RATTLE,
focus on a single molecule whose bonds are constrained. Let Ri and Vi
be the position and velocity of atom {i} at time {n}, for
{i}=1,...,{N}, where {N} is the number of sites of our reference
molecule. The distance vector between sites {i} and {j} is given by
:c,image(Eqs/fix_rattle_rij.jpg)
The constraints can then be formulated as
:c,image(Eqs/fix_rattle_constraints.jpg)
The SHAKE algorithm satisfies the first condition, i.e. the sites at
time {n+1} will have the desired separations Dij immediately after the
coordinates are integrated. If we also enforce the second condition,
the velocity components along the bonds will vanish. RATTLE satisfies
both conditions. As implemented in LAMMPS, fix rattle uses fix shake
for satisfying the coordinate constraints. Therefore the settings and
optional keywords are the same for both fixes, and all the information
below about SHAKE is also relevant for RATTLE.
[SHAKE:]
Each timestep the specified bonds and angles are reset to their
equilibrium lengths and angular values via the SHAKE algorithm
("Ryckaert et al. (1977)"_#Ryckaert). This is done by applying an
additional constraint force so that the new positions preserve the
desired atom separations. The equations for the additional force are
solved via an iterative method that typically converges to an accurate
solution in a few iterations. The desired tolerance (e.g. 1.0e-4 = 1
part in 10000) and maximum # of iterations are specified as arguments.
Setting the N argument will print statistics to the screen and log
file about regarding the lengths of bonds and angles that are being
constrained. Small delta values mean SHAKE is doing a good job.
In LAMMPS, only small clusters of atoms can be constrained. This is
so the constraint calculation for a cluster can be performed by a
single processor, to enable good parallel performance. A cluster is
defined as a central atom connected to others in the cluster by
constrained bonds. LAMMPS allows for the following kinds of clusters
to be constrained: one central atom bonded to 1 or 2 or 3 atoms, or
one central atom bonded to 2 others and the angle between the 3 atoms
also constrained. This means water molecules or CH2 or CH3 groups may
be constrained, but not all the C-C backbone bonds of a long polymer
chain.
The {b} constraint lists bond types that will be constrained. The {t}
constraint lists atom types. All bonds connected to an atom of the
specified type will be constrained. The {m} constraint lists atom
masses. All bonds connected to atoms of the specified masses will be
constrained (within a fudge factor of MASSDELTA specified in
fix_shake.cpp). The {a} constraint lists angle types. If both bonds
in the angle are constrained then the angle will also be constrained
if its type is in the list.
For all constraints, a particular bond is only constrained if both
atoms in the bond are in the group specified with the SHAKE fix.
The degrees-of-freedom removed by SHAKE bonds and angles are accounted
for in temperature and pressure computations. Similarly, the SHAKE
contribution to the pressure of the system (virial) is also accounted
for.
NOTE: This command works by using the current forces on atoms to
calculate an additional constraint force which when added will leave
the atoms in positions that satisfy the SHAKE constraints (e.g. bond
length) after the next time integration step. If you define fixes
(e.g. "fix efield"_fix_efield.html) that add additional force to the
atoms after fix shake operates, then this fix will not take them into
account and the time integration will typically not satisfy the SHAKE
constraints. The solution for this is to make sure that fix shake is
defined in your input script after any other fixes which add or change
forces (to atoms that fix shake operates on).
:line
The {mol} keyword should be used when other commands, such as "fix
deposit"_fix_deposit.html or "fix pour"_fix_pour.html, add molecules
on-the-fly during a simulation, and you wish to constrain the new
molecules via SHAKE. You specify a {template-ID} previously defined
using the "molecule"_molecule.html command, which reads a file that
defines the molecule. You must use the same {template-ID} that the
command adding molecules uses. The coordinates, atom types, special
bond restrictions, and SHAKE info can be specified in the molecule
file. See the "molecule"_molecule.html command for details. The only
settings required to be in this file (by this command) are the SHAKE
info of atoms in the molecule.
:line
Styles with a suffix are functionally the same as the corresponding
style without the suffix. They have been optimized to run faster,
depending on your available hardware, as discussed in
"Section 5"_Section_accelerate.html of the manual. The
accelerated styles take the same arguments and should produce the same
results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[RATTLE:]
The velocity constraints lead to a linear system of equations which
can be solved analytically. The implementation of the algorithm in
LAMMPS closely follows ("Andersen (1983)"_#Andersen3).
NOTE: The fix rattle command modifies forces and velocities and thus
should be defined after all other integration fixes in your input
script. If you define other fixes that modify velocities or forces
after fix rattle operates, then fix rattle will not take them into
account and the overall time integration will typically not satisfy
the RATTLE constraints. You can check whether the constraints work
correctly by setting the value of RATTLE_DEBUG in src/fix_rattle.cpp
to 1 and recompiling LAMMPS.
:line
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about these fixes is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to these fixes. No global or per-atom quantities are
stored by these fixes for access by various "output
commands"_Section_howto.html#howto_15. No parameter of these fixes
can be used with the {start/stop} keywords of the "run"_run.html
command. These fixes are not invoked during "energy
minimization"_minimize.html.
[Restrictions:]
These fixes are part of the RIGID package. They are only enabled if
LAMMPS was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
For computational efficiency, there can only be one shake or rattle
fix defined in a simulation.
If you use a tolerance that is too large or a max-iteration count that
is too small, the constraints will not be enforced very strongly,
which can lead to poor energy conservation. You can test for this in
your system by running a constant NVE simulation with a particular set
of SHAKE parameters and monitoring the energy versus time.
SHAKE or RATTLE should not be used to constrain an angle at 180 degrees
(e.g. linear CO2 molecule). This causes numeric difficulties.
[Related commands:] none
[Default:] none
:line
:link(Ryckaert)
[(Ryckaert)] J.-P. Ryckaert, G. Ciccotti and H. J. C. Berendsen,
J of Comp Phys, 23, 327-341 (1977).
:link(Andersen3)
[(Andersen)] H. Andersen, J of Comp Phys, 52, 24-34 (1983).
diff --git a/doc/src/fix_wall_reflect.txt b/doc/src/fix_wall_reflect.txt
index 5b425316e..954ec65bf 100644
--- a/doc/src/fix_wall_reflect.txt
+++ b/doc/src/fix_wall_reflect.txt
@@ -1,184 +1,184 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
fix wall/reflect command :h3
fix wall/reflect/kk command :h3
[Syntax:]
fix ID group-ID wall/reflect face arg ... keyword value ... :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
wall/reflect = style name of this fix command :l
one or more face/arg pairs may be appended :l
face = {xlo} or {xhi} or {ylo} or {yhi} or {zlo} or {zhi} :l
{xlo},{ylo},{zlo} arg = EDGE or constant or variable
EDGE = current lo edge of simulation box
constant = number like 0.0 or -30.0 (distance units)
variable = "equal-style variable"_variable.html like v_x or v_wiggle
{xhi},{yhi},{zhi} arg = EDGE or constant or variable
EDGE = current hi edge of simulation box
constant = number like 50.0 or 100.3 (distance units)
variable = "equal-style variable"_variable.html like v_x or v_wiggle :pre
zero or more keyword/value pairs may be appended :l
keyword = {units} :l
{units} value = {lattice} or {box}
{lattice} = the wall position is defined in lattice units
{box} = the wall position is defined in simulation box units :pre
:ule
[Examples:]
fix xwalls all wall/reflect xlo EDGE xhi EDGE
fix walls all wall/reflect xlo 0.0 ylo 10.0 units box
fix top all wall/reflect zhi v_pressdown :pre
[Description:]
Bound the simulation with one or more walls which reflect particles
in the specified group when they attempt to move thru them.
Reflection means that if an atom moves outside the wall on a timestep
by a distance delta (e.g. due to "fix nve"_fix_nve.html), then it is
put back inside the face by the same delta, and the sign of the
corresponding component of its velocity is flipped.
When used in conjunction with "fix nve"_fix_nve.html and "run_style
verlet"_run_style.html, the resultant time-integration algorithm is
equivalent to the primitive splitting algorithm (PSA) described by
"Bond"_#Bond. Because each reflection event divides
the corresponding timestep asymmetrically, energy conservation is only
satisfied to O(dt), rather than to O(dt^2) as it would be for
velocity-Verlet integration without reflective walls.
Up to 6 walls or faces can be specified in a single command: {xlo},
{xhi}, {ylo}, {yhi}, {zlo}, {zhi}. A {lo} face reflects particles
that move to a coordinate less than the wall position, back in the
{hi} direction. A {hi} face reflects particles that move to a
coordinate higher than the wall position, back in the {lo} direction.
The position of each wall can be specified in one of 3 ways: as the
EDGE of the simulation box, as a constant value, or as a variable. If
EDGE is used, then the corresponding boundary of the current
simulation box is used. If a numeric constant is specified then the
wall is placed at that position in the appropriate dimension (x, y, or
z). In both the EDGE and constant cases, the wall will never move.
If the wall position is a variable, it should be specified as v_name,
where name is an "equal-style variable"_variable.html name. In this
case the variable is evaluated each timestep and the result becomes
the current position of the reflecting wall. Equal-style variables
can specify formulas with various mathematical functions, and include
"thermo_style"_thermo_style.html command keywords for the simulation
box parameters and timestep and elapsed time. Thus it is easy to
specify a time-dependent wall position.
The {units} keyword determines the meaning of the distance units used
to define a wall position, but only when a numeric constant or
variable is used. It is not relevant when EDGE is used to specify a
face position. In the variable case, the variable is assumed to
produce a value compatible with the {units} setting you specify.
A {box} value selects standard distance units as defined by the
"units"_units.html command, e.g. Angstroms for units = real or metal.
A {lattice} value means the distance units are in lattice spacings.
The "lattice"_lattice.html command must have been previously used to
define the lattice spacings.
:line
Here are examples of variable definitions that move the wall position
in a time-dependent fashion using equal-style
"variables"_variable.html.
variable ramp equal ramp(0,10)
fix 1 all wall/reflect xlo v_ramp :pre
variable linear equal vdisplace(0,20)
fix 1 all wall/reflect xlo v_linear :pre
variable wiggle equal swiggle(0.0,5.0,3.0)
fix 1 all wall/reflect xlo v_wiggle :pre
variable wiggle equal cwiggle(0.0,5.0,3.0)
fix 1 all wall/reflect xlo v_wiggle :pre
The ramp(lo,hi) function adjusts the wall position linearly from lo to
hi over the course of a run. The vdisplace(c0,velocity) function does
something similar using the equation position = c0 + velocity*delta,
where delta is the elapsed time.
The swiggle(c0,A,period) function causes the wall position to
oscillate sinusoidally according to this equation, where omega = 2 PI
/ period:
position = c0 + A sin(omega*delta) :pre
The cwiggle(c0,A,period) function causes the wall position to
oscillate sinusoidally according to this equation, which will have an
initial wall velocity of 0.0, and thus may impose a gentler
perturbation on the particles:
position = c0 + A (1 - cos(omega*delta)) :pre
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restart, fix_modify, output, run start/stop, minimize info:]
No information about this fix is written to "binary restart
files"_restart.html. None of the "fix_modify"_fix_modify.html options
are relevant to this fix. No global or per-atom quantities are stored
by this fix for access by various "output
commands"_Section_howto.html#howto_15. 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.
[Restrictions:]
Any dimension (xyz) that has a reflecting wall must be non-periodic.
A reflecting wall should not be used with rigid bodies such as those
defined by a "fix rigid" command. This is because the wall/reflect
displaces atoms directly rather than exerts a force on them. For
rigid bodies, use a soft wall instead, such as "fix
wall/lj93"_fix_wall.html. LAMMPS will flag the use of a rigid
fix with fix wall/reflect with a warning, but will not generate an
error.
[Related commands:]
"fix wall/lj93"_fix_wall.html, "fix oneway"_fix_oneway.html
[Default:] none
:line
:link(Bond)
[(Bond)] Bond and Leimkuhler, SIAM J Sci Comput, 30, p 134 (2007).
diff --git a/doc/src/improper_class2.txt b/doc/src/improper_class2.txt
index 0b41afe2d..14ec6258d 100644
--- a/doc/src/improper_class2.txt
+++ b/doc/src/improper_class2.txt
@@ -1,125 +1,125 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
improper_style class2 command :h3
improper_style class2/omp command :h3
improper_style class2/kk command :h3
[Syntax:]
improper_style class2 :pre
[Examples:]
improper_style class2
improper_coeff 1 100.0 0
improper_coeff * aa 0.0 0.0 0.0 115.06 130.01 115.06 :pre
[Description:]
The {class2} improper style uses the potential
:c,image(Eqs/improper_class2.jpg)
where Ei is the improper term and Eaa is an angle-angle term. The 3 X
terms in Ei are an average over 3 out-of-plane angles.
The 4 atoms in an improper quadruplet (listed in the data file read by
the "read_data"_read_data.html command) are ordered I,J,K,L. X_IJKL
refers to the angle between the plane of I,J,K and the plane of J,K,L,
and the bond JK lies in both planes. Similarly for X_KJLI and X_LJIK.
Note that atom J appears in the common bonds (JI, JK, JL) of all 3 X
terms. Thus J (the 2nd atom in the quadruplet) is the atom of
symmetry in the 3 X angles.
The subscripts on the various theta's refer to different combinations
of 3 atoms (I,J,K,L) used to form a particular angle. E.g. Theta_IJL
is the angle formed by atoms I,J,L with J in the middle. Theta1,
theta2, theta3 are the equilibrium positions of those angles. Again,
atom J (the 2nd atom in the quadruplet) is the atom of symmetry in the
theta angles, since it is always the center atom.
Since atom J is the atom of symmetry, normally the bonds J-I, J-K, J-L
would exist for an improper to be defined between the 4 atoms, but
this is not required.
See "(Sun)"_#improper-Sun for a description of the COMPASS class2 force field.
Coefficients for the Ei and Eaa formulas must be defined for each
improper type via the "improper_coeff"_improper_coeff.html command as
in the example above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands.
These are the 2 coefficients for the Ei formula:
K (energy/radian^2)
X0 (degrees) :ul
X0 is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of K are in energy/radian^2.
For the Eaa formula, each line in a
"improper_coeff"_improper_coeff.html command in the input script lists
7 coefficients, the first of which is "aa" to indicate they are
AngleAngle coefficients. In a data file, these coefficients should be
listed under a "AngleAngle Coeffs" heading and you must leave out the
"aa", i.e. only list 6 coefficients after the improper type.
aa
M1 (energy/distance)
M2 (energy/distance)
M3 (energy/distance)
theta1 (degrees)
theta2 (degrees)
theta3 (degrees) :ul
The theta values are specified in degrees, but LAMMPS converts them to
radians internally; hence the units of M are in energy/radian^2.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This improper style can only be used if LAMMPS was built with the
CLASS2 package. See the "Making LAMMPS"_Section_start.html#start_3
section for more info on packages.
[Related commands:]
"improper_coeff"_improper_coeff.html
[Default:] none
:line
:link(improper-Sun)
[(Sun)] Sun, J Phys Chem B 102, 7338-7364 (1998).
diff --git a/doc/src/improper_cossq.txt b/doc/src/improper_cossq.txt
index e238063a8..138a6a165 100644
--- a/doc/src/improper_cossq.txt
+++ b/doc/src/improper_cossq.txt
@@ -1,86 +1,86 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
improper_style cossq command :h3
improper_style cossq/omp command :h3
[Syntax:]
improper_style cossq :pre
[Examples:]
improper_style cossq
improper_coeff 1 4.0 0.0 :pre
[Description:]
The {cossq} improper style uses the potential
:c,image(Eqs/improper_cossq.jpg)
where x is the improper angle, x0 is its equilibrium value, and K is a
prefactor.
If the 4 atoms in an improper quadruplet (listed in the data file read
by the "read_data"_read_data.html command) are ordered I,J,K,L then X
is the angle between the plane of I,J,K and the plane of J,K,L.
Alternatively, you can think of atoms J,K,L as being in a plane, and
atom I above the plane, and X as a measure of how far out-of-plane I
is with respect to the other 3 atoms.
Note that defining 4 atoms to interact in this way, does not mean that
bonds necessarily exist between I-J, J-K, or K-L, as they would in a
linear dihedral. Normally, the bonds I-J, I-K, I-L would exist for an
improper to be defined between the 4 atoms.
The following coefficients must be defined for each improper type via
the "improper_coeff"_improper_coeff.html command as in the example
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands:
K (energy)
X0 (degrees) :ul
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This improper style can only be used if LAMMPS was built with the
USER-MISC package. See the "Making LAMMPS"_Section_start.html#start_3
section for more info on packages.
[Related commands:]
"improper_coeff"_improper_coeff.html
[Default:] none
diff --git a/doc/src/improper_cvff.txt b/doc/src/improper_cvff.txt
index 72f346ba0..5f69eccc6 100644
--- a/doc/src/improper_cvff.txt
+++ b/doc/src/improper_cvff.txt
@@ -1,87 +1,87 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
improper_style cvff command :h3
improper_style cvff/intel command :h3
improper_style cvff/omp command :h3
[Syntax:]
improper_style cvff :pre
[Examples:]
improper_style cvff
improper_coeff 1 80.0 -1 4 :pre
[Description:]
The {cvff} improper style uses the potential
:c,image(Eqs/improper_cvff.jpg)
where phi is the improper dihedral angle.
If the 4 atoms in an improper quadruplet (listed in the data file read
by the "read_data"_read_data.html command) are ordered I,J,K,L then
the improper dihedral angle is between the plane of I,J,K and the
plane of J,K,L. Note that because this is effectively a dihedral
angle, the formula for this improper style is the same as for
"dihedral_style harmonic"_dihedral_harmonic.html.
Note that defining 4 atoms to interact in this way, does not mean that
bonds necessarily exist between I-J, J-K, or K-L, as they would in a
linear dihedral. Normally, the bonds I-J, I-K, I-L would exist for an
improper to be defined between the 4 atoms.
The following coefficients must be defined for each improper type via
the "improper_coeff"_improper_coeff.html command as in the example
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands:
K (energy)
d (+1 or -1)
n (0,1,2,3,4,6) :ul
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This improper style can only be used if LAMMPS was built with the
MOLECULE package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info on packages.
[Related commands:]
"improper_coeff"_improper_coeff.html
[Default:] none
diff --git a/doc/src/improper_fourier.txt b/doc/src/improper_fourier.txt
index 3a5354b1f..f9062da20 100644
--- a/doc/src/improper_fourier.txt
+++ b/doc/src/improper_fourier.txt
@@ -1,82 +1,82 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
improper_style fourier command :h3
improper_style fourier/omp command :h3
[Syntax:]
improper_style fourier :pre
[Examples:]
improper_style fourier
improper_coeff 1 100.0 180.0 :pre
[Description:]
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:
:c,image(Eqs/umbrella.jpg)
If all parameter (see bellow) 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
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands:
K (energy)
C0 (real)
C1 (real)
C2 (real)
all (integer >= 0) :ul
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This angle style can only be used if LAMMPS was built with the
USER_MISC package. See the "Making LAMMPS"_Section_start.html#start_3
section for more info on packages.
[Related commands:]
"improper_coeff"_improper_coeff.html
[Default:] none
diff --git a/doc/src/improper_harmonic.txt b/doc/src/improper_harmonic.txt
index b47b0ca41..bb17e5a64 100644
--- a/doc/src/improper_harmonic.txt
+++ b/doc/src/improper_harmonic.txt
@@ -1,91 +1,91 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
improper_style harmonic command :h3
improper_style harmonic/intel command :h3
improper_style harmonic/kk command :h3
improper_style harmonic/omp command :h3
[Syntax:]
improper_style harmonic :pre
[Examples:]
improper_style harmonic
improper_coeff 1 100.0 0 :pre
[Description:]
The {harmonic} improper style uses the potential
:c,image(Eqs/improper_harmonic.jpg)
where X is the improper angle, X0 is its equilibrium value, and K is a
prefactor. Note that the usual 1/2 factor is included in K.
If the 4 atoms in an improper quadruplet (listed in the data file read
by the "read_data"_read_data.html command) are ordered I,J,K,L then X
is the angle between the plane of I,J,K and the plane of J,K,L.
Alternatively, you can think of atoms J,K,L as being in a plane, and
atom I above the plane, and X as a measure of how far out-of-plane I
is with respect to the other 3 atoms.
Note that defining 4 atoms to interact in this way, does not mean that
bonds necessarily exist between I-J, J-K, or K-L, as they would in a
linear dihedral. Normally, the bonds I-J, I-K, I-L would exist for an
improper to be defined between the 4 atoms.
The following coefficients must be defined for each improper type via
the "improper_coeff"_improper_coeff.html command as in the example
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands:
K (energy/radian^2)
X0 (degrees) :ul
X0 is specified in degrees, but LAMMPS converts it to radians
internally; hence the units of K are in energy/radian^2.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This improper style can only be used if LAMMPS was built with the
MOLECULE package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info on packages.
[Related commands:]
"improper_coeff"_improper_coeff.html
[Default:] none
diff --git a/doc/src/improper_ring.txt b/doc/src/improper_ring.txt
index cba59399e..c02d39247 100644
--- a/doc/src/improper_ring.txt
+++ b/doc/src/improper_ring.txt
@@ -1,93 +1,93 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
improper_style ring command :h3
improper_style ring/omp command :h3
[Syntax:]
improper_style ring :pre
[Examples:]
improper_style ring
improper_coeff 1 8000 70.5 :pre
[Description:]
The {ring} improper style uses the potential
:c,image(Eqs/improper_ring.jpg)
where K is a prefactor, theta is the angle formed by the atoms
specified by (i,j,k,l) indices and theta0 its equilibrium value.
If the 4 atoms in an improper quadruplet (listed in the data file read
by the "read_data"_read_data.html command) are ordered i,j,k,l then
theta_{ijl} is the angle between atoms i,j and l, theta_{ijk} is the
angle between atoms i,j and k, theta_{kjl} is the angle between atoms
j,k, and l.
The "ring" improper style implements the improper potential introduced
by Destree et al., in Equation (9) of "(Destree)"_#Destree. This
potential does not affect small amplitude vibrations but is used in an
ad-hoc way to prevent the onset of accidentally large amplitude
fluctuations leading to the occurrence of a planar conformation of the
three bonds i-j, j-k and j-l, an intermediate conformation toward the
chiral inversion of a methine carbon. In the "Impropers" section of
data file four atoms: i, j, k and l are specified with i,j and l lying
on the backbone of the chain and k specifying the chirality of j.
The following coefficients must be defined for each improper type via
the "improper_coeff"_improper_coeff.html command as in the example
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands:
K (energy)
theta0 (degrees) :ul
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This improper style can only be used if LAMMPS was built with the
USER-MISC package. See the "Making LAMMPS"_Section_start.html#start_3
section for more info on packages.
[Related commands:]
"improper_coeff"_improper_coeff.html
:link(Destree)
[(Destree)] M. Destree, F. Laupretre, A. Lyulin, and J.-P. Ryckaert,
J Chem Phys, 112, 9632 (2000).
diff --git a/doc/src/improper_umbrella.txt b/doc/src/improper_umbrella.txt
index fafa2e7e4..d6df9ee6c 100644
--- a/doc/src/improper_umbrella.txt
+++ b/doc/src/improper_umbrella.txt
@@ -1,90 +1,90 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
improper_style umbrella command :h3
improper_style umbrella/omp command :h3
[Syntax:]
improper_style umbrella :pre
[Examples:]
improper_style umbrella
improper_coeff 1 100.0 180.0 :pre
[Description:]
The {umbrella} improper style uses the following potential, which is
commonly referred to as a classic inversion and used in the
"DREIDING"_Section_howto.html#howto_4 force field:
:c,image(Eqs/improper_umbrella.jpg)
where K is the force constant and omega is the angle between the IL
axis and the IJK plane:
:c,image(Eqs/umbrella.jpg)
If omega0 = 0 the potential term has a minimum for the planar
structure. Otherwise it has two minima at +/- omega0, with a barrier
in between.
See "(Mayo)"_#umbrella-Mayo for a description of the DREIDING force field.
The following coefficients must be defined for each improper type via
the "improper_coeff"_improper_coeff.html command as in the example
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands:
K (energy)
omega0 (degrees) :ul
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This improper style can only be used if LAMMPS was built with the
MOLECULE package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info on packages.
[Related commands:]
"improper_coeff"_improper_coeff.html
[Default:] none
:line
:link(umbrella-Mayo)
[(Mayo)] Mayo, Olfason, Goddard III, J Phys Chem, 94, 8897-8909
(1990),
diff --git a/doc/src/jump.txt b/doc/src/jump.txt
index 1b1a20951..4e3799f7b 100644
--- a/doc/src/jump.txt
+++ b/doc/src/jump.txt
@@ -1,130 +1,130 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
jump command :h3
[Syntax:]
jump file label :pre
file = filename of new input script to switch to
label = optional label within file to jump to :ul
[Examples:]
jump newfile
jump in.run2 runloop
jump SELF runloop :pre
[Description:]
This command closes the current input script file, opens the file with
the specified name, and begins reading LAMMPS commands from that file.
Unlike the "include"_include.html command, the original file is not
returned to, although by using multiple jump commands it is possible
to chain from file to file or back to the original file.
If the word "SELF" is used for the filename, then the current input
script is re-opened and read again.
NOTE: The SELF option is not guaranteed to work when the current input
script is being read through stdin (standard input), e.g.
lmp_g++ < in.script :pre
since the SELF option invokes the C-library rewind() call, which may
not be supported for stdin on some systems or by some MPI
implementations. This can be worked around by using the "-in
-command-line argument"_Section_start.html#start_7, e.g.
+command-line argument"_Section_start.html#start_6, e.g.
lmp_g++ -in in.script :pre
or by using the "-var command-line
-argument"_Section_start.html#start_7 to pass the script name as a
+argument"_Section_start.html#start_6 to pass the script name as a
variable to the input script. In the latter case, a
"variable"_variable.html called "fname" could be used in place of
SELF, e.g.
lmp_g++ -var fname in.script < in.script :pre
The 2nd argument to the jump command is optional. If specified, it is
treated as a label and the new file is scanned (without executing
commands) until the label is found, and commands are executed from
that point forward. This can be used to loop over a portion of the
input script, as in this example. These commands perform 10 runs,
each of 10000 steps, and create 10 dump files named file.1, file.2,
etc. The "next"_next.html command is used to exit the loop after 10
iterations. When the "a" variable has been incremented for the tenth
time, it will cause the next jump command to be skipped.
variable a loop 10
label loop
dump 1 all atom 100 file.$a
run 10000
undump 1
next a
jump in.lj loop :pre
If the jump {file} argument is a variable, the jump command can be
used to cause different processor partitions to run different input
scripts. In this example, LAMMPS is run on 40 processors, with 4
partitions of 10 procs each. An in.file containing the example
variable and jump command will cause each partition to run a different
simulation.
mpirun -np 40 lmp_ibm -partition 4x10 -in in.file :pre
variable f world script.1 script.2 script.3 script.4
jump $f :pre
Here is an example of a loop which checks every 1000 steps if the
system temperature has reached a certain value, and if so, breaks out
of the loop to finish the run. Note that any variable could be
checked, so long as it is current on the timestep when the run
completes. As explained on the "variable"_variable.html doc page,
this can be insured by including the variable in thermodynamic output.
variable myTemp equal temp
label loop
variable a loop 1000
run 1000
if "$\{myTemp\} < 300.0" then "jump SELF break"
next a
jump SELF loop
label break
print "ALL DONE" :pre
Here is an example of a double loop which uses the if and
"jump"_jump.html commands to break out of the inner loop when a
condition is met, then continues iterating thru the outer loop.
label loopa
variable a loop 5
label loopb
variable b loop 5
print "A,B = $a,$b"
run 10000
if "$b > 2" then "jump SELF break"
next b
jump in.script loopb
label break
variable b delete
next a
jump SELF loopa :pre
[Restrictions:]
If you jump to a file and it does not contain the specified label,
LAMMPS will come to the end of the file and exit.
[Related commands:]
"variable"_variable.html, "include"_include.html, "label"_label.html,
"next"_next.html
[Default:] none
diff --git a/doc/src/log.txt b/doc/src/log.txt
index 460482ea1..92bb12e6d 100644
--- a/doc/src/log.txt
+++ b/doc/src/log.txt
@@ -1,46 +1,46 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
log command :h3
[Syntax:]
log file keyword :pre
file = name of new logfile
keyword = {append} if output should be appended to logfile (optional) :ul
[Examples:]
log log.equil
log log.equil append :pre
[Description:]
This command closes the current LAMMPS log file, opens a new file with
the specified name, and begins logging information to it. If the
specified file name is {none}, then no new log file is opened. If the
optional keyword {append} is specified, then output will be appended
to an existing log file, instead of overwriting it.
If multiple processor partitions are being used, the file name should
be a variable, so that different processors do not attempt to write to
the same log file.
The file "log.lammps" is the default log file for a LAMMPS run. The
name of the initial log file can also be set by the command-line
-switch -log. See "Section 2.7"_Section_start.html#start_7 for
+switch -log. See "Section 2.6"_Section_start.html#start_6 for
details.
[Restrictions:] none
[Related commands:] none
[Default:]
The default LAMMPS log file is named log.lammps
diff --git a/doc/src/neb.txt b/doc/src/neb.txt
index d2e8be3f0..144fe8bde 100644
--- a/doc/src/neb.txt
+++ b/doc/src/neb.txt
@@ -1,427 +1,427 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
neb command :h3
[Syntax:]
neb etol ftol N1 N2 Nevery file-style arg keyword :pre
etol = stopping tolerance for energy (energy units) :ulb,l
ftol = stopping tolerance for force (force units) :l
N1 = max # of iterations (timesteps) to run initial NEB :l
N2 = max # of iterations (timesteps) to run barrier-climbing NEB :l
Nevery = print replica energies and reaction coordinates every this many timesteps :l
file-style = {final} or {each} or {none} :l
{final} arg = filename
filename = file with initial coords for final replica
coords for intermediate replicas are linearly interpolated
between first and last replica
{each} arg = filename
filename = unique filename for each replica (except first)
with its initial coords
{none} arg = no argument all replicas assumed to already have
their initial coords :pre
keyword = {verbose}
:ule
[Examples:]
neb 0.1 0.0 1000 500 50 final coords.final
neb 0.0 0.001 1000 500 50 each coords.initial.$i
neb 0.0 0.001 1000 500 50 none verbose :pre
[Description:]
Perform a nudged elastic band (NEB) calculation using multiple
replicas of a system. Two or more replicas must be used; the first
and last are the end points of the transition path.
NEB is a method for finding both the atomic configurations and height
of the energy barrier associated with a transition state, e.g. for an
atom to perform a diffusive hop from one energy basin to another in a
coordinated fashion with its neighbors. The implementation in LAMMPS
follows the discussion in these 4 papers: "(HenkelmanA)"_#HenkelmanA,
"(HenkelmanB)"_#HenkelmanB, "(Nakano)"_#Nakano3 and "(Maras)"_#Maras2.
Each replica runs on a partition of one or more processors. Processor
partitions are defined at run-time using the -partition command-line
-switch; see "Section 2.7"_Section_start.html#start_7 of the manual.
+switch; see "Section 2.6"_Section_start.html#start_6 of the manual.
Note that if you have MPI installed, you can run a multi-replica
simulation with more replicas (partitions) than you have physical
processors, e.g you can run a 10-replica simulation on just one or two
processors. You will simply not get the performance speed-up you
would see with one or more physical processors per replica. See
"Section 6.5"_Section_howto.html#howto_5 of the manual for further
discussion.
NOTE: As explained below, a NEB calculation perfoms a damped dynamics
minimization across all the replicas. The minimizer uses whatever
timestep you have defined in your input script, via the
"timestep"_timestep.html command. Often NEB will converge more
quickly if you use a timestep about 10x larger than you would normally
use for dynamics simulations.
When a NEB 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 atoms, the interaction
potentials, and the starting configuration when the neb command is
issued should be the same for every replica.
In a NEB calculation each replica is connected to other replicas by
inter-replica nudging forces. These forces are imposed by the "fix
neb"_fix_neb.html command, which must be used in conjunction with the
neb command. The group used to define the fix neb command defines the
NEB atoms which are the only ones that inter-replica springs are
applied to. If the group does not include all atoms, then non-NEB
atoms have no inter-replica springs and the forces they feel and their
motion is computed in the usual way due only to other atoms within
their replica. Conceptually, the non-NEB atoms provide a background
force field for the NEB atoms. They can be allowed to move during the
NEB minimization procedure (which will typically induce different
coordinates for non-NEB atoms in different replicas), or held fixed
using other LAMMPS commands such as "fix setforce"_fix_setforce.html.
Note that the "partition"_partition.html command can be used to invoke
a command on a subset of the replicas, e.g. if you wish to hold NEB or
non-NEB atoms fixed in only the end-point replicas.
The initial atomic configuration for each of the replicas can be
specified in different manners via the {file-style} setting, as
discussed below. Only atoms whose initial coordinates should differ
from the current configuration need be specified.
Conceptually, the initial and final configurations for the first
replica should be states on either side of an energy barrier.
As explained below, the initial configurations of intermediate
replicas can be atomic coordinates interpolated in a linear fashion
between the first and last replicas. This is often adequate for
simple transitions. For more complex transitions, it may lead to slow
convergence or even bad results if the minimum energy path (MEP, see
below) of states over the barrier cannot be correctly converged to
from such an initial path. In this case, you will want to generate
initial states for the intermediate replicas that are geometrically
closer to the MEP and read them in.
:line
For a {file-style} setting of {final}, a filename is specified which
contains atomic 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 position to that atom in an
interpolated manner. This is done by using the current position of
the atom as the starting point and the read-in position as the final
point. The distance between them is calculated, and the new position
is assigned to be a fraction of the distance. E.g. if there are 10
replicas, the 2nd replica will assign a position that is 10% of the
distance along a line between the starting and final point, and the
9th replica will assign a position that is 90% of the distance along
the line. Note that for this procedure to produce consistent
coordinates across all the replicas, the current coordinates need to
be the same in all replicas. LAMMPS does not check for this, but
invalid initial configurations will likely result if it is not the
case.
NOTE: The "distance" between the starting and final point is
calculated in a minimum-image sense for a periodic simulation box.
This means that if the two positions are on opposite sides of a box
(periodic in that dimension), the distance between them will be small,
because the periodic image of one of the atoms is close to the other.
Similarly, even if the assigned position resulting from the
interpolation is outside the periodic box, the atom will be wrapped
back into the box when the NEB calculation begins.
For a {file-style} setting of {each}, a filename is specified which is
assumed to be unique to each replica. This can be done by using a
variable in the filename, e.g.
variable i equal part
neb 0.0 0.001 1000 500 50 each coords.initial.$i :pre
which in this case will substitute the partition ID (0 to N-1) for the
variable I, which is also effectively the replica ID. See the
"variable"_variable.html command for other options, such as using
world-, universe-, or uloop-style variables.
Each replica (except the first replica) will read its file, formatted
as described below, and for any atom that appears in the file, assign
the specified coordinates to its atom. The various files do not need
to contain the same set of atoms.
For a {file-style} setting of {none}, no filename is specified. Each
replica is assumed to already be in its initial configuration at the
time the neb command is issued. This allows each replica to define
its own configuration by reading a replica-specific data or restart or
dump file, via the "read_data"_read_data.html,
"read_restart"_read_restart.html, or "read_dump"_read_dump.html
commands. The replica-specific names of these files can be specified
as in the discussion above for the {each} file-style. Also see the
section below for how a NEB calculation can produce restart files, so
that a long calculation can be restarted if needed.
NOTE: None of the {file-style} settings change the initial
configuration of any atom in the first replica. The first replica
must thus be in the correct initial configuration at the time the neb
command is issued.
:line
A NEB calculation proceeds in two stages, each of which is a
minimization procedure, performed via damped dynamics. To enable
this, you must first define a damped dynamics
"min_style"_min_style.html, such as {quickmin} or {fire}. The {cg},
{sd}, and {hftn} styles cannot be used, since they perform iterative
line searches in their inner loop, which cannot be easily synchronized
across multiple replicas.
The minimizer tolerances for energy and force are set by {etol} and
{ftol}, the same as for the "minimize"_minimize.html command.
A non-zero {etol} means that the NEB calculation will terminate if the
energy criterion is met by every replica. The energies being compared
to {etol} do not include any contribution from the inter-replica
nudging forces, since these are non-conservative. A non-zero {ftol}
means that the NEB calculation will terminate if the force criterion
is met by every replica. The forces being compared to {ftol} include
the inter-replica nudging forces.
The maximum number of iterations in each stage is set by {N1} and
{N2}. These are effectively timestep counts since each iteration of
damped dynamics is like a single timestep in a dynamics
"run"_run.html. During both stages, the potential energy of each
replica and its normalized distance along the reaction path (reaction
coordinate RD) will be printed to the screen and log file every
{Nevery} timesteps. The RD is 0 and 1 for the first and last replica.
For intermediate replicas, it is the cumulative distance (normalized
by the total cumulative distance) between adjacent replicas, where
"distance" is defined as the length of the 3N-vector of differences in
atomic coordinates, where N is the number of NEB atoms involved in the
transition. These outputs allow you to monitor NEB's progress in
finding a good energy barrier. {N1} and {N2} must both be multiples
of {Nevery}.
In the first stage of NEB, 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 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 nugding
force added by the "fix neb"_fix_neb.html command.
In the second stage of NEB, the replica with the highest energy is
selected and the inter-replica forces on it are converted to a force
that drives its atom coordinates to the top or saddle point of the
barrier, via the barrier-climbing calculation described in
"(HenkelmanB)"_#HenkelmanB. As before, the other replicas rearrange
themselves along the MEP so as to be roughly equally spaced.
When both stages are complete, if the NEB calculation was successful,
the configurations of the replicas should be along (close to) the MEP
and the replica with the highest energy should be an atomic
configuration at (close to) the saddle point of the transition. The
potential energies for the set of replicas represents the energy
profile of the transition along the MEP.
:line
A few other settings in your input script are required or advised to
perform a NEB calculation. See the NOTE about the choice of timestep
at the beginning of this doc page.
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.
The minimizers in LAMMPS operate on all atoms in your system, even
non-NEB atoms, as defined above. To prevent non-NEB atoms from moving
during the minimization, you should use the "fix
setforce"_fix_setforce.html command to set the force on each of those
atoms to 0.0. This is not required, and may not even be desired in
some cases, but if those atoms move too far (e.g. because the initial
state of your system was not well-minimized), it can cause problems
for the NEB procedure.
The damped dynamics "minimizers"_min_style.html, such as {quickmin}
and {fire}), adjust the position and velocity of the atoms via an
Euler integration step. Thus you must define an appropriate
"timestep"_timestep.html to use with NEB. As mentioned above, NEB
will often converge more quickly if you use a timestep about 10x
larger than you would normally use for dynamics simulations.
:line
Each file read by the neb command containing atomic coordinates used
to initialize one or more replicas must be formatted as follows.
The file can be ASCII text or a gzipped text file (detected by a .gz
suffix). The file can contain initial blank lines or comment lines
starting with "#" which are ignored. The first non-blank, non-comment
line should list N = the number of lines to follow. The N successive
lines contain the following information:
ID1 x1 y1 z1
ID2 x2 y2 z2
...
IDN xN yN zN :pre
The fields are the atom ID, followed by the x,y,z coordinates. The
lines can be listed in any order. Additional trailing information on
the line is OK, such as a comment.
Note that for a typical NEB calculation you do not need to specify
initial coordinates for very many atoms to produce differing starting
and final replicas whose intermediate replicas will converge to the
energy barrier. Typically only new coordinates for atoms
geometrically near the barrier need be specified.
Also note there is no requirement that the atoms in the file
correspond to the NEB atoms in the group defined by the "fix
neb"_fix_neb.html command. Not every NEB atom need be in the file,
and non-NEB atoms can be listed in the file.
:line
Four kinds of output can be generated during a NEB calculation: energy
barrier statistics, thermodynamic output by each replica, dump files,
and restart files.
When running with multiple partitions (each of which is a replica in
this case), the print-out to the screen and master log.lammps file
contains a line of output, printed once every {Nevery} timesteps. It
contains the timestep, the maximum force per replica, the maximum
force per atom (in any replica), potential gradients in the initial,
final, and climbing replicas, the forward and backward energy
barriers, the total reaction coordinate (RDT), and the normalized
reaction coordinate and potential energy of each replica.
The "maximum force per replica" is the two-norm of the 3N-length force
vector for the atoms in each replica, maximized across replicas, which
is what the {ftol} setting is checking against. In this case, N is
all the atoms in each replica. The "maximum force per atom" is the
maximum force component of any atom in any replica. The potential
gradients are the two-norm of the 3N-length force vector solely due to
the interaction potential i.e. without adding in inter-replica
forces.
The "reaction coordinate" (RD) for each replica is the two-norm of the
3N-length vector of distances between its atoms and the preceding
replica's atoms, 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 atoms being operated on by
the fix neb command.
The forward (reverse) energy barrier is the potential energy of the
highest replica minus the energy of the first (last) replica.
Supplementary informations for all replicas can be printed out to the
screen and master log.lammps file by adding the verbose keyword. These
informations include the following. The "path angle" (pathangle) for
the replica i which is the angle between the 3N-length vectors (Ri-1 -
Ri) and (Ri+1 - Ri) (where Ri is the atomic coordinates of replica
i). A "path angle" of 180 indicates that replicas i-1, i and i+1 are
aligned. "angletangrad" is the angle between the 3N-length tangent
vector and the 3N-length force vector at image i. The tangent vector
is calculated as in "(HenkelmanA)"_#HenkelmanA for all intermediate
replicas and at R2 - R1 and RM - RM-1 for the first and last replica,
respectively. "anglegrad" is the angle between the 3N-length energy
gradient vector of replica i and that of replica i+1. It is not
defined for the final replica and reads nan. gradV is the norm of the
energy gradient of image i. ReplicaForce is the two-norm of the
3N-length force vector (including nudging forces) for replica i.
MaxAtomForce is the maximum force component of any atom in replica i.
When a NEB calculation does not converge properly, these suplementary
informations can help understanding what is going wrong. For instance
when the path angle becomes accute the definition of tangent used in
the NEB calculation is questionable and the NEB cannot may diverge
"(Maras)"_#Maras2.
When running on multiple partitions, LAMMPS produces additional log
files for each partition, e.g. log.lammps.0, log.lammps.1, etc. For a
NEB calculation, these contain the thermodynamic output for each
replica.
If "dump"_dump.html commands in the input script define a filename
that includes a {universe} or {uloop} style "variable"_variable.html,
then one dump file (per dump command) will be created for each
replica. At the end of the NEB calculation, the final snapshot in
each file will contain the sequence of snapshots that transition the
system over the energy barrier. Earlier snapshots will show the
convergence of the replicas to the MEP.
Likewise, "restart"_restart.html filenames can be specified with a
{universe} or {uloop} style "variable"_variable.html, to generate
restart files for each replica. These may be useful if the NEB
calculation fails to converge properly to the MEP, and you wish to
restart the calculation from an intermediate point with altered
parameters.
There are 2 Python scripts provided in the tools/python directory,
neb_combine.py and neb_final.py, which are useful in analyzing output
from a NEB calculation. Assume a NEB simulation with M replicas, and
the NEB atoms labeled with a specific atom type.
The neb_combine.py script extracts atom coords for the NEB atoms from
all M dump files and creates a single dump file where each snapshot
contains the NEB atoms from all the replicas and one copy of non-NEB
atoms from the first replica (presumed to be identical in other
replicas). This can be visualized/animated to see how the NEB atoms
relax as the NEB calculation proceeds.
The neb_final.py script extracts the final snapshot from each of the M
dump files to create a single dump file with M snapshots. This can be
visualized to watch the system make its transition over the energy
barrier.
To illustrate, here are images from the final snapshot produced by the
neb_combine.py script run on the dump files produced by the two
example input scripts in examples/neb. Click on them to see a larger
image.
:image(JPG/hop1_small.jpg,JPG/hop1.jpg)
:image(JPG/hop2_small.jpg,JPG/hop2.jpg)
:line
[Restrictions:]
This command can only be used if LAMMPS was built with the REPLICA
package. See the "Making LAMMPS"_Section_start.html#start_3 section
for more info on packages.
:line
[Related commands:]
"prd"_prd.html, "temper"_temper.html, "fix langevin"_fix_langevin.html,
"fix viscous"_fix_viscous.html
[Default:]
none
:line
:link(HenkelmanA)
[(HenkelmanA)] Henkelman and Jonsson, J Chem Phys, 113, 9978-9985 (2000).
:link(HenkelmanB)
[(HenkelmanB)] Henkelman, Uberuaga, Jonsson, J Chem Phys, 113,
9901-9904 (2000).
:link(Nakano3)
[(Nakano)] Nakano, Comp Phys Comm, 178, 280-289 (2008).
:link(Maras2)
[(Maras)] Maras, Trushin, Stukowski, Ala-Nissila, Jonsson,
Comp Phys Comm, 205, 13-21 (2016)
diff --git a/doc/src/neighbor.txt b/doc/src/neighbor.txt
index 7b8f499ba..062f79a5b 100644
--- a/doc/src/neighbor.txt
+++ b/doc/src/neighbor.txt
@@ -1,83 +1,83 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
neighbor command :h3
[Syntax:]
neighbor skin style :pre
skin = extra distance beyond force cutoff (distance units)
style = {bin} or {nsq} or {multi} :ul
[Examples:]
neighbor 0.3 bin
neighbor 2.0 nsq :pre
[Description:]
This command sets parameters that affect the building of pairwise
neighbor lists. All atom pairs within a neighbor cutoff distance
equal to the their force cutoff plus the {skin} distance are stored in
the list. Typically, the larger the skin distance, the less often
neighbor lists need to be built, but more pairs must be checked for
possible force interactions every timestep. The default value for
{skin} depends on the choice of units for the simulation; see the
default values below.
The {skin} distance is also used to determine how often atoms migrate
to new processors if the {check} option of the
"neigh_modify"_neigh_modify.html command is set to {yes}. Atoms are
migrated (communicated) to new processors on the same timestep that
neighbor lists are re-built.
The {style} value selects what algorithm is used to build the list.
The {bin} style creates the list by binning which is an operation that
scales linearly with N/P, the number of atoms per processor where N =
total number of atoms and P = number of processors. It is almost
always faster than the {nsq} style which scales as (N/P)^2. For
unsolvated small molecules in a non-periodic box, the {nsq} choice can
sometimes be faster. Either style should give the same answers.
The {multi} style is a modified binning algorithm that is useful for
systems with a wide range of cutoff distances, e.g. due to different
size particles. For the {bin} style, the bin size is set to 1/2 of
the largest cutoff distance between any pair of atom types and a
single set of bins is defined to search over for all atom types. This
can be inefficient if one pair of types has a very long cutoff, but
other type pairs have a much shorter cutoff. For style {multi} the
bin size is set to 1/2 of the shortest cutoff distance and multiple
sets of bins are defined to search over for different atom types.
This imposes some extra setup overhead, but the searches themselves
may be much faster for the short-cutoff cases. See the "comm_modify
mode multi"_comm_modify.html command for a communication option option
that may also be beneficial for simulations of this kind.
The "neigh_modify"_neigh_modify.html command has additional options
that control how often neighbor lists are built and which pairs are
stored in the list.
When a run is finished, counts of the number of neighbors stored in
the pairwise list and the number of times neighbor lists were built
are printed to the screen and log file. See "this
-section"_Section_start.html#start_8 for details.
+section"_Section_start.html#start_7 for details.
[Restrictions:] none
[Related commands:]
"neigh_modify"_neigh_modify.html, "units"_units.html,
"comm_modify"_comm_modify.html
[Default:]
0.3 bin for units = lj, skin = 0.3 sigma
2.0 bin for units = real or metal, skin = 2.0 Angstroms
0.001 bin for units = si, skin = 0.001 meters = 1.0 mm
0.1 bin for units = cgs, skin = 0.1 cm = 1.0 mm :all(b)
diff --git a/doc/src/next.txt b/doc/src/next.txt
index fe9dc9754..08f73b896 100644
--- a/doc/src/next.txt
+++ b/doc/src/next.txt
@@ -1,142 +1,142 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
next command :h3
[Syntax:]
next variables :pre
variables = one or more variable names :ul
[Examples:]
next x
next a t x myTemp :pre
[Description:]
This command is used with variables defined by the
"variable"_variable.html command. It assigns the next value to the
variable from the list of values defined for that variable by the
"variable"_variable.html command. Thus when that variable is
subsequently substituted for in an input script command, the new value
is used.
See the "variable"_variable.html command for info on how to define and
use different kinds of variables in LAMMPS input scripts. If a
variable name is a single lower-case character from "a" to "z", it can
be used in an input script command as $a or $z. If it is multiple
letters, it can be used as $\{myTemp\}.
If multiple variables are used as arguments to the {next} command,
then all must be of the same variable style: {index}, {loop}, {file},
{universe}, or {uloop}. An exception is that {universe}- and
{uloop}-style variables can be mixed in the same {next} command.
All the variables specified with the next command are incremented by
one value from their respective list of values. A {file}-style
variable reads the next line from its associated file. An
{atomfile}-style variable reads the next set of lines (one per atom)
from its associated file. {String-} or {atom}- or {equal}- or
{world}-style variables cannot be used with the next command,
since they only store a single value.
When any of the variables in the next command has no more values, a
flag is set that causes the input script to skip the next
"jump"_jump.html command encountered. This enables a loop containing
a next command to exit. As explained in the "variable"_variable.html
command, the variable that has exhausted its values is also deleted.
This allows it to be used and re-defined later in the input script.
{File}-style and {atomfile}-style variables are exhausted when the
end-of-file is reached.
When the next command is used with {index}- or {loop}-style variables,
the next value is assigned to the variable for all processors. When
the next command is used with {file}-style variables, the next line is
read from its file and the string assigned to the variable. When the
next command is used with {atomfile}-style variables, the next set of
per-atom values is read from its file and assigned to the variable.
When the next command is used with {universe}- or {uloop}-style
variables, all {universe}- or {uloop}-style variables must be listed
in the next command. This is because of the manner in which the
incrementing is done, using a single lock file for all variables. The
next value (for each variable) is assigned to whichever processor
partition executes the command first. All processors in the partition
are assigned the same value(s). Running LAMMPS on multiple partitions
of processors via the "-partition" command-line switch is described in
-"this section"_Section_start.html#start_7 of the manual. {Universe}-
+"this section"_Section_start.html#start_6 of the manual. {Universe}-
and {uloop}-style variables are incremented using the files
"tmp.lammps.variable" and "tmp.lammps.variable.lock" which you will
see in your directory during and after such a LAMMPS run.
Here is an example of running a series of simulations using the next
command with an {index}-style variable. If this input script is named
in.polymer, 8 simulations would be run using data files from
directories run1 thru run8.
variable d index run1 run2 run3 run4 run5 run6 run7 run8
shell cd $d
read_data data.polymer
run 10000
shell cd ..
clear
next d
jump in.polymer :pre
If the variable "d" were of style {universe}, and the same in.polymer
input script were run on 3 partitions of processors, then the first 3
simulations would begin, one on each set of processors. Whichever
partition finished first, it would assign variable "d" the 4th value
and run another simulation, and so forth until all 8 simulations were
finished.
Jump and next commands can also be nested to enable multi-level loops.
For example, this script will run 15 simulations in a double loop.
variable i loop 3
variable j loop 5
clear
...
read_data data.polymer.$i$j
print Running simulation $i.$j
run 10000
next j
jump in.script
next i
jump in.script :pre
Here is an example of a double loop which uses the "if"_if.html and
"jump"_jump.html commands to break out of the inner loop when a
condition is met, then continues iterating thru the outer loop.
label loopa
variable a loop 5
label loopb
variable b loop 5
print "A,B = $a,$b"
run 10000
if $b > 2 then "jump in.script break"
next b
jump in.script loopb
label break
variable b delete :pre
next a
jump in.script loopa :pre
[Restrictions:]
As described above.
[Related commands:]
"jump"_jump.html, "include"_include.html, "shell"_shell.html,
"variable"_variable.html,
[Default:] none
diff --git a/doc/src/package.txt b/doc/src/package.txt
index 18a26bd55..1b9092644 100644
--- a/doc/src/package.txt
+++ b/doc/src/package.txt
@@ -1,589 +1,589 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
package command :h3
[Syntax:]
package style args :pre
style = {gpu} or {intel} or {kokkos} or {omp} :ulb,l
args = arguments specific to the style :l
{gpu} args = Ngpu keyword value ...
Ngpu = # of GPUs per node
zero or more keyword/value pairs may be appended
keywords = {neigh} or {newton} or {binsize} or {split} or {gpuID} or {tpa} or {device} or {blocksize}
{neigh} value = {yes} or {no}
yes = neighbor list build on GPU (default)
no = neighbor list build on CPU
{newton} = {off} or {on}
off = set Newton pairwise flag off (default and required)
on = set Newton pairwise flag on (currently not allowed)
{binsize} value = size
size = bin size for neighbor list construction (distance units)
{split} = fraction
fraction = fraction of atoms assigned to GPU (default = 1.0)
{gpuID} values = first last
first = ID of first GPU to be used on each node
last = ID of last GPU to be used on each node
{tpa} value = Nthreads
Nthreads = # of GPU threads used per atom
{device} value = device_type
device_type = {kepler} or {fermi} or {cypress} or {generic}
{blocksize} value = size
size = thread block size for pair force computation
{intel} args = NPhi keyword value ...
Nphi = # of coprocessors per node
zero or more keyword/value pairs may be appended
keywords = {mode} or {omp} or {lrt} or {balance} or {ghost} or {tpc} or {tptask} or {no_affinity}
{mode} value = {single} or {mixed} or {double}
single = perform force calculations in single precision
mixed = perform force calculations in mixed precision
double = perform force calculations in double precision
{omp} value = Nthreads
Nthreads = number of OpenMP threads to use on CPU (default = 0)
{lrt} value = {yes} or {no}
yes = use additional thread dedicated for some PPPM calculations
no = do not dedicate an extra thread for some PPPM calculations
{balance} value = split
split = fraction of work to offload to coprocessor, -1 for dynamic
{ghost} value = {yes} or {no}
yes = include ghost atoms for offload
no = do not include ghost atoms for offload
{tpc} value = Ntpc
Ntpc = max number of coprocessor threads per coprocessor core (default = 4)
{tptask} value = Ntptask
Ntptask = max number of coprocessor threads per MPI task (default = 240)
{no_affinity} values = none
{kokkos} args = keyword value ...
zero or more keyword/value pairs may be appended
keywords = {neigh} or {neigh/qeq} or {newton} or {binsize} or {comm} or {comm/exchange} or {comm/forward}
{neigh} value = {full} or {half}
full = full neighbor list
half = half neighbor list built in thread-safe manner
{neigh/qeq} value = {full} or {half}
full = full neighbor list
half = half neighbor list built in thread-safe manner
{newton} = {off} or {on}
off = set Newton pairwise and bonded flags off (default)
on = set Newton pairwise and bonded flags on
{binsize} value = size
size = bin size for neighbor list construction (distance units)
{comm} value = {no} or {host} or {device}
use value for both comm/exchange and comm/forward
{comm/exchange} value = {no} or {host} or {device}
{comm/forward} value = {no} or {host} or {device}
no = perform communication pack/unpack in non-KOKKOS mode
host = perform pack/unpack on host (e.g. with OpenMP threading)
device = perform pack/unpack on device (e.g. on GPU)
{omp} args = Nthreads keyword value ...
Nthread = # of OpenMP threads to associate with each MPI process
zero or more keyword/value pairs may be appended
keywords = {neigh}
{neigh} value = {yes} or {no}
yes = threaded neighbor list build (default)
no = non-threaded neighbor list build :pre
:ule
[Examples:]
package gpu 1
package gpu 1 split 0.75
package gpu 2 split -1.0
package kokkos neigh half comm device
package omp 0 neigh no
package omp 4
package intel 1
package intel 2 omp 4 mode mixed balance 0.5 :pre
[Description:]
This command invokes package-specific settings for the various
accelerator packages available in LAMMPS. Currently the following
packages use settings from this command: GPU, USER-INTEL, KOKKOS, and
USER-OMP.
If this command is specified in an input script, it must be near the
top of the script, before the simulation box has been defined. This
is because it specifies settings that the accelerator packages use in
their initialization, before a simulation is defined.
This command can also be specified from the command-line when
launching LAMMPS, using the "-pk" "command-line
-switch"_Section_start.html#start_7. The syntax is exactly the same as
+switch"_Section_start.html#start_6. The syntax is exactly the same as
when used in an input script.
Note that all of the accelerator packages require the package command
to be specified (except the OPT package), if the package is to be used
in a simulation (LAMMPS can be built with an accelerator package
without using it in a particular simulation). However, in all cases,
a default version of the command is typically invoked by other
accelerator settings.
The KOKKOS package requires a "-k on" "command-line
-switch"_Section_start.html#start_7 respectively, which invokes a
+switch"_Section_start.html#start_6 respectively, which invokes a
"package kokkos" command with default settings.
For the GPU, USER-INTEL, and USER-OMP packages, if a "-sf gpu" or "-sf
-intel" or "-sf omp" "command-line switch"_Section_start.html#start_7
+intel" or "-sf omp" "command-line switch"_Section_start.html#start_6
is used to auto-append accelerator suffixes to various styles in the
input script, then those switches also invoke a "package gpu",
"package intel", or "package omp" command with default settings.
NOTE: A package command for a particular style can be invoked multiple
times when a simulation is setup, e.g. by the "-c on", "-k on", "-sf",
-and "-pk" "command-line switches"_Section_start.html#start_7, and by
+and "-pk" "command-line switches"_Section_start.html#start_6, and by
using this command in an input script. Each time it is used all of
the style options are set, either to default values or to specified
settings. I.e. settings from previous invocations do not persist
across multiple invocations.
See the "Section 5.3"_Section_accelerate.html#acc_3 section of the
manual for more details about using the various accelerator packages
for speeding up LAMMPS simulations.
:line
The {gpu} style invokes settings associated with the use of the GPU
package.
The {Ngpu} argument sets the number of GPUs per node. There must be
at least as many MPI tasks per node as GPUs, as set by the mpirun or
mpiexec command. If there are more MPI tasks (per node)
than GPUs, multiple MPI tasks will share each GPU.
Optional keyword/value pairs can also be specified. Each has a
default value as listed below.
The {neigh} keyword specifies where neighbor lists for pair style
computation will be built. If {neigh} is {yes}, which is the default,
neighbor list building is performed on the GPU. If {neigh} is {no},
neighbor list building is performed on the CPU. GPU neighbor list
building currently cannot be used with a triclinic box. GPU neighbor
list calculation currently cannot be used with
"hybrid"_pair_hybrid.html pair styles. GPU neighbor lists are not
compatible with commands that are not GPU-enabled. When a non-GPU
enabled command requires a neighbor list, it will also be built on the
CPU. In these cases, it will typically be more efficient to only use
CPU neighbor list builds.
The {newton} keyword sets the Newton flags for pairwise (not bonded)
interactions to {off} or {on}, the same as the "newton"_newton.html
command allows. Currently, only an {off} value is allowed, since all
the GPU package pair styles require this setting. This means more
computation is done, but less communication. In the future a value of
{on} may be allowed, so the {newton} keyword is included as an option
for compatibility with the package command for other accelerator
styles. Note that the newton setting for bonded interactions is not
affected by this keyword.
The {binsize} keyword sets the size of bins used to bin atoms in
neighbor list builds performed on the GPU, if {neigh} = {yes} is set.
If {binsize} is set to 0.0 (the default), then bins = the size of the
pairwise cutoff + neighbor skin distance. This is 2x larger than the
LAMMPS default used for neighbor list building on the CPU. This will
be close to optimal for the GPU, so you do not normally need to use
this keyword. Note that if you use a longer-than-usual pairwise
cutoff, e.g. to allow for a smaller fraction of KSpace work with a
"long-range Coulombic solver"_kspace_style.html because the GPU is
faster at performing pairwise interactions, then it may be optimal to
make the {binsize} smaller than the default. For example, with a
cutoff of 20*sigma in LJ "units"_units.html and a neighbor skin
distance of sigma, a {binsize} = 5.25*sigma can be more efficient than
the default.
The {split} keyword can be used for load balancing force calculations
between CPU and GPU cores in GPU-enabled pair styles. If 0 < {split} <
1.0, a fixed fraction of particles is offloaded to the GPU while force
calculation for the other particles occurs simultaneously on the CPU.
If {split} < 0.0, the optimal fraction (based on CPU and GPU timings)
is calculated every 25 timesteps, i.e. dynamic load-balancing across
the CPU and GPU is performed. If {split} = 1.0, all force
calculations for GPU accelerated pair styles are performed on the GPU.
In this case, other "hybrid"_pair_hybrid.html pair interactions,
"bond"_bond_style.html, "angle"_angle_style.html,
"dihedral"_dihedral_style.html, "improper"_improper_style.html, and
"long-range"_kspace_style.html calculations can be performed on the
CPU while the GPU is performing force calculations for the GPU-enabled
pair style. If all CPU force computations complete before the GPU
completes, LAMMPS will block until the GPU has finished before
continuing the timestep.
As an example, if you have two GPUs per node and 8 CPU cores per node,
and would like to run on 4 nodes (32 cores) with dynamic balancing of
force calculation across CPU and GPU cores, you could specify
mpirun -np 32 -sf gpu -in in.script # launch command
package gpu 2 split -1 # input script command :pre
In this case, all CPU cores and GPU devices on the nodes would be
utilized. Each GPU device would be shared by 4 CPU cores. The CPU
cores would perform force calculations for some fraction of the
particles at the same time the GPUs performed force calculation for
the other particles.
The {gpuID} keyword allows selection of which GPUs on each node will
be used for a simulation. The {first} and {last} values specify the
GPU IDs to use (from 0 to Ngpu-1). By default, first = 0 and last =
Ngpu-1, so that all GPUs are used, assuming Ngpu is set to the number
of physical GPUs. If you only wish to use a subset, set Ngpu to a
smaller number and first/last to a sub-range of the available GPUs.
The {tpa} keyword sets the number of GPU thread per atom used to
perform force calculations. With a default value of 1, the number of
threads will be chosen based on the pair style, however, the value can
be set explicitly with this keyword to fine-tune performance. For
large cutoffs or with a small number of particles per GPU, increasing
the value can improve performance. The number of threads per atom must
be a power of 2 and currently cannot be greater than 32.
The {device} keyword can be used to tune parameters optimized for a
specific accelerator, when using OpenCL. For CUDA, the {device}
keyword is ignored. Currently, the device type is limited to NVIDIA
Kepler, NVIDIA Fermi, AMD Cypress, or a generic device. More devices
may be added later. The default device type can be specified when
building LAMMPS with the GPU library, via settings in the
lib/gpu/Makefile that is used.
The {blocksize} keyword allows you to tweak the number of threads used
per thread block. This number should be a multiple of 32 (for GPUs)
and its maximum depends on the specific GPU hardware. Typical choices
are 64, 128, or 256. A larger blocksize increases occupancy of
individual GPU cores, but reduces the total number of thread blocks,
thus may lead to load imbalance.
:line
The {intel} style invokes settings associated with the use of the
USER-INTEL package. All of its settings, except the {omp} and {mode}
keywords, are ignored if LAMMPS was not built with Xeon Phi
coprocessor support. All of its settings, including the {omp} and
{mode} keyword are applicable if LAMMPS was built with coprocessor
support.
The {Nphi} argument sets the number of coprocessors per node.
This can be set to any value, including 0, if LAMMPS was not
built with coprocessor support.
Optional keyword/value pairs can also be specified. Each has a
default value as listed below.
The {omp} keyword determines the number of OpenMP threads allocated
for each MPI task when any portion of the interactions computed by a
USER-INTEL pair style are run on the CPU. This can be the case even
if LAMMPS was built with coprocessor support; see the {balance}
keyword discussion below. If you are running with less MPI tasks/node
than there are CPUs, it can be advantageous to use OpenMP threading on
the CPUs.
NOTE: The {omp} keyword has nothing to do with coprocessor threads on
the Xeon Phi; see the {tpc} and {tptask} keywords below for a
discussion of coprocessor threads.
The {Nthread} value for the {omp} keyword sets the number of OpenMP
threads allocated for each MPI task. Setting {Nthread} = 0 (the
default) instructs LAMMPS to use whatever value is the default for the
given OpenMP environment. This is usually determined via the
{OMP_NUM_THREADS} environment variable or the compiler runtime, which
is usually a value of 1.
For more details, including examples of how to set the OMP_NUM_THREADS
environment variable, see the discussion of the {Nthreads} setting on
this doc page for the "package omp" command. Nthreads is a required
argument for the USER-OMP package. Its meaning is exactly the same
for the USER-INTEL package.
NOTE: If you build LAMMPS with both the USER-INTEL and USER-OMP
packages, be aware that both packages allow setting of the {Nthreads}
value via their package commands, but there is only a single global
{Nthreads} value used by OpenMP. Thus if both package commands are
invoked, you should insure the two values are consistent. If they are
not, the last one invoked will take precedence, for both packages.
Also note that if the "-sf hybrid intel omp" "command-line
-switch"_"_Section_start.html#start_7 is used, it invokes a "package
+switch"_"_Section_start.html#start_6 is used, it invokes a "package
intel" command, followed by a "package omp" command, both with a
setting of {Nthreads} = 0.
The {mode} keyword determines the precision mode to use for
computing pair style forces, either on the CPU or on the coprocessor,
when using a USER-INTEL supported "pair style"_pair_style.html. It
can take a value of {single}, {mixed} which is the default, or
{double}. {Single} means single precision is used for the entire
force calculation. {Mixed} means forces between a pair of atoms are
computed in single precision, but accumulated and stored in double
precision, including storage of forces, torques, energies, and virial
quantities. {Double} means double precision is used for the entire
force calculation.
The {lrt} keyword can be used to enable "Long Range Thread (LRT)"
mode. It can take a value of {yes} to enable and {no} to disable.
LRT mode generates an extra thread (in addition to any OpenMP threads
specified with the OMP_NUM_THREADS environment variable or the {omp}
keyword). The extra thread is dedicated for performing part of the
"PPPM solver"_kspace_style.html computations and communications. This
can improve parallel performance on processors supporting
Simultaneous Multithreading (SMT) such as Hyperthreading on Intel
processors. In this mode, one additional thread is generated per MPI
process. LAMMPS will generate a warning in the case that more threads
are used than available in SMT hardware on a node. If the PPPM solver
from the USER-INTEL package is not used, then the LRT setting is
ignored and no extra threads are generated. Enabling LRT will replace
the "run_style"_run_style.html with the {verlet/lrt/intel} style that
is identical to the default {verlet} style aside from supporting the
LRT feature.
The {balance} keyword sets the fraction of "pair
style"_pair_style.html work offloaded to the coprocessor for split
values between 0.0 and 1.0 inclusive. While this fraction of work is
running on the coprocessor, other calculations will run on the host,
including neighbor and pair calculations that are not offloaded, as
well as angle, bond, dihedral, kspace, and some MPI communications.
If {split} is set to -1, the fraction of work is dynamically adjusted
automatically throughout the run. This typically give performance
within 5 to 10 percent of the optimal fixed fraction.
The {ghost} keyword determines whether or not ghost atoms, i.e. atoms
at the boundaries of processor sub-domains, are offloaded for neighbor
and force calculations. When the value = "no", ghost atoms are not
offloaded. This option can reduce the amount of data transfer with
the coprocessor and can also overlap MPI communication of forces with
computation on the coprocessor when the "newton pair"_newton.html
setting is "on". When the value = "yes", ghost atoms are offloaded.
In some cases this can provide better performance, especially if the
{balance} fraction is high.
The {tpc} keyword sets the max # of coprocessor threads {Ntpc} that
will run on each core of the coprocessor. The default value = 4,
which is the number of hardware threads per core supported by the
current generation Xeon Phi chips.
The {tptask} keyword sets the max # of coprocessor threads (Ntptask}
assigned to each MPI task. The default value = 240, which is the
total # of threads an entire current generation Xeon Phi chip can run
(240 = 60 cores * 4 threads/core). This means each MPI task assigned
to the Phi will enough threads for the chip to run the max allowed,
even if only 1 MPI task is assigned. If 8 MPI tasks are assigned to
the Phi, each will run with 30 threads. If you wish to limit the
number of threads per MPI task, set {tptask} to a smaller value.
E.g. for {tptask} = 16, if 8 MPI tasks are assigned, each will run
with 16 threads, for a total of 128.
Note that the default settings for {tpc} and {tptask} are fine for
most problems, regardless of how many MPI tasks you assign to a Phi.
The {no_affinity} keyword will turn off automatic setting of core
affinity for MPI tasks and OpenMP threads on the host when using
offload to a coprocessor. Affinity settings are used when possible
to prevent MPI tasks and OpenMP threads from being on separate NUMA
domains and to prevent offload threads from interfering with other
processes/threads used for LAMMPS.
:line
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.
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.
A value of {full} uses a full neighbor lists and is the default. This
performs twice as much computation as the {half} option, however that
is often a win because it is thread-safe and doesn't require atomic
operations in the calculation of pair forces. For that reason, {full}
is the default setting. However, when running in MPI-only mode with 1
thread per MPI task, {half} neighbor lists will typically be faster,
just as it is for non-accelerated pair styles. Similarly, the {neigh/qeq}
keyword determines how neighbor lists are built for "fix qeq/reax/kk"_fix_qeq_reax.html.
If not explicitly set, the value of {neigh/qeq} will match {neigh}.
The {newton} keyword sets the Newton flags for pairwise and bonded
interactions to {off} or {on}, the same as the "newton"_newton.html
command allows. The default is {off} because this will almost always
give better performance for the KOKKOS package. This means more
computation is done, but less communication. However, when running in
MPI-only mode with 1 thread per MPI task, a value of {on} will
typically be faster, just as it is for non-accelerated pair styles.
The {binsize} keyword sets the size of bins used to bin atoms in
neighbor list builds. The same value can be set by the "neigh_modify
binsize"_neigh_modify.html command. Making it an option in the
package kokkos command allows it to be set from the command line. The
default value is 0.0, which means the LAMMPS default will be used,
which is bins = 1/2 the size of the pairwise cutoff + neighbor skin
distance. This is fine when neighbor lists are built on the CPU. For
GPU builds, a 2x larger binsize equal to the pairwise cutoff +
neighbor skin, is often faster, which can be set by this keyword.
Note that if you use a longer-than-usual pairwise cutoff, e.g. to
allow for a smaller fraction of KSpace work with a "long-range
Coulombic solver"_kspace_style.html because the GPU is faster at
performing pairwise interactions, then this rule of thumb may give too
large a binsize.
The {comm} and {comm/exchange} and {comm/forward} 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. The data is for atom
coordinates and any other atom properties that needs to be updated for
ghost atoms owned by each processor.
The {comm} keyword is simply a short-cut to set the same value
for both the {comm/exchange} and {comm/forward} keywords.
The value options for all 3 keywords are {no} or {host} or {device}.
A value of {no} means to use the standard non-KOKKOS method of
packing/unpacking data for the communication. A value of {host} means
to use the host, typically a multi-core CPU, and perform the
packing/unpacking in parallel with threads. A value of {device} means
to use the device, typically a GPU, to perform the packing/unpacking
operation.
The optimal choice for these keywords depends on the input script and
the hardware used. The {no} value is useful for verifying that the
Kokkos-based {host} and {device} values are working correctly. It may
also be the fastest choice when using Kokkos styles in MPI-only mode
(i.e. with a thread count of 1).
When running on CPUs or Xeon Phi, the {host} and {device} values work
identically. When using GPUs, the {device} value will typically be
optimal if all of your styles used in your input script are supported
by the KOKKOS package. In this case data can stay on the GPU for many
timesteps without being moved between the host and GPU, if you use the
{device} value. This requires that your MPI is able to access GPU
memory directly. Currently that is true for OpenMPI 1.8 (or later
versions), Mvapich2 1.9 (or later), and CrayMPI. If your script uses
styles (e.g. fixes) which are not yet supported by the KOKKOS package,
then data has to be move between the host and device anyway, so it is
typically faster to let the host handle communication, by using the
{host} value. Using {host} instead of {no} will enable use of
multiple threads to pack/unpack communicated data.
:line
The {omp} style invokes settings associated with the use of the
USER-OMP package.
The {Nthread} argument sets the number of OpenMP threads allocated for
each MPI task. For example, if your system has nodes with dual
quad-core processors, it has a total of 8 cores per node. You could
use two MPI tasks per node (e.g. using the -ppn option of the mpirun
command in MPICH or -npernode in OpenMPI), and set {Nthreads} = 4.
This would use all 8 cores on each node. Note that the product of MPI
tasks * threads/task should not exceed the physical number of cores
(on a node), otherwise performance will suffer.
Setting {Nthread} = 0 instructs LAMMPS to use whatever value is the
default for the given OpenMP environment. This is usually determined
via the {OMP_NUM_THREADS} environment variable or the compiler
runtime. Note that in most cases the default for OpenMP capable
compilers is to use one thread for each available CPU core when
{OMP_NUM_THREADS} is not explicitly set, which can lead to poor
performance.
Here are examples of how to set the environment variable when
launching LAMMPS:
env OMP_NUM_THREADS=4 lmp_machine -sf omp -in in.script
env OMP_NUM_THREADS=2 mpirun -np 2 lmp_machine -sf omp -in in.script
mpirun -x OMP_NUM_THREADS=2 -np 2 lmp_machine -sf omp -in in.script :pre
or you can set it permanently in your shell's start-up script.
All three of these examples use a total of 4 CPU cores.
Note that different MPI implementations have different ways of passing
the OMP_NUM_THREADS environment variable to all MPI processes. The
2nd example line above is for MPICH; the 3rd example line with -x is
for OpenMPI. Check your MPI documentation for additional details.
What combination of threads and MPI tasks gives the best performance
is difficult to predict and can depend on many components of your
input. Not all features of LAMMPS support OpenMP threading via the
USER-OMP package and the parallel efficiency can be very different,
too.
Optional keyword/value pairs can also be specified. Each has a
default value as listed below.
The {neigh} keyword specifies whether neighbor list building will be
multi-threaded in addition to force calculations. If {neigh} is set
to {no} then neighbor list calculation is performed only by MPI tasks
with no OpenMP threading. If {mode} is {yes} (the default), a
multi-threaded neighbor list build is used. Using {neigh} = {yes} is
almost always faster and should produce identical neighbor lists at the
expense of using more memory. Specifically, neighbor list pages are
allocated for all threads at the same time and each thread works
within its own pages.
:line
[Restrictions:]
This command cannot be used after the simulation box is defined by a
"read_data"_read_data.html or "create_box"_create_box.html command.
The gpu style of this command can only be invoked if LAMMPS was built
with the GPU package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
The intel style of this command can only be invoked if LAMMPS was
built with the USER-INTEL package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
The kk style of this command can only be invoked if LAMMPS was built
with the KOKKOS package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
The omp style of this command can only be invoked if LAMMPS was built
with the USER-OMP package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
[Related commands:]
"suffix"_suffix.html, "-pk" "command-line
-setting"_Section_start.html#start_7
+setting"_Section_start.html#start_6
[Default:]
For the GPU package, the default is Ngpu = 1 and the option defaults
are neigh = yes, newton = off, binsize = 0.0, split = 1.0, gpuID = 0
to Ngpu-1, tpa = 1, and device = not used. These settings are made
automatically if the "-sf gpu" "command-line
-switch"_Section_start.html#start_7 is used. If it is not used, you
+switch"_Section_start.html#start_6 is used. If it is not used, you
must invoke the package gpu command in your input script or via the
-"-pk gpu" "command-line switch"_Section_start.html#start_7.
+"-pk gpu" "command-line switch"_Section_start.html#start_6.
For the USER-INTEL package, the default is Nphi = 1 and the option
defaults are omp = 0, mode = mixed, lrt = no, balance = -1, tpc = 4,
tptask = 240. The default ghost option is determined by the pair
style being used. This value is output to the screen in the offload
report at the end of each run. Note that all of these settings,
except "omp" and "mode", are ignored if LAMMPS was not built with
Xeon Phi coprocessor support. These settings are made automatically
-if the "-sf intel" "command-line switch"_Section_start.html#start_7
+if the "-sf intel" "command-line switch"_Section_start.html#start_6
is used. If it is not used, you must invoke the package intel
command in your input script or or via the "-pk intel" "command-line
-switch"_Section_start.html#start_7.
+switch"_Section_start.html#start_6.
For the KOKKOS package, the option defaults neigh = full,
neigh/qeq = full, newton = off, binsize = 0.0, and comm = device.
These settings are made automatically by the required "-k on" "command-line
-switch"_Section_start.html#start_7. You can change them bu using the
+switch"_Section_start.html#start_6. You can change them bu using the
package kokkos command in your input script or via the "-pk kokkos"
-"command-line switch"_Section_start.html#start_7.
+"command-line switch"_Section_start.html#start_6.
For the OMP package, the default is Nthreads = 0 and the option
defaults are neigh = yes. These settings are made automatically if
-the "-sf omp" "command-line switch"_Section_start.html#start_7 is
+the "-sf omp" "command-line switch"_Section_start.html#start_6 is
used. If it is not used, you must invoke the package omp command in
your input script or via the "-pk omp" "command-line
-switch"_Section_start.html#start_7.
+switch"_Section_start.html#start_6.
diff --git a/doc/src/pair_adp.txt b/doc/src/pair_adp.txt
index 457a797d9..9d2a48dcb 100644
--- a/doc/src/pair_adp.txt
+++ b/doc/src/pair_adp.txt
@@ -1,186 +1,186 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style adp command :h3
pair_style adp/omp command :h3
[Syntax:]
pair_style adp :pre
[Examples:]
pair_style adp
pair_coeff * * Ta.adp Ta
pair_coeff * * ../potentials/AlCu.adp Al Al Cu :pre
[Description:]
Style {adp} computes pairwise interactions for metals and metal alloys
using the angular dependent potential (ADP) of "(Mishin)"_#Mishin,
which is a generalization of the "embedded atom method (EAM)
potential"_pair_eam.html. The LAMMPS implementation is discussed in
"(Singh)"_#Singh. The total energy Ei of an atom I is given by
:c,image(Eqs/pair_adp.jpg)
where F is the embedding energy which is a function of the atomic
electron density rho, phi is a pair potential interaction, alpha and
beta are the element types of atoms I and J, and s and t = 1,2,3 and
refer to the cartesian coordinates. The mu and lambda terms represent
the dipole and quadruple distortions of the local atomic environment
which extend the original EAM framework by introducing angular forces.
Note that unlike for other potentials, cutoffs for ADP potentials are
not set in the pair_style or pair_coeff command; they are specified in
the ADP potential files themselves. Likewise, the ADP potential files
list atomic masses; thus you do not need to use the "mass"_mass.html
command to specify them.
The NIST WWW site distributes and documents ADP potentials:
http://www.ctcms.nist.gov/potentials :pre
Note that these must be converted into the extended DYNAMO {setfl}
format discussed below.
The NIST site is maintained by Chandler Becker (cbecker at nist.gov)
who is good resource for info on interatomic potentials and file
formats.
:line
Only a single pair_coeff command is used with the {adp} style which
specifies an extended DYNAMO {setfl} file, which contains information
for M elements. These are mapped to LAMMPS atom types by specifying N
additional arguments after the filename in the pair_coeff command,
where N is the number of LAMMPS atom types:
filename
N element names = mapping of extended {setfl} elements to atom types :ul
See the "pair_coeff"_pair_coeff.html doc page for alternate ways to
specify the path for the potential file.
As an example, the potentials/AlCu.adp file, included in the
potentials directory of the LAMMPS distribution, is an extended {setfl}
file which has tabulated ADP values for w elements and their alloy
interactions: Cu and Al. If your LAMMPS simulation has 4 atoms types
and you want the 1st 3 to be Al, and the 4th to be Cu, you would use
the following pair_coeff command:
pair_coeff * * AlCu.adp Al Al Al Cu :pre
The 1st 2 arguments must be * * so as to span all LAMMPS atom types.
The first three Al arguments map LAMMPS atom types 1,2,3 to the Al
element in the extended {setfl} file. The final Cu argument maps
LAMMPS atom type 4 to the Al element in the extended {setfl} file.
Note that there is no requirement that your simulation use all the
elements specified by the extended {setfl} file.
If a mapping value is specified as NULL, the mapping is not performed.
This can be used when an {adp} potential is used as part of the
{hybrid} pair style. The NULL values are placeholders for atom types
that will be used with other potentials.
{Adp} files in the {potentials} directory of the LAMMPS distribution
have an ".adp" suffix. A DYNAMO {setfl} file extended for ADP is
formatted as follows. Basically it is the standard {setfl} format
with additional tabulated functions u and w added to the file after
the tabulated pair potentials. See the "pair_eam"_pair_eam.html
command for further details on the {setfl} format.
lines 1,2,3 = comments (ignored)
line 4: Nelements Element1 Element2 ... ElementN
line 5: Nrho, drho, Nr, dr, cutoff :ul
Following the 5 header lines are Nelements sections, one for each
element, each with the following format:
line 1 = atomic number, mass, lattice constant, lattice type (e.g. FCC)
embedding function F(rho) (Nrho values)
density function rho(r) (Nr values) :ul
Following the Nelements sections, Nr values for each pair potential
phi(r) array are listed for all i,j element pairs in the same format
as other arrays. Since these interactions are symmetric (i,j = j,i)
only phi arrays with i >= j are listed, in the following order: i,j =
(1,1), (2,1), (2,2), (3,1), (3,2), (3,3), (4,1), ..., (Nelements,
Nelements). The tabulated values for each phi function are listed as
r*phi (in units of eV-Angstroms), since they are for atom pairs, the
same as for "other EAM files"_pair_eam.html.
After the phi(r) arrays, each of the u(r) arrays are listed in the
same order with the same assumptions of symmetry. Directly following
the u(r), the w(r) arrays are listed. Note that phi(r) is the only
array tabulated with a scaling by r.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, where types I and J correspond to
two different element types, no special mixing rules are needed, since
the ADP potential files specify alloy interactions explicitly.
This pair style does not support the "pair_modify"_pair_modify.html
shift, table, and tail options.
This 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.
This pair style can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. It does not support the
{inner}, {middle}, {outer} keywords.
:line
[Restrictions:]
This pair style is part of the MANYBODY package. It is only enabled
if LAMMPS was built with that package.
[Related commands:]
"pair_coeff"_pair_coeff.html, "pair_eam"_pair_eam.html
[Default:] none
:line
:link(Mishin)
[(Mishin)] Mishin, Mehl, and Papaconstantopoulos, Acta Mater, 53, 4029
(2005).
:link(Singh)
[(Singh)] Singh and Warner, Acta Mater, 58, 5797-5805 (2010),
diff --git a/doc/src/pair_agni.txt b/doc/src/pair_agni.txt
index 06dcccb9d..402e537da 100644
--- a/doc/src/pair_agni.txt
+++ b/doc/src/pair_agni.txt
@@ -1,128 +1,128 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style agni command :h3
pair_style agni/omp command :h3
[Syntax:]
pair_style agni :pre
[Examples:]
pair_style agni
pair_coeff * * Al.agni Al
[Description:]
Style {agni} style computes the manybody vectorial force components for
an atom as
:c,image(Eqs/pair_agni.jpg)
{u} labels the individual components, i.e. x, y or z, and {V} is the
corresponding atomic fingerprint. {d} is the Euclidean distance between
any two atomic fingerprints. A total of N_t reference atomic
environments are considered to construct the force field file. {alpha_t}
and {l} are the weight coefficients and length scale parameter of the
non-linear regression model.
The method implements the recently proposed machine learning access to
atomic forces as discussed extensively in the following publications -
"(Botu1)"_#Botu2015adaptive and "(Botu2)"_#Botu2015learning. The premise
of the method is to map the atomic environment numerically into a
fingerprint, and use machine learning methods to create a mapping to the
vectorial atomic forces.
Only a single pair_coeff command is used with the {agni} style which
specifies an AGNI potential file containing the parameters of the
force field for the needed elements. These are mapped to LAMMPS atom
types by specifying N additional arguments after the filename in the
pair_coeff command, where N is the number of LAMMPS atom types:
filename
N element names = mapping of AGNI elements to atom types :ul
See the "pair_coeff"_pair_coeff.html doc page for alternate ways
to specify the path for the force field file.
An AGNI force field is fully specified by the filename which contains the
parameters of the force field, i.e., the reference training environments
used to construct the machine learning force field. Example force field
and input files are provided in the examples/USER/misc/agni directory.
:line
Styles with {omp} suffix is functionally the same as the corresponding
style without the suffix. They have been optimized to run faster, depending
on your available hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated style takes the same arguments and
should produce the same results, except for round-off and precision
issues.
The accelerated style is part of the USER-OMP. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated style explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
This pair style does not support the "pair_modify"_pair_modify.html
shift, table, and tail options.
This pair style does not write its information to "binary restart
files"_restart.html, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.
This pair style can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. It does not support the
{inner}, {middle}, {outer} keywords.
:line
[Restrictions:]
Currently, only elemental systems are implemented. Also, the method only
provides access to the forces and not energies or stresses. However, one
can access the energy via thermodynamic integration of the forces as
discussed in "(Botu3)"_#Botu2016construct. This pair style is part
of the USER-MISC package. It is only enabled if LAMMPS was built with
that package. See the "Making LAMMPS"_Section_start.html#start_3 section
for more info.
The AGNI force field files provided with LAMMPS (see the
potentials directory) are parameterized for metal "units"_units.html.
You can use the AGNI potential with any LAMMPS units, but you would need
to create your own AGNI potential file with coefficients listed in the
appropriate units if your simulation doesn't use "metal" units.
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
:line
:link(Botu2015adaptive)
[(Botu1)] V. Botu and R. Ramprasad, Int. J. Quant. Chem., 115(16), 1074 (2015).
:link(Botu2015learning)
[(Botu2)] V. Botu and R. Ramprasad, Phys. Rev. B, 92(9), 094306 (2015).
:link(Botu2016construct)
[(Botu3)] V. Botu, R. Batra, J. Chapman and R. Ramprasad, https://arxiv.org/abs/1610.02098 (2016).
diff --git a/doc/src/pair_airebo.txt b/doc/src/pair_airebo.txt
index 0c03eb326..e66ecb637 100644
--- a/doc/src/pair_airebo.txt
+++ b/doc/src/pair_airebo.txt
@@ -1,243 +1,243 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style airebo command :h3
pair_style airebo/omp command :h3
pair_style airebo/morse command :h3
pair_style airebo/morse/omp command :h3
pair_style rebo command :h3
pair_style rebo/omp command :h3
[Syntax:]
pair_style style cutoff LJ_flag TORSION_flag cutoff_min :pre
style = {airebo} or {airebo/morse} or {rebo}
cutoff = LJ or Morse cutoff (sigma scale factor) (AIREBO and AIREBO-M only)
LJ_flag = 0/1 to turn off/on the LJ or Morse term (AIREBO and AIREBO-M only, optional)
TORSION_flag = 0/1 to turn off/on the torsion term (AIREBO and AIREBO-M only, optional)
cutoff_min = Start of the transition region of cutoff (sigma scale factor) (AIREBO and AIREBO-M only, optional) :ul
[Examples:]
pair_style airebo 3.0
pair_style airebo 2.5 1 0
pair_coeff * * ../potentials/CH.airebo H C :pre
pair_style airebo/morse 3.0
pair_coeff * * ../potentials/CH.airebo-m H C :pre
pair_style rebo
pair_coeff * * ../potentials/CH.airebo H C :pre
[Description:]
The {airebo} pair style computes the Adaptive Intermolecular Reactive
Empirical Bond Order (AIREBO) Potential of "(Stuart)"_#Stuart for a
system of carbon and/or hydrogen atoms. Note that this is the initial
formulation of AIREBO from 2000, not the later formulation.
The {airebo/morse} pair style computes the AIREBO-M potential, which
is equivalent to AIREBO, but replaces the LJ term with a Morse potential.
The Morse potentials are parameterized by high-quality quantum chemistry
(MP2) calculations and do not diverge as quickly as particle density
increases. This allows AIREBO-M to retain accuracy to much higher pressures
than AIREBO (up to 40 GPa for Polyethylene). Details for this potential
and its parameterization are given in "(O'Conner)"_#OConnor.
The {rebo} pair style computes the Reactive Empirical Bond Order (REBO)
Potential of "(Brenner)"_#Brenner. Note that this is the so-called
2nd generation REBO from 2002, not the original REBO from 1990.
As discussed below, 2nd generation REBO is closely related to the
initial AIREBO; it is just a subset of the potential energy terms.
The AIREBO potential consists of three terms:
:c,image(Eqs/pair_airebo.jpg)
By default, all three terms are included. For the {airebo} style, if
the first two optional flag arguments to the pair_style command are
included, the LJ and torsional terms can be turned off. Note that
both or neither of the flags must be included. If both of the LJ an
torsional terms are turned off, it becomes the 2nd-generation REBO
potential, with a small caveat on the spline fitting procedure
mentioned below. This can be specified directly as pair_style {rebo}
with no additional arguments.
The detailed formulas for this potential are given in
"(Stuart)"_#Stuart; here we provide only a brief description.
The E_REBO term has the same functional form as the hydrocarbon REBO
potential developed in "(Brenner)"_#Brenner. The coefficients for
E_REBO in AIREBO are essentially the same as Brenner's potential, but
a few fitted spline values are slightly different. For most cases the
E_REBO term in AIREBO will produce the same energies, forces and
statistical averages as the original REBO potential from which it was
derived. The E_REBO term in the AIREBO potential gives the model its
reactive capabilities and only describes short-ranged C-C, C-H and H-H
interactions (r < 2 Angstroms). These interactions have strong
coordination-dependence through a bond order parameter, which adjusts
the attraction between the I,J atoms based on the position of other
nearby atoms and thus has 3- and 4-body dependence.
The E_LJ term adds longer-ranged interactions (2 < r < cutoff) using a
form similar to the standard "Lennard Jones potential"_pair_lj.html.
The E_LJ term in AIREBO contains a series of switching functions so
that the short-ranged LJ repulsion (1/r^12) does not interfere with
the energetics captured by the E_REBO term. The extent of the E_LJ
interactions is determined by the {cutoff} argument to the pair_style
command which is a scale factor. For each type pair (C-C, C-H, H-H)
the cutoff is obtained by multiplying the scale factor by the sigma
value defined in the potential file for that type pair. In the
standard AIREBO potential, sigma_CC = 3.4 Angstroms, so with a scale
factor of 3.0 (the argument in pair_style), the resulting E_LJ cutoff
would be 10.2 Angstroms.
By default, the longer-ranged interaction is smoothly switched off
between 2.16 and 3.0 sigma. By specifying {cutoff_min} in addition
to {cutoff}, the switching can be configured to take place between
{cutoff_min} and {cutoff}. {cutoff_min} can only be specified if all
optional arguments are given.
The E_TORSION term is an explicit 4-body potential that describes
various dihedral angle preferences in hydrocarbon configurations.
:line
Only a single pair_coeff command is used with the {airebo}, {airebo}
or {rebo} style which specifies an AIREBO or AIREBO-M potential file
with parameters for C and H. Note that the {rebo} style in LAMMPS
uses the same AIREBO-formatted potential file. These are mapped to
LAMMPS atom types by specifying N additional arguments after the
filename in the pair_coeff command, where N is the number of LAMMPS
atom types:
filename
N element names = mapping of AIREBO elements to atom types :ul
See the "pair_coeff"_pair_coeff.html doc page for alternate ways
to specify the path for the potential file.
As an example, if your LAMMPS simulation has 4 atom types and you want
the 1st 3 to be C, and the 4th to be H, you would use the following
pair_coeff command:
pair_coeff * * CH.airebo C C C H :pre
The 1st 2 arguments must be * * so as to span all LAMMPS atom types.
The first three C arguments map LAMMPS atom types 1,2,3 to the C
element in the AIREBO file. The final H argument maps LAMMPS atom
type 4 to the H element in the SW file. If a mapping value is
specified as NULL, the mapping is not performed. This can be used
when a {airebo} potential is used as part of the {hybrid} pair style.
The NULL values are placeholders for atom types that will be used with
other potentials.
The parameters/coefficients for the AIREBO potentials are listed in
the CH.airebo file to agree with the original "(Stuart)"_#Stuart
paper. Thus the parameters are specific to this potential and the way
it was fit, so modifying the file should be done cautiously.
Similarly the parameters/coefficients for the AIREBO-M potentials are
listed in the CH.airebo-m file to agree with the "(O'Connor)"_#OConnor
paper. Thus the parameters are specific to this potential and the way
it was fit, so modifying the file should be done cautiously. The
AIREBO-M Morse potentials were parameterized using a cutoff of
3.0 (sigma). Modifying this cutoff may impact simulation accuracy.
This pair style tallies a breakdown of the total AIREBO potential
energy into sub-categories, which can be accessed via the "compute
pair"_compute_pair.html command as a vector of values of length 3.
The 3 values correspond to the following sub-categories:
{E_REBO} = REBO energy
{E_LJ} = Lennard-Jones energy
{E_TORSION} = Torsion energy :ol
To print these quantities to the log file (with descriptive column
headings) the following commands could be included in an input script:
compute 0 all pair airebo
variable REBO equal c_0\[1\]
variable LJ equal c_0\[2\]
variable TORSION equal c_0\[3\]
thermo_style custom step temp epair v_REBO v_LJ v_TORSION :pre
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
These pair styles do not support the "pair_modify"_pair_modify.html
mix, shift, table, and tail options.
These pair styles do not write their information to "binary restart
files"_restart.html, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.
These pair styles can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. They do not support the
{inner}, {middle}, {outer} keywords.
[Restrictions:]
These pair styles are part of the MANYBODY package. They are only
enabled if LAMMPS was built with that package. See the
"Making LAMMPS"_Section_start.html#start_3 section for more info.
These pair potentials require the "newton"_newton.html setting to be
"on" for pair interactions.
The CH.airebo and CH.airebo-m potential files provided with LAMMPS
(see the potentials directory) are parameterized for metal "units"_units.html.
You can use the AIREBO, AIREBO-M or REBO potential with any LAMMPS units,
but you would need to create your own AIREBO or AIREBO-M potential file
with coefficients listed in the appropriate units, if your simulation
doesn't use "metal" units.
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
:line
:link(Stuart)
[(Stuart)] Stuart, Tutein, Harrison, J Chem Phys, 112, 6472-6486
(2000).
:link(Brenner)
[(Brenner)] Brenner, Shenderova, Harrison, Stuart, Ni, Sinnott, J
Physics: Condensed Matter, 14, 783-802 (2002).
:link(OConnor)
[(O'Connor)] O'Connor et al., J. Chem. Phys. 142, 024903 (2015).
diff --git a/doc/src/pair_beck.txt b/doc/src/pair_beck.txt
index 4e792754b..e160f09b3 100644
--- a/doc/src/pair_beck.txt
+++ b/doc/src/pair_beck.txt
@@ -1,109 +1,109 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style beck command :h3
pair_style beck/gpu command :h3
pair_style beck/omp command :h3
[Syntax:]
pair_style beck Rc :pre
Rc = cutoff for interactions (distance units) :ul
[Examples:]
pair_style beck 8.0
pair_coeff * * 399.671876712 0.0000867636112694 0.675 4.390 0.0003746
pair_coeff 1 1 399.671876712 0.0000867636112694 0.675 4.390 0.0003746 6.0 :pre
[Description:]
Style {beck} computes interactions based on the potential by
"(Beck)"_#Beck, originally designed for simulation of Helium. It
includes truncation at a cutoff distance Rc.
:c,image(Eqs/pair_beck.jpg)
The following coefficients must be defined for each pair of atoms
types via the "pair_coeff"_pair_coeff.html command as in the examples
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands.
A (energy units)
B (energy-distance^6 units)
a (distance units)
alpha (1/distance units)
beta (1/distance^6 units)
cutoff (distance units) :ul
The last coefficient is optional. If not specified, the global cutoff
Rc is used.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, coefficients must be specified.
No default mixing rules are used.
This pair style does not support the "pair_modify"_pair_modify.html shift
option for the energy of the pair interaction.
The "pair_modify"_pair_modify.html table option is not relevant
for this pair style.
This pair style does not support the "pair_modify"_pair_modify.html
tail option for adding long-range tail corrections.
This pair style writes its information to "binary restart
files"_restart.html, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.
This pair style can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. It does not support the
{inner}, {middle}, {outer} keywords.
:line
[Restrictions:] none
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
:line
:link(Beck)
[(Beck)] Beck, Molecular Physics, 14, 311 (1968).
diff --git a/doc/src/pair_born.txt b/doc/src/pair_born.txt
index d38d9e319..a3cc744a2 100644
--- a/doc/src/pair_born.txt
+++ b/doc/src/pair_born.txt
@@ -1,205 +1,205 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style born command :h3
pair_style born/omp command :h3
pair_style born/gpu command :h3
pair_style born/coul/long command :h3
pair_style born/coul/long/cs command :h3
pair_style born/coul/long/gpu command :h3
pair_style born/coul/long/omp command :h3
pair_style born/coul/msm command :h3
pair_style born/coul/msm/omp command :h3
pair_style born/coul/wolf command :h3
pair_style born/coul/wolf/gpu command :h3
pair_style born/coul/wolf/omp command :h3
pair_style born/coul/dsf command :h3
pair_style born/coul/dsf/cs command :h3
[Syntax:]
pair_style style args :pre
style = {born} or {born/coul/long} or {born/coul/long/cs} or {born/coul/msm} or {born/coul/wolf}
args = list of arguments for a particular style :ul
{born} args = cutoff
cutoff = global cutoff for non-Coulombic interactions (distance units)
{born/coul/long} or {born/coul/long/cs} args = cutoff (cutoff2)
cutoff = global cutoff for non-Coulombic (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{born/coul/msm} args = cutoff (cutoff2)
cutoff = global cutoff for non-Coulombic (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{born/coul/wolf} args = alpha cutoff (cutoff2)
alpha = damping parameter (inverse distance units)
cutoff = global cutoff for non-Coulombic (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{born/coul/dsf} or {born/coul/dsf/cs} args = alpha cutoff (cutoff2)
alpha = damping parameter (inverse distance units)
cutoff = global cutoff for non-Coulombic (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (distance units) :pre
[Examples:]
pair_style born 10.0
pair_coeff * * 6.08 0.317 2.340 24.18 11.51
pair_coeff 1 1 6.08 0.317 2.340 24.18 11.51 :pre
pair_style born/coul/long 10.0
pair_style born/coul/long/cs 10.0
pair_style born/coul/long 10.0 8.0
pair_style born/coul/long/cs 10.0 8.0
pair_coeff * * 6.08 0.317 2.340 24.18 11.51
pair_coeff 1 1 6.08 0.317 2.340 24.18 11.51 :pre
pair_style born/coul/msm 10.0
pair_style born/coul/msm 10.0 8.0
pair_coeff * * 6.08 0.317 2.340 24.18 11.51
pair_coeff 1 1 6.08 0.317 2.340 24.18 11.51 :pre
pair_style born/coul/wolf 0.25 10.0
pair_style born/coul/wolf 0.25 10.0 9.0
pair_coeff * * 6.08 0.317 2.340 24.18 11.51
pair_coeff 1 1 6.08 0.317 2.340 24.18 11.51 :pre
pair_style born/coul/dsf 0.1 10.0 12.0
pair_coeff * * 0.0 1.00 0.00 0.00 0.00
pair_coeff 1 1 480.0 0.25 0.00 1.05 0.50 :pre
[Description:]
The {born} style computes the Born-Mayer-Huggins or Tosi/Fumi
potential described in "(Fumi and Tosi)"_#FumiTosi, given by
:c,image(Eqs/pair_born.jpg)
where sigma is an interaction-dependent length parameter, rho is an
ionic-pair dependent length parameter, and Rc is the cutoff.
The styles with {coul/long} or {coul/msm} add a Coulombic term as
described for the "lj/cut"_pair_lj.html pair styles. An additional
damping factor is applied to the Coulombic term so it can be used in
conjunction with the "kspace_style"_kspace_style.html command and its
{ewald} or {pppm} of {msm} option. The Coulombic cutoff specified for
this style means that pairwise interactions within this distance are
computed directly; interactions outside that distance are computed in
reciprocal space.
If one cutoff is specified for the {born/coul/long} and
{born/coul/msm} style, it is used for both the A,C,D and Coulombic
terms. If two cutoffs are specified, the first is used as the cutoff
for the A,C,D terms, and the second is the cutoff for the Coulombic
term.
The {born/coul/wolf} style adds a Coulombic term as described for the
Wolf potential in the "coul/wolf"_pair_coul.html pair style.
The {born/coul/dsf} style computes the Coulomb contribution with the
damped shifted force model as in the "coul/dsf"_pair_coul.html style.
Style {born/coul/long/cs} is identical to {born/coul/long} except that
a term is added for the "core/shell model"_Section_howto.html#howto_25
to allow charges on core and shell particles to be separated by r =
0.0. The same correction is introduced for {born/coul/dsf/cs} style
which is identical to {born/coul/dsf}.
Note that these potentials are related to the "Buckingham
potential"_pair_buck.html.
The following coefficients must be defined for each pair of atoms
types via the "pair_coeff"_pair_coeff.html command as in the examples
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands, or by mixing as described below:
A (energy units)
rho (distance units)
sigma (distance units)
C (energy units * distance units^6)
D (energy units * distance units^8)
cutoff (distance units) :ul
The second coefficient, rho, must be greater than zero.
The last coefficient is optional. If not specified, the global A,C,D
cutoff specified in the pair_style command is used.
For {born/coul/long}, {born/coul/wolf} and {born/coul/dsf} no
Coulombic cutoff can be specified for an individual I,J type pair.
All type pairs use the same global Coulombic cutoff specified in the
pair_style command.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
These pair styles do not support mixing. Thus, coefficients for all
I,J pairs must be specified explicitly.
These styles support the "pair_modify"_pair_modify.html shift option
for the energy of the exp(), 1/r^6, and 1/r^8 portion of the pair
interaction.
The {born/coul/long} pair style supports the
"pair_modify"_pair_modify.html table option ti tabulate the
short-range portion of the long-range Coulombic interaction.
These styles support the pair_modify tail option for adding long-range
tail corrections to energy and pressure.
Thess styles writes thei information to binary "restart"_restart.html
files, so pair_style and pair_coeff commands do not need to be
specified in an input script that reads a restart file.
These styles can only be used via the {pair} keyword of the "run_style
respa"_run_style.html command. They do not support the {inner},
{middle}, {outer} keywords.
:line
[Restrictions:]
The {born/coul/long} style is part of the KSPACE package. It is only
enabled if LAMMPS was built with that package. See the
"Making LAMMPS"_Section_start.html#start_3 section for more info.
[Related commands:]
"pair_coeff"_pair_coeff.html, "pair_style buck"_pair_buck.html
[Default:] none
:line
:link(FumiTosi)
Fumi and Tosi, J Phys Chem Solids, 25, 31 (1964),
Fumi and Tosi, J Phys Chem Solids, 25, 45 (1964).
diff --git a/doc/src/pair_brownian.txt b/doc/src/pair_brownian.txt
index 33eed7762..79b71e91c 100644
--- a/doc/src/pair_brownian.txt
+++ b/doc/src/pair_brownian.txt
@@ -1,143 +1,143 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style brownian command :h3
pair_style brownian/omp command :h3
pair_style brownian/poly command :h3
pair_style brownian/poly/omp command :h3
[Syntax:]
pair_style style mu flaglog flagfld cutinner cutoff t_target seed flagHI flagVF :pre
style = {brownian} or {brownian/poly}
mu = dynamic viscosity (dynamic viscosity units)
flaglog = 0/1 log terms in the lubrication approximation on/off
flagfld = 0/1 to include/exclude Fast Lubrication Dynamics effects
cutinner = inner cutoff distance (distance units)
cutoff = outer cutoff for interactions (distance units)
t_target = target temp of the system (temperature units)
seed = seed for the random number generator (positive integer)
flagHI (optional) = 0/1 to include/exclude 1/r hydrodynamic interactions
flagVF (optional) = 0/1 to include/exclude volume fraction corrections in the long-range isotropic terms :ul
[Examples:]
pair_style brownian 1.5 1 1 2.01 2.5 2.0 5878567 (assuming radius = 1)
pair_coeff 1 1 2.05 2.8
pair_coeff * * :pre
[Description:]
Styles {brownian} and {brownian/poly} compute Brownian forces and
torques on finite-size spherical particles. The former requires
monodisperse spherical particles; the latter allows for polydisperse
spherical particles.
These pair styles are designed to be used with either the "pair_style
lubricate"_pair_lubricate.html or "pair_style
lubricateU"_pair_lubricateU.html commands to provide thermostatting
when dissipative lubrication forces are acting. Thus the parameters
{mu}, {flaglog}, {flagfld}, {cutinner}, and {cutoff} should be
specified consistent with the settings in the lubrication pair styles.
For details, refer to either of the lubrication pair styles.
The {t_target} setting is used to specify the target temperature of
the system. The random number {seed} is used to generate random
numbers for the thermostatting procedure.
The {flagHI} and {flagVF} settings are optional. Neither should be
used, or both must be defined.
:line
The following coefficients must be defined for each pair of atoms
types via the "pair_coeff"_pair_coeff.html command as in the examples
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands, or by mixing as described below:
cutinner (distance units)
cutoff (distance units) :ul
The two coefficients are optional. If neither is specified, the two
cutoffs specified in the pair_style command are used. Otherwise both
must be specified.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "this section"_Section_accelerate.html of
the manual. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "this section"_Section_accelerate.html of the manual for more
instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, the two cutoff distances for this
pair style can be mixed. The default mix value is {geometric}. See
the "pair_modify" command for details.
This pair style does not support the "pair_modify"_pair_modify.html
shift option for the energy of the pair interaction.
The "pair_modify"_pair_modify.html table option is not relevant
for this pair style.
This pair style does not support the "pair_modify"_pair_modify.html
tail option for adding long-range tail corrections to energy and
pressure.
This pair style writes its information to "binary restart
files"_restart.html, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.
This pair style can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. It does not support the
{inner}, {middle}, {outer} keywords.
:line
[Restrictions:]
These styles are part of the COLLOID package. They are only enabled
if LAMMPS was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
Only spherical monodisperse particles are allowed for pair_style
brownian.
Only spherical particles are allowed for pair_style brownian/poly.
[Related commands:]
"pair_coeff"_pair_coeff.html, "pair_style
lubricate"_pair_lubricate.html, "pair_style
lubricateU"_pair_lubricateU.html
[Default:]
The default settings for the optional args are flagHI = 1 and flagVF =
1.
diff --git a/doc/src/pair_buck.txt b/doc/src/pair_buck.txt
index e705e735f..d18b39d5d 100644
--- a/doc/src/pair_buck.txt
+++ b/doc/src/pair_buck.txt
@@ -1,201 +1,201 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style buck command :h3
pair_style buck/gpu command :h3
pair_style buck/intel command :h3
pair_style buck/kk command :h3
pair_style buck/omp command :h3
pair_style buck/coul/cut command :h3
pair_style buck/coul/cut/gpu command :h3
pair_style buck/coul/cut/intel command :h3
pair_style buck/coul/cut/kk command :h3
pair_style buck/coul/cut/omp command :h3
pair_style buck/coul/long command :h3
pair_style buck/coul/long/cs command :h3
pair_style buck/coul/long/gpu command :h3
pair_style buck/coul/long/intel command :h3
pair_style buck/coul/long/kk command :h3
pair_style buck/coul/long/omp command :h3
pair_style buck/coul/msm command :h3
pair_style buck/coul/msm/omp command :h3
[Syntax:]
pair_style style args :pre
style = {buck} or {buck/coul/cut} or {buck/coul/long} or {buck/coul/long/cs} or {buck/coul/msm}
args = list of arguments for a particular style :ul
{buck} args = cutoff
cutoff = global cutoff for Buckingham interactions (distance units)
{buck/coul/cut} args = cutoff (cutoff2)
cutoff = global cutoff for Buckingham (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{buck/coul/long} or {buck/coul/long/cs} args = cutoff (cutoff2)
cutoff = global cutoff for Buckingham (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{buck/coul/msm} args = cutoff (cutoff2)
cutoff = global cutoff for Buckingham (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units) :pre
[Examples:]
pair_style buck 2.5
pair_coeff * * 100.0 1.5 200.0
pair_coeff * * 100.0 1.5 200.0 3.0 :pre
pair_style buck/coul/cut 10.0
pair_style buck/coul/cut 10.0 8.0
pair_coeff * * 100.0 1.5 200.0
pair_coeff 1 1 100.0 1.5 200.0 9.0
pair_coeff 1 1 100.0 1.5 200.0 9.0 8.0 :pre
pair_style buck/coul/long 10.0
pair_style buck/coul/long/cs 10.0
pair_style buck/coul/long 10.0 8.0
pair_style buck/coul/long/cs 10.0 8.0
pair_coeff * * 100.0 1.5 200.0
pair_coeff 1 1 100.0 1.5 200.0 9.0 :pre
pair_style buck/coul/msm 10.0
pair_style buck/coul/msm 10.0 8.0
pair_coeff * * 100.0 1.5 200.0
pair_coeff 1 1 100.0 1.5 200.0 9.0 :pre
[Description:]
The {buck} style computes a Buckingham potential (exp/6 instead of
Lennard-Jones 12/6) given by
:c,image(Eqs/pair_buck.jpg)
where rho is an ionic-pair dependent length parameter, and Rc is the
cutoff on both terms.
The styles with {coul/cut} or {coul/long} or {coul/msm} add a
Coulombic term as described for the "lj/cut"_pair_lj.html pair styles.
For {buck/coul/long} and {buc/coul/msm}, an additional damping factor
is applied to the Coulombic term so it can be used in conjunction with
the "kspace_style"_kspace_style.html command and its {ewald} or {pppm}
or {msm} option. The Coulombic cutoff specified for this style means
that pairwise interactions within this distance are computed directly;
interactions outside that distance are computed in reciprocal space.
If one cutoff is specified for the {born/coul/cut} and
{born/coul/long} and {born/coul/msm} styles, it is used for both the
A,C and Coulombic terms. If two cutoffs are specified, the first is
used as the cutoff for the A,C terms, and the second is the cutoff for
the Coulombic term.
Style {buck/coul/long/cs} is identical to {buck/coul/long} except that
a term is added for the "core/shell model"_Section_howto.html#howto_25
to allow charges on core and shell particles to be separated by r =
0.0.
Note that these potentials are related to the "Born-Mayer-Huggins
potential"_pair_born.html.
NOTE: For all these pair styles, the terms with A and C are always
cutoff. The additional Coulombic term can be cutoff or long-range (no
cutoff) depending on whether the style name includes coul/cut or
coul/long or coul/msm. If you wish the C/r^6 term to be long-range
(no cutoff), then see the "pair_style
buck/long/coul/long"_pair_buck_long.html command.
The following coefficients must be defined for each pair of atoms
types via the "pair_coeff"_pair_coeff.html command as in the examples
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands:
A (energy units)
rho (distance units)
C (energy-distance^6 units)
cutoff (distance units)
cutoff2 (distance units) :ul
The second coefficient, rho, must be greater than zero.
The coefficients A, rho, and C can be written as analytical expressions
of epsilon and sigma, in analogy to the Lennard-Jones potential
"(Khrapak)"_#Khrapak.
The latter 2 coefficients are optional. If not specified, the global
A,C and Coulombic cutoffs are used. If only one cutoff is specified,
it is used as the cutoff for both A,C and Coulombic interactions for
this type pair. If both coefficients are specified, they are used as
the A,C and Coulombic cutoffs for this type pair. You cannot specify
2 cutoffs for style {buck}, since it has no Coulombic terms.
For {buck/coul/long} only the LJ cutoff can be specified since a
Coulombic cutoff cannot be specified for an individual I,J type pair.
All type pairs use the same global Coulombic cutoff specified in the
pair_style command.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
These pair styles do not support mixing. Thus, coefficients for all
I,J pairs must be specified explicitly.
These styles support the "pair_modify"_pair_modify.html shift option
for the energy of the exp() and 1/r^6 portion of the pair interaction.
The {buck/coul/long} pair style supports the
"pair_modify"_pair_modify.html table option to tabulate the
short-range portion of the long-range Coulombic interaction.
These styles support the pair_modify tail option for adding long-range
tail corrections to energy and pressure for the A,C terms in the
pair interaction.
These styles write their information to "binary restart
files"_restart.html, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.
These styles can only be used via the {pair} keyword of the "run_style
respa"_run_style.html command. They do not support the {inner},
{middle}, {outer} keywords.
[Restrictions:]
The {buck/coul/long} style is part of the KSPACE package. The
{buck/coul/long/cs} style is part of the CORESHELL package. They are
only enabled if LAMMPS was built with that package. See the
"Making LAMMPS"_Section_start.html#start_3 section for more info.
[Related commands:]
"pair_coeff"_pair_coeff.html, "pair_style born"_pair_born.html
[Default:] none
:link(Khrapak)
[(Khrapak)] Khrapak, Chaudhuri, and Morfill, J Chem Phys, 134, 054120 (2011).
diff --git a/doc/src/pair_buck_long.txt b/doc/src/pair_buck_long.txt
index ba18738e4..05e760e1b 100644
--- a/doc/src/pair_buck_long.txt
+++ b/doc/src/pair_buck_long.txt
@@ -1,171 +1,171 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style buck/long/coul/long command :h3
pair_style buck/long/coul/long/omp command :h3
[Syntax:]
pair_style buck/long/coul/long flag_buck flag_coul cutoff (cutoff2) :pre
flag_buck = {long} or {cut} :ulb,l
{long} = use Kspace long-range summation for the dispersion term 1/r^6
{cut} = use a cutoff :pre
flag_coul = {long} or {off} :l
{long} = use Kspace long-range summation for the Coulombic term 1/r
{off} = omit the Coulombic term :pre
cutoff = global cutoff for Buckingham (and Coulombic if only 1 cutoff) (distance units) :l
cutoff2 = global cutoff for Coulombic (optional) (distance units) :l
:ule
[Examples:]
pair_style buck/long/coul/long cut off 2.5
pair_style buck/long/coul/long cut long 2.5 4.0
pair_style buck/long/coul/long long long 4.0
pair_coeff * * 1 1
pair_coeff 1 1 1 3 4 :pre
[Description:]
The {buck/long/coul/long} style computes a Buckingham potential (exp/6
instead of Lennard-Jones 12/6) and Coulombic potential, given by
:c,image(Eqs/pair_buck.jpg)
:c,image(Eqs/pair_coulomb.jpg)
Rc is the cutoff. If one cutoff is specified in the pair_style
command, it is used for both the Buckingham and Coulombic terms. If
two cutoffs are specified, they are used as cutoffs for the Buckingham
and Coulombic terms respectively.
The purpose of this pair style is to capture long-range interactions
resulting from both attractive 1/r^6 Buckingham and Coulombic 1/r
interactions. This is done by use of the {flag_buck} and {flag_coul}
settings. The "Ismail"_#Ismail paper has more details on when it is
appropriate to include long-range 1/r^6 interactions, using this
potential.
If {flag_buck} is set to {long}, no cutoff is used on the Buckingham
1/r^6 dispersion term. The long-range portion can be calculated by
using the "kspace_style ewald/disp or pppm/disp"_kspace_style.html
commands. The specified Buckingham cutoff then determines which
portion of the Buckingham interactions are computed directly by the
pair potential versus which part is computed in reciprocal space via
the Kspace style. If {flag_buck} is set to {cut}, the Buckingham
interactions are simply cutoff, as with "pair_style
buck"_pair_buck.html.
If {flag_coul} is set to {long}, no cutoff is used on the Coulombic
interactions. The long-range portion can calculated by using any of
several "kspace_style"_kspace_style.html command options such as
{pppm} or {ewald}. Note that if {flag_buck} is also set to long, then
the {ewald/disp} or {pppm/disp} Kspace style needs to be used to
perform the long-range calculations for both the Buckingham and
Coulombic interactions. If {flag_coul} is set to {off}, Coulombic
interactions are not computed.
The following coefficients must be defined for each pair of atoms
types via the "pair_coeff"_pair_coeff.html command as in the examples
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands:
A (energy units)
rho (distance units)
C (energy-distance^6 units)
cutoff (distance units)
cutoff2 (distance units) :ul
The second coefficient, rho, must be greater than zero.
The latter 2 coefficients are optional. If not specified, the global
Buckingham and Coulombic cutoffs specified in the pair_style command
are used. If only one cutoff is specified, it is used as the cutoff
for both Buckingham and Coulombic interactions for this type pair. If
both coefficients are specified, they are used as the Buckingham and
Coulombic cutoffs for this type pair. Note that if you are using
{flag_buck} set to {long}, you cannot specify a Buckingham cutoff for
an atom type pair, since only one global Buckingham cutoff is allowed.
Similarly, if you are using {flag_coul} set to {long}, you cannot
specify a Coulombic cutoff for an atom type pair, since only one
global Coulombic cutoff is allowed.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
This pair styles does not support mixing. Thus, coefficients for all
I,J pairs must be specified explicitly.
This pair style supports the "pair_modify"_pair_modify.html shift
option for the energy of the exp() and 1/r^6 portion of the pair
interaction, assuming {flag_buck} is {cut}.
This pair style does not support the "pair_modify"_pair_modify.html
shift option for the energy of the Buckingham portion of the pair
interaction.
This pair style supports the "pair_modify"_pair_modify.html table and
table/disp options since they can tabulate the short-range portion of
the long-range Coulombic and dispersion interactions.
This pair style write its information to "binary restart
files"_restart.html, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.
This pair style supports the use of the {inner}, {middle}, and {outer}
keywords of the "run_style respa"_run_style.html command, meaning the
pairwise forces can be partitioned by distance at different levels of
the rRESPA hierarchy. See the "run_style"_run_style.html command for
details.
:line
[Restrictions:]
This style is part of the KSPACE package. It is only enabled if
LAMMPS was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info. Note that
the KSPACE package is installed by default.
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
:line
:link(Ismail)
[(Ismail)] Ismail, Tsige, In 't Veld, Grest, Molecular Physics
(accepted) (2007).
diff --git a/doc/src/pair_charmm.txt b/doc/src/pair_charmm.txt
index 1e78607c0..ef4ef41c9 100644
--- a/doc/src/pair_charmm.txt
+++ b/doc/src/pair_charmm.txt
@@ -1,269 +1,269 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style lj/charmm/coul/charmm command :h3
pair_style lj/charmm/coul/charmm/omp command :h3
pair_style lj/charmm/coul/charmm/implicit command :h3
pair_style lj/charmm/coul/charmm/implicit/omp command :h3
pair_style lj/charmm/coul/long command :h3
pair_style lj/charmm/coul/long/gpu command :h3
pair_style lj/charmm/coul/long/intel command :h3
pair_style lj/charmm/coul/long/opt command :h3
pair_style lj/charmm/coul/long/omp command :h3
pair_style lj/charmm/coul/msm command :h3
pair_style lj/charmm/coul/msm/omp command :h3
pair_style lj/charmmfsw/coul/charmmfsh command :h3
pair_style lj/charmmfsw/coul/long command :h3
[Syntax:]
pair_style style args :pre
style = {lj/charmm/coul/charmm} or {lj/charmm/coul/charmm/implicit} or {lj/charmm/coul/long} or {lj/charmm/coul/msm} or {lj/charmmfsw/coul/charmmfsh} or {lj/charmmfsw/coul/long}
args = list of arguments for a particular style :ul
{lj/charmm/coul/charmm} args = inner outer (inner2) (outer2)
inner, outer = global switching cutoffs for Lennard Jones (and Coulombic if only 2 args)
inner2, outer2 = global switching cutoffs for Coulombic (optional)
{lj/charmm/coul/charmm/implicit} args = inner outer (inner2) (outer2)
inner, outer = global switching cutoffs for LJ (and Coulombic if only 2 args)
inner2, outer2 = global switching cutoffs for Coulombic (optional)
{lj/charmm/coul/long} args = inner outer (cutoff)
inner, outer = global switching cutoffs for LJ (and Coulombic if only 2 args)
cutoff = global cutoff for Coulombic (optional, outer is Coulombic cutoff if only 2 args)
{lj/charmm/coul/msm} args = inner outer (cutoff)
inner, outer = global switching cutoffs for LJ (and Coulombic if only 2 args)
cutoff = global cutoff for Coulombic (optional, outer is Coulombic cutoff if only 2 args)
{lj/charmmfsw/coul/charmmfsh} args = inner outer (cutoff)
inner, outer = global cutoffs for LJ (and Coulombic if only 2 args)
cutoff = global cutoff for Coulombic (optional, outer is Coulombic cutoff if only 2 args)
{lj/charmmfsw/coul/long} args = inner outer (cutoff)
inner, outer = global cutoffs for LJ (and Coulombic if only 2 args)
cutoff = global cutoff for Coulombic (optional, outer is Coulombic cutoff if only 2 args) :pre
[Examples:]
pair_style lj/charmm/coul/charmm 8.0 10.0
pair_style lj/charmm/coul/charmm 8.0 10.0 7.0 9.0
pair_style lj/charmmfsw/coul/charmmfsh 10.0 12.0
pair_style lj/charmmfsw/coul/charmmfsh 10.0 12.0 9.0
pair_coeff * * 100.0 2.0
pair_coeff 1 1 100.0 2.0 150.0 3.5 :pre
pair_style lj/charmm/coul/charmm/implicit 8.0 10.0
pair_style lj/charmm/coul/charmm/implicit 8.0 10.0 7.0 9.0
pair_coeff * * 100.0 2.0
pair_coeff 1 1 100.0 2.0 150.0 3.5 :pre
pair_style lj/charmm/coul/long 8.0 10.0
pair_style lj/charmm/coul/long 8.0 10.0 9.0
pair_style lj/charmmfsw/coul/long 8.0 10.0
pair_style lj/charmmfsw/coul/long 8.0 10.0 9.0
pair_coeff * * 100.0 2.0
pair_coeff 1 1 100.0 2.0 150.0 3.5 :pre
pair_style lj/charmm/coul/msm 8.0 10.0
pair_style lj/charmm/coul/msm 8.0 10.0 9.0
pair_coeff * * 100.0 2.0
pair_coeff 1 1 100.0 2.0 150.0 3.5 :pre
[Description:]
These pair styles compute Lennard Jones (LJ) and Coulombic
interactions with additional switching or shifting functions that ramp
the energy and/or force smoothly to zero between an inner and outer
cutoff. They are implementations of the widely used CHARMM force
field used in the "CHARMM"_http://www.scripps.edu/brooks MD code (and
others). See "(MacKerell)"_#pair-MacKerell for a description of the
CHARMM force field.
The styles with {charmm} (not {charmmfsw} or {charmmfsh}) in their
name are the older, original LAMMPS implementations. They compute the
LJ and Coulombic interactions with an energy switching function (esw,
shown in the formula below as S(r)), which ramps the energy smoothly
to zero between the inner and outer cutoff. This can cause
irregularities in pair-wise forces (due to the discontinuous 2nd
derivative of energy at the boundaries of the switching region), which
in some cases can result in detectable artifacts in an MD simulation.
The newer styles with {charmmfsw} or {charmmfsh} in their name replace
the energy switching with force switching (fsw) and force shifting
(fsh) functions, for LJ and Coulombic interactions respectively.
These follow the formulas and description given in
"(Steinbach)"_#Steinbach and "(Brooks)"_#Brooks1 to minimize these
artifacts.
NOTE: The newer {charmmfsw} or {charmmfsh} styles were released in
March 2017. We recommend they be used instead of the older {charmm}
styles. This includes the newer "dihedral_style
charmmfsw"_dihedral_charmm.html command. Eventually code from the new
styles will propagate into the related pair styles (e.g. implicit,
accelerator, free energy variants).
NOTE: The newest CHARMM pair styles reset the Coulombic energy
conversion factor used internally in the code, from the LAMMPS value
to the CHARMM value, as if it were effectively a parameter of the
force field. This is because the CHARMM code uses a slightly
different value for the this conversion factor in "real
units"_units.html (Kcal/mole), namely CHARMM = 332.0716, LAMMPS =
332.06371. This is to enable more precise agreement by LAMMPS with
the CHARMM force field energies and forces, when using one of these
two CHARMM pair styles.
:c,image(Eqs/pair_charmm.jpg)
where S(r) is the energy switching function mentioned above for the
{charmm} styles. See the "(Steinbach)"_#Steinbach paper for the
functional forms of the force switching and force shifting functions
used in the {charmmfsw} and {charmmfsh} styles.
When using the {lj/charmm/coul/charmm styles}, both the LJ and
Coulombic terms require an inner and outer cutoff. They can be the
same for both formulas or different depending on whether 2 or 4
arguments are used in the pair_style command. For the
{lj/charmmfsw/coul/charmmfsh} style, the LJ term requires both an
inner and outer cutoff, while the Coulombic term requires only one
cutoff. If the Coulomb cutoff is not specified (2 instead of 3
arguments), the LJ outer cutoff is used for the Coulombic cutoff. In
all cases where an inner and outer cutoff are specified, the inner
cutoff distance must be less than the outer cutoff. It is typical to
make the difference between the inner and outer cutoffs about 2.0
Angstroms.
Style {lj/charmm/coul/charmm/implicit} computes the same formulas as
style {lj/charmm/coul/charmm} except that an additional 1/r term is
included in the Coulombic formula. The Coulombic energy thus varies
as 1/r^2. This is effectively a distance-dependent dielectric term
which is a simple model for an implicit solvent with additional
screening. It is designed for use in a simulation of an unsolvated
biomolecule (no explicit water molecules).
Styles {lj/charmm/coul/long} and {lj/charmm/coul/msm} compute the same
formulas as style {lj/charmm/coul/charmm} and style
{lj/charmmfsw/coul/long} computes the same formulas as style
{lj/charmmfsw/coul/charmmfsh}, except that an additional damping
factor is applied to the Coulombic term, so it can be used in
conjunction with the "kspace_style"_kspace_style.html command and its
{ewald} or {pppm} or {msm} option. Only one Coulombic cutoff is
specified for these styles; if only 2 arguments are used in the
pair_style command, then the outer LJ cutoff is used as the single
Coulombic cutoff. The Coulombic cutoff specified for these styles
means that pairwise interactions within this distance are computed
directly; interactions outside that distance are computed in
reciprocal space.
The following coefficients must be defined for each pair of atoms
types via the "pair_coeff"_pair_coeff.html command as in the examples
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands, or by mixing as described below:
epsilon (energy units)
sigma (distance units)
epsilon_14 (energy units)
sigma_14 (distance units) :ul
Note that sigma is defined in the LJ formula as the zero-crossing
distance for the potential, not as the energy minimum at 2^(1/6)
sigma.
The latter 2 coefficients are optional. If they are specified, they
are used in the LJ formula between 2 atoms of these types which are
also first and fourth atoms in any dihedral. No cutoffs are specified
because the CHARMM force field does not allow varying cutoffs for
individual atom pairs; all pairs use the global cutoff(s) specified in
the pair_style command.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, the epsilon, sigma, epsilon_14,
and sigma_14 coefficients for all of the lj/charmm pair styles can be
mixed. The default mix value is {arithmetic} to coincide with the
usual settings for the CHARMM force field. See the "pair_modify"
command for details.
None of the {lj/charmm} or {lj/charmmfsw} pair styles support the
"pair_modify"_pair_modify.html shift option, since the Lennard-Jones
portion of the pair interaction is smoothed to 0.0 at the cutoff.
The {lj/charmm/coul/long} and {lj/charmmfsw/coul/long} styles support
the "pair_modify"_pair_modify.html table option since they can
tabulate the short-range portion of the long-range Coulombic
interaction.
None of the {lj/charmm} or {lj/charmmfsw} pair styles support the
"pair_modify"_pair_modify.html tail option for adding long-range tail
corrections to energy and pressure, since the Lennard-Jones portion of
the pair interaction is smoothed to 0.0 at the cutoff.
All of the {lj/charmm} and {lj/charmmfsw} pair styles write their
information to "binary restart files"_restart.html, so pair_style and
pair_coeff commands do not need to be specified in an input script
that reads a restart file.
The {lj/charmm/coul/long} and {lj/charmmfsw/coul/long} pair styles
support the use of the {inner}, {middle}, and {outer} keywords of the
"run_style respa"_run_style.html command, meaning the pairwise forces
can be partitioned by distance at different levels of the rRESPA
hierarchy. The other styles only support the {pair} keyword of
run_style respa. See the "run_style"_run_style.html command for
details.
:line
[Restrictions:]
All the styles with {coul/charmm} or {coul/charmmfsh} styles are part
of the MOLECULE package. All the styles with {coul/long} style are
part of the KSPACE package. They are only enabled if LAMMPS was built
with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info. Note that
the MOLECULE and KSPACE packages are installed by default.
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
:line
:link(Brooks1)
[(Brooks)] Brooks, et al, J Comput Chem, 30, 1545 (2009).
:link(pair-MacKerell)
[(MacKerell)] MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field,
Fischer, Gao, Guo, Ha, et al, J Phys Chem, 102, 3586 (1998).
:link(Steinbach)
[(Steinbach)] Steinbach, Brooks, J Comput Chem, 15, 667 (1994).
diff --git a/doc/src/pair_class2.txt b/doc/src/pair_class2.txt
index 23b90aae2..36fae5068 100644
--- a/doc/src/pair_class2.txt
+++ b/doc/src/pair_class2.txt
@@ -1,170 +1,170 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style lj/class2 command :h3
pair_style lj/class2/gpu command :h3
pair_style lj/class2/kk command :h3
pair_style lj/class2/omp command :h3
pair_style lj/class2/coul/cut command :h3
pair_style lj/class2/coul/cut/kk command :h3
pair_style lj/class2/coul/cut/omp command :h3
pair_style lj/class2/coul/long command :h3
pair_style lj/class2/coul/long/gpu command :h3
pair_style lj/class2/coul/long/kk command :h3
pair_style lj/class2/coul/long/omp command :h3
[Syntax:]
pair_style style args :pre
style = {lj/class2} or {lj/class2/coul/cut} or {lj/class2/coul/long}
args = list of arguments for a particular style :ul
{lj/class2} args = cutoff
cutoff = global cutoff for class 2 interactions (distance units)
{lj/class2/coul/cut} args = cutoff (cutoff2)
cutoff = global cutoff for class 2 (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{lj/class2/coul/long} args = cutoff (cutoff2)
cutoff = global cutoff for class 2 (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units) :pre
[Examples:]
pair_style lj/class2 10.0
pair_coeff * * 100.0 2.5
pair_coeff 1 2* 100.0 2.5 9.0 :pre
pair_style lj/class2/coul/cut 10.0
pair_style lj/class2/coul/cut 10.0 8.0
pair_coeff * * 100.0 3.0
pair_coeff 1 1 100.0 3.5 9.0
pair_coeff 1 1 100.0 3.5 9.0 9.0 :pre
pair_style lj/class2/coul/long 10.0
pair_style lj/class2/coul/long 10.0 8.0
pair_coeff * * 100.0 3.0
pair_coeff 1 1 100.0 3.5 9.0 :pre
[Description:]
The {lj/class2} styles compute a 6/9 Lennard-Jones potential given by
:c,image(Eqs/pair_class2.jpg)
Rc is the cutoff.
The {lj/class2/coul/cut} and {lj/class2/coul/long} styles add a
Coulombic term as described for the "lj/cut"_pair_lj.html pair styles.
See "(Sun)"_#pair-Sun for a description of the COMPASS class2 force field.
The following coefficients must be defined for each pair of atoms
types via the "pair_coeff"_pair_coeff.html command as in the examples
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands, or by mixing as described below:
epsilon (energy units)
sigma (distance units)
cutoff1 (distance units)
cutoff2 (distance units) :ul
The latter 2 coefficients are optional. If not specified, the global
class 2 and Coulombic cutoffs are used. If only one cutoff is
specified, it is used as the cutoff for both class 2 and Coulombic
interactions for this type pair. If both coefficients are specified,
they are used as the class 2 and Coulombic cutoffs for this type pair.
You cannot specify 2 cutoffs for style {lj/class2}, since it has no
Coulombic terms.
For {lj/class2/coul/long} only the class 2 cutoff can be specified
since a Coulombic cutoff cannot be specified for an individual I,J
type pair. All type pairs use the same global Coulombic cutoff
specified in the pair_style command.
:line
If the pair_coeff command is not used to define coefficients for a
particular I != J type pair, the mixing rule for epsilon and sigma for
all class2 potentials is to use the {sixthpower} formulas documented
by the "pair_modify"_pair_modify.html command. The "pair_modify
mix"_pair_modify.html setting is thus ignored for class2 potentials
for epsilon and sigma. However it is still followed for mixing the
cutoff distance.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance for all of the lj/class2 pair styles can be mixed.
Epsilon and sigma are always mixed with the value {sixthpower}. The
cutoff distance is mixed by whatever option is set by the pair_modify
command (default = geometric). See the "pair_modify" command for
details.
All of the lj/class2 pair styles support the
"pair_modify"_pair_modify.html shift option for the energy of the
Lennard-Jones portion of the pair interaction.
The {lj/class2/coul/long} pair style does not support the
"pair_modify"_pair_modify.html table option since a tabulation
capability has not yet been added to this potential.
All of the lj/class2 pair styles support the
"pair_modify"_pair_modify.html tail option for adding a long-range
tail correction to the energy and pressure of the Lennard-Jones
portion of the pair interaction.
All of the lj/class2 pair styles write their information to "binary
restart files"_restart.html, so pair_style and pair_coeff commands do
not need to be specified in an input script that reads a restart file.
All of the lj/class2 pair styles can only be used via the {pair}
keyword of the "run_style respa"_run_style.html command. They do not
support the {inner}, {middle}, {outer} keywords.
[Restrictions:]
These styles are part of the CLASS2 package. They are only enabled if
LAMMPS was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
:line
:link(pair-Sun)
[(Sun)] Sun, J Phys Chem B 102, 7338-7364 (1998).
diff --git a/doc/src/pair_colloid.txt b/doc/src/pair_colloid.txt
index a0df1d464..83b15b358 100644
--- a/doc/src/pair_colloid.txt
+++ b/doc/src/pair_colloid.txt
@@ -1,205 +1,205 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style colloid command :h3
pair_style colloid/gpu command :h3
pair_style colloid/omp command :h3
[Syntax:]
pair_style colloid cutoff :pre
cutoff = global cutoff for colloidal interactions (distance units) :ul
[Examples:]
pair_style colloid 10.0
pair_coeff * * 25 1.0 10.0 10.0
pair_coeff 1 1 144 1.0 0.0 0.0 3.0
pair_coeff 1 2 75.398 1.0 0.0 10.0 9.0
pair_coeff 2 2 39.478 1.0 10.0 10.0 25.0 :pre
[Description:]
Style {colloid} computes pairwise interactions between large colloidal
particles and small solvent particles using 3 formulas. A colloidal
particle has a size > sigma; a solvent particle is the usual
Lennard-Jones particle of size sigma.
The colloid-colloid interaction energy is given by
:c,image(Eqs/pair_colloid_cc.jpg)
where A_cc is the Hamaker constant, a1 and a2 are the radii of the two
colloidal particles, and Rc is the cutoff. This equation results from
describing each colloidal particle as an integrated collection of
Lennard-Jones particles of size sigma and is derived in
"(Everaers)"_#Everaers1.
The colloid-solvent interaction energy is given by
:c,image(Eqs/pair_colloid_cs.jpg)
where A_cs is the Hamaker constant, a is the radius of the colloidal
particle, and Rc is the cutoff. This formula is derived from the
colloid-colloid interaction, letting one of the particle sizes go to
zero.
The solvent-solvent interaction energy is given by the usual
Lennard-Jones formula
:c,image(Eqs/pair_colloid_ss.jpg)
with A_ss set appropriately, which results from letting both particle
sizes go to zero.
When used in combination with "pair_style
yukawa/colloid"_pair_colloid.html, the two terms become the so-called
DLVO potential, which combines electrostatic repulsion and van der
Waals attraction.
The following coefficients must be defined for each pair of atoms
types via the "pair_coeff"_pair_coeff.html command as in the examples
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands, or by mixing as described below:
A (energy units)
sigma (distance units)
d1 (distance units)
d2 (distance units)
cutoff (distance units) :ul
A is the Hamaker energy prefactor and should typically be set as
follows:
A_cc = colloid/colloid = 4 pi^2 = 39.5
A_cs = colloid/solvent = sqrt(A_cc*A_ss)
A_ss = solvent/solvent = 144 (assuming epsilon = 1, so that 144/36 = 4) :ul
Sigma is the size of the solvent particle or the constituent particles
integrated over in the colloidal particle and should typically be set
as follows:
Sigma_cc = colloid/colloid = 1.0
Sigma_cs = colloid/solvent = arithmetic mixing between colloid sigma and solvent sigma
Sigma_ss = solvent/solvent = 1.0 or whatever size the solvent particle is :ul
Thus typically Sigma_cs = 1.0, unless the solvent particle's size !=
1.0.
D1 and d2 are particle diameters, so that d1 = 2*a1 and d2 = 2*a2 in
the formulas above. Both d1 and d2 must be values >= 0. If d1 > 0
and d2 > 0, then the pair interacts via the colloid-colloid formula
above. If d1 = 0 and d2 = 0, then the pair interacts via the
solvent-solvent formula. I.e. a d value of 0 is a Lennard-Jones
particle of size sigma. If either d1 = 0 or d2 = 0 and the other is
larger, then the pair interacts via the colloid-solvent formula.
Note that the diameter of a particular particle type may appear in
multiple pair_coeff commands, as it interacts with other particle
types. You should insure the particle diameter is specified
consistently each time it appears.
The last coefficient is optional. If not specified, the global cutoff
specified in the pair_style command is used. However, you typically
want different cutoffs for interactions between different particle
sizes. E.g. if colloidal particles of diameter 10 are used with
solvent particles of diameter 1, then a solvent-solvent cutoff of 2.5
would correspond to a colloid-colloid cutoff of 25. A good
rule-of-thumb is to use a colloid-solvent cutoff that is half the big
diameter + 4 times the small diameter. I.e. 9 = 5 + 4 for the
colloid-solvent cutoff in this case.
NOTE: When using pair_style colloid for a mixture with 2 (or more)
widely different particles sizes (e.g. sigma=10 colloids in a
background sigma=1 LJ fluid), you will likely want to use these
commands for efficiency: "neighbor multi"_neighbor.html and
"comm_modify multi"_comm_modify.html.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, the A, sigma, d1, and d2
coefficients and cutoff distance for this pair style can be mixed. A
is an energy value mixed like a LJ epsilon. D1 and d2 are distance
values and are mixed like sigma. The default mix value is
{geometric}. See the "pair_modify" command for details.
This pair style supports the "pair_modify"_pair_modify.html shift
option for the energy of the pair interaction.
The "pair_modify"_pair_modify.html table option is not relevant
for this pair style.
This pair style does not support the "pair_modify"_pair_modify.html
tail option for adding long-range tail corrections to energy and
pressure.
This pair style writes its information to "binary restart
files"_restart.html, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.
This pair style can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. It does not support the
{inner}, {middle}, {outer} keywords.
:line
[Restrictions:]
This style is part of the COLLOID package. It is only enabled if
LAMMPS was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
Normally, this pair style should be used with finite-size particles
which have a diameter, e.g. see the "atom_style
sphere"_atom_style.html command. However, this is not a requirement,
since the only definition of particle size is via the pair_coeff
parameters for each type. In other words, the physical radius of the
particle is ignored. Thus you should insure that the d1,d2 parameters
you specify are consistent with the physical size of the particles of
that type.
Per-particle polydispersity is not yet supported by this pair style;
only per-type polydispersity is enabled via the pair_coeff parameters.
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
:line
:link(Everaers1)
[(Everaers)] Everaers, Ejtehadi, Phys Rev E, 67, 041710 (2003).
diff --git a/doc/src/pair_comb.txt b/doc/src/pair_comb.txt
index 3a2f380bf..f5461b1cb 100644
--- a/doc/src/pair_comb.txt
+++ b/doc/src/pair_comb.txt
@@ -1,192 +1,192 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style comb command :h3
pair_style comb/omp command :h3
pair_style comb3 command :h3
[Syntax:]
pair_style comb
pair_style comb3 keyword :pre
keyword = {polar}
{polar} value = {polar_on} or {polar_off} = whether or not to include atomic polarization :pre
:ule
[Examples:]
pair_style comb
pair_coeff * * ../potentials/ffield.comb Si
pair_coeff * * ../potentials/ffield.comb Hf Si O :pre
pair_style comb3 polar_off
pair_coeff * * ../potentials/ffield.comb3 O Cu N C O :pre
[Description:]
Style {comb} computes the second-generation variable charge COMB
(Charge-Optimized Many-Body) potential. Style {comb3} computes the
third-generation COMB potential. These COMB potentials are described
in "(COMB)"_#COMB and "(COMB3)"_#COMB3. Briefly, the total energy
{ET} of a system of atoms is given by
:c,image(Eqs/pair_comb1.jpg)
where {Eiself} is the self-energy of atom {i}
(including atomic ionization energies and electron affinities),
{Eijshort} is the bond-order potential between
atoms {i} and {j},
{EijCoul} is the Coulomb interactions,
{Epolar} is the polarization term for organic systems
(style {comb3} only),
{EvdW} is the van der Waals energy (style {comb3} only),
{Ebarr} is a charge barrier function, and
{Ecorr} are angular correction terms.
The COMB potentials (styles {comb} and {comb3}) are variable charge
potentials. The equilibrium charge on each atom is calculated by the
electronegativity equalization (QEq) method. See "Rick"_#Rick2 for
further details. This is implemented by the "fix
qeq/comb"_fix_qeq_comb.html command, which should normally be
specified in the input script when running a model with the COMB
potential. The "fix qeq/comb"_fix_qeq_comb.html command has options
that determine how often charge equilibration is performed, its
convergence criterion, and which atoms are included in the
calculation.
Only a single pair_coeff command is used with the {comb} and {comb3}
styles which specifies the COMB potential file with parameters for all
needed elements. These are mapped to LAMMPS atom types by specifying
N additional arguments after the potential file in the pair_coeff
command, where N is the number of LAMMPS atom types.
For example, if your LAMMPS simulation of a Si/SiO2/
HfO2 interface has 4 atom types, and you want the 1st and
last to be Si, the 2nd to be Hf, and the 3rd to be O, and you would
use the following pair_coeff command:
pair_coeff * * ../potentials/ffield.comb Si Hf O Si :pre
The first two arguments must be * * so as to span all LAMMPS atom
types. The first and last Si arguments map LAMMPS atom types 1 and 4
to the Si element in the {ffield.comb} file. The second Hf argument
maps LAMMPS atom type 2 to the Hf element, and the third O argument
maps LAMMPS atom type 3 to the O element in the potential file. If a
mapping value is specified as NULL, the mapping is not performed.
This can be used when a {comb} potential is used as part of the
{hybrid} pair style. The NULL values are placeholders for atom types
that will be used with other potentials.
For style {comb}, the provided potential file {ffield.comb} contains
all currently-available 2nd generation COMB parameterizations: for Si,
Cu, Hf, Ti, O, their oxides and Zr, Zn and U metals. For style
{comb3}, the potential file {ffield.comb3} contains all
currently-available 3rd generation COMB parameterizations: O, Cu, N, C,
H, Ti, Zn and Zr. The status of the optimization of the compounds, for
example Cu2O, TiN and hydrocarbons, are given in the
following table:
:c,image(Eqs/pair_comb2.jpg)
For style {comb3}, in addition to ffield.comb3, a special parameter
file, {lib.comb3}, that is exclusively used for C/O/H systems, will be
automatically loaded if carbon atom is detected in LAMMPS input
structure. This file must be in your working directory or in the
directory pointed to by the environment variable LAMMPS_POTENTIALS, as
described on the "pair_coeff"_pair_coeff.html command doc page.
Keyword {polar} indicates whether the force field includes
the atomic polarization. Since the equilibration of the polarization
has not yet been implemented, it can only set polar_off at present.
NOTE: You can not use potential file {ffield.comb} with style {comb3},
nor file {ffield.comb3} with style {comb}.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, where types I and J correspond to
two different element types, mixing is performed by LAMMPS as
described above from values in the potential file.
These pair styles does not support the "pair_modify"_pair_modify.html
shift, table, and tail options.
These pair styles do not write its information to "binary restart
files"_restart.html, since it is stored in potential files. Thus, you
need to re-specify the pair_style, pair_coeff, and "fix
qeq/comb"_fix_qeq_comb.html commands in an input script that reads a
restart file.
These pair styles can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. It does not support the
{inner}, {middle}, {outer} keywords.
:line
[Restrictions:]
These pair styles are part of the MANYBODY package. It is only enabled
if LAMMPS was built with that package. See
the "Making LAMMPS"_Section_start.html#start_3 section for more info.
These pair styles requires the "newton"_newton.html setting to be "on"
for pair interactions.
The COMB potentials in the {ffield.comb} and {ffield.comb3} files provided
with LAMMPS (see the potentials directory) are parameterized for metal
"units"_units.html. You can use the COMB potential with any LAMMPS
units, but you would need to create your own COMB potential file with
coefficients listed in the appropriate units if your simulation
doesn't use "metal" units.
[Related commands:]
"pair_style"_pair_style.html, "pair_coeff"_pair_coeff.html,
"fix qeq/comb"_fix_qeq_comb.html
[Default:] none
:line
:link(COMB)
[(COMB)] T.-R. Shan, B. D. Devine, T. W. Kemper, S. B. Sinnott, and
S. R. Phillpot, Phys. Rev. B 81, 125328 (2010)
:link(COMB3)
[(COMB3)] T. Liang, T.-R. Shan, Y.-T. Cheng, B. D. Devine, M. Noordhoek,
Y. Li, Z. Lu, S. R. Phillpot, and S. B. Sinnott, Mat. Sci. & Eng: R 74,
255-279 (2013).
:link(Rick2)
[(Rick)] S. W. Rick, S. J. Stuart, B. J. Berne, J Chem Phys 101, 6141
(1994).
diff --git a/doc/src/pair_coul.txt b/doc/src/pair_coul.txt
index 4a601e90c..29e5beed3 100644
--- a/doc/src/pair_coul.txt
+++ b/doc/src/pair_coul.txt
@@ -1,342 +1,342 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style coul/cut command :h3
pair_style coul/cut/gpu command :h3
pair_style coul/cut/kk command :h3
pair_style coul/cut/omp command :h3
pair_style coul/debye command :h3
pair_style coul/debye/gpu command :h3
pair_style coul/debye/kk command :h3
pair_style coul/debye/omp command :h3
pair_style coul/dsf command :h3
pair_style coul/dsf/gpu command :h3
pair_style coul/dsf/kk command :h3
pair_style coul/dsf/omp command :h3
pair_style coul/long command :h3
pair_style coul/long/cs command :h3
pair_style coul/long/omp command :h3
pair_style coul/long/gpu command :h3
pair_style coul/long/kk command :h3
pair_style coul/msm command :h3
pair_style coul/msm/omp command :h3
pair_style coul/streitz command :h3
pair_style coul/wolf command :h3
pair_style coul/wolf/kk command :h3
pair_style coul/wolf/omp command :h3
pair_style tip4p/cut command :h3
pair_style tip4p/long command :h3
pair_style tip4p/cut/omp command :h3
pair_style tip4p/long/omp command :h3
[Syntax:]
pair_style coul/cut cutoff
pair_style coul/debye kappa cutoff
pair_style coul/dsf alpha cutoff
pair_style coul/long cutoff
pair_style coul/long/cs cutoff
pair_style coul/long/gpu cutoff
pair_style coul/wolf alpha cutoff
pair_style coul/streitz cutoff keyword alpha
pair_style tip4p/cut otype htype btype atype qdist cutoff
pair_style tip4p/long otype htype btype atype qdist cutoff :pre
cutoff = global cutoff for Coulombic interactions
kappa = Debye length (inverse distance units)
alpha = damping parameter (inverse distance units) :ul
[Examples:]
pair_style coul/cut 2.5
pair_coeff * *
pair_coeff 2 2 3.5 :pre
pair_style coul/debye 1.4 3.0
pair_coeff * *
pair_coeff 2 2 3.5 :pre
pair_style coul/dsf 0.05 10.0
pair_coeff * * :pre
pair_style coul/long 10.0
pair_style coul/long/cs 10.0
pair_coeff * * :pre
pair_style coul/msm 10.0
pair_coeff * * :pre
pair_style coul/wolf 0.2 9.0
pair_coeff * * :pre
pair_style coul/streitz 12.0 ewald
pair_style coul/streitz 12.0 wolf 0.30
pair_coeff * * AlO.streitz Al O :pre
pair_style tip4p/cut 1 2 7 8 0.15 12.0
pair_coeff * * :pre
pair_style tip4p/long 1 2 7 8 0.15 10.0
pair_coeff * * :pre
[Description:]
The {coul/cut} style computes the standard Coulombic interaction
potential given by
:c,image(Eqs/pair_coulomb.jpg)
where C is an energy-conversion constant, Qi and Qj are the charges on
the 2 atoms, and epsilon is the dielectric constant which can be set
by the "dielectric"_dielectric.html command. The cutoff Rc truncates
the interaction distance.
:line
Style {coul/debye} adds an additional exp() damping factor to the
Coulombic term, given by
:c,image(Eqs/pair_debye.jpg)
where kappa is the Debye length. This potential is another way to
mimic the screening effect of a polar solvent.
:line
Style {coul/dsf} computes Coulombic interactions via the damped
shifted force model described in "Fennell"_#Fennell1, given by:
:c,image(Eqs/pair_coul_dsf.jpg)
where {alpha} is the damping parameter and erfc() is the
complementary error-function. The potential corrects issues in the
Wolf model (described below) to provide consistent forces and energies
(the Wolf potential is not differentiable at the cutoff) and smooth
decay to zero.
:line
Style {coul/wolf} computes Coulombic interactions via the Wolf
summation method, described in "Wolf"_#Wolf1, given by:
:c,image(Eqs/pair_coul_wolf.jpg)
where {alpha} is the damping parameter, and erc() and erfc() are
error-function and complementary error-function terms. This potential
is essentially a short-range, spherically-truncated,
charge-neutralized, shifted, pairwise {1/r} summation. With a
manipulation of adding and subtracting a self term (for i = j) to the
first and second term on the right-hand-side, respectively, and a
small enough {alpha} damping parameter, the second term shrinks and
the potential becomes a rapidly-converging real-space summation. With
a long enough cutoff and small enough alpha parameter, the energy and
forces calculated by the Wolf summation method approach those of the
Ewald sum. So it is a means of getting effective long-range
interactions with a short-range potential.
:line
Style {coul/streitz} is the Coulomb pair interaction defined as part
of the Streitz-Mintmire potential, as described in "this
paper"_#Streitz2, in which charge distribution about an atom is modeled
as a Slater 1{s} orbital. More details can be found in the referenced
paper. To fully reproduce the published Streitz-Mintmire potential,
which is a variable charge potential, style {coul/streitz} must be
used with "pair_style eam/alloy"_pair_eam.html (or some other
short-range potential that has been parameterized appropriately) via
the "pair_style hybrid/overlay"_pair_hybrid.html command. Likewise,
charge equilibration must be performed via the "fix
qeq/slater"_fix_qeq.html command. For example:
pair_style hybrid/overlay coul/streitz 12.0 wolf 0.31 eam/alloy
pair_coeff * * coul/streitz AlO.streitz Al O
pair_coeff * * eam/alloy AlO.eam.alloy Al O
fix 1 all qeq/slater 1 12.0 1.0e-6 100 coul/streitz :pre
The keyword {wolf} in the coul/streitz command denotes computing
Coulombic interactions via Wolf summation. An additional damping
parameter is required for the Wolf summation, as described for the
coul/wolf potential above. Alternatively, Coulombic interactions can
be computed via an Ewald summation. For example:
pair_style hybrid/overlay coul/streitz 12.0 ewald eam/alloy
kspace_style ewald 1e-6 :pre
Keyword {ewald} does not need a damping parameter, but a
"kspace_style"_kspace_style.html must be defined, which can be style
{ewald} or {pppm}. The Ewald method was used in Streitz and
Mintmire's original paper, but a Wolf summation offers a speed-up in
some cases.
For the fix qeq/slater command, the {qfile} can be a filename that
contains QEq parameters as discussed on the "fix qeq"_fix_qeq.html
command doc page. Alternatively {qfile} can be replaced by
"coul/streitz", in which case the fix will extract QEq parameters from
the coul/streitz pair style itself.
See the examples/strietz directory for an example input script that
uses the Streitz-Mintmire potential. The potentials directory has the
AlO.eam.alloy and AlO.streitz potential files used by the example.
Note that the Streiz-Mintmire potential is generally used for oxides,
but there is no conceptual problem with extending it to nitrides and
carbides (such as SiC, TiN). Pair coul/strietz used by itself or with
any other pair style such as EAM, MEAM, Tersoff, or LJ in
hybrid/overlay mode. To do this, you would need to provide a
Streitz-Mintmire parameterization for the material being modeled.
:line
Styles {coul/long} and {coul/msm} compute the same Coulombic
interactions as style {coul/cut} except that an additional damping
factor is applied so it can be used in conjunction with the
"kspace_style"_kspace_style.html command and its {ewald} or {pppm}
option. The Coulombic cutoff specified for this style means that
pairwise interactions within this distance are computed directly;
interactions outside that distance are computed in reciprocal space.
Style {coul/long/cs} is identical to {coul/long} except that a term is
added for the "core/shell model"_Section_howto.html#howto_25 to allow
charges on core and shell particles to be separated by r = 0.0.
Styles {tip4p/cut} and {tip4p/long} implement the coulomb part of
the TIP4P water model of "(Jorgensen)"_#Jorgensen3, which introduces
a massless site located a short distance away from the oxygen atom
along the bisector of the HOH angle. The atomic types of the oxygen and
hydrogen atoms, the bond and angle types for OH and HOH interactions,
and the distance to the massless charge site are specified as
pair_style arguments. Style {tip4p/cut} uses a global cutoff for
Coulomb interactions; style {tip4p/long} is for use with a long-range
Coulombic solver (Ewald or PPPM).
NOTE: For each TIP4P water molecule in your system, the atom IDs for
the O and 2 H atoms must be consecutive, with the O atom first. This
is to enable LAMMPS to "find" the 2 H atoms associated with each O
atom. For example, if the atom ID of an O atom in a TIP4P water
molecule is 500, then its 2 H atoms must have IDs 501 and 502.
See the "howto section"_Section_howto.html#howto_8 for more
information on how to use the TIP4P pair styles and lists of
parameters to set. Note that the neighbor list cutoff for Coulomb
interactions is effectively extended by a distance 2*qdist when using
the TIP4P pair style, to account for the offset distance of the
fictitious charges on O atoms in water molecules. Thus it is
typically best in an efficiency sense to use a LJ cutoff >= Coulomb
cutoff + 2*qdist, to shrink the size of the neighbor list. This leads
to slightly larger cost for the long-range calculation, so you can
test the trade-off for your model.
:line
Note that these potentials are designed to be combined with other pair
potentials via the "pair_style hybrid/overlay"_pair_hybrid.html
command. This is because they have no repulsive core. Hence if they
are used by themselves, there will be no repulsion to keep two
oppositely charged particles from moving arbitrarily close to each
other.
The following coefficients must be defined for each pair of atoms
types via the "pair_coeff"_pair_coeff.html command as in the examples
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands, or by mixing as described below:
cutoff (distance units) :ul
For {coul/cut} and {coul/debye}, the cutoff coefficient is optional.
If it is not used (as in some of the examples above), the default
global value specified in the pair_style command is used.
For {coul/long} and {coul/msm} no cutoff can be specified for an
individual I,J type pair via the pair_coeff command. All type pairs
use the same global Coulombic cutoff specified in the pair_style
command.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, the cutoff distance for the
{coul/cut} style can be mixed. The default mix value is {geometric}.
See the "pair_modify" command for details.
The "pair_modify"_pair_modify.html shift option is not relevant
for these pair styles.
The {coul/long} style supports the "pair_modify"_pair_modify.html
table option for tabulation of the short-range portion of the
long-range Coulombic interaction.
These pair styles do not support the "pair_modify"_pair_modify.html
tail option for adding long-range tail corrections to energy and
pressure.
These pair styles write their information to "binary restart
files"_restart.html, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.
This pair style can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. It does not support the
{inner}, {middle}, {outer} keywords.
:line
[Restrictions:]
The {coul/long}, {coul/msm} and {tip4p/long} styles are part of the
KSPACE package. The {coul/long/cs} style is part of the CORESHELL
package. They are only enabled if LAMMPS was built with that package.
See the "Making LAMMPS"_Section_start.html#start_3 section for more info.
[Related commands:]
"pair_coeff"_pair_coeff.html, "pair_style,
hybrid/overlay"_pair_hybrid.html, "kspace_style"_kspace_style.html
[Default:] none
:line
:link(Wolf1)
[(Wolf)] D. Wolf, P. Keblinski, S. R. Phillpot, J. Eggebrecht, J Chem
Phys, 110, 8254 (1999).
:link(Fennell1)
[(Fennell)] C. J. Fennell, J. D. Gezelter, J Chem Phys, 124,
234104 (2006).
:link(Streitz2)
[(Streitz)] F. H. Streitz, J. W. Mintmire, Phys Rev B, 50, 11996-12003
(1994).
:link(Jorgensen3)
[(Jorgensen)] Jorgensen, Chandrasekhar, Madura, Impey, Klein, J Chem
Phys, 79, 926 (1983).
diff --git a/doc/src/pair_dipole.txt b/doc/src/pair_dipole.txt
index 985581cac..2516e5eae 100644
--- a/doc/src/pair_dipole.txt
+++ b/doc/src/pair_dipole.txt
@@ -1,275 +1,275 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style lj/cut/dipole/cut command :h3
pair_style lj/cut/dipole/cut/gpu command :h3
pair_style lj/cut/dipole/cut/omp command :h3
pair_style lj/sf/dipole/sf command :h3
pair_style lj/sf/dipole/sf/gpu command :h3
pair_style lj/sf/dipole/sf/omp command :h3
pair_style lj/cut/dipole/long command :h3
pair_style lj/long/dipole/long command :h3
[Syntax:]
pair_style lj/cut/dipole/cut cutoff (cutoff2)
pair_style lj/sf/dipole/sf cutoff (cutoff2)
pair_style lj/cut/dipole/long cutoff (cutoff2)
pair_style lj/long/dipole/long flag_lj flag_coul cutoff (cutoff2) :pre
cutoff = global cutoff LJ (and Coulombic if only 1 arg) (distance units) :ulb,l
cutoff2 = global cutoff for Coulombic and dipole (optional) (distance units) :l
flag_lj = {long} or {cut} or {off} :l
{long} = use long-range damping on dispersion 1/r^6 term
{cut} = use a cutoff on dispersion 1/r^6 term
{off} = omit disperion 1/r^6 term entirely :pre
flag_coul = {long} or {off} :l
{long} = use long-range damping on Coulombic 1/r and point-dipole terms
{off} = omit Coulombic and point-dipole terms entirely :pre
:ule
[Examples:]
pair_style lj/cut/dipole/cut 10.0
pair_coeff * * 1.0 1.0
pair_coeff 2 3 1.0 1.0 2.5 4.0 :pre
pair_style lj/sf/dipole/sf 9.0
pair_coeff * * 1.0 1.0
pair_coeff 2 3 1.0 1.0 2.5 4.0 scale 0.5
pair_coeff 2 3 1.0 1.0 2.5 4.0 :pre
pair_style lj/cut/dipole/long 10.0
pair_coeff * * 1.0 1.0
pair_coeff 2 3 1.0 1.0 2.5 4.0 :pre
pair_style lj/long/dipole/long long long 3.5 10.0
pair_coeff * * 1.0 1.0
pair_coeff 2 3 1.0 1.0 2.5 4.0 :pre
[Description:]
Style {lj/cut/dipole/cut} computes interactions between pairs of particles
that each have a charge and/or a point dipole moment. In addition to
the usual Lennard-Jones interaction between the particles (Elj) the
charge-charge (Eqq), charge-dipole (Eqp), and dipole-dipole (Epp)
interactions are computed by these formulas for the energy (E), force
(F), and torque (T) between particles I and J.
:c,image(Eqs/pair_dipole.jpg)
where qi and qj are the charges on the two particles, pi and pj are
the dipole moment vectors of the two particles, r is their separation
distance, and the vector r = Ri - Rj is the separation vector between
the two particles. Note that Eqq and Fqq are simply Coulombic energy
and force, Fij = -Fji as symmetric forces, and Tij != -Tji since the
torques do not act symmetrically. These formulas are discussed in
"(Allen)"_#Allen2 and in "(Toukmaji)"_#Toukmaji2.
Also note, that in the code, all of these terms (except Elj) have a
C/epsilon prefactor, the same as the Coulombic term in the LJ +
Coulombic pair styles discussed "here"_pair_lj.html. C is an
energy-conversion constant and epsilon is the dielectric constant
which can be set by the "dielectric"_dielectric.html command. The
same is true of the equations that follow for other dipole pair
styles.
Style {lj/sf/dipole/sf} computes "shifted-force" interactions between
pairs of particles that each have a charge and/or a point dipole
moment. In general, a shifted-force potential is a (sligthly) modified
potential containing extra terms that make both the energy and its
derivative go to zero at the cutoff distance; this removes
(cutoff-related) problems in energy conservation and any numerical
instability in the equations of motion "(Allen)"_#Allen2. Shifted-force
interactions for the Lennard-Jones (E_LJ), charge-charge (Eqq),
charge-dipole (Eqp), dipole-charge (Epq) and dipole-dipole (Epp)
potentials are computed by these formulas for the energy (E), force
(F), and torque (T) between particles I and J:
:c,image(Eqs/pair_dipole_sf.jpg)
:c,image(Eqs/pair_dipole_sf2.jpg)
where epsilon and sigma are the standard LJ parameters, r_c is the
cutoff, qi and qj are the charges on the two particles, pi and pj are
the dipole moment vectors of the two particles, r is their separation
distance, and the vector r = Ri - Rj is the separation vector between
the two particles. Note that Eqq and Fqq are simply Coulombic energy
and force, Fij = -Fji as symmetric forces, and Tij != -Tji since the
torques do not act symmetrically. The shifted-force formula for the
Lennard-Jones potential is reported in "(Stoddard)"_#Stoddard. The
original (unshifted) formulas for the electrostatic potentials, forces
and torques can be found in "(Price)"_#Price2. The shifted-force
electrostatic potentials have been obtained by applying equation 5.13
of "(Allen)"_#Allen2. The formulas for the corresponding forces and
torques have been obtained by applying the 'chain rule' as in appendix
C.3 of "(Allen)"_#Allen2.
If one cutoff is specified in the pair_style command, it is used for
both the LJ and Coulombic (q,p) terms. If two cutoffs are specified,
they are used as cutoffs for the LJ and Coulombic (q,p) terms
respectively. This pair style also supports an optional {scale} keyword
as part of a pair_coeff statement, where the interactions can be
scaled according to this factor. This scale factor is also made available
for use with fix adapt.
Style {lj/cut/dipole/long} computes long-range point-dipole
interactions as discussed in "(Toukmaji)"_#Toukmaji2. Dipole-dipole,
dipole-charge, and charge-charge interactions are all supported, along
with the standard 12/6 Lennard-Jones interactions, which are computed
with a cutoff. A "kspace_style"_kspace_style.html must be defined to
use this pair style. Currently, only "kspace_style
ewald/disp"_kspace_style.html support long-range point-dipole
interactions.
Style {lj/long/dipole/long} also computes point-dipole interactions as
discussed in "(Toukmaji)"_#Toukmaji2. Long-range dipole-dipole,
dipole-charge, and charge-charge interactions are all supported, along
with the standard 12/6 Lennard-Jones interactions. LJ interactions
can be cutoff or long-ranged.
For style {lj/long/dipole/long}, if {flag_lj} is set to {long}, no
cutoff is used on the LJ 1/r^6 dispersion term. The long-range
portion is calculated by using the "kspace_style
ewald_disp"_kspace_style.html command. The specified LJ cutoff then
determines which portion of the LJ interactions are computed directly
by the pair potential versus which part is computed in reciprocal
space via the Kspace style. If {flag_lj} is set to {cut}, the LJ
interactions are simply cutoff, as with "pair_style
lj/cut"_pair_lj.html. If {flag_lj} is set to {off}, LJ interactions
are not computed at all.
If {flag_coul} is set to {long}, no cutoff is used on the Coulombic or
dipole interactions. The long-range portion is calculated by using
{ewald_disp} of the "kspace_style"_kspace_style.html command. If
{flag_coul} is set to {off}, Coulombic and dipole interactions are not
computed at all.
Atoms with dipole moments should be integrated using the "fix
nve/sphere update dipole"_fix_nve_sphere.html or the "fix
nvt/sphere update dipole"_fix_nvt_sphere.html command to rotate the
dipole moments. The {omega} option on the "fix
langevin"_fix_langevin.html command can be used to thermostat the
rotational motion. The "compute temp/sphere"_compute_temp_sphere.html
command can be used to monitor the temperature, since it includes
rotational degrees of freedom. The "atom_style
hybrid dipole sphere"_atom_style.html command should be used since
it defines the point dipoles and their rotational state.
The magnitude and orientation of the dipole moment for each particle
can be defined by the "set"_set.html command or in the "Atoms" section
of the data file read in by the "read_data"_read_data.html command.
The following coefficients must be defined for each pair of atoms
types via the "pair_coeff"_pair_coeff.html command as in the examples
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands, or by mixing as described below:
epsilon (energy units)
sigma (distance units)
cutoff1 (distance units)
cutoff2 (distance units) :ul
The latter 2 coefficients are optional. If not specified, the global
LJ and Coulombic cutoffs specified in the pair_style command are used.
If only one cutoff is specified, it is used as the cutoff for both LJ
and Coulombic interactions for this type pair. If both coefficients
are specified, they are used as the LJ and Coulombic cutoffs for this
type pair.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distances for this pair style can be mixed. The default
mix value is {geometric}. See the "pair_modify" command for details.
For atom type pairs I,J and I != J, the A, sigma, d1, and d2
coefficients and cutoff distance for this pair style can be mixed. A
is an energy value mixed like a LJ epsilon. D1 and d2 are distance
values and are mixed like sigma. The default mix value is
{geometric}. See the "pair_modify" command for details.
This pair style does not support the "pair_modify"_pair_modify.html
shift option for the energy of the Lennard-Jones portion of the pair
interaction; such energy goes to zero at the cutoff by construction.
The "pair_modify"_pair_modify.html table option is not relevant
for this pair style.
This pair style does not support the "pair_modify"_pair_modify.html
tail option for adding long-range tail corrections to energy and
pressure.
This pair style writes its information to "binary restart
files"_restart.html, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.
This pair style can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. It does not support the
{inner}, {middle}, {outer} keywords.
[Restrictions:]
The {lj/cut/dipole/cut}, {lj/cut/dipole/long}, and
{lj/long/dipole/long} styles are part of the DIPOLE package. They are
only enabled if LAMMPS was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
The {lj/sf/dipole/sf} style is part of the USER-MISC package. It is
only enabled if LAMMPS was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
Using dipole pair styles with {electron} "units"_units.html is not
currently supported.
[Related commands:]
"pair_coeff"_pair_coeff.html, "set"_set.html, "read_data"_read_data.html,
"fix nve/sphere"_fix_nve_sphere.html, "fix nvt/sphere"_fix_nvt_sphere.html
[Default:] none
:line
:link(Allen2)
[(Allen)] Allen and Tildesley, Computer Simulation of Liquids,
Clarendon Press, Oxford, 1987.
:link(Toukmaji2)
[(Toukmaji)] Toukmaji, Sagui, Board, and Darden, J Chem Phys, 113,
10913 (2000).
:link(Stoddard)
[(Stoddard)] Stoddard and Ford, Phys Rev A, 8, 1504 (1973).
:link(Price2)
[(Price)] Price, Stone and Alderton, Mol Phys, 52, 987 (1984).
diff --git a/doc/src/pair_dpd.txt b/doc/src/pair_dpd.txt
index 62a5faffe..9dd204ad2 100644
--- a/doc/src/pair_dpd.txt
+++ b/doc/src/pair_dpd.txt
@@ -1,209 +1,209 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style dpd command :h3
pair_style dpd/gpu command :h3
pair_style dpd/omp command :h3
pair_style dpd/tstat command :h3
pair_style dpd/tstat/gpu command :h3
pair_style dpd/tstat/omp command :h3
[Syntax:]
pair_style dpd T cutoff seed
pair_style dpd/tstat Tstart Tstop cutoff seed :pre
T = temperature (temperature units)
Tstart,Tstop = desired temperature at start/end of run (temperature units)
cutoff = global cutoff for DPD interactions (distance units)
seed = random # seed (positive integer) :ul
[Examples:]
pair_style dpd 1.0 2.5 34387
pair_coeff * * 3.0 1.0
pair_coeff 1 1 3.0 1.0 1.0 :pre
pair_style dpd/tstat 1.0 1.0 2.5 34387
pair_coeff * * 1.0
pair_coeff 1 1 1.0 1.0 :pre
[Description:]
Style {dpd} computes a force field for dissipative particle dynamics
(DPD) following the exposition in "(Groot)"_#Groot.
Style {dpd/tstat} invokes a DPD thermostat on pairwise interactions,
which is equivalent to the non-conservative portion of the DPD force
field. This pair-wise thermostat can be used in conjunction with any
"pair style"_pair_style.html, and in leiu of per-particle thermostats
like "fix langevin"_fix_langevin.html or ensemble thermostats like
Nose Hoover as implemented by "fix nvt"_fix_nh.html. To use
{dpd/tstat} as a thermostat for another pair style, use the "pair_style
hybrid/overlay"_pair_hybrid.html command to compute both the desired
pair interaction and the thermostat for each pair of particles.
For style {dpd}, the force on atom I due to atom J is given as a sum
of 3 terms
:c,image(Eqs/pair_dpd.jpg)
where Fc is a conservative force, Fd is a dissipative force, and Fr is
a random force. Rij is a unit vector in the direction Ri - Rj, Vij is
the vector difference in velocities of the two atoms = Vi - Vj, alpha
is a Gaussian random number with zero mean and unit variance, dt is
the timestep size, and w(r) is a weighting factor that varies between
0 and 1. Rc is the cutoff. Sigma is set equal to sqrt(2 Kb T gamma),
where Kb is the Boltzmann constant and T is the temperature parameter
in the pair_style command.
For style {dpd/tstat}, the force on atom I due to atom J is the same
as the above equation, except that the conservative Fc term is
dropped. Also, during the run, T is set each timestep to a ramped
value from Tstart to Tstop.
For style {dpd}, the pairwise energy associated with style {dpd} is
only due to the conservative force term Fc, and is shifted to be zero
at the cutoff distance Rc. The pairwise virial is calculated using
all 3 terms. For style {dpd/tstat} there is no pairwise energy, but
the last two terms of the formula make a contribution to the virial.
For style {dpd}, the following coefficients must be defined for each
pair of atoms types via the "pair_coeff"_pair_coeff.html command as in
the examples above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands:
A (force units)
gamma (force/velocity units)
cutoff (distance units) :ul
The last coefficient is optional. If not specified, the global DPD
cutoff is used. Note that sigma is set equal to sqrt(2 T gamma),
where T is the temperature set by the "pair_style"_pair_style.html
command so it does not need to be specified.
For style {dpd/tstat}, the coefficients defined for each pair of
atoms types via the "pair_coeff"_pair_coeff.html command is the same,
except that A is not included.
The GPU-accelerated versions of these styles are implemented based on
the work of "(Afshar)"_#Afshar and "(Phillips)"_#Phillips.
NOTE: If you are modeling DPD polymer chains, you may want to use the
"pair_style srp"_pair_srp.html command in conjuction with these pair
styles. It is a soft segmental repulsive potential (SRP) that can
prevent DPD polymer chains from crossing each other.
NOTE: The virial calculation for pressure when using this pair style
includes all the components of force listed above, including the
random force.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
These pair styles do not support mixing. Thus, coefficients for all
I,J pairs must be specified explicitly.
These pair styles do not support the "pair_modify"_pair_modify.html
shift option for the energy of the pair interaction. Note that as
discussed above, the energy due to the conservative Fc term is already
shifted to be 0.0 at the cutoff distance Rc.
The "pair_modify"_pair_modify.html table option is not relevant
for these pair styles.
These pair style do not support the "pair_modify"_pair_modify.html
tail option for adding long-range tail corrections to energy and
pressure.
These pair styles writes their information to "binary restart
files"_restart.html, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file. Note
that the user-specified random number seed is stored in the restart
file, so when a simulation is restarted, each processor will
re-initialize its random number generator the same way it did
initially. This means the random forces will be random, but will not
be the same as they would have been if the original simulation had
continued past the restart time.
These pair styles can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. They do not support the
{inner}, {middle}, {outer} keywords.
The {dpd/tstat} style can ramp its target temperature over multiple
runs, using the {start} and {stop} keywords of the "run"_run.html
command. See the "run"_run.html command for details of how to do
this.
:line
[Restrictions:]
The default frequency for rebuilding neighbor lists is every 10 steps
(see the "neigh_modify"_neigh_modify.html command). This may be too
infrequent for style {dpd} simulations since particles move rapidly
and can overlap by large amounts. If this setting yields a non-zero
number of "dangerous" reneighborings (printed at the end of a
simulation), you should experiment with forcing reneighboring more
often and see if system energies/trajectories change.
These pair styles requires you to use the "comm_modify vel
yes"_comm_modify.html command so that velocites are stored by ghost
atoms.
These pair styles will not restart exactly when using the
"read_restart"_read_restart.html command, though they should provide
statistically similar results. This is because the forces they
compute depend on atom velocities. See the
"read_restart"_read_restart.html command for more details.
[Related commands:]
"pair_coeff"_pair_coeff.html, "fix nvt"_fix_nh.html, "fix
langevin"_fix_langevin.html, "pair_style srp"_pair_srp.html
[Default:] none
:line
:link(Groot)
[(Groot)] Groot and Warren, J Chem Phys, 107, 4423-35 (1997).
:link(Afshar)
[(Afshar)] Afshar, F. Schmid, A. Pishevar, S. Worley, Comput Phys
Comm, 184, 1119-1128 (2013).
:link(Phillips)
[(Phillips)] C. L. Phillips, J. A. Anderson, S. C. Glotzer, Comput
Phys Comm, 230, 7191-7201 (2011).
diff --git a/doc/src/pair_eam.txt b/doc/src/pair_eam.txt
index 4d3c2b2de..ce8495aff 100644
--- a/doc/src/pair_eam.txt
+++ b/doc/src/pair_eam.txt
@@ -1,448 +1,448 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style eam command :h3
pair_style eam/gpu command :h3
pair_style eam/intel command :h3
pair_style eam/kk command :h3
pair_style eam/omp command :h3
pair_style eam/opt command :h3
pair_style eam/alloy command :h3
pair_style eam/alloy/gpu command :h3
pair_style eam/alloy/kk command :h3
pair_style eam/alloy/omp command :h3
pair_style eam/alloy/opt command :h3
pair_style eam/cd command :h3
pair_style eam/cd/omp command :h3
pair_style eam/fs command :h3
pair_style eam/fs/gpu command :h3
pair_style eam/fs/kk command :h3
pair_style eam/fs/omp command :h3
pair_style eam/fs/opt command :h3
[Syntax:]
pair_style style :pre
style = {eam} or {eam/alloy} or {eam/cd} or {eam/fs} :ul
[Examples:]
pair_style eam
pair_coeff * * cuu3
pair_coeff 1*3 1*3 niu3.eam :pre
pair_style eam/alloy
pair_coeff * * ../potentials/NiAlH_jea.eam.alloy Ni Al Ni Ni :pre
pair_style eam/cd
pair_coeff * * ../potentials/FeCr.cdeam Fe Cr :pre
pair_style eam/fs
pair_coeff * * NiAlH_jea.eam.fs Ni Al Ni Ni :pre
[Description:]
Style {eam} computes pairwise interactions for metals and metal alloys
using embedded-atom method (EAM) potentials "(Daw)"_#Daw. The total
energy Ei of an atom I is given by
:c,image(Eqs/pair_eam.jpg)
where F is the embedding energy which is a function of the atomic
electron density rho, phi is a pair potential interaction, and alpha
and beta are the element types of atoms I and J. The multi-body
nature of the EAM potential is a result of the embedding energy term.
Both summations in the formula are over all neighbors J of atom I
within the cutoff distance.
The cutoff distance and the tabulated values of the functionals F,
rho, and phi are listed in one or more files which are specified by
the "pair_coeff"_pair_coeff.html command. These are ASCII text files
in a DYNAMO-style format which is described below. DYNAMO was the
original serial EAM MD code, written by the EAM originators. Several
DYNAMO potential files for different metals are included in the
"potentials" directory of the LAMMPS distribution. All of these files
are parameterized in terms of LAMMPS "metal units"_units.html.
NOTE: The {eam} style reads single-element EAM potentials in the
DYNAMO {funcfl} format. Either single element or alloy systems can be
modeled using multiple {funcfl} files and style {eam}. For the alloy
case LAMMPS mixes the single-element potentials to produce alloy
potentials, the same way that DYNAMO does. Alternatively, a single
DYNAMO {setfl} file or Finnis/Sinclair EAM file can be used by LAMMPS
to model alloy systems by invoking the {eam/alloy} or {eam/cd} or
{eam/fs} styles as described below. These files require no mixing
since they specify alloy interactions explicitly.
NOTE: Note that unlike for other potentials, cutoffs for EAM
potentials are not set in the pair_style or pair_coeff command; they
are specified in the EAM potential files themselves. Likewise, the
EAM potential files list atomic masses; thus you do not need to use
the "mass"_mass.html command to specify them.
There are several WWW sites that distribute and document EAM
potentials stored in DYNAMO or other formats:
http://www.ctcms.nist.gov/potentials
http://cst-www.nrl.navy.mil/ccm6/ap
http://enpub.fulton.asu.edu/cms/potentials/main/main.htm :pre
These potentials should be usable with LAMMPS, though the alternate
formats would need to be converted to the DYNAMO format used by LAMMPS
and described on this page. The NIST site is maintained by Chandler
Becker (cbecker at nist.gov) who is good resource for info on
interatomic potentials and file formats.
:line
For style {eam}, potential values are read from a file that is in the
DYNAMO single-element {funcfl} format. If the DYNAMO file was created
by a Fortran program, it cannot have "D" values in it for exponents.
C only recognizes "e" or "E" for scientific notation.
Note that unlike for other potentials, cutoffs for EAM potentials are
not set in the pair_style or pair_coeff command; they are specified in
the EAM potential files themselves.
For style {eam} a potential file must be assigned to each I,I pair of
atom types by using one or more pair_coeff commands, each with a
single argument:
filename :ul
Thus the following command
pair_coeff *2 1*2 cuu3.eam :pre
will read the cuu3 potential file and use the tabulated Cu values for
F, phi, rho that it contains for type pairs 1,1 and 2,2 (type pairs
1,2 and 2,1 are ignored). See the "pair_coeff"_pair_coeff.html doc
page for alternate ways to specify the path for the potential file.
In effect, this makes atom types 1 and 2 in LAMMPS be Cu atoms.
Different single-element files can be assigned to different atom types
to model an alloy system. The mixing to create alloy potentials for
type pairs with I != J is done automatically the same way that the
serial DYNAMO code originally did it; you do not need to specify
coefficients for these type pairs.
{Funcfl} files in the {potentials} directory of the LAMMPS
distribution have an ".eam" suffix. A DYNAMO single-element {funcfl}
file is formatted as follows:
line 1: comment (ignored)
line 2: atomic number, mass, lattice constant, lattice type (e.g. FCC)
line 3: Nrho, drho, Nr, dr, cutoff :ul
On line 2, all values but the mass are ignored by LAMMPS. The mass is
in mass "units"_units.html, e.g. mass number or grams/mole for metal
units. The cubic lattice constant is in Angstroms. On line 3, Nrho
and Nr are the number of tabulated values in the subsequent arrays,
drho and dr are the spacing in density and distance space for the
values in those arrays, and the specified cutoff becomes the pairwise
cutoff used by LAMMPS for the potential. The units of dr are
Angstroms; I'm not sure of the units for drho - some measure of
electron density.
Following the three header lines are three arrays of tabulated values:
embedding function F(rho) (Nrho values)
effective charge function Z(r) (Nr values)
density function rho(r) (Nr values) :ul
The values for each array can be listed as multiple values per line,
so long as each array starts on a new line. For example, the
individual Z(r) values are for r = 0,dr,2*dr, ... (Nr-1)*dr.
The units for the embedding function F are eV. The units for the
density function rho are the same as for drho (see above, electron
density). The units for the effective charge Z are "atomic charge" or
sqrt(Hartree * Bohr-radii). For two interacting atoms i,j this is used
by LAMMPS to compute the pair potential term in the EAM energy
expression as r*phi, in units of eV-Angstroms, via the formula
r*phi = 27.2 * 0.529 * Zi * Zj :pre
where 1 Hartree = 27.2 eV and 1 Bohr = 0.529 Angstroms.
:line
Style {eam/alloy} computes pairwise interactions using the same
formula as style {eam}. However the associated
"pair_coeff"_pair_coeff.html command reads a DYNAMO {setfl} file
instead of a {funcfl} file. {Setfl} files can be used to model a
single-element or alloy system. In the alloy case, as explained
above, {setfl} files contain explicit tabulated values for alloy
interactions. Thus they allow more generality than {funcfl} files for
modeling alloys.
For style {eam/alloy}, potential values are read from a file that is
in the DYNAMO multi-element {setfl} format, except that element names
(Ni, Cu, etc) are added to one of the lines in the file. If the
DYNAMO file was created by a Fortran program, it cannot have "D"
values in it for exponents. C only recognizes "e" or "E" for
scientific notation.
Only a single pair_coeff command is used with the {eam/alloy} style
which specifies a DYNAMO {setfl} file, which contains information for
M elements. These are mapped to LAMMPS atom types by specifying N
additional arguments after the filename in the pair_coeff command,
where N is the number of LAMMPS atom types:
filename
N element names = mapping of {setfl} elements to atom types :ul
As an example, the potentials/NiAlH_jea.eam.alloy file is a {setfl}
file which has tabulated EAM values for 3 elements and their alloy
interactions: Ni, Al, and H. See the "pair_coeff"_pair_coeff.html doc
page for alternate ways to specify the path for the potential file.
If your LAMMPS simulation has 4 atoms types and you want the 1st 3 to
be Ni, and the 4th to be Al, you would use the following pair_coeff
command:
pair_coeff * * NiAlH_jea.eam.alloy Ni Ni Ni Al :pre
The 1st 2 arguments must be * * so as to span all LAMMPS atom types.
The first three Ni arguments map LAMMPS atom types 1,2,3 to the Ni
element in the {setfl} file. The final Al argument maps LAMMPS atom
type 4 to the Al element in the {setfl} file. Note that there is no
requirement that your simulation use all the elements specified by the
{setfl} file.
If a mapping value is specified as NULL, the mapping is not performed.
This can be used when an {eam/alloy} potential is used as part of the
{hybrid} pair style. The NULL values are placeholders for atom types
that will be used with other potentials.
{Setfl} files in the {potentials} directory of the LAMMPS distribution
have an ".eam.alloy" suffix. A DYNAMO multi-element {setfl} file is
formatted as follows:
lines 1,2,3 = comments (ignored)
line 4: Nelements Element1 Element2 ... ElementN
line 5: Nrho, drho, Nr, dr, cutoff :ul
In a DYNAMO {setfl} file, line 4 only lists Nelements = the # of
elements in the {setfl} file. For LAMMPS, the element name (Ni, Cu,
etc) of each element must be added to the line, in the order the
elements appear in the file.
The meaning and units of the values in line 5 is the same as for the
{funcfl} file described above. Note that the cutoff (in Angstroms) is
a global value, valid for all pairwise interactions for all element
pairings.
Following the 5 header lines are Nelements sections, one for each
element, each with the following format:
line 1 = atomic number, mass, lattice constant, lattice type (e.g. FCC)
embedding function F(rho) (Nrho values)
density function rho(r) (Nr values) :ul
As with the {funcfl} files, only the mass (in mass "units"_units.html,
e.g. mass number or grams/mole for metal units) is used by LAMMPS from
the 1st line. The cubic lattice constant is in Angstroms. The F and
rho arrays are unique to a single element and have the same format and
units as in a {funcfl} file.
Following the Nelements sections, Nr values for each pair potential
phi(r) array are listed for all i,j element pairs in the same format
as other arrays. Since these interactions are symmetric (i,j = j,i)
only phi arrays with i >= j are listed, in the following order: i,j =
(1,1), (2,1), (2,2), (3,1), (3,2), (3,3), (4,1), ..., (Nelements,
Nelements). Unlike the effective charge array Z(r) in {funcfl} files,
the tabulated values for each phi function are listed in {setfl} files
directly as r*phi (in units of eV-Angstroms), since they are for atom
pairs.
:line
Style {eam/cd} is similar to the {eam/alloy} style, except that it
computes alloy pairwise interactions using the concentration-dependent
embedded-atom method (CD-EAM). This model can reproduce the enthalpy
of mixing of alloys over the full composition range, as described in
"(Stukowski)"_#Stukowski.
The pair_coeff command is specified the same as for the {eam/alloy}
style. However the DYNAMO {setfl} file must has two
lines added to it, at the end of the file:
line 1: Comment line (ignored)
line 2: N Coefficient0 Coefficient1 ... CoefficientN :ul
The last line begins with the degree {N} of the polynomial function
{h(x)} that modifies the cross interaction between A and B elements.
Then {N+1} coefficients for the terms of the polynomial are then
listed.
Modified EAM {setfl} files used with the {eam/cd} style must contain
exactly two elements, i.e. in the current implementation the {eam/cd}
style only supports binary alloys. The first and second elements in
the input EAM file are always taken as the {A} and {B} species.
{CD-EAM} files in the {potentials} directory of the LAMMPS
distribution have a ".cdeam" suffix.
:line
Style {eam/fs} computes pairwise interactions for metals and metal
alloys using a generalized form of EAM potentials due to Finnis and
Sinclair "(Finnis)"_#Finnis. The total energy Ei of an atom I is
given by
:c,image(Eqs/pair_eam_fs.jpg)
This has the same form as the EAM formula above, except that rho is
now a functional specific to the atomic types of both atoms I and J,
so that different elements can contribute differently to the total
electron density at an atomic site depending on the identity of the
element at that atomic site.
The associated "pair_coeff"_pair_coeff.html command for style {eam/fs}
reads a DYNAMO {setfl} file that has been extended to include
additional rho_alpha_beta arrays of tabulated values. A discussion of
how FS EAM differs from conventional EAM alloy potentials is given in
"(Ackland1)"_#Ackland1. An example of such a potential is the same
author's Fe-P FS potential "(Ackland2)"_#Ackland2. Note that while FS
potentials always specify the embedding energy with a square root
dependence on the total density, the implementation in LAMMPS does not
require that; the user can tabulate any functional form desired in the
FS potential files.
For style {eam/fs}, the form of the pair_coeff command is exactly the
same as for style {eam/alloy}, e.g.
pair_coeff * * NiAlH_jea.eam.fs Ni Ni Ni Al :pre
where there are N additional arguments after the filename, where N is
the number of LAMMPS atom types. See the "pair_coeff"_pair_coeff.html
doc page for alternate ways to specify the path for the potential
file. The N values determine the mapping of LAMMPS atom types to EAM
elements in the file, as described above for style {eam/alloy}. As
with {eam/alloy}, if a mapping value is NULL, the mapping is not
performed. This can be used when an {eam/fs} potential is used as
part of the {hybrid} pair style. The NULL values are used as
placeholders for atom types that will be used with other potentials.
FS EAM files include more information than the DYNAMO {setfl} format
files read by {eam/alloy}, in that i,j density functionals for all
pairs of elements are included as needed by the Finnis/Sinclair
formulation of the EAM.
FS EAM files in the {potentials} directory of the LAMMPS distribution
have an ".eam.fs" suffix. They are formatted as follows:
lines 1,2,3 = comments (ignored)
line 4: Nelements Element1 Element2 ... ElementN
line 5: Nrho, drho, Nr, dr, cutoff :ul
The 5-line header section is identical to an EAM {setfl} file.
Following the header are Nelements sections, one for each element I,
each with the following format:
line 1 = atomic number, mass, lattice constant, lattice type (e.g. FCC)
embedding function F(rho) (Nrho values)
density function rho(r) for element I at element 1 (Nr values)
density function rho(r) for element I at element 2
...
density function rho(r) for element I at element Nelement :ul
The units of these quantities in line 1 are the same as for {setfl}
files. Note that the rho(r) arrays in Finnis/Sinclair can be
asymmetric (i,j != j,i) so there are Nelements^2 of them listed in the
file.
Following the Nelements sections, Nr values for each pair potential
phi(r) array are listed in the same manner (r*phi, units of
eV-Angstroms) as in EAM {setfl} files. Note that in Finnis/Sinclair,
the phi(r) arrays are still symmetric, so only phi arrays for i >= j
are listed.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for more
instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, where types I and J correspond to
two different element types, mixing is performed by LAMMPS as
described above with the individual styles. You never need to specify
a pair_coeff command with I != J arguments for the eam styles.
This pair style does not support the "pair_modify"_pair_modify.html
shift, table, and tail options.
The eam pair styles do not write their 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.
The eam pair styles can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. They do not support the
{inner}, {middle}, {outer} keywords.
:line
[Restrictions:]
All of these styles except the {eam/cd} style are part of the MANYBODY
package. They are only enabled if LAMMPS was built with that package.
See the "Making LAMMPS"_Section_start.html#start_3 section for more info.
The {eam/cd} style is part of the USER-MISC package and also requires
the MANYBODY package. It is only enabled if LAMMPS was built with
those packages. See the "Making LAMMPS"_Section_start.html#start_3
section for more info.
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
:line
:link(Ackland1)
[(Ackland1)] Ackland, Condensed Matter (2005).
:link(Ackland2)
[(Ackland2)] Ackland, Mendelev, Srolovitz, Han and Barashev, Journal
of Physics: Condensed Matter, 16, S2629 (2004).
:link(Daw)
[(Daw)] Daw, Baskes, Phys Rev Lett, 50, 1285 (1983).
Daw, Baskes, Phys Rev B, 29, 6443 (1984).
:link(Finnis)
[(Finnis)] Finnis, Sinclair, Philosophical Magazine A, 50, 45 (1984).
:link(Stukowski)
[(Stukowski)] Stukowski, Sadigh, Erhart, Caro; Modeling Simulation
Materials Science & Engineering, 7, 075005 (2009).
diff --git a/doc/src/pair_edip.txt b/doc/src/pair_edip.txt
index 86453859d..e5b1420b5 100644
--- a/doc/src/pair_edip.txt
+++ b/doc/src/pair_edip.txt
@@ -1,172 +1,172 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style edip command :h3
pair_style edip/multi command :h3
[Syntax:]
pair_style style :pre
style = {edip} or {edip/multi} :ul
[Examples:]
pair_style edip
pair_coeff * * Si.edip Si
[Description:]
The {edip} and {edip/multi} styles compute a 3-body "EDIP"_#EDIP
potential which is popular for modeling silicon materials where
it can have advantages over other models such as the
"Stillinger-Weber"_pair_sw.html or "Tersoff"_pair_tersoff.html
potentials. The {edip} style has been programmed for single element
potentials, while {edip/multi} supports multi-element EDIP runs.
In EDIP, the energy E of a system of atoms is
:c,image(Eqs/pair_edip.jpg)
where phi2 is a two-body term and phi3 is a three-body term. The
summations in the formula are over all neighbors J and K of atom I
within a cutoff distance = a.
Both terms depend on the local environment of atom I through its
effective coordination number defined by Z, which is unity for a
cutoff distance < c and gently goes to 0 at distance = a.
Only a single pair_coeff command is used with the {edip} style which
specifies a EDIP potential file with parameters for all
needed elements. These are mapped to LAMMPS atom types by specifying
N additional arguments after the filename in the pair_coeff command,
where N is the number of LAMMPS atom types:
filename
N element names = mapping of EDIP elements to atom types :ul
See the "pair_coeff"_pair_coeff.html doc page for alternate ways
to specify the path for the potential file.
As an example, imagine a file Si.edip has EDIP values for Si.
EDIP files in the {potentials} directory of the LAMMPS
distribution have a ".edip" suffix. Lines that are not blank or
comments (starting with #) define parameters for a triplet of
elements. The parameters in a single entry correspond to the two-body
and three-body coefficients in the formula above:
element 1 (the center atom in a 3-body interaction)
element 2
element 3
A (energy units)
B (distance units)
cutoffA (distance units)
cutoffC (distance units)
alpha
beta
eta
gamma (distance units)
lambda (energy units)
mu
tho
sigma (distance units)
Q0
u1
u2
u3
u4 :ul
The A, B, beta, sigma parameters are used only for two-body interactions.
The eta, gamma, lambda, mu, Q0 and all u1 to u4 parameters are used only
for three-body interactions. The alpha and cutoffC parameters are used
for the coordination environment function only.
The EDIP potential file must contain entries for all the
elements listed in the pair_coeff command. It can also contain
entries for additional elements not being used in a particular
simulation; LAMMPS ignores those entries.
For a single-element simulation, only a single entry is required
(e.g. SiSiSi). For a two-element simulation, the file must contain 8
entries (for SiSiSi, SiSiC, SiCSi, SiCC, CSiSi, CSiC, CCSi, CCC), that
specify EDIP parameters for all permutations of the two elements
interacting in three-body configurations. Thus for 3 elements, 27
entries would be required, etc.
At the moment, only a single element parametrization is
implemented. However, the author is not aware of other
multi-element EDIP parameterization. If you know any and
you are interest in that, please contact the author of
the EDIP package.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
This pair style does not support the "pair_modify"_pair_modify.html
shift, table, and tail options.
This pair style does not write its information to "binary restart
files"_restart.html, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.
This pair style can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. It does not support the
{inner}, {middle}, {outer} keywords.
:line
[Restrictions:]
This pair style can only be used if LAMMPS was built with the
USER-MISC package. See the "Making LAMMPS"_Section_start.html#start_3
section for more info on packages.
This pair style requires the "newton"_newton.html setting to be "on"
for pair interactions.
The EDIP potential files provided with LAMMPS (see the potentials directory)
are parameterized for metal "units"_units.html.
You can use the EDIP potential with any LAMMPS units, but you would need
to create your own EDIP potential file with coefficients listed in the
appropriate units if your simulation doesn't use "metal" units.
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
:line
:link(EDIP)
[(EDIP)] J F Justo et al, Phys Rev B 58, 2539 (1998).
diff --git a/doc/src/pair_eim.txt b/doc/src/pair_eim.txt
index 3f068d404..75ad2d468 100644
--- a/doc/src/pair_eim.txt
+++ b/doc/src/pair_eim.txt
@@ -1,174 +1,174 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style eim command :h3
pair_style eim/omp command :h3
[Syntax:]
pair_style style :pre
style = {eim} :ul
[Examples:]
pair_style eim
pair_coeff * * Na Cl ../potentials/ffield.eim Na Cl
pair_coeff * * Na Cl ffield.eim Na Na Na Cl
pair_coeff * * Na Cl ../potentials/ffield.eim Cl NULL Na :pre
[Description:]
Style {eim} computes pairwise interactions for ionic compounds
using embedded-ion method (EIM) potentials "(Zhou)"_#Zhou2. The
energy of the system E is given by
:c,image(Eqs/pair_eim1.jpg)
The first term is a double pairwise sum over the J neighbors of all I
atoms, where phi_ij is a pair potential. The second term sums over
the embedding energy E_i of atom I, which is a function of its charge
q_i and the electrical potential sigma_i at its location. E_i, q_i,
and sigma_i are calculated as
:c,image(Eqs/pair_eim2.jpg)
where eta_ji is a pairwise function describing electron flow from atom
I to atom J, and psi_ij is another pairwise function. The multi-body
nature of the EIM potential is a result of the embedding energy term.
A complete list of all the pair functions used in EIM is summarized
below
:c,image(Eqs/pair_eim3.jpg)
Here E_b, r_e, r_(c,phi), alpha, beta, A_(psi), zeta, r_(s,psi),
r_(c,psi), A_(eta), r_(s,eta), r_(c,eta), chi, and pair function type
p are parameters, with subscripts ij indicating the two species of
atoms in the atomic pair.
NOTE: Even though the EIM potential is treating atoms as charged ions,
you should not use a LAMMPS "atom_style"_atom_style.html that stores a
charge on each atom and thus requires you to assign a charge to each
atom, e.g. the {charge} or {full} atom styles. This is because the
EIM potential infers the charge on an atom from the equation above for
q_i; you do not assign charges explicitly.
:line
All the EIM parameters are listed in a potential file which is
specified by the "pair_coeff"_pair_coeff.html command. This is an
ASCII text file in a format described below. The "ffield.eim" file
included in the "potentials" directory of the LAMMPS distribution
currently includes nine elements Li, Na, K, Rb, Cs, F, Cl, Br, and I.
A system with any combination of these elements can be modeled. This
file is parameterized in terms of LAMMPS "metal units"_units.html.
Note that unlike other potentials, cutoffs for EIM potentials are not
set in the pair_style or pair_coeff command; they are specified in the
EIM potential file itself. Likewise, the EIM potential file lists
atomic masses; thus you do not need to use the "mass"_mass.html
command to specify them.
Only a single pair_coeff command is used with the {eim} style which
specifies an EIM potential file and the element(s) to extract
information for. The EIM elements are mapped to LAMMPS atom types by
specifying N additional arguments after the filename in the pair_coeff
command, where N is the number of LAMMPS atom types:
Elem1, Elem2, ...
EIM potential file
N element names = mapping of EIM elements to atom types :ul
See the "pair_coeff"_pair_coeff.html doc page for alternate ways
to specify the path for the potential file.
As an example like one of those above, suppose you want to model a
system with Na and Cl atoms. If your LAMMPS simulation has 4 atoms
types and you want the 1st 3 to be Na, and the 4th to be Cl, you would
use the following pair_coeff command:
pair_coeff * * Na Cl ffield.eim Na Na Na Cl :pre
The 1st 2 arguments must be * * so as to span all LAMMPS atom types.
The filename is the EIM potential file. The Na and Cl arguments
(before the file name) are the two elements for which info will be
extracted from the potential file. The first three trailing Na
arguments map LAMMPS atom types 1,2,3 to the EIM Na element. The
final Cl argument maps LAMMPS atom type 4 to the EIM Cl element.
If a mapping value is specified as NULL, the mapping is not performed.
This can be used when an {eim} potential is used as part of the
{hybrid} pair style. The NULL values are placeholders for atom types
that will be used with other potentials.
The ffield.eim file in the {potentials} directory of the LAMMPS
distribution is formatted as follows:
Lines starting with # are comments and are ignored by LAMMPS. Lines
starting with "global:" include three global values. The first value
divides the cations from anions, i.e., any elements with
electronegativity above this value are viewed as anions, and any
elements with electronegativity below this value are viewed as
cations. The second and third values are related to the cutoff
function - i.e. the 0.510204, 1.64498, and 0.010204 shown in the above
equation can be derived from these values.
Lines starting with "element:" are formatted as follows: name of
element, atomic number, atomic mass, electronic negativity, atomic
radius (LAMMPS ignores it), ionic radius (LAMMPS ignores it), cohesive
energy (LAMMPS ignores it), and q0 (must be 0).
Lines starting with "pair:" are entered as: element 1, element 2,
r_(c,phi), r_(c,phi) (redundant for historical reasons), E_b, r_e,
alpha, beta, r_(c,eta), A_(eta), r_(s,eta), r_(c,psi), A_(psi), zeta,
r_(s,psi), and p.
The lines in the file can be in any order; LAMMPS extracts the info it
needs.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This style is part of the MANYBODY package. It is only enabled if
LAMMPS was built with that package.
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
:line
:link(Zhou2)
[(Zhou)] Zhou, submitted for publication (2010). Please contact
Xiaowang Zhou (Sandia) for details via email at xzhou at sandia.gov.
diff --git a/doc/src/pair_gayberne.txt b/doc/src/pair_gayberne.txt
index 8639f220a..c92357858 100644
--- a/doc/src/pair_gayberne.txt
+++ b/doc/src/pair_gayberne.txt
@@ -1,231 +1,231 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style gayberne command :h3
pair_style gayberne/gpu command :h3
pair_style gayberne/intel command :h3
pair_style gayberne/omp command :h3
[Syntax:]
pair_style gayberne gamma upsilon mu cutoff :pre
gamma = shift for potential minimum (typically 1)
upsilon = exponent for eta orientation-dependent energy function
mu = exponent for chi orientation-dependent energy function
cutoff = global cutoff for interactions (distance units) :ul
[Examples:]
pair_style gayberne 1.0 1.0 1.0 10.0
pair_coeff * * 1.0 1.7 1.7 3.4 3.4 1.0 1.0 1.0 :pre
[Description:]
The {gayberne} styles compute a Gay-Berne anisotropic LJ interaction
"(Berardi)"_#Berardi between pairs of ellipsoidal particles or an
ellipsoidal and spherical particle via the formulas
:c,image(Eqs/pair_gayberne.jpg)
where A1 and A2 are the transformation matrices from the simulation
box frame to the body frame and r12 is the center to center vector
between the particles. Ur controls the shifted distance dependent
interaction based on the distance of closest approach of the two
particles (h12) and the user-specified shift parameter gamma. When
both particles are spherical, the formula reduces to the usual
Lennard-Jones interaction (see details below for when Gay-Berne treats
a particle as "spherical").
For large uniform molecules it has been shown that the energy
parameters are approximately representable in terms of local contact
curvatures "(Everaers)"_#Everaers2:
:c,image(Eqs/pair_gayberne2.jpg)
The variable names utilized as potential parameters are for the most
part taken from "(Everaers)"_#Everaers2 in order to be consistent with
the "RE-squared pair potential"_pair_resquared.html. Details on the
upsilon and mu parameters are given
"here"_PDF/pair_resquared_extra.pdf.
More details of the Gay-Berne formulation are given in the references
listed below and in "this supplementary
document"_PDF/pair_gayberne_extra.pdf.
Use of this pair style requires the NVE, NVT, or NPT fixes with the
{asphere} extension (e.g. "fix nve/asphere"_fix_nve_asphere.html) in
order to integrate particle rotation. Additionally, "atom_style
ellipsoid"_atom_style.html should be used since it defines the
rotational state and the size and shape of each ellipsoidal particle.
The following coefficients must be defined for each pair of atoms
types via the "pair_coeff"_pair_coeff.html command as in the examples
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands, or by mixing as described below:
epsilon = well depth (energy units)
sigma = minimum effective particle radii (distance units)
epsilon_i_a = relative well depth of type I for side-to-side interactions
epsilon_i_b = relative well depth of type I for face-to-face interactions
epsilon_i_c = relative well depth of type I for end-to-end interactions
epsilon_j_a = relative well depth of type J for side-to-side interactions
epsilon_j_b = relative well depth of type J for face-to-face interactions
epsilon_j_c = relative well depth of type J for end-to-end interactions
cutoff (distance units) :ul
The last coefficient is optional. If not specified, the global
cutoff specified in the pair_style command is used.
It is typical with the Gay-Berne potential to define {sigma} as the
minimum of the 3 shape diameters of the particles involved in an I,I
interaction, though this is not required. Note that this is a
different meaning for {sigma} than the "pair_style
resquared"_pair_resquared.html potential uses.
The epsilon_i and epsilon_j coefficients are actually defined for atom
types, not for pairs of atom types. Thus, in a series of pair_coeff
commands, they only need to be specified once for each atom type.
Specifically, if any of epsilon_i_a, epsilon_i_b, epsilon_i_c are
non-zero, the three values are assigned to atom type I. If all the
epsilon_i values are zero, they are ignored. If any of epsilon_j_a,
epsilon_j_b, epsilon_j_c are non-zero, the three values are assigned
to atom type J. If all three epsilon_j values are zero, they are
ignored. Thus the typical way to define the epsilon_i and epsilon_j
coefficients is to list their values in "pair_coeff I J" commands when
I = J, but set them to 0.0 when I != J. If you do list them when I !=
J, you should insure they are consistent with their values in other
pair_coeff commands, since only the last setting will be in effect.
Note that if this potential is being used as a sub-style of
"pair_style hybrid"_pair_hybrid.html, and there is no "pair_coeff I I"
setting made for Gay-Berne for a particular type I (because I-I
interactions are computed by another hybrid pair potential), then you
still need to insure the epsilon a,b,c coefficients are assigned to
that type. e.g. in a "pair_coeff I J" command.
NOTE: If the epsilon a = b = c for an atom type, and if the shape of
the particle itself is spherical, meaning its 3 shape parameters are
all the same, then the particle is treated as an LJ sphere by the
Gay-Berne potential. This is significant because if two LJ spheres
interact, then the simple Lennard-Jones formula is used to compute
their interaction energy/force using the specified epsilon and sigma
as the standard LJ parameters. This is much cheaper to compute than
the full Gay-Berne formula. To treat the particle as a LJ sphere with
sigma = D, you should normally set epsilon a = b = c = 1.0, set the
pair_coeff sigma = D, and also set the 3 shape parameters for the
particle to D. The one exception is that if the 3 shape parameters
are set to 0.0, which is a valid way in LAMMPS to specify a point
particle, then the Gay-Berne potential will treat that as shape
parameters of 1.0 (i.e. a LJ particle with sigma = 1), since it
requires finite-size particles. In this case you should still set the
pair_coeff sigma to 1.0 as well.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance for this pair style can be mixed. The default mix
value is {geometric}. See the "pair_modify" command for details.
This pair styles supports the "pair_modify"_pair_modify.html shift
option for the energy of the Lennard-Jones portion of the pair
interaction, but only for sphere-sphere interactions. There is no
shifting performed for ellipsoidal interactions due to the anisotropic
dependence of the interaction.
The "pair_modify"_pair_modify.html table option is not relevant
for this pair style.
This pair style does not support the "pair_modify"_pair_modify.html
tail option for adding long-range tail corrections to energy and
pressure.
This pair style writes its information to "binary restart
files"_restart.html, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.
This pair style can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. It does not support the
{inner}, {middle}, {outer} keywords.
:line
[Restrictions:]
The {gayberne} style is part of the ASPHERE package. It is only
enabled if LAMMPS was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
These pair style require that atoms store torque and a quaternion to
represent their orientation, as defined by the
"atom_style"_atom_style.html. It also require they store a per-type
"shape"_set.html. The particles cannot store a per-particle
diameter.
This pair style requires that atoms be ellipsoids as defined by the
"atom_style ellipsoid"_atom_style.html command.
Particles acted on by the potential can be finite-size aspherical or
spherical particles, or point particles. Spherical particles have all
3 of their shape parameters equal to each other. Point particles have
all 3 of their shape parameters equal to 0.0.
The Gay-Berne potential does not become isotropic as r increases
"(Everaers)"_#Everaers2. The distance-of-closest-approach
approximation used by LAMMPS becomes less accurate when high-aspect
ratio ellipsoids are used.
[Related commands:]
"pair_coeff"_pair_coeff.html, "fix nve/asphere"_fix_nve_asphere.html,
"compute temp/asphere"_compute_temp_asphere.html, "pair_style
resquared"_pair_resquared.html
[Default:] none
:line
:link(Everaers2)
[(Everaers)] Everaers and Ejtehadi, Phys Rev E, 67, 041710 (2003).
:link(Berardi)
[(Berardi)] Berardi, Fava, Zannoni, Chem Phys Lett, 297, 8-14 (1998).
Berardi, Muccioli, Zannoni, J Chem Phys, 128, 024905 (2008).
:link(Perram)
[(Perram)] Perram and Rasmussen, Phys Rev E, 54, 6565-6572 (1996).
:link(Allen3)
[(Allen)] Allen and Germano, Mol Phys 104, 3225-3235 (2006).
diff --git a/doc/src/pair_gran.txt b/doc/src/pair_gran.txt
index 62a58b350..d7e87af01 100644
--- a/doc/src/pair_gran.txt
+++ b/doc/src/pair_gran.txt
@@ -1,271 +1,271 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style gran/hooke command :h3
pair_style gran/omp command :h3
pair_style gran/hooke/history command :h3
pair_style gran/hooke/history/omp command :h3
pair_style gran/hertz/history command :h3
pair_style gran/hertz/history/omp command :h3
[Syntax:]
pair_style style Kn Kt gamma_n gamma_t xmu dampflag :pre
style = {gran/hooke} or {gran/hooke/history} or {gran/hertz/history} :ulb,l
Kn = elastic constant for normal particle repulsion (force/distance units or pressure units - see discussion below) :l
Kt = elastic constant for tangential contact (force/distance units or pressure units - see discussion below) :l
gamma_n = damping coefficient for collisions in normal direction (1/time units or 1/time-distance units - see discussion below) :l
gamma_t = damping coefficient for collisions in tangential direction (1/time units or 1/time-distance units - see discussion below) :l
xmu = static yield criterion (unitless value between 0.0 and 1.0e4) :l
dampflag = 0 or 1 if tangential damping force is excluded or included :l
:ule
NOTE: Versions of LAMMPS before 9Jan09 had different style names for
granular force fields. This is to emphasize the fact that the
Hertzian equation has changed to model polydispersity more accurately.
A side effect of the change is that the Kn, Kt, gamma_n, and gamma_t
coefficients in the pair_style command must be specified with
different values in order to reproduce calculations made with earlier
versions of LAMMPS, even for monodisperse systems. See the NOTE below
for details.
[Examples:]
pair_style gran/hooke/history 200000.0 NULL 50.0 NULL 0.5 1
pair_style gran/hooke 200000.0 70000.0 50.0 30.0 0.5 0 :pre
[Description:]
The {gran} styles use the following formulas for the frictional force
between two granular particles, as described in
"(Brilliantov)"_#Brilliantov, "(Silbert)"_#Silbert, and
"(Zhang)"_#Zhang3, when the distance r between two particles of radii
Ri and Rj is less than their contact distance d = Ri + Rj. There is
no force between the particles when r > d.
The two Hookean styles use this formula:
:c,image(Eqs/pair_gran_hooke.jpg)
The Hertzian style uses this formula:
:c,image(Eqs/pair_gran_hertz.jpg)
In both equations the first parenthesized term is the normal force
between the two particles and the second parenthesized term is the
tangential force. The normal force has 2 terms, a contact force and a
damping force. The tangential force also has 2 terms: a shear force
and a damping force. The shear force is a "history" effect that
accounts for the tangential displacement between the particles for the
duration of the time they are in contact. This term is included in
pair styles {hooke/history} and {hertz/history}, but is not included
in pair style {hooke}. The tangential damping force term is included
in all three pair styles if {dampflag} is set to 1; it is not included
if {dampflag} is set to 0.
The other quantities in the equations are as follows:
delta = d - r = overlap distance of 2 particles
Kn = elastic constant for normal contact
Kt = elastic constant for tangential contact
gamma_n = viscoelastic damping constant for normal contact
gamma_t = viscoelastic damping constant for tangential contact
m_eff = Mi Mj / (Mi + Mj) = effective mass of 2 particles of mass Mi and Mj
Delta St = tangential displacement vector between 2 particles \
which is truncated to satisfy a frictional yield criterion
n_ij = unit vector along the line connecting the centers of the 2 particles
Vn = normal component of the relative velocity of the 2 particles
Vt = tangential component of the relative velocity of the 2 particles :ul
The Kn, Kt, gamma_n, and gamma_t coefficients are specified as
parameters to the pair_style command. If a NULL is used for Kt, then
a default value is used where Kt = 2/7 Kn. If a NULL is used for
gamma_t, then a default value is used where gamma_t = 1/2 gamma_n.
The interpretation and units for these 4 coefficients are different in
the Hookean versus Hertzian equations.
The Hookean model is one where the normal push-back force for two
overlapping particles is a linear function of the overlap distance.
Thus the specified Kn is in units of (force/distance). Note that this
push-back force is independent of absolute particle size (in the
monodisperse case) and of the relative sizes of the two particles (in
the polydisperse case). This model also applies to the other terms in
the force equation so that the specified gamma_n is in units of
(1/time), Kt is in units of (force/distance), and gamma_t is in units
of (1/time).
The Hertzian model is one where the normal push-back force for two
overlapping particles is proportional to the area of overlap of the
two particles, and is thus a non-linear function of overlap distance.
Thus Kn has units of force per area and is thus specified in units of
(pressure). The effects of absolute particle size (monodispersity)
and relative size (polydispersity) are captured in the radii-dependent
pre-factors. When these pre-factors are carried through to the other
terms in the force equation it means that the specified gamma_n is in
units of (1/(time*distance)), Kt is in units of (pressure), and
gamma_t is in units of (1/(time*distance)).
Note that in the Hookean case, Kn can be thought of as a linear spring
constant with units of force/distance. In the Hertzian case, Kn is
like a non-linear spring constant with units of force/area or
pressure, and as shown in the "(Zhang)"_#Zhang3 paper, Kn = 4G /
(3(1-nu)) where nu = the Poisson ratio, G = shear modulus = E /
(2(1+nu)), and E = Young's modulus. Similarly, Kt = 4G / (2-nu).
(NOTE: in an earlier version of the manual, we incorrectly stated that
Kt = 8G / (2-nu).)
Thus in the Hertzian case Kn and Kt can be set to values that
corresponds to properties of the material being modeled. This is also
true in the Hookean case, except that a spring constant must be chosen
that is appropriate for the absolute size of particles in the model.
Since relative particle sizes are not accounted for, the Hookean
styles may not be a suitable model for polydisperse systems.
NOTE: In versions of LAMMPS before 9Jan09, the equation for Hertzian
interactions did not include the sqrt(RiRj/Ri+Rj) term and thus was
not as accurate for polydisperse systems. For monodisperse systems,
sqrt(RiRj/Ri+Rj) is a constant factor that effectively scales all 4
coefficients: Kn, Kt, gamma_n, gamma_t. Thus you can set the values
of these 4 coefficients appropriately in the current code to reproduce
the results of a previous Hertzian monodisperse calculation. For
example, for the common case of a monodisperse system with particles
of diameter 1, all 4 of these coefficients should now be set 2x larger
than they were previously.
Xmu is also specified in the pair_style command and is the upper limit
of the tangential force through the Coulomb criterion Ft = xmu*Fn,
where Ft and Fn are the total tangential and normal force components
in the formulas above. Thus in the Hookean case, the tangential force
between 2 particles grows according to a tangential spring and
dash-pot model until Ft/Fn = xmu and is then held at Ft = Fn*xmu until
the particles lose contact. In the Hertzian case, a similar analogy
holds, though the spring is no longer linear.
NOTE: Normally, xmu should be specified as a fractional value between
0.0 and 1.0, however LAMMPS allows large values (up to 1.0e4) to allow
for modeling of systems which can sustain very large tangential
forces.
The effective mass {m_eff} is given by the formula above for two
isolated particles. If either particle is part of a rigid body, its
mass is replaced by the mass of the rigid body in the formula above.
This is determined by searching for a "fix rigid"_fix_rigid.html
command (or its variants).
For granular styles there are no additional coefficients to set for
each pair of atom types via the "pair_coeff"_pair_coeff.html command.
All settings are global and are made via the pair_style command.
However you must still use the "pair_coeff"_pair_coeff.html for all
pairs of granular atom types. For example the command
pair_coeff * * :pre
should be used if all atoms in the simulation interact via a granular
potential (i.e. one of the pair styles above is used). If a granular
potential is used as a sub-style of "pair_style
hybrid"_pair_hybrid.html, then specific atom types can be used in the
pair_coeff command to determine which atoms interact via a granular
potential.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
The "pair_modify"_pair_modify.html mix, shift, table, and tail options
are not relevant for granular pair styles.
These pair styles write their information to "binary restart
files"_restart.html, so a pair_style command does not need to be
specified in an input script that reads a restart file.
These pair styles can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. They do not support the
{inner}, {middle}, {outer} keywords.
The single() function of these pair styles returns 0.0 for the energy
of a pairwise interaction, since energy is not conserved in these
dissipative potentials. It also returns only the normal component of
the pairwise interaction force. However, the single() function also
calculates 10 extra pairwise quantities. The first 3 are the
components of the tangential force between particles I and J, acting
on particle I. The 4th is the magnitude of this tangential force.
The next 3 (5-7) are the components of the relative velocity in the
normal direction (along the line joining the 2 sphere centers). The
last 3 (8-10) the components of the relative velocity in the
tangential direction.
These extra quantities can be accessed by the "compute
pair/local"_compute_pair_local.html command, as {p1}, {p2}, ...,
{p10}.
:line
[Restrictions:]
All the granular pair styles are part of the GRANULAR package. It is
only enabled if LAMMPS was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
These pair styles require that atoms store torque and angular velocity
(omega) as defined by the "atom_style"_atom_style.html. They also
require a per-particle radius is stored. The {sphere} atom style does
all of this.
This pair style requires you to use the "comm_modify vel
yes"_comm_modify.html command so that velocites are stored by ghost
atoms.
These pair styles will not restart exactly when using the
"read_restart"_read_restart.html command, though they should provide
statistically similar results. This is because the forces they
compute depend on atom velocities. See the
"read_restart"_read_restart.html command for more details.
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
:line
:link(Brilliantov)
[(Brilliantov)] Brilliantov, Spahn, Hertzsch, Poschel, Phys Rev E, 53,
p 5382-5392 (1996).
:link(Silbert)
[(Silbert)] Silbert, Ertas, Grest, Halsey, Levine, Plimpton, Phys Rev
E, 64, p 051302 (2001).
:link(Zhang3)
[(Zhang)] Zhang and Makse, Phys Rev E, 72, p 011301 (2005).
diff --git a/doc/src/pair_gromacs.txt b/doc/src/pair_gromacs.txt
index 3aca8c3cd..ec84a2d57 100644
--- a/doc/src/pair_gromacs.txt
+++ b/doc/src/pair_gromacs.txt
@@ -1,155 +1,155 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style lj/gromacs command :h3
pair_style lj/gromacs/gpu command :h3
pair_style lj/gromacs/omp command :h3
pair_style lj/gromacs/coul/gromacs command :h3
pair_style lj/gromacs/coul/gromacs/omp command :h3
[Syntax:]
pair_style style args :pre
style = {lj/gromacs} or {lj/gromacs/coul/gromacs}
args = list of arguments for a particular style :ul
{lj/gromacs} args = inner outer
inner, outer = global switching cutoffs for Lennard Jones
{lj/gromacs/coul/gromacs} args = inner outer (inner2) (outer2)
inner, outer = global switching cutoffs for Lennard Jones (and Coulombic if only 2 args)
inner2, outer2 = global switching cutoffs for Coulombic (optional) :pre
[Examples:]
pair_style lj/gromacs 9.0 12.0
pair_coeff * * 100.0 2.0
pair_coeff 2 2 100.0 2.0 8.0 10.0 :pre
pair_style lj/gromacs/coul/gromacs 9.0 12.0
pair_style lj/gromacs/coul/gromacs 8.0 10.0 7.0 9.0
pair_coeff * * 100.0 2.0 :pre
[Description:]
The {lj/gromacs} styles compute shifted LJ and Coulombic interactions
with an additional switching function S(r) that ramps the energy and force
smoothly to zero between an inner and outer cutoff. It is a commonly
used potential in the "GROMACS"_http://www.gromacs.org MD code and for
the coarse-grained models of "(Marrink)"_#Marrink.
:c,image(Eqs/pair_gromacs.jpg)
r1 is the inner cutoff; rc is the outer cutoff. The coefficients A, B,
and C are computed by LAMMPS to perform the shifting and smoothing.
The function
S(r) is actually applied once to each term of the LJ formula and once
to the Coulombic formula, so there are 2 or 3 sets of A,B,C coefficients
depending on which pair_style is used. The boundary conditions
applied to the smoothing function are as follows: S'(r1) = S''(r1) = 0,
S(rc) = -E(rc), S'(rc) = -E'(rc), and S''(rc) = -E''(rc),
where E(r) is the corresponding term
in the LJ or Coulombic potential energy function.
Single and double primes denote first and second
derivatives with respect to r, respectively.
The inner and outer cutoff for the LJ and Coulombic terms can be the
same or different depending on whether 2 or 4 arguments are used in
the pair_style command. The inner LJ cutoff must be > 0, but the
inner Coulombic cutoff can be >= 0.
The following coefficients must be defined for each pair of atoms
types via the "pair_coeff"_pair_coeff.html command as in the examples
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands, or by mixing as described below:
epsilon (energy units)
sigma (distance units)
inner (distance units)
outer (distance units) :ul
Note that sigma is defined in the LJ formula as the zero-crossing
distance for the potential, not as the energy minimum at 2^(1/6)
sigma.
The last 2 coefficients are optional inner and outer cutoffs for style
{lj/gromacs}. If not specified, the global {inner} and {outer} values
are used.
The last 2 coefficients cannot be used with style
{lj/gromacs/coul/gromacs} because this force field does not allow
varying cutoffs for individual atom pairs; all pairs use the global
cutoff(s) specified in the pair_style command.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance for all of the lj/cut pair styles can be mixed.
The default mix value is {geometric}. See the "pair_modify" command
for details.
None of the GROMACS pair styles support the
"pair_modify"_pair_modify.html shift option, since the Lennard-Jones
portion of the pair interaction is already smoothed to 0.0 at the
cutoff.
The "pair_modify"_pair_modify.html table option is not relevant
for this pair style.
None of the GROMACS pair styles support the
"pair_modify"_pair_modify.html tail option for adding long-range tail
corrections to energy and pressure, since there are no corrections for
a potential that goes to 0.0 at the cutoff.
All of the GROMACS pair styles write their information to "binary
restart files"_restart.html, so pair_style and pair_coeff commands do
not need to be specified in an input script that reads a restart file.
All of the GROMACS pair styles can only be used via the {pair}
keyword of the "run_style respa"_run_style.html command. They do not
support the {inner}, {middle}, {outer} keywords.
:line
[Restrictions:] none
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
:line
:link(Marrink)
[(Marrink)] Marrink, de Vries, Mark, J Phys Chem B, 108, 750-760 (2004).
diff --git a/doc/src/pair_hbond_dreiding.txt b/doc/src/pair_hbond_dreiding.txt
index 9641e294f..d3cf90ec1 100644
--- a/doc/src/pair_hbond_dreiding.txt
+++ b/doc/src/pair_hbond_dreiding.txt
@@ -1,243 +1,243 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style hbond/dreiding/lj command :h3
pair_style hbond/dreiding/lj/omp command :h3
pair_style hbond/dreiding/morse command :h3
pair_style hbond/dreiding/morse/omp command :h3
[Syntax:]
pair_style style N inner_distance_cutoff outer_distance_cutoff angle_cutof :pre
style = {hbond/dreiding/lj} or {hbond/dreiding/morse}
n = cosine angle periodicity
inner_distance_cutoff = global inner cutoff for Donor-Acceptor interactions (distance units)
outer_distance_cutoff = global cutoff for Donor-Acceptor interactions (distance units)
angle_cutoff = global angle cutoff for Acceptor-Hydrogen-Donor
interactions (degrees) :ul
[Examples:]
pair_style hybrid/overlay lj/cut 10.0 hbond/dreiding/lj 4 9.0 11.0 90
pair_coeff 1 2 hbond/dreiding/lj 3 i 9.5 2.75 4 9.0 11.0 90.0 :pre
pair_style hybrid/overlay lj/cut 10.0 hbond/dreiding/morse 2 9.0 11.0 90
pair_coeff 1 2 hbond/dreiding/morse 3 i 3.88 1.7241379 2.9 2 9 11 90 :pre
[Description:]
The {hbond/dreiding} styles compute the Acceptor-Hydrogen-Donor (AHD)
3-body hydrogen bond interaction for the
"DREIDING"_Section_howto.html#howto_4 force field, given by:
:c,image(Eqs/pair_hbond_dreiding.jpg)
where Rin is the inner spline distance cutoff, Rout is the outer
distance cutoff, theta_c is the angle cutoff, and n is the cosine
periodicity.
Here, {r} is the radial distance between the donor (D) and acceptor
(A) atoms and {theta} is the bond angle between the acceptor, the
hydrogen (H) and the donor atoms:
:c,image(Eqs/dreiding_hbond.jpg)
These 3-body interactions can be defined for pairs of acceptor and
donor atoms, based on atom types. For each donor/acceptor atom pair,
the 3rd atom in the interaction is a hydrogen permanently bonded to
the donor atom, e.g. in a bond list read in from a data file via the
"read_data"_read_data.html command. The atom types of possible
hydrogen atoms for each donor/acceptor type pair are specified by the
"pair_coeff"_pair_coeff.html command (see below).
Style {hbond/dreiding/lj} is the original DREIDING potential of
"(Mayo)"_#pair-Mayo. It uses a LJ 12/10 functional for the Donor-Acceptor
interactions. To match the results in the original paper, use n = 4.
Style {hbond/dreiding/morse} is an improved version using a Morse
potential for the Donor-Acceptor interactions. "(Liu)"_#Liu showed
that the Morse form gives improved results for Dendrimer simulations,
when n = 2.
See this "howto section"_Section_howto.html#howto_4 of the manual for
more information on the DREIDING forcefield.
NOTE: Because the Dreiding hydrogen bond potential is only one portion
of an overall force field which typically includes other pairwise
interactions, it is common to use it as a sub-style in a "pair_style
hybrid/overlay"_pair_hybrid.html command, where another pair style
provides the repulsive core interaction between pairs of atoms, e.g. a
1/r^12 Lennard-Jones repulsion.
NOTE: When using the hbond/dreiding pair styles with "pair_style
hybrid/overlay"_pair_hybrid.html, you should explicitly define pair
interactions between the donor atom and acceptor atoms, (as well as
between these atoms and ALL other atoms in your system). Whenever
"pair_style hybrid/overlay"_pair_hybrid.html is used, ordinary mixing
rules are not applied to atoms like the donor and acceptor atoms
because they are typically referenced in multiple pair styles.
Neglecting to do this can cause difficult-to-detect physics problems.
NOTE: In the original Dreiding force field paper 1-4 non-bonded
interactions ARE allowed. If this is desired for your model, use the
special_bonds command (e.g. "special_bonds lj 0.0 0.0 1.0") to turn
these interactions on.
:line
The following coefficients must be defined for pairs of eligible
donor/acceptor types via the "pair_coeff"_pair_coeff.html command as
in the examples above.
NOTE: Unlike other pair styles and their associated
"pair_coeff"_pair_coeff.html commands, you do not need to specify
pair_coeff settings for all possible I,J type pairs. Only I,J type
pairs for atoms which act as joint donors/acceptors need to be
specified; all other type pairs are assumed to be inactive.
NOTE: A "pair_coeff"_pair_coeff.html command can be specified multiple
times for the same donor/acceptor type pair. This enables multiple
hydrogen types to be assigned to the same donor/acceptor type pair.
For other pair_styles, if the pair_coeff command is re-used for the
same I.J type pair, the settings for that type pair are overwritten.
For the hydrogen bond potentials this is not the case; the settings
are cumulative. This means the only way to turn off a previous
setting, is to re-use the pair_style command and start over.
For the {hbond/dreiding/lj} style the list of coefficients is as
follows:
K = hydrogen atom type = 1 to Ntypes
donor flag = {i} or {j}
epsilon (energy units)
sigma (distance units)
n = exponent in formula above
distance cutoff Rin (distance units)
distance cutoff Rout (distance units)
angle cutoff (degrees) :ul
For the {hbond/dreiding/morse} style the list of coefficients is as
follows:
K = hydrogen atom type = 1 to Ntypes
donor flag = {i} or {j}
D0 (energy units)
alpha (1/distance units)
r0 (distance units)
n = exponent in formula above
distance cutoff Rin (distance units)
distance cutoff Rout (distance units)
angle cutoff (degrees) :ul
A single hydrogen atom type K can be specified, or a wild-card
asterisk can be used in place of or in conjunction with the K
arguments to select multiple types as hydrogens. This takes the form
"*" or "*n" or "n*" or "m*n". See the "pair_coeff"_pair_coeff.html
command doc page for details.
If the donor flag is {i}, then the atom of type I in the pair_coeff
command is treated as the donor, and J is the acceptor. If the donor
flag is {j}, then the atom of type J in the pair_coeff command is
treated as the donor and I is the donor. This option is required
because the "pair_coeff"_pair_coeff.html command requires that I <= J.
Epsilon and sigma are settings for the hydrogen bond potential based
on a Lennard-Jones functional form. Note that sigma is defined as the
zero-crossing distance for the potential, not as the energy minimum at
2^(1/6) sigma.
D0 and alpha and r0 are settings for the hydrogen bond potential based
on a Morse functional form.
The last 3 coefficients for both styles are optional. If not
specified, the global n, distance cutoff, and angle cutoff specified
in the pair_style command are used. If you wish to only override the
2nd or 3rd optional parameter, you must also specify the preceding
optional parameters.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
These pair styles do not support mixing. You must explicitly identify
each donor/acceptor type pair.
These styles do not support the "pair_modify"_pair_modify.html shift
option for the energy of the interactions.
The "pair_modify"_pair_modify.html table option is not relevant for
these pair styles.
These pair styles do not support the "pair_modify"_pair_modify.html
tail option for adding long-range tail corrections to energy and
pressure.
These pair styles do not write their information to "binary restart
files"_restart.html, so pair_style and pair_coeff commands need to be
re-specified in an input script that reads a restart file.
These pair styles can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. They do not support the
{inner}, {middle}, {outer} keywords.
These pair styles tally a count of how many hydrogen bonding
interactions they calculate each timestep and the hbond energy. These
quantities can be accessed via the "compute pair"_compute_pair.html
command as a vector of values of length 2.
To print these quantities to the log file (with a descriptive column
heading) the following commands could be included in an input script:
compute hb all pair hbond/dreiding/lj
variable n_hbond equal c_hb\[1\] #number hbonds
variable E_hbond equal c_hb\[2\] #hbond energy
thermo_style custom step temp epair v_E_hbond :pre
:line
[Restrictions:] none
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
:line
:link(pair-Mayo)
[(Mayo)] Mayo, Olfason, Goddard III, J Phys Chem, 94, 8897-8909
(1990).
:link(Liu)
[(Liu)] Liu, Bryantsev, Diallo, Goddard III, J. Am. Chem. Soc 131 (8)
2798 (2009)
diff --git a/doc/src/pair_hybrid.txt b/doc/src/pair_hybrid.txt
index 5166fe1f8..fc1824cf6 100644
--- a/doc/src/pair_hybrid.txt
+++ b/doc/src/pair_hybrid.txt
@@ -1,388 +1,388 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style hybrid command :h3
pair_style hybrid/omp command :h3
pair_style hybrid/overlay command :h3
pair_style hybrid/overlay/omp command :h3
[Syntax:]
pair_style hybrid style1 args style2 args ...
pair_style hybrid/overlay style1 args style2 args ... :pre
style1,style2 = list of one or more pair styles and their arguments :ul
[Examples:]
pair_style hybrid lj/cut/coul/cut 10.0 eam lj/cut 5.0
pair_coeff 1*2 1*2 eam niu3
pair_coeff 3 3 lj/cut/coul/cut 1.0 1.0
pair_coeff 1*2 3 lj/cut 0.5 1.2 :pre
pair_style hybrid/overlay lj/cut 2.5 coul/long 2.0
pair_coeff * * lj/cut 1.0 1.0
pair_coeff * * coul/long :pre
[Description:]
The {hybrid} and {hybrid/overlay} styles enable the use of multiple
pair styles in one simulation. With the {hybrid} style, exactly one
pair style is assigned to each pair of atom types. With the
{hybrid/overlay} style, one or more pair styles can be assigned to
each pair of atom types. The assignment of pair styles to type pairs
is made via the "pair_coeff"_pair_coeff.html command.
Here are two examples of hybrid simulations. The {hybrid} style could
be used for a simulation of a metal droplet on a LJ surface. The
metal atoms interact with each other via an {eam} potential, the
surface atoms interact with each other via a {lj/cut} potential, and
the metal/surface interaction is also computed via a {lj/cut}
potential. The {hybrid/overlay} style could be used as in the 2nd
example above, where multiple potentials are superposed in an additive
fashion to compute the interaction between atoms. In this example,
using {lj/cut} and {coul/long} together gives the same result as if
the {lj/cut/coul/long} potential were used by itself. In this case,
it would be more efficient to use the single combined potential, but
in general any combination of pair potentials can be used together in
to produce an interaction that is not encoded in any single pair_style
file, e.g. adding Coulombic forces between granular particles.
All pair styles that will be used are listed as "sub-styles" following
the {hybrid} or {hybrid/overlay} keyword, in any order. Each
sub-style's name is followed by its usual arguments, as illustrated in
the example above. See the doc pages of individual pair styles for a
listing and explanation of the appropriate arguments.
Note that an individual pair style can be used multiple times as a
sub-style. For efficiency this should only be done if your model
requires it. E.g. if you have different regions of Si and C atoms and
wish to use a Tersoff potential for pure Si for one set of atoms, and
a Tersoff potential for pure C for the other set (presumably with some
3rd potential for Si-C interactions), then the sub-style {tersoff}
could be listed twice. But if you just want to use a Lennard-Jones or
other pairwise potential for several different atom type pairs in your
model, then you should just list the sub-style once and use the
pair_coeff command to assign parameters for the different type pairs.
NOTE: There are two exceptions to this option to list an individual
pair style multiple times. The first is for pair styles implemented
as Fortran libraries: "pair_style meam"_pair_meam.html and "pair_style
reax"_pair_reax.html ("pair_style reax/c"_pair_reaxc.html is OK).
This is because unlike a C++ class, they can not be instantiated
multiple times, due to the manner in which they were coded in Fortran.
The second is for GPU-enabled pair styles in the GPU package. This is
b/c the GPU package also currently assumes that only one instance of a
pair style is being used.
In the pair_coeff commands, the name of a pair style must be added
after the I,J type specification, with the remaining coefficients
being those appropriate to that style. If the pair style is used
multiple times in the pair_style command, then an additional numeric
argument must also be specified which is a number from 1 to M where M
is the number of times the sub-style was listed in the pair style
command. The extra number indicates which instance of the sub-style
these coefficients apply to.
For example, consider a simulation with 3 atom types: types 1 and 2
are Ni atoms, type 3 are LJ atoms with charges. The following
commands would set up a hybrid simulation:
pair_style hybrid eam/alloy lj/cut/coul/cut 10.0 lj/cut 8.0
pair_coeff * * eam/alloy nialhjea Ni Ni NULL
pair_coeff 3 3 lj/cut/coul/cut 1.0 1.0
pair_coeff 1*2 3 lj/cut 0.8 1.3 :pre
As an example of using the same pair style multiple times, consider a
simulation with 2 atom types. Type 1 is Si, type 2 is C. The
following commands would model the Si atoms with Tersoff, the C atoms
with Tersoff, and the cross-interactions with Lennard-Jones:
pair_style hybrid lj/cut 2.5 tersoff tersoff
pair_coeff * * tersoff 1 Si.tersoff Si NULL
pair_coeff * * tersoff 2 C.tersoff NULL C
pair_coeff 1 2 lj/cut 1.0 1.5 :pre
If pair coefficients are specified in the data file read via the
"read_data"_read_data.html command, then the same rule applies.
E.g. "eam/alloy" or "lj/cut" must be added after the atom type, for
each line in the "Pair Coeffs" section, e.g.
Pair Coeffs :pre
1 lj/cut/coul/cut 1.0 1.0
... :pre
Note that the pair_coeff command for some potentials such as
"pair_style eam/alloy"_pair_eam.html includes a mapping specification
of elements to all atom types, which in the hybrid case, can include
atom types not assigned to the {eam/alloy} potential. The NULL
keyword is used by many such potentials (eam/alloy, Tersoff, AIREBO,
etc), to denote an atom type that will be assigned to a different
sub-style.
For the {hybrid} style, each atom type pair I,J is assigned to exactly
one sub-style. Just as with a simulation using a single pair style,
if you specify the same atom type pair in a second pair_coeff command,
the previous assignment will be overwritten.
For the {hybrid/overlay} style, each atom type pair I,J can be
assigned to one or more sub-styles. If you specify the same atom type
pair in a second pair_coeff command with a new sub-style, then the
second sub-style is added to the list of potentials that will be
calculated for two interacting atoms of those types. If you specify
the same atom type pair in a second pair_coeff command with a
sub-style that has already been defined for that pair of atoms, then
the new pair coefficients simply override the previous ones, as in the
normal usage of the pair_coeff command. E.g. these two sets of
commands are the same:
pair_style lj/cut 2.5
pair_coeff * * 1.0 1.0
pair_coeff 2 2 1.5 0.8 :pre
pair_style hybrid/overlay lj/cut 2.5
pair_coeff * * lj/cut 1.0 1.0
pair_coeff 2 2 lj/cut 1.5 0.8 :pre
Coefficients must be defined for each pair of atoms types via the
"pair_coeff"_pair_coeff.html command as described above, or in the
data file or restart files read by the "read_data"_read_data.html or
"read_restart"_read_restart.html commands, or by mixing as described
below.
For both the {hybrid} and {hybrid/overlay} styles, every atom type
pair I,J (where I <= J) must be assigned to at least one sub-style via
the "pair_coeff"_pair_coeff.html command as in the examples above, or
in the data file read by the "read_data"_read_data.html, or by mixing
as described below.
If you want there to be no interactions between a particular pair of
atom types, you have 3 choices. You can assign the type pair to some
sub-style and use the "neigh_modify exclude type"_neigh_modify.html
command. You can assign it to some sub-style and set the coefficients
so that there is effectively no interaction (e.g. epsilon = 0.0 in a
LJ potential). Or, for {hybrid} and {hybrid/overlay} simulations, you
can use this form of the pair_coeff command in your input script:
pair_coeff 2 3 none :pre
or this form in the "Pair Coeffs" section of the data file:
3 none :pre
If an assignment to {none} is made in a simulation with the
{hybrid/overlay} pair style, it wipes out all previous assignments of
that atom type pair to sub-styles.
Note that you may need to use an "atom_style"_atom_style.html hybrid
command in your input script, if atoms in the simulation will need
attributes from several atom styles, due to using multiple pair
potentials.
:line
Different force fields (e.g. CHARMM vs AMBER) may have different rules
for applying weightings that change the strength of pairwise
interactions between pairs of atoms that are also 1-2, 1-3, and 1-4
neighbors in the molecular bond topology, as normally set by the
"special_bonds"_special_bonds.html command. Different weights can be
assigned to different pair hybrid sub-styles via the "pair_modify
special"_pair_modify.html command. This allows multiple force fields
to be used in a model of a hybrid system, however, there is no consistent
approach to determine parameters automatically for the interactions
between the two force fields, this is only recommended when particles
described by the different force fields do not mix.
Here is an example for mixing CHARMM and AMBER: The global {amber}
setting sets the 1-4 interactions to non-zero scaling factors and
then overrides them with 0.0 only for CHARMM:
special_bonds amber
pair_hybrid lj/charmm/coul/long 8.0 10.0 lj/cut/coul/long 10.0
pair_modify pair lj/charmm/coul/long special lj/coul 0.0 0.0 0.0 :pre
The this input achieves the same effect:
special_bonds 0.0 0.0 0.1
pair_hybrid lj/charmm/coul/long 8.0 10.0 lj/cut/coul/long 10.0
pair_modify pair lj/cut/coul/long special lj 0.0 0.0 0.5
pair_modify pair lj/cut/coul/long special coul 0.0 0.0 0.83333333
pair_modify pair lj/charmm/coul/long special lj/coul 0.0 0.0 0.0 :pre
Here is an example for mixing Tersoff with OPLS/AA based on
a data file that defines bonds for all atoms where for the
Tersoff part of the system the force constants for the bonded
interactions have been set to 0. Note the global settings are
effectively {lj/coul 0.0 0.0 0.5} as required for OPLS/AA:
special_bonds lj/coul 1e-20 1e-20 0.5
pair_hybrid tersoff lj/cut/coul/long 12.0
pair_modify pair tersoff special lj/coul 1.0 1.0 1.0 :pre
For use with the various "compute */tally"_compute_tally.html
computes, the "pair_modify compute/tally"_pair_modify.html
command can be used to selectively turn off processing of
the compute tally styles, for example, if those pair styles
(e.g. manybody styles) do not support this feature.
See the "pair_modify"_pair_modify.html doc page for details on
the specific syntax, requirements and restrictions.
:line
The potential energy contribution to the overall system due to an
individual sub-style can be accessed and output via the "compute
pair"_compute_pair.html command.
:line
NOTE: Several of the potentials defined via the pair_style command in
LAMMPS are really many-body potentials, such as Tersoff, AIREBO, MEAM,
ReaxFF, etc. The way to think about using these potentials in a
hybrid setting is as follows.
A subset of atom types is assigned to the many-body potential with a
single "pair_coeff"_pair_coeff.html command, using "* *" to include
all types and the NULL keywords described above to exclude specific
types not assigned to that potential. If types 1,3,4 were assigned in
that way (but not type 2), this means that all many-body interactions
between all atoms of types 1,3,4 will be computed by that potential.
Pair_style hybrid allows interactions between type pairs 2-2, 1-2,
2-3, 2-4 to be specified for computation by other pair styles. You
could even add a second interaction for 1-1 to be computed by another
pair style, assuming pair_style hybrid/overlay is used.
But you should not, as a general rule, attempt to exclude the
many-body interactions for some subset of the type pairs within the
set of 1,3,4 interactions, e.g. exclude 1-1 or 1-3 interactions. That
is not conceptually well-defined for many-body interactions, since the
potential will typically calculate energies and foces for small groups
of atoms, e.g. 3 or 4 atoms, using the neighbor lists of the atoms to
find the additional atoms in the group. It is typically non-physical
to think of excluding an interaction between a particular pair of
atoms when the potential computes 3-body or 4-body interactions.
However, you can still use the pair_coeff none setting or the
"neigh_modify exclude"_neigh_modify.html command to exclude certain
type pairs from the neighbor list that will be passed to a manybody
sub-style. This will alter the calculations made by a many-body
potential, since it builds its list of 3-body, 4-body, etc
interactions from the pair list. You will need to think carefully as
to whether it produces a physically meaningful result for your model.
For example, imagine you have two atom types in your model, type 1 for
atoms in one surface, and type 2 for atoms in the other, and you wish
to use a Tersoff potential to compute interactions within each
surface, but not between surfaces. Then either of these two command
sequences would implement that model:
pair_style hybrid tersoff
pair_coeff * * tersoff SiC.tersoff C C
pair_coeff 1 2 none :pre
pair_style tersoff
pair_coeff * * SiC.tersoff C C
neigh_modify exclude type 1 2 :pre
Either way, only neighbor lists with 1-1 or 2-2 interactions would be
passed to the Tersoff potential, which means it would compute no
3-body interactions containing both type 1 and 2 atoms.
Here is another example, using hybrid/overlay, to use 2 many-body
potentials together, in an overlapping manner. Imagine you have CNT
(C atoms) on a Si surface. You want to use Tersoff for Si/Si and Si/C
interactions, and AIREBO for C/C interactions. Si atoms are type 1; C
atoms are type 2. Something like this will work:
pair_style hybrid/overlay tersoff airebo 3.0
pair_coeff * * tersoff SiC.tersoff.custom Si C
pair_coeff * * airebo CH.airebo NULL C :pre
Note that to prevent the Tersoff potential from computing C/C
interactions, you would need to modify the SiC.tersoff file to turn
off C/C interaction, i.e. by setting the appropriate coefficients to
0.0.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual.
Since the {hybrid} and {hybrid/overlay} styles delegate computation to
the individual sub-styles, the suffix versions of the {hybrid} and
{hybrid/overlay} styles are used to propagate the corresponding suffix
to all sub-styles, if those versions exist. Otherwise the
non-accelerated version will be used.
The individual accelerated sub-styles are part of the GPU,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the
"Making LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
Any pair potential settings made via the
"pair_modify"_pair_modify.html command are passed along to all
sub-styles of the hybrid potential.
For atom type pairs I,J and I != J, if the sub-style assigned to I,I
and J,J is the same, and if the sub-style allows for mixing, then the
coefficients for I,J can be mixed. This means you do not have to
specify a pair_coeff command for I,J since the I,J type pair will be
assigned automatically to the sub-style defined for both I,I and J,J
and its coefficients generated by the mixing rule used by that
sub-style. For the {hybrid/overlay} style, there is an additional
requirement that both the I,I and J,J pairs are assigned to a single
sub-style. See the "pair_modify" command for details of mixing rules.
See the See the doc page for the sub-style to see if allows for
mixing.
The hybrid pair styles supports the "pair_modify"_pair_modify.html
shift, table, and tail options for an I,J pair interaction, if the
associated sub-style supports it.
For the hybrid pair styles, the list of sub-styles and their
respective settings are written to "binary restart
files"_restart.html, so a "pair_style"_pair_style.html command does
not need to specified in an input script that reads a restart file.
However, the coefficient information is not stored in the restart
file. Thus, pair_coeff commands need to be re-specified in the
restart input script.
These pair styles support the use of the {inner}, {middle}, and
{outer} keywords of the "run_style respa"_run_style.html command, if
their sub-styles do.
[Restrictions:]
When using a long-range Coulombic solver (via the
"kspace_style"_kspace_style.html command) with a hybrid pair_style,
one or more sub-styles will be of the "long" variety,
e.g. {lj/cut/coul/long} or {buck/coul/long}. You must insure that the
short-range Coulombic cutoff used by each of these long pair styles is
the same or else LAMMPS will generate an error.
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
diff --git a/doc/src/pair_lj.txt b/doc/src/pair_lj.txt
index 5c8e31ac4..058d54fb5 100644
--- a/doc/src/pair_lj.txt
+++ b/doc/src/pair_lj.txt
@@ -1,320 +1,320 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style lj/cut command :h3
pair_style lj/cut/gpu command :h3
pair_style lj/cut/intel command :h3
pair_style lj/cut/kk command :h3
pair_style lj/cut/opt command :h3
pair_style lj/cut/omp command :h3
pair_style lj/cut/coul/cut command :h3
pair_style lj/cut/coul/cut/gpu command :h3
pair_style lj/cut/coul/cut/omp command :h3
pair_style lj/cut/coul/debye command :h3
pair_style lj/cut/coul/debye/gpu command :h3
pair_style lj/cut/coul/debye/kk command :h3
pair_style lj/cut/coul/debye/omp command :h3
pair_style lj/cut/coul/dsf command :h3
pair_style lj/cut/coul/dsf/gpu command :h3
pair_style lj/cut/coul/dsf/kk command :h3
pair_style lj/cut/coul/dsf/omp command :h3
pair_style lj/cut/coul/long command :h3
pair_style lj/cut/coul/long/cs command :h3
pair_style lj/cut/coul/long/gpu command :h3
pair_style lj/cut/coul/long/intel command :h3
pair_style lj/cut/coul/long/opt command :h3
pair_style lj/cut/coul/long/omp command :h3
pair_style lj/cut/coul/msm command :h3
pair_style lj/cut/coul/msm/gpu command :h3
pair_style lj/cut/coul/msm/omp command :h3
pair_style lj/cut/tip4p/cut command :h3
pair_style lj/cut/tip4p/cut/omp command :h3
pair_style lj/cut/tip4p/long command :h3
pair_style lj/cut/tip4p/long/omp command :h3
pair_style lj/cut/tip4p/long/opt command :h3
[Syntax:]
pair_style style args :pre
style = {lj/cut} or {lj/cut/coul/cut} or {lj/cut/coul/debye} or {lj/cut/coul/dsf} or {lj/cut/coul/long} or {lj/cut/coul/long/cs} or {lj/cut/coul/msm} or {lj/cut/tip4p/long}
args = list of arguments for a particular style :ul
{lj/cut} args = cutoff
cutoff = global cutoff for Lennard Jones interactions (distance units)
{lj/cut/coul/cut} args = cutoff (cutoff2)
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{lj/cut/coul/debye} args = kappa cutoff (cutoff2)
kappa = inverse of the Debye length (inverse distance units)
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{lj/cut/coul/dsf} args = alpha cutoff (cutoff2)
alpha = damping parameter (inverse distance units)
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (distance units)
{lj/cut/coul/long} args = cutoff (cutoff2)
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{lj/cut/coul/msm} args = cutoff (cutoff2)
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{lj/cut/tip4p/cut} args = otype htype btype atype qdist cutoff (cutoff2)
otype,htype = atom types for TIP4P O and H
btype,atype = bond and angle types for TIP4P waters
qdist = distance from O atom to massless charge (distance units)
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{lj/cut/tip4p/long} args = otype htype btype atype qdist cutoff (cutoff2)
otype,htype = atom types for TIP4P O and H
btype,atype = bond and angle types for TIP4P waters
qdist = distance from O atom to massless charge (distance units)
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units) :pre
[Examples:]
pair_style lj/cut 2.5
pair_coeff * * 1 1
pair_coeff 1 1 1 1.1 2.8 :pre
pair_style lj/cut/coul/cut 10.0
pair_style lj/cut/coul/cut 10.0 8.0
pair_coeff * * 100.0 3.0
pair_coeff 1 1 100.0 3.5 9.0
pair_coeff 1 1 100.0 3.5 9.0 9.0 :pre
pair_style lj/cut/coul/debye 1.5 3.0
pair_style lj/cut/coul/debye 1.5 2.5 5.0
pair_coeff * * 1.0 1.0
pair_coeff 1 1 1.0 1.5 2.5
pair_coeff 1 1 1.0 1.5 2.5 5.0 :pre
pair_style lj/cut/coul/dsf 0.05 2.5 10.0
pair_coeff * * 1.0 1.0
pair_coeff 1 1 1.0 1.0 2.5 :pre
pair_style lj/cut/coul/long 10.0
pair_style lj/cut/coul/long/cs 10.0
pair_style lj/cut/coul/long 10.0 8.0
pair_style lj/cut/coul/long/cs 10.0 8.0
pair_coeff * * 100.0 3.0
pair_coeff 1 1 100.0 3.5 9.0 :pre
pair_style lj/cut/coul/msm 10.0
pair_style lj/cut/coul/msm 10.0 8.0
pair_coeff * * 100.0 3.0
pair_coeff 1 1 100.0 3.5 9.0 :pre
pair_style lj/cut/tip4p/cut 1 2 7 8 0.15 12.0
pair_style lj/cut/tip4p/cut 1 2 7 8 0.15 12.0 10.0
pair_coeff * * 100.0 3.0
pair_coeff 1 1 100.0 3.5 9.0 :pre
pair_style lj/cut/tip4p/long 1 2 7 8 0.15 12.0
pair_style lj/cut/tip4p/long 1 2 7 8 0.15 12.0 10.0
pair_coeff * * 100.0 3.0
pair_coeff 1 1 100.0 3.5 9.0 :pre
[Description:]
The {lj/cut} styles compute the standard 12/6 Lennard-Jones potential,
given by
:c,image(Eqs/pair_lj.jpg)
Rc is the cutoff.
Style {lj/cut/coul/cut} adds a Coulombic pairwise interaction given by
:c,image(Eqs/pair_coulomb.jpg)
where C is an energy-conversion constant, Qi and Qj are the charges on
the 2 atoms, and epsilon is the dielectric constant which can be set
by the "dielectric"_dielectric.html command. If one cutoff is
specified in the pair_style command, it is used for both the LJ and
Coulombic terms. If two cutoffs are specified, they are used as
cutoffs for the LJ and Coulombic terms respectively.
Style {lj/cut/coul/debye} adds an additional exp() damping factor
to the Coulombic term, given by
:c,image(Eqs/pair_debye.jpg)
where kappa is the inverse of the Debye length. This potential is
another way to mimic the screening effect of a polar solvent.
Style {lj/cut/coul/dsf} computes the Coulombic term via the damped
shifted force model described in "Fennell"_#Fennell2, given by:
:c,image(Eqs/pair_coul_dsf.jpg)
where {alpha} is the damping parameter and erfc() is the complementary
error-function. This potential is essentially a short-range,
spherically-truncated, charge-neutralized, shifted, pairwise {1/r}
summation. The potential is based on Wolf summation, proposed as an
alternative to Ewald summation for condensed phase systems where
charge screening causes electrostatic interactions to become
effectively short-ranged. In order for the electrostatic sum to be
absolutely convergent, charge neutralization within the cutoff radius
is enforced by shifting the potential through placement of image
charges on the cutoff sphere. Convergence can often be improved by
setting {alpha} to a small non-zero value.
Styles {lj/cut/coul/long} and {lj/cut/coul/msm} compute the same
Coulombic interactions as style {lj/cut/coul/cut} except that an
additional damping factor is applied to the Coulombic term so it can
be used in conjunction with the "kspace_style"_kspace_style.html
command and its {ewald} or {pppm} option. The Coulombic cutoff
specified for this style means that pairwise interactions within this
distance are computed directly; interactions outside that distance are
computed in reciprocal space.
Style {lj/cut/coul/long/cs} is identical to {lj/cut/coul/long} except
that a term is added for the "core/shell
model"_Section_howto.html#howto_25 to allow charges on core and shell
particles to be separated by r = 0.0.
Styles {lj/cut/tip4p/cut} and {lj/cut/tip4p/long} implement the TIP4P
water model of "(Jorgensen)"_#Jorgensen2, which introduces a massless
site located a short distance away from the oxygen atom along the
bisector of the HOH angle. The atomic types of the oxygen and
hydrogen atoms, the bond and angle types for OH and HOH interactions,
and the distance to the massless charge site are specified as
pair_style arguments. Style {lj/cut/tip4p/cut} uses a cutoff for
Coulomb interactions; style {lj/cut/tip4p/long} is for use with a
long-range Coulombic solver (Ewald or PPPM).
NOTE: For each TIP4P water molecule in your system, the atom IDs for
the O and 2 H atoms must be consecutive, with the O atom first. This
is to enable LAMMPS to "find" the 2 H atoms associated with each O
atom. For example, if the atom ID of an O atom in a TIP4P water
molecule is 500, then its 2 H atoms must have IDs 501 and 502.
See the "howto section"_Section_howto.html#howto_8 for more
information on how to use the TIP4P pair styles and lists of
parameters to set. Note that the neighbor list cutoff for Coulomb
interactions is effectively extended by a distance 2*qdist when using
the TIP4P pair style, to account for the offset distance of the
fictitious charges on O atoms in water molecules. Thus it is
typically best in an efficiency sense to use a LJ cutoff >= Coulomb
cutoff + 2*qdist, to shrink the size of the neighbor list. This leads
to slightly larger cost for the long-range calculation, so you can
test the trade-off for your model.
For all of the {lj/cut} pair styles, the following coefficients must
be defined for each pair of atoms types via the
"pair_coeff"_pair_coeff.html command as in the examples above, or in
the data file or restart files read by the "read_data"_read_data.html
or "read_restart"_read_restart.html commands, or by mixing as
described below:
epsilon (energy units)
sigma (distance units)
cutoff1 (distance units)
cutoff2 (distance units) :ul
Note that sigma is defined in the LJ formula as the zero-crossing
distance for the potential, not as the energy minimum at 2^(1/6)
sigma.
The latter 2 coefficients are optional. If not specified, the global
LJ and Coulombic cutoffs specified in the pair_style command are used.
If only one cutoff is specified, it is used as the cutoff for both LJ
and Coulombic interactions for this type pair. If both coefficients
are specified, they are used as the LJ and Coulombic cutoffs for this
type pair. You cannot specify 2 cutoffs for style {lj/cut}, since it
has no Coulombic terms.
For {lj/cut/coul/long} and {lj/cut/coul/msm} and {lj/cut/tip4p/cut}
and {lj/cut/tip4p/long} only the LJ cutoff can be specified since a
Coulombic cutoff cannot be specified for an individual I,J type pair.
All type pairs use the same global Coulombic cutoff specified in the
pair_style command.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance for all of the lj/cut pair styles can be mixed.
The default mix value is {geometric}. See the "pair_modify" command
for details.
All of the {lj/cut} pair styles support the
"pair_modify"_pair_modify.html shift option for the energy of the
Lennard-Jones portion of the pair interaction.
The {lj/cut/coul/long} and {lj/cut/tip4p/long} pair styles support the
"pair_modify"_pair_modify.html table option since they can tabulate
the short-range portion of the long-range Coulombic interaction.
All of the {lj/cut} pair styles support the
"pair_modify"_pair_modify.html tail option for adding a long-range
tail correction to the energy and pressure for the Lennard-Jones
portion of the pair interaction.
All of the {lj/cut} pair styles write their information to "binary
restart files"_restart.html, so pair_style and pair_coeff commands do
not need to be specified in an input script that reads a restart file.
The {lj/cut} and {lj/cut/coul/long} pair styles support the use of the
{inner}, {middle}, and {outer} keywords of the "run_style
respa"_run_style.html command, meaning the pairwise forces can be
partitioned by distance at different levels of the rRESPA hierarchy.
The other styles only support the {pair} keyword of run_style respa.
See the "run_style"_run_style.html command for details.
:line
[Restrictions:]
The {lj/cut/coul/long} and {lj/cut/tip4p/long} styles are part of the
KSPACE package. The {lj/cut/tip4p/cut} style is part of the MOLECULE
package. These styles are only enabled if LAMMPS was built with those
packages. See the "Making LAMMPS"_Section_start.html#start_3 section
for more info. Note that the KSPACE and MOLECULE packages are
installed by default.
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
:line
:link(Jorgensen2)
[(Jorgensen)] Jorgensen, Chandrasekhar, Madura, Impey, Klein, J Chem
Phys, 79, 926 (1983).
:link(Fennell2)
[(Fennell)] C. J. Fennell, J. D. Gezelter, J Chem Phys, 124,
234104 (2006).
diff --git a/doc/src/pair_lj96.txt b/doc/src/pair_lj96.txt
index 6e7c3cbae..83f6ec063 100644
--- a/doc/src/pair_lj96.txt
+++ b/doc/src/pair_lj96.txt
@@ -1,107 +1,107 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style lj96/cut command :h3
pair_style lj96/cut/gpu command :h3
pair_style lj96/cut/omp command :h3
[Syntax:]
pair_style lj96/cut cutoff :pre
cutoff = global cutoff for lj96/cut interactions (distance units) :ul
[Examples:]
pair_style lj96/cut 2.5
pair_coeff * * 1.0 1.0 4.0
pair_coeff 1 1 1.0 1.0 :pre
[Description:]
The {lj96/cut} style compute a 9/6 Lennard-Jones potential, instead
of the standard 12/6 potential, given by
:c,image(Eqs/pair_lj96.jpg)
Rc is the cutoff.
The following coefficients must be defined for each pair of atoms
types via the "pair_coeff"_pair_coeff.html command as in the examples
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands, or by mixing as described below:
epsilon (energy units)
sigma (distance units)
cutoff (distance units) :ul
The last coefficient is optional. If not specified, the global LJ
cutoff specified in the pair_style command is used.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance for all of the lj/cut pair styles can be mixed.
The default mix value is {geometric}. See the "pair_modify" command
for details.
This pair style supports the "pair_modify"_pair_modify.html shift
option for the energy of the pair interaction.
The "pair_modify"_pair_modify.html table option is not relevant
for this pair style.
This pair style supports the "pair_modify"_pair_modify.html tail
option for adding a long-range tail correction to the energy and
pressure of the pair interaction.
This pair style writes its information to "binary restart
files"_restart.html, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.
This pair style supports the use of the {inner}, {middle}, and {outer}
keywords of the "run_style respa"_run_style.html command, meaning the
pairwise forces can be partitioned by distance at different levels of
the rRESPA hierarchy. See the "run_style"_run_style.html command for
details.
:line
[Restrictions:] none
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
diff --git a/doc/src/pair_lj_cubic.txt b/doc/src/pair_lj_cubic.txt
index d33e3ec09..4ca8c3c14 100644
--- a/doc/src/pair_lj_cubic.txt
+++ b/doc/src/pair_lj_cubic.txt
@@ -1,129 +1,129 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style lj/cubic command :h3
pair_style lj/cubic/gpu command :h3
pair_style lj/cubic/omp command :h3
[Syntax:]
pair_style lj/cubic :pre
[Examples:]
pair_style lj/cubic
pair_coeff * * 1.0 0.8908987 :pre
[Description:]
The {lj/cubic} style computes a truncated LJ interaction potential
whose energy and force are continuous everywhere. Inside the
inflection point the interaction is identical to the standard 12/6
"Lennard-Jones"_pair_lj.html potential. The LJ function outside the
inflection point is replaced with a cubic function of distance. The
energy, force, and second derivative are continuous at the inflection
point. The cubic coefficient A3 is chosen so that both energy and
force go to zero at the cutoff distance. Outside the cutoff distance
the energy and force are zero.
:c,image(Eqs/pair_lj_cubic.jpg)
The location of the inflection point rs is defined
by the LJ diameter, rs/sigma = (26/7)^1/6. The cutoff distance
is defined by rc/rs = 67/48 or rc/sigma = 1.737....
The analytic expression for the
the cubic coefficient
A3*rmin^3/epsilon = 27.93... is given in the paper by
Holian and Ravelo "(Holian)"_#Holian.
This potential is commonly used to study the shock mechanics of FCC
solids, as in Ravelo et al. "(Ravelo)"_#Ravelo2.
The following coefficients must be defined for each pair of atom types
via the "pair_coeff"_pair_coeff.html command as in the example above,
or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands, or by mixing as described below:
epsilon (energy units)
sigma (distance units) :ul
Note that sigma is defined in the LJ formula as the zero-crossing
distance for the potential, not as the energy minimum, which is
located at rmin = 2^(1/6)*sigma. In the above example, sigma =
0.8908987, so rmin = 1.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance for all of the lj/cut pair styles can be mixed.
The default mix value is {geometric}. See the "pair_modify" command
for details.
The lj/cubic pair style does not support the
"pair_modify"_pair_modify.html shift option,
since pair interaction is already smoothed to 0.0 at the
cutoff.
The "pair_modify"_pair_modify.html table option is not relevant
for this pair style.
The lj/cubic pair style does not support the
"pair_modify"_pair_modify.html tail option for adding long-range tail
corrections to energy and pressure, since there are no corrections for
a potential that goes to 0.0 at the cutoff.
The lj/cubic pair style writes its information to "binary
restart files"_restart.html, so pair_style and pair_coeff commands do
not need to be specified in an input script that reads a restart file.
The lj/cubic pair style can only be used via the {pair}
keyword of the "run_style respa"_run_style.html command. It does not
support the {inner}, {middle}, {outer} keywords.
:line
[Restrictions:] none
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
:line
:link(Holian)
[(Holian)] Holian and Ravelo, Phys Rev B, 51, 11275 (1995).
:link(Ravelo2)
[(Ravelo)] Ravelo, Holian, Germann and Lomdahl, Phys Rev B, 70, 014103 (2004).
diff --git a/doc/src/pair_lj_expand.txt b/doc/src/pair_lj_expand.txt
index c5f0c88a7..e0838426f 100644
--- a/doc/src/pair_lj_expand.txt
+++ b/doc/src/pair_lj_expand.txt
@@ -1,111 +1,111 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style lj/expand command :h3
pair_style lj/expand/gpu command :h3
pair_style lj/expand/omp command :h3
[Syntax:]
pair_style lj/expand cutoff :pre
cutoff = global cutoff for lj/expand interactions (distance units) :ul
[Examples:]
pair_style lj/expand 2.5
pair_coeff * * 1.0 1.0 0.5
pair_coeff 1 1 1.0 1.0 -0.2 2.0 :pre
[Description:]
Style {lj/expand} computes a LJ interaction with a distance shifted by
delta which can be useful when particles are of different sizes, since
it is different that using different sigma values in a standard LJ
formula:
:c,image(Eqs/pair_lj_expand.jpg)
Rc is the cutoff which does not include the delta distance. I.e. the
actual force cutoff is the sum of cutoff + delta.
The following coefficients must be defined for each pair of atoms
types via the "pair_coeff"_pair_coeff.html command as in the examples
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands, or by mixing as described below:
epsilon (energy units)
sigma (distance units)
delta (distance units)
cutoff (distance units) :ul
The delta values can be positive or negative. The last coefficient is
optional. If not specified, the global LJ cutoff is used.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, the epsilon, sigma, and shift
coefficients and cutoff distance for this pair style can be mixed.
Shift is always mixed via an {arithmetic} rule. The other
coefficients are mixed according to the pair_modify mix value. The
default mix value is {geometric}. See the "pair_modify" command for
details.
This pair style supports the "pair_modify"_pair_modify.html shift
option for the energy of the pair interaction.
The "pair_modify"_pair_modify.html table option is not relevant
for this pair style.
This pair style supports the "pair_modify"_pair_modify.html tail
option for adding a long-range tail correction to the energy and
pressure of the pair interaction.
This pair style writes its information to "binary restart
files"_restart.html, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.
This pair style can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. It does not support the
{inner}, {middle}, {outer} keywords.
:line
[Restrictions:] none
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
diff --git a/doc/src/pair_lj_long.txt b/doc/src/pair_lj_long.txt
index da9f37b9c..6be4562d1 100644
--- a/doc/src/pair_lj_long.txt
+++ b/doc/src/pair_lj_long.txt
@@ -1,230 +1,230 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style lj/long/coul/long command :h3
pair_style lj/long/coul/long/intel command :h3
pair_style lj/long/coul/long/omp command :h3
pair_style lj/long/coul/long/opt command :h3
pair_style lj/long/tip4p/long command :h3
[Syntax:]
pair_style style args :pre
style = {lj/long/coul/long} or {lj/long/tip4p/long}
args = list of arguments for a particular style :ul
{lj/long/coul/long} args = flag_lj flag_coul cutoff (cutoff2)
flag_lj = {long} or {cut} or {off}
{long} = use Kspace long-range summation for dispersion 1/r^6 term
{cut} = use a cutoff on dispersion 1/r^6 term
{off} = omit disperion 1/r^6 term entirely
flag_coul = {long} or {off}
{long} = use Kspace long-range summation for Coulombic 1/r term
{off} = omit Coulombic term
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{lj/long/tip4p/long} args = flag_lj flag_coul otype htype btype atype qdist cutoff (cutoff2)
flag_lj = {long} or {cut}
{long} = use Kspace long-range summation for dispersion 1/r^6 term
{cut} = use a cutoff
flag_coul = {long} or {off}
{long} = use Kspace long-range summation for Coulombic 1/r term
{off} = omit Coulombic term
otype,htype = atom types for TIP4P O and H
btype,atype = bond and angle types for TIP4P waters
qdist = distance from O atom to massless charge (distance units)
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units) :pre
[Examples:]
pair_style lj/long/coul/long cut off 2.5
pair_style lj/long/coul/long cut long 2.5 4.0
pair_style lj/long/coul/long long long 2.5 4.0
pair_coeff * * 1 1
pair_coeff 1 1 1 3 4 :pre
pair_style lj/long/tip4p/long long long 1 2 7 8 0.15 12.0
pair_style lj/long/tip4p/long long long 1 2 7 8 0.15 12.0 10.0
pair_coeff * * 100.0 3.0
pair_coeff 1 1 100.0 3.5 9.0 :pre
[Description:]
Style {lj/long/coul/long} computes the standard 12/6 Lennard-Jones and
Coulombic potentials, given by
:c,image(Eqs/pair_lj.jpg)
:c,image(Eqs/pair_coulomb.jpg)
where C is an energy-conversion constant, Qi and Qj are the charges on
the 2 atoms, epsilon is the dielectric constant which can be set by
the "dielectric"_dielectric.html command, and Rc is the cutoff. If
one cutoff is specified in the pair_style command, it is used for both
the LJ and Coulombic terms. If two cutoffs are specified, they are
used as cutoffs for the LJ and Coulombic terms respectively.
The purpose of this pair style is to capture long-range interactions
resulting from both attractive 1/r^6 Lennard-Jones and Coulombic 1/r
interactions. This is done by use of the {flag_lj} and {flag_coul}
settings. The "In 't Veld"_#Veld2 paper has more details on when it is
appropriate to include long-range 1/r^6 interactions, using this
potential.
Style {lj/long/tip4p/long} implements the TIP4P water model of
"(Jorgensen)"_#Jorgensen4, which introduces a massless site located a
short distance away from the oxygen atom along the bisector of the HOH
angle. The atomic types of the oxygen and hydrogen atoms, the bond
and angle types for OH and HOH interactions, and the distance to the
massless charge site are specified as pair_style arguments.
NOTE: For each TIP4P water molecule in your system, the atom IDs for
the O and 2 H atoms must be consecutive, with the O atom first. This
is to enable LAMMPS to "find" the 2 H atoms associated with each O
atom. For example, if the atom ID of an O atom in a TIP4P water
molecule is 500, then its 2 H atoms must have IDs 501 and 502.
See the "howto section"_Section_howto.html#howto_8 for more
information on how to use the TIP4P pair style. Note that the
neighbor list cutoff for Coulomb interactions is effectively extended
by a distance 2*qdist when using the TIP4P pair style, to account for
the offset distance of the fictitious charges on O atoms in water
molecules. Thus it is typically best in an efficiency sense to use a
LJ cutoff >= Coulomb cutoff + 2*qdist, to shrink the size of the
neighbor list. This leads to slightly larger cost for the long-range
calculation, so you can test the trade-off for your model.
If {flag_lj} is set to {long}, no cutoff is used on the LJ 1/r^6
dispersion term. The long-range portion can be calculated by using
the "kspace_style ewald/disp or pppm/disp"_kspace_style.html commands.
The specified LJ cutoff then determines which portion of the LJ
interactions are computed directly by the pair potential versus which
part is computed in reciprocal space via the Kspace style. If
{flag_lj} is set to {cut}, the LJ interactions are simply cutoff, as
with "pair_style lj/cut"_pair_lj.html.
If {flag_coul} is set to {long}, no cutoff is used on the Coulombic
interactions. The long-range portion can calculated by using any of
several "kspace_style"_kspace_style.html command options such as
{pppm} or {ewald}. Note that if {flag_lj} is also set to long, then
the {ewald/disp} or {pppm/disp} Kspace style needs to be used to
perform the long-range calculations for both the LJ and Coulombic
interactions. If {flag_coul} is set to {off}, Coulombic interactions
are not computed.
The following coefficients must be defined for each pair of atoms
types via the "pair_coeff"_pair_coeff.html command as in the examples
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands, or by mixing as described below:
epsilon (energy units)
sigma (distance units)
cutoff1 (distance units)
cutoff2 (distance units) :ul
Note that sigma is defined in the LJ formula as the zero-crossing
distance for the potential, not as the energy minimum at 2^(1/6)
sigma.
The latter 2 coefficients are optional. If not specified, the global
LJ and Coulombic cutoffs specified in the pair_style command are used.
If only one cutoff is specified, it is used as the cutoff for both LJ
and Coulombic interactions for this type pair. If both coefficients
are specified, they are used as the LJ and Coulombic cutoffs for this
type pair.
Note that if you are using {flag_lj} set to {long}, you
cannot specify a LJ cutoff for an atom type pair, since only one
global LJ cutoff is allowed. Similarly, if you are using {flag_coul}
set to {long}, you cannot specify a Coulombic cutoff for an atom type
pair, since only one global Coulombic cutoff is allowed.
For {lj/long/tip4p/long} only the LJ cutoff can be specified
since a Coulombic cutoff cannot be specified for an individual I,J
type pair. All type pairs use the same global Coulombic cutoff
specified in the pair_style command.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance for all of the lj/long pair styles can be mixed.
The default mix value is {geometric}. See the "pair_modify" command
for details.
These pair styles support the "pair_modify"_pair_modify.html shift
option for the energy of the Lennard-Jones portion of the pair
interaction, assuming {flag_lj} is {cut}.
These pair styles support the "pair_modify"_pair_modify.html table and
table/disp options since they can tabulate the short-range portion of
the long-range Coulombic and dispersion interactions.
Thes pair styles do not support the "pair_modify"_pair_modify.html
tail option for adding a long-range tail correction to the
Lennard-Jones portion of the energy and pressure.
These pair styles write their information to "binary restart
files"_restart.html, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.
The pair lj/long/coul/long styles support the use of the {inner},
{middle}, and {outer} keywords of the "run_style respa"_run_style.html
command, meaning the pairwise forces can be partitioned by distance at
different levels of the rRESPA hierarchy. See the
"run_style"_run_style.html command for details.
:line
[Restrictions:]
These styles are part of the KSPACE package. They are only enabled if
LAMMPS was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info. Note that
the KSPACE package is installed by default.
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
:line
:link(Veld2)
[(In 't Veld)] In 't Veld, Ismail, Grest, J Chem Phys (accepted) (2007).
:link(Jorgensen4)
[(Jorgensen)] Jorgensen, Chandrasekhar, Madura, Impey, Klein, J Chem
Phys, 79, 926 (1983).
diff --git a/doc/src/pair_lj_smooth.txt b/doc/src/pair_lj_smooth.txt
index 133773abd..b1678cad5 100644
--- a/doc/src/pair_lj_smooth.txt
+++ b/doc/src/pair_lj_smooth.txt
@@ -1,122 +1,122 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style lj/smooth command :h3
pair_style lj/smooth/omp command :h3
[Syntax:]
pair_style lj/smooth Rin Rc :pre
Rin = inner cutoff beyond which force smoothing will be applied (distance units)
Rc = outer cutoff for lj/smooth interactions (distance units) :ul
[Examples:]
pair_style lj/smooth 8.0 10.0
pair_coeff * * 10.0 1.5
pair_coeff 1 1 20.0 1.3 7.0 9.0 :pre
[Description:]
Style {lj/smooth} computes a LJ interaction with a force smoothing
applied between the inner and outer cutoff.
:c,image(Eqs/pair_lj_smooth.jpg)
The polynomial coefficients C1, C2, C3, C4 are computed by LAMMPS to
cause the force to vary smoothly from the inner cutoff Rin to the
outer cutoff Rc.
At the inner cutoff the force and its 1st derivative
will match the unsmoothed LJ formula. At the outer cutoff the force
and its 1st derivative will be 0.0. The inner cutoff cannot be 0.0.
NOTE: this force smoothing causes the energy to be discontinuous both
in its values and 1st derivative. This can lead to poor energy
conservation and may require the use of a thermostat. Plot the energy
and force resulting from this formula via the
"pair_write"_pair_write.html command to see the effect.
The following coefficients must be defined for each pair of atoms
types via the "pair_coeff"_pair_coeff.html command as in the examples
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands, or by mixing as described below:
epsilon (energy units)
sigma (distance units)
inner (distance units)
outer (distance units) :ul
The last 2 coefficients are optional inner and outer cutoffs. If not
specified, the global values for Rin and Rc are used.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, the epsilon, sigma, Rin
coefficients and the cutoff distance for this pair style can be mixed.
Rin is a cutoff value and is mixed like the cutoff. The other
coefficients are mixed according to the pair_modify mix option. The
default mix value is {geometric}. See the "pair_modify" command for
details.
This pair style supports the "pair_modify"_pair_modify.html shift
option for the energy of the pair interaction.
The "pair_modify"_pair_modify.html table option is not relevant
for this pair style.
This pair style does not support the "pair_modify"_pair_modify.html
tail option for adding long-range tail corrections to energy and
pressure, since the energy of the pair interaction is smoothed to 0.0
at the cutoff.
This pair style writes its information to "binary restart
files"_restart.html, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.
This pair style can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. It does not support the
{inner}, {middle}, {outer} keywords.
:line
[Restrictions:] none
[Related commands:]
"pair_coeff"_pair_coeff.html, "pair
lj/smooth/linear"_pair_lj_smooth_linear.html
[Default:] none
diff --git a/doc/src/pair_lj_smooth_linear.txt b/doc/src/pair_lj_smooth_linear.txt
index a48c441f5..5f7c226ce 100644
--- a/doc/src/pair_lj_smooth_linear.txt
+++ b/doc/src/pair_lj_smooth_linear.txt
@@ -1,111 +1,111 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style lj/smooth/linear command :h3
pair_style lj/smooth/linear/omp command :h3
[Syntax:]
pair_style lj/smooth/linear cutoff :pre
cutoff = global cutoff for Lennard-Jones interactions (distance units) :ul
[Examples:]
pair_style lj/smooth/linear 2.5
pair_coeff * * 1.0 1.0
pair_coeff 1 1 0.3 3.0 9.0 :pre
[Description:]
Style {lj/smooth/linear} computes a truncated and force-shifted LJ
interaction (aka Shifted Force Lennard-Jones) that combines the
standard 12/6 Lennard-Jones function and subtracts a linear term based
on the cutoff distance, so that both, the potential and the force, go
continuously to zero at the cutoff Rc "(Toxvaerd)"_#Toxvaerd:
:c,image(Eqs/pair_lj_smooth_linear.jpg)
The following coefficients must be defined for each pair of atoms
types via the "pair_coeff"_pair_coeff.html command as in the examples
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands, or by mixing as described below:
epsilon (energy units)
sigma (distance units)
cutoff (distance units) :ul
The last coefficient is optional. If not specified, the global
LJ cutoff specified in the pair_style command is used.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance can be mixed. The default mix value is geometric.
See the "pair_modify" command for details.
This pair style does not support the "pair_modify"_pair_modify.html
shift option for the energy of the pair interaction, since it goes
to 0.0 at the cutoff by construction.
The "pair_modify"_pair_modify.html table option is not relevant
for this pair style.
This pair style does not support the "pair_modify"_pair_modify.html
tail option for adding long-range tail corrections to energy and
pressure, since the energy of the pair interaction is smoothed to 0.0
at the cutoff.
This pair style writes its information to "binary restart
files"_restart.html, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.
This pair style can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. It does not support the
{inner}, {middle}, {outer} keywords.
:line
[Restrictions:] none
[Related commands:]
"pair_coeff"_pair_coeff.html, "pair lj/smooth"_pair_lj_smooth.html
[Default:] none
:line
:link(Toxvaerd)
[(Toxvaerd)] Toxvaerd, Dyre, J Chem Phys, 134, 081102 (2011).
diff --git a/doc/src/pair_lj_soft.txt b/doc/src/pair_lj_soft.txt
index e372092cf..2ef133da5 100644
--- a/doc/src/pair_lj_soft.txt
+++ b/doc/src/pair_lj_soft.txt
@@ -1,278 +1,278 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style lj/cut/soft command :h3
pair_style lj/cut/soft/omp command :h3
pair_style lj/cut/coul/cut/soft command :h3
pair_style lj/cut/coul/cut/soft/omp command :h3
pair_style lj/cut/coul/long/soft command :h3
pair_style lj/cut/coul/long/soft/omp command :h3
pair_style lj/cut/tip4p/long/soft command :h3
pair_style lj/cut/tip4p/long/soft/omp command :h3
pair_style lj/charmm/coul/long/soft command :h3
pair_style lj/charmm/coul/long/soft/omp command :h3
pair_style coul/cut/soft command :h3
pair_style coul/cut/soft/omp command :h3
pair_style coul/long/soft command :h3
pair_style coul/long/soft/omp command :h3
pair_style tip4p/long/soft command :h3
pair_style tip4p/long/soft/omp command :h3
[Syntax:]
pair_style style args :pre
style = {lj/cut/soft} or {lj/cut/coul/cut/soft} or {lj/cut/coul/long/soft} or {lj/cut/tip4p/long/soft} or {lj/charmm/coul/long/soft} or {coul/cut/soft} or {coul/long/soft} or {tip4p/long/soft}
args = list of arguments for a particular style :ul
{lj/cut/soft} args = n alpha_lj cutoff
n, alpha_LJ = parameters of soft-core potential
cutoff = global cutoff for Lennard-Jones interactions (distance units)
{lj/cut/coul/cut/soft} args = n alpha_LJ alpha_C cutoff (cutoff2)
n, alpha_LJ, alpha_C = parameters of soft-core potential
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{lj/cut/coul/long/soft} args = n alpha_LJ alpha_C cutoff
n, alpha_LJ, alpha_C = parameters of the soft-core potential
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{lj/cut/tip4p/long/soft} args = otype htype btype atype qdist n alpha_LJ alpha_C cutoff (cutoff2)
otype,htype = atom types for TIP4P O and H
btype,atype = bond and angle types for TIP4P waters
qdist = distance from O atom to massless charge (distance units)
n, alpha_LJ, alpha_C = parameters of the soft-core potential
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{lj/charmm/coul/long/soft} args = n alpha_LJ alpha_C inner outer (cutoff)
n, alpha_LJ, alpha_C = parameters of the soft-core potential
inner, outer = global switching cutoffs for LJ (and Coulombic if only 5 args)
cutoff = global cutoff for Coulombic (optional, outer is Coulombic cutoff if only 5 args)
{coul/cut/soft} args = n alpha_C cutoff
n, alpha_C = parameters of the soft-core potential
cutoff = global cutoff for Coulomb interactions (distance units)
{coul/long/soft} args = n alpha_C cutoff
n, alpha_C = parameters of the soft-core potential
cutoff = global cutoff for Coulomb interactions (distance units)
{tip4p/long/soft} args = otype htype btype atype qdist n alpha_C cutoff
otype,htype = atom types for TIP4P O and H
btype,atype = bond and angle types for TIP4P waters
qdist = distance from O atom to massless charge (distance units)
n, alpha_C = parameters of the soft-core potential
cutoff = global cutoff for Coulomb interactions (distance units)
:pre
[Examples:]
pair_style lj/cut/soft 2.0 0.5 9.5
pair_coeff * * 0.28 3.1 1.0
pair_coeff 1 1 0.28 3.1 1.0 9.5 :pre
pair_style lj/cut/coul/cut/soft 2.0 0.5 10.0 9.5
pair_style lj/cut/coul/cut/soft 2.0 0.5 10.0 9.5 9.5
pair_coeff * * 0.28 3.1 1.0
pair_coeff 1 1 0.28 3.1 0.5 10.0
pair_coeff 1 1 0.28 3.1 0.5 10.0 9.5 :pre
pair_style lj/cut/coul/long/soft 2.0 0.5 10.0 9.5
pair_style lj/cut/coul/long/soft 2.0 0.5 10.0 9.5 9.5
pair_coeff * * 0.28 3.1 1.0
pair_coeff 1 1 0.28 3.1 0.0 10.0
pair_coeff 1 1 0.28 3.1 0.0 10.0 9.5 :pre
pair_style lj/cut/tip4p/long/soft 1 2 7 8 0.15 2.0 0.5 10.0 9.8
pair_style lj/cut/tip4p/long/soft 1 2 7 8 0.15 2.0 0.5 10.0 9.8 9.5
pair_coeff * * 0.155 3.1536 1.0
pair_coeff 1 1 0.155 3.1536 1.0 9.5 :pre
pair_style lj/charmm/coul/long 2.0 0.5 10.0 8.0 10.0
pair_style lj/charmm/coul/long 2.0 0.5 10.0 8.0 10.0 9.0
pair_coeff * * 0.28 3.1 1.0
pair_coeff 1 1 0.28 3.1 1.0 0.14 3.1 :pre
pair_style coul/long/soft 1.0 10.0 9.5
pair_coeff * * 1.0
pair_coeff 1 1 1.0 9.5 :pre
pair_style tip4p/long/soft 1 2 7 8 0.15 2.0 0.5 10.0 9.8
pair_coeff * * 1.0
pair_coeff 1 1 1.0 9.5 :pre
[Description:]
The {lj/cut/soft} style and substyles compute the 12/6 Lennard-Jones
and Coulomb potential modified by a soft core, in order to avoid
singularities during free energy calculations when sites are created
or annihilated "(Beutler)"_#Beutler,
:c,image(Eqs/pair_lj_soft.jpg)
Coulomb interactions are also damped with a soft core at short
distance,
:c,image(Eqs/pair_coul_soft.jpg)
In the Coulomb part C is an energy-conversion constant, q_i and q_j
are the charges on the 2 atoms, and epsilon is the dielectric constant
which can be set by the "dielectric"_dielectric.html command.
The coefficient lambda is an activation parameter. When lambda = 1 the
pair potential is identical to a Lennard-Jones term or a Coulomb term
or a combination of both. When lambda = 0 the interactions are
deactivated. The transition between these two extrema is smoothed by a
soft repulsive core in order to avoid singularities in potential
energy and forces when sites are created or annihilated and can overlap
"(Beutler)"_#Beutler.
The parameters n, alpha_LJ and alpha_C are set in the
"pair_style"_pair_style.html command, before the cutoffs. Usual
choices for the exponent are n = 2 or n = 1. For the remaining
coefficients alpha_LJ = 0.5 and alpha_C = 10 Angstrom^2 are
appropriate choices. Plots of the LJ and Coulomb terms are shown
below, for lambda ranging from 1 to 0 every 0.1.
:image(JPG/lj_soft.jpg),image(JPG/coul_soft.jpg)
:c
For the {lj/cut/coul/cut/soft} or {lj/cut/coul/long/soft} pair styles,
the following coefficients must be defined for each pair of atoms
types via the "pair_coeff"_pair_coeff.html command as in the examples
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands, or by mixing as described below:
epsilon (energy units)
sigma (distance units)
lambda (activation parameter between 0 and 1)
cutoff1 (distance units)
cutoff2 (distance units) :ul
The latter two coefficients are optional. If not specified, the global
LJ and Coulombic cutoffs specified in the pair_style command are used.
If only one cutoff is specified, it is used as the cutoff for both LJ
and Coulombic interactions for this type pair. If both coefficients
are specified, they are used as the LJ and Coulombic cutoffs for this
type pair. You cannot specify 2 cutoffs for style {lj/cut/soft},
since it has no Coulombic terms. For the {coul/cut/soft} and
{coul/long/soft} only lambda and the optional cutoff2 are to be
specified.
Style {lj/cut/tip4p/long/soft} implements a soft-core version of the
TIP4P water model. The usage of this pair style is documented in the
"pair_lj"_pair_lj.html styles. The soft-core version introduces the
lambda parameter to the list of arguments, after epsilon and sigma in
the "pair_coeff"_pair_coeff.html command. The parameters n, alpha_LJ
and alpha_C are set in the "pair_style"_pair_style.html command,
before the cutoffs.
Style {lj/charmm/coul/long/soft} implements a soft-core version of the
CHARMM version of LJ interactions with an additional switching
function S(r) that ramps the energy and force smoothly to zero between
an inner and outer cutoff. The usage of this pair style is documented
in the "pair_charmm"_pair_charmm.html styles. The soft-core version
introduces the lambda parameter to the list of arguments, after
epsilon and sigma in the "pair_coeff"_pair_coeff.html command (and
before the optional eps14 and sigma14). The parameters n,
alpha_LJ and alpha_C are set in the "pair_style"_pair_style.html
command, before the cutoffs.
The {coul/cut/soft}, {coul/long/soft} and {tip4p/long/soft} substyles
are designed to be combined with other pair potentials via the
"pair_style hybrid/overlay"_pair_hybrid.html command. This is because
they have no repulsive core. Hence, if used by themselves, there will
be no repulsion to keep two oppositely charged particles from
overlapping each other. In this case, if lambda = 1, a singularity may
occur. These substyles are suitable to represent charges embedded in
the Lennard-Jones radius of another site (for example hydrogen atoms
in several water models).
NOTES: When using the core-softed Coulomb potentials with long-range
solvers ({coul/long/soft}, {lj/cut/coul/long/soft}, etc.) in a free
energy calculation in which sites holding electrostatic charges are
being created or annihilated (using "fix adapt/fep"_fix_adapt_fep.html
and "compute fep"_compute_fep.html) it is important to adapt both the
lambda activation parameter (from 0 to 1, or the reverse) and the
value of the charge (from 0 to its final value, or the reverse). This
ensures that long-range electrostatic terms (kspace) are correct. It
is not necessary to use core-softed Coulomb potentials if the van der
Waals site is present during the free-energy route, thus avoiding
overlap of the charges. Examples are provided in the LAMMPS source
directory tree, under examples/USER/fep.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, tail correction, restart info]:
For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance for this pair style can be mixed.
The default mix value is {geometric}. See the "pair_modify" command
for details.
These pair styles support the "pair_modify"_pair_modify.html shift
option for the energy of the Lennard-Jones portion of the pair
interaction.
These pair styles support the "pair_modify"_pair_modify.html tail
option for adding a long-range tail correction to the energy and
pressure for the Lennard-Jones portion of the pair interaction.
These pair styles write information to "binary restart
files"_restart.html, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.
:line
[Restrictions:]
To avoid division by zero do not set sigma = 0; use the lambda
parameter instead to activate/deactivate interactions, or use
epsilon = 0 and sigma = 1. Alternatively, when sites do not
interact though the Lennard-Jones term the {coul/long/soft} or
similar substyle can be used via the
"pair_style hybrid/overlay"_pair_hybrid.html command.
:line
All of the plain {soft} pair styles are part of the USER-FEP package.
The {long} styles also requires the KSPACE package to be installed.
They are only enabled if LAMMPS was built with those packages. See
the "Making LAMMPS"_Section_start.html#start_3 section for more info.
[Related commands:]
"pair_coeff"_pair_coeff.html, "fix adapt"_fix_adapt.html,
"fix adapt/fep"_fix_adapt_fep.html, "compute fep"_compute_fep.html
[Default:] none
:line
:link(Beutler)
[(Beutler)] Beutler, Mark, van Schaik, Gerber, van Gunsteren, Chem
Phys Lett, 222, 529 (1994).
diff --git a/doc/src/pair_lubricate.txt b/doc/src/pair_lubricate.txt
index 501a04380..b39c7545c 100644
--- a/doc/src/pair_lubricate.txt
+++ b/doc/src/pair_lubricate.txt
@@ -1,228 +1,228 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style lubricate command :h3
pair_style lubricate/omp command :h3
pair_style lubricate/poly command :h3
pair_style lubricate/poly/omp command :h3
[Syntax:]
pair_style style mu flaglog flagfld cutinner cutoff flagHI flagVF :pre
style = {lubricate} or {lubricate/poly}
mu = dynamic viscosity (dynamic viscosity units)
flaglog = 0/1 to exclude/include log terms in the lubrication approximation
flagfld = 0/1 to exclude/include Fast Lubrication Dynamics (FLD) effects
cutinner = inner cutoff distance (distance units)
cutoff = outer cutoff for interactions (distance units)
flagHI (optional) = 0/1 to exclude/include 1/r hydrodynamic interactions
flagVF (optional) = 0/1 to exclude/include volume fraction corrections in the long-range isotropic terms :ul
[Examples:] (all assume radius = 1)
pair_style lubricate 1.5 1 1 2.01 2.5
pair_coeff 1 1 2.05 2.8
pair_coeff * * :pre
pair_style lubricate 1.5 1 1 2.01 2.5
pair_coeff * *
variable mu equal ramp(1,2)
fix 1 all adapt 1 pair lubricate mu * * v_mu :pre
[Description:]
Styles {lubricate} and {lubricate/poly} compute hydrodynamic
interactions between mono-disperse finite-size spherical particles in
a pairwise fashion. The interactions have 2 components. The first is
Ball-Melrose lubrication terms via the formulas in "(Ball and
Melrose)"_#Ball1
:c,image(Eqs/pair_lubricate.jpg)
which represents the dissipation W between two nearby particles due to
their relative velocities in the presence of a background solvent with
viscosity {mu}. Note that this is dynamic viscosity which has units of
mass/distance/time, not kinematic viscosity.
The Asq (squeeze) term is the strongest and is included if {flagHI} is
set to 1 (default). It scales as 1/gap where gap is the separation
between the surfaces of the 2 particles. The Ash (shear) and Apu
(pump) terms are only included if {flaglog} is set to 1. They are the
next strongest interactions, and the only other singular interaction,
and scale as log(gap). Note that {flaglog} = 1 and {flagHI} = 0 is
invalid, and will result in a warning message, after which {flagHI} will
be set to 1. The Atw (twist) term is currently not included. It is
typically a very small contribution to the lubrication forces.
The {flagHI} and {flagVF} settings are optional. Neither should be
used, or both must be defined.
{Cutinner} sets the minimum center-to-center separation that will be
used in calculations irrespective of the actual separation. {Cutoff}
is the maximum center-to-center separation at which an interaction is
computed. Using a {cutoff} less than 3 radii is recommended if
{flaglog} is set to 1.
The other component is due to the Fast Lubrication Dynamics (FLD)
approximation, described in "(Kumar)"_#Kumar1, which can be
represented by the following equation
:c,image(Eqs/fld.jpg)
where U represents the velocities and angular velocities of the
particles, U^{infty} represents the velocity and the angular velocity
of the undisturbed fluid, and E^{infty} represents the rate of strain
tensor of the undisturbed fluid with viscosity {mu}. Again, note that
this is dynamic viscosity which has units of mass/distance/time, not
kinematic viscosity. Volume fraction corrections to R_FU are included
as long as {flagVF} is set to 1 (default).
NOTE: When using the FLD terms, these pair styles are designed to be
used with explicit time integration and a correspondingly small
timestep. Thus either "fix nve/sphere"_fix_nve_sphere.html or "fix
nve/asphere"_fix_nve_asphere.html should be used for time integration.
To perform implicit FLD, see the "pair_style
lubricateU"_pair_lubricateU.html command.
Style {lubricate} requires monodisperse spherical particles; style
{lubricate/poly} allows for polydisperse spherical particles.
The viscosity {mu} can be varied in a time-dependent manner over the
course of a simulation, in which case in which case the pair_style
setting for {mu} will be overridden. See the "fix adapt"_fix_adapt.html
command for details.
If the suspension is sheared via the "fix deform"_fix_deform.html
command then the pair style uses the shear rate to adjust the
hydrodynamic interactions accordingly. Volume changes due to fix
deform are accounted for when computing the volume fraction
corrections to R_FU.
When computing the volume fraction corrections to R_FU, the presence
of walls (whether moving or stationary) will affect the volume
fraction available to colloidal particles. This is currently accounted
for with the following types of walls: "wall/lj93"_fix_wall.html,
"wall/lj126"_fix_wall.html, "wall/colloid"_fix_wall.html, and
"wall/harmonic"_fix_wall.html. For these wall styles, the correct
volume fraction will be used when walls do not coincide with the box
boundary, as well as when walls move and thereby cause a change in the
volume fraction. Other wall styles will still work, but they will
result in the volume fraction being computed based on the box
boundaries.
Since lubrication forces are dissipative, it is usually desirable to
thermostat the system at a constant temperature. If Brownian motion
(at a constant temperature) is desired, it can be set using the
"pair_style brownian"_pair_brownian.html command. These pair styles
and the brownian style should use consistent parameters for {mu},
{flaglog}, {flagfld}, {cutinner}, {cutoff}, {flagHI} and {flagVF}.
:line
The following coefficients must be defined for each pair of atoms
types via the "pair_coeff"_pair_coeff.html command as in the examples
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands, or by mixing as described below:
cutinner (distance units)
cutoff (distance units) :ul
The two coefficients are optional. If neither is specified, the two
cutoffs specified in the pair_style command are used. Otherwise both
must be specified.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "this section"_Section_accelerate.html of
the manual. The accelerated styles take the same arguments and should
produce the same results, except for round-off and precision issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "this section"_Section_accelerate.html of the manual for more
instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, the two cutoff distances for this
pair style can be mixed. The default mix value is {geometric}. See
the "pair_modify" command for details.
This pair style does not support the "pair_modify"_pair_modify.html
shift option for the energy of the pair interaction.
The "pair_modify"_pair_modify.html table option is not relevant
for this pair style.
This pair style does not support the "pair_modify"_pair_modify.html
tail option for adding long-range tail corrections to energy and
pressure.
This pair style writes its information to "binary restart
files"_restart.html, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.
This pair style can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. It does not support the
{inner}, {middle}, {outer} keywords.
:line
[Restrictions:]
These styles are part of the COLLOID package. They are only enabled
if LAMMPS was built with that package. See the "Making
LAMMPS"_Section_start.html#start_2_3 section for more info.
Only spherical monodisperse particles are allowed for pair_style
lubricate.
Only spherical particles are allowed for pair_style lubricate/poly.
These pair styles will not restart exactly when using the
"read_restart"_read_restart.html command, though they should provide
statistically similar results. This is because the forces they
compute depend on atom velocities. See the
"read_restart"_read_restart.html command for more details.
[Related commands:]
"pair_coeff"_pair_coeff.html, "pair_style
lubricateU"_pair_lubricateU.html
[Default:]
The default settings for the optional args are flagHI = 1 and flagVF =
1.
:line
:link(Ball1)
[(Ball)] Ball and Melrose, Physica A, 247, 444-472 (1997).
:link(Kumar1)
[(Kumar)] Kumar and Higdon, Phys Rev E, 82, 051401 (2010). See also
his thesis for more details: A. Kumar, "Microscale Dynamics in
Suspensions of Non-spherical Particles", Thesis, University of
Illinois Urbana-Champaign,
(2010). ("https://www.ideals.illinois.edu/handle/2142/16032"_https://www.ideals.illinois.edu/handle/2142/16032)
diff --git a/doc/src/pair_meam_spline.txt b/doc/src/pair_meam_spline.txt
index 2295a6640..6653b397a 100644
--- a/doc/src/pair_meam_spline.txt
+++ b/doc/src/pair_meam_spline.txt
@@ -1,168 +1,168 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style meam/spline :h3
pair_style meam/spline/omp :h3
[Syntax:]
pair_style meam/spline :pre
[Examples:]
pair_style meam/spline
pair_coeff * * Ti.meam.spline Ti
pair_coeff * * Ti.meam.spline Ti Ti Ti :pre
[Description:]
The {meam/spline} style computes pairwise interactions for metals
using a variant of modified embedded-atom method (MEAM) potentials
"(Lenosky)"_#Lenosky1. For a single species ("old-style") MEAM,
the total energy E is given by
:c,image(Eqs/pair_meam_spline.jpg)
where rho_i is the density at atom I, theta_jik is the angle between
atoms J, I, and K centered on atom I. The five functions Phi, U, rho,
f, and g are represented by cubic splines.
The {meam/spline} style also supports a new style multicomponent
modified embedded-atom method (MEAM) potential "(Zhang)"_#Zhang4, where
the total energy E is given by
:c,image(Eqs/pair_meam_spline_multicomponent.jpg)
where the five functions Phi, U, rho, f, and g depend on the chemistry
of the atoms in the interaction. In particular, if there are N different
chemistries, there are N different U, rho, and f functions, while there
are N(N+1)/2 different Phi and g functions. The new style multicomponent
MEAM potential files are indicated by the second line in the file starts
with "meam/spline" followed by the number of elements and the name of each
element.
The cutoffs and the coefficients for these spline functions are listed
in a parameter file which is specified by the
"pair_coeff"_pair_coeff.html command. Parameter files for different
elements are included in the "potentials" directory of the LAMMPS
distribution and have a ".meam.spline" file suffix. All of these
files are parameterized in terms of LAMMPS "metal units"_units.html.
Note that unlike for other potentials, cutoffs for spline-based MEAM
potentials are not set in the pair_style or pair_coeff command; they
are specified in the potential files themselves.
Unlike the EAM pair style, which retrieves the atomic mass from the
potential file, the spline-based MEAM potentials do not include mass
information; thus you need to use the "mass"_mass.html command to
specify it.
Only a single pair_coeff command is used with the {meam/spline} style
which specifies a potential file with parameters for all needed
elements. These are mapped to LAMMPS atom types by specifying N
additional arguments after the filename in the pair_coeff command,
where N is the number of LAMMPS atom types:
filename
N element names = mapping of spline-based MEAM elements to atom types :ul
See the "pair_coeff"_pair_coeff.html doc page for alternate ways
to specify the path for the potential file.
As an example, imagine the Ti.meam.spline file has values for Ti (old style). If
your LAMMPS simulation has 3 atoms types and they are all to be
treated with this potentials, you would use the following pair_coeff
command:
pair_coeff * * Ti.meam.spline Ti Ti Ti :pre
The 1st 2 arguments must be * * so as to span all LAMMPS atom types.
The three Ti arguments map LAMMPS atom types 1,2,3 to the Ti element
in the potential file. If a mapping value is specified as NULL, the
mapping is not performed. This can be used when a {meam/spline}
potential is used as part of the {hybrid} pair style. The NULL values
are placeholders for atom types that will be used with other
potentials. The old-style potential maps any non-NULL species named
on the command line to that single type.
An example with a two component spline (new style) is TiO.meam.spline, where
the command
pair_coeff * * TiO.meam.spline Ti O :pre
will map the 1st atom type to Ti and the second atom type to O. Note
in this case that the species names need to match exactly with the
names of the elements in the TiO.meam.spline file; otherwise an
error will be raised. This behavior is different than the old style
MEAM files.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
This pair style does not support the "pair_modify"_pair_modify.html
shift, table, and tail options.
The {meam/spline} pair style does not write its information to "binary
restart files"_restart.html, since it is stored in an external
potential parameter file. Thus, you need to re-specify the pair_style
and pair_coeff commands in an input script that reads a restart file.
The {meam/spline} pair style can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. They do not support the
{inner}, {middle}, {outer} keywords.
:line
[Restrictions:]
This pair style requires the "newton"_newton.html setting to be "on"
for pair interactions.
This pair style is only enabled if LAMMPS was built with the USER-MISC
package. See the "Making LAMMPS"_Section_start.html#start_3 section
for more info.
[Related commands:]
"pair_coeff"_pair_coeff.html, "pair_style meam"_pair_meam.html
[Default:] none
:line
:link(Lenosky1)
[(Lenosky)] Lenosky, Sadigh, Alonso, Bulatov, de la Rubia, Kim, Voter,
Kress, Modelling Simulation Materials Science Engineering, 8, 825
(2000).
:link(Zhang4)
[(Zhang)] Zhang and Trinkle, Computational Materials Science, 124, 204-210 (2016).
diff --git a/doc/src/pair_morse.txt b/doc/src/pair_morse.txt
index 5fbb6d5c0..3eb5ac5af 100644
--- a/doc/src/pair_morse.txt
+++ b/doc/src/pair_morse.txt
@@ -1,163 +1,163 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style morse command :h3
pair_style morse/gpu command :h3
pair_style morse/omp command :h3
pair_style morse/opt command :h3
pair_style morse/smooth/linear command :h3
pair_style morse/smooth/linear/omp command :h3
pair_style morse/soft command :h3
pair_style morse/kk command :h3
[Syntax:]
pair_style style args :pre
style = {morse} or {morse/smooth/linear} or {morse/soft}
args = list of arguments for a particular style :ul
{morse} args = cutoff
cutoff = global cutoff for Morse interactions (distance units)
{morse/smooth/linear} args = cutoff
cutoff = global cutoff for Morse interactions (distance units)
{morse/soft} args = n lf cutoff
n = soft-core parameter
lf = transformation range is lf < lambda < 1
cutoff = global cutoff for Morse interactions (distance units)
:pre
[Examples:]
pair_style morse 2.5
pair_style morse/smooth/linear 2.5
pair_coeff * * 100.0 2.0 1.5
pair_coeff 1 1 100.0 2.0 1.5 3.0 :pre
pair_style morse/soft 4 0.9 10.0
pair_coeff * * 100.0 2.0 1.5 1.0
pair_coeff 1 1 100.0 2.0 1.5 1.0 3.0 :pre
[Description:]
Style {morse} computes pairwise interactions with the formula
:c,image(Eqs/pair_morse.jpg)
Rc is the cutoff.
The following coefficients must be defined for each pair of atoms
types via the "pair_coeff"_pair_coeff.html command as in the examples
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands:
D0 (energy units)
alpha (1/distance units)
r0 (distance units)
cutoff (distance units) :ul
The last coefficient is optional. If not specified, the global morse
cutoff is used.
:line
The {morse/smooth/linear} variant is similar to the lj/smooth/linear
variant in that it adds to the potential a shift and a linear term
so that both, potential energy and force, go to zero at the cut-off:
:c,image(Eqs/pair_morse_smooth_linear.jpg)
The syntax of the pair_style and pair_coeff commands are the same for
the {morse} and {morse/smooth/linear} styles.
:line
The {morse/soft} variant is similar to the {lj/cut/soft} pair style
in that it modifies the potential at short range to have a soft core.
This helps to avoid singularities during free energy calculation in
which sites are created or annihilated. The formula differs from that
of {lj/cut/soft}, and is instead given by:
:c,image(Eqs/pair_morse_soft.jpg)
The {morse/soft} style requires the following pair coefficients:
D0 (energy units)
alpha (1/distance units)
r0 (distance units)
lamda (unitless, between 0.0 and 1.0)
cutoff (distance units) :ul
The last coefficient is optional. If not specified, the global morse
cutoff is used.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
None of these pair styles support mixing. Thus, coefficients for all
I,J pairs must be specified explicitly.
All of these pair styles support the "pair_modify"_pair_modify.html
shift option for the energy of the pair interaction.
The "pair_modify"_pair_modify.html table options is not relevant for
the Morse pair styles.
None of these pair styles support the "pair_modify"_pair_modify.html
tail option for adding long-range tail corrections to energy and
pressure.
All of these pair styles write their information to "binary restart
files"_restart.html, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.
These pair styles can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. They do not support the
{inner}, {middle}, {outer} keywords.
:line
[Restrictions:]
The {morse/smooth/linear} pair style is only enabled if LAMMPS was
built with the USER-MISC package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
The {morse/soft} pair style is only enabled if LAMMPS was built with
the USER-FEP package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
diff --git a/doc/src/pair_nb3b_harmonic.txt b/doc/src/pair_nb3b_harmonic.txt
index 3f7066c82..2395707fb 100644
--- a/doc/src/pair_nb3b_harmonic.txt
+++ b/doc/src/pair_nb3b_harmonic.txt
@@ -1,125 +1,125 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style nb3b/harmonic command :h3
pair_style nb3b/harmonic/omp command :h3
[Syntax:]
pair_style nb3b/harmonic :pre
[Examples:]
pair_style nb3b/harmonic
pair_coeff * * MgOH.nb3bharmonic Mg O H :pre
[Description:]
This pair style computes a nonbonded 3-body harmonic potential for the
energy E of a system of atoms as
:c,image(Eqs/pair_nb3b_harmonic.jpg)
where {theta_0} is the equilibrium value of the angle and {K} is a
prefactor. Note that the usual 1/2 factor is included in {K}. The form
of the potential is identical to that used in angle_style {harmonic},
but in this case, the atoms do not need to be explicitly bonded.
Only a single pair_coeff command is used with this style which
specifies a potential file with parameters for specified elements.
These are mapped to LAMMPS atom types by specifying N additional
arguments after the filename in the pair_coeff command, where N is the
number of LAMMPS atom types:
filename
N element names = mapping of elements to atom types :ul
See the "pair_coeff"_pair_coeff.html doc page for alternate ways
to specify the path for the potential file.
As an example, imagine a file SiC.nb3b.harmonic has potential values
for Si and C. If your LAMMPS simulation has 4 atoms types and you
want the 1st 3 to be Si, and the 4th to be C, you would use the
following pair_coeff command:
pair_coeff * * SiC.nb3b.harmonic Si Si Si C :pre
The 1st 2 arguments must be * * so as to span all LAMMPS atom types.
The first three Si arguments map LAMMPS atom types 1,2,3 to the Si
element in the potential file. The final C argument maps LAMMPS atom
type 4 to the C element in the potential file. If a mapping value is
specified as NULL, the mapping is not performed. This can be used
when the potential is used as part of the {hybrid} pair style. The
NULL values are placeholders for atom types that will be used with
other potentials. An example of a pair_coeff command for use with the
{hybrid} pair style is:
pair_coeff * * nb3b/harmonic MgOH.nb3b.harmonic Mg O H
Three-body nonbonded harmonic files in the {potentials} directory of
the LAMMPS distribution have a ".nb3b.harmonic" suffix. Lines that
are not blank or comments (starting with #) define parameters for a
triplet of elements.
Each entry has six arguments. The first three are atom types as
referenced in the LAMMPS input file. The first argument specifies the
central atom. The fourth argument indicates the {K} parameter. The
fifth argument indicates {theta_0}. The sixth argument indicates a
separation cutoff in Angstroms.
For a given entry, if the second and third arguments are identical,
then the entry is for a cutoff for the distance between types 1 and 2
(values for {K} and {theta_0} are irrelevant in this case).
For a given entry, if the first three arguments are all different,
then the entry is for the {K} and {theta_0} parameters (the cutoff in
this case is irrelevant).
It is required that the potential file contains entries for {all}
permutations of the elements listed in the pair_coeff command.
If certain combinations are not parameterized the corresponding
parameters should be set to zero. The potential file can also
contain entries for additional elements which are not used in
a particular simulation; LAMMPS ignores those entries.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This pair style can only be used if LAMMPS was built with the MANYBODY
package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info on packages.
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
diff --git a/doc/src/pair_nm.txt b/doc/src/pair_nm.txt
index 9096bdc52..81cea1a38 100644
--- a/doc/src/pair_nm.txt
+++ b/doc/src/pair_nm.txt
@@ -1,169 +1,169 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style nm/cut command :h3
pair_style nm/cut/coul/cut command :h3
pair_style nm/cut/coul/long command :h3
pair_style nm/cut/omp command :h3
pair_style nm/cut/coul/cut/omp command :h3
pair_style nm/cut/coul/long/omp command :h3
[Syntax:]
pair_style style args :pre
style = {nm/cut} or {nm/cut/coul/cut} or {nm/cut/coul/long} :ulb,l
args = list of arguments for a particular style :l
{nm/cut} args = cutoff
cutoff = global cutoff for Pair interactions (distance units)
{nm/cut/coul/cut} args = cutoff (cutoff2)
cutoff = global cutoff for Pair (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units)
{nm/cut/coul/long} args = cutoff (cutoff2)
cutoff = global cutoff for Pair (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units) :pre
:ule
[Examples:]
pair_style nm/cut 12.0
pair_coeff * * 0.01 5.4 8.0 7.0
pair_coeff 1 1 0.01 4.4 7.0 6.0 :pre
pair_style nm/cut/coul/cut 12.0 15.0
pair_coeff * * 0.01 5.4 8.0 7.0
pair_coeff 1 1 0.01 4.4 7.0 6.0 :pre
pair_style nm/cut/coul/long 12.0 15.0
pair_coeff * * 0.01 5.4 8.0 7.0
pair_coeff 1 1 0.01 4.4 7.0 6.0 :pre
[Description:]
Style {nm} computes site-site interactions based on the N-M potential
by "Clarke"_#Clarke, mainly used for ionic liquids. A site can
represent a single atom or a united-atom site. The energy of an
interaction has the following form:
:c,image(Eqs/pair_nm.jpg)
Rc is the cutoff.
Style {nm/cut/coul/cut} adds a Coulombic pairwise interaction given by
:c,image(Eqs/pair_coulomb.jpg)
where C is an energy-conversion constant, Qi and Qj are the charges on
the 2 atoms, and epsilon is the dielectric constant which can be set
by the "dielectric"_dielectric.html command. If one cutoff is
specified in the pair_style command, it is used for both the NM and
Coulombic terms. If two cutoffs are specified, they are used as
cutoffs for the NM and Coulombic terms respectively.
Styles {nm/cut/coul/long} compute the same
Coulombic interactions as style {nm/cut/coul/cut} except that an
additional damping factor is applied to the Coulombic term so it can
be used in conjunction with the "kspace_style"_kspace_style.html
command and its {ewald} or {pppm} option. The Coulombic cutoff
specified for this style means that pairwise interactions within this
distance are computed directly; interactions outside that distance are
computed in reciprocal space.
For all of the {nm} pair styles, the following coefficients must
be defined for each pair of atoms types
via the "pair_coeff"_pair_coeff.html command as in the
examples above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands.
E0 (energy units)
r0 (distance units)
n (unitless)
m (unitless)
cutoff1 (distance units)
cutoff2 (distance units) :ul
The latter 2 coefficients are optional. If not specified, the global
NM and Coulombic cutoffs specified in the pair_style command are used.
If only one cutoff is specified, it is used as the cutoff for both NM
and Coulombic interactions for this type pair. If both coefficients
are specified, they are used as the NM and Coulombic cutoffs for this
type pair. You cannot specify 2 cutoffs for style {nm}, since it
has no Coulombic terms.
For {nm/cut/coul/long} only the NM cutoff can be specified since a
Coulombic cutoff cannot be specified for an individual I,J type pair.
All type pairs use the same global Coulombic cutoff specified in the
pair_style command.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
These pair styles do not support mixing. Thus, coefficients for all
I,J pairs must be specified explicitly.
All of the {nm} pair styles supports the
"pair_modify"_pair_modify.html shift option for the energy of the pair
interaction.
The {nm/cut/coul/long} pair styles support the
"pair_modify"_pair_modify.html table option since they can tabulate
the short-range portion of the long-range Coulombic interaction.
All of the {nm} pair styles support the "pair_modify"_pair_modify.html
tail option for adding a long-range tail correction to the energy and
pressure for the NM portion of the pair interaction.
All of the {nm} pair styles write their information to "binary restart
files"_restart.html, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.
All of the {nm} pair styles can only be used via the {pair} keyword of
the "run_style respa"_run_style.html command. They do not support the
{inner}, {middle}, {outer} keywords.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
[Restrictions:]
These pair styles are part of the MISC package. It is only enabled if
LAMMPS was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
:line
:link(Clarke)
[(Clarke)] Clarke and Smith, J Chem Phys, 84, 2290 (1986).
diff --git a/doc/src/pair_peri.txt b/doc/src/pair_peri.txt
index 7abe6378d..deca093e3 100644
--- a/doc/src/pair_peri.txt
+++ b/doc/src/pair_peri.txt
@@ -1,216 +1,216 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style peri/pmb command :h3
pair_style peri/pmb/omp command :h3
pair_style peri/lps command :h3
pair_style peri/lps/omp command :h3
pair_style peri/ves command :h3
pair_style peri/eps command :h3
[Syntax:]
pair_style style :pre
style = {peri/pmb} or {peri/lps} or {peri/ves} or {peri/eps} :ul
[Examples:]
pair_style peri/pmb
pair_coeff * * 1.6863e22 0.0015001 0.0005 0.25 :pre
pair_style peri/lps
pair_coeff * * 14.9e9 14.9e9 0.0015001 0.0005 0.25 :pre
pair_style peri/ves
pair_coeff * * 14.9e9 14.9e9 0.0015001 0.0005 0.25 0.5 0.001 :pre
pair_style peri/eps
pair_coeff * * 14.9e9 14.9e9 0.0015001 0.0005 0.25 118.43 :pre
[Description:]
The peridynamic pair styles implement material models that can be used
at the mescscopic and macroscopic scales. See "this
document"_PDF/PDLammps_overview.pdf for an overview of LAMMPS commands
for Peridynamics modeling.
Style {peri/pmb} implements the Peridynamic bond-based prototype
microelastic brittle (PMB) model.
Style {peri/lps} implements the Peridynamic state-based linear
peridynamic solid (LPS) model.
Style {peri/ves} implements the Peridynamic state-based linear
peridynamic viscoelastic solid (VES) model.
Style {peri/eps} implements the Peridynamic state-based elastic-plastic
solid (EPS) model.
The canonical papers on Peridynamics are "(Silling 2000)"_#Silling2000
and "(Silling 2007)"_#Silling2007. The implementation of Peridynamics
in LAMMPS is described in "(Parks)"_#Parks. Also see the "PDLAMMPS
user guide"_http://www.sandia.gov/~mlparks/papers/PDLAMMPS.pdf for
more details about its implementation.
The peridynamic VES and EPS models in PDLAMMPS were implemented by
R. Rahman and J. T. Foster at University of Texas at San Antonio. The
original VES formulation is described in "(Mitchell2011)" and the
original EPS formulation is in "(Mitchell2011a)". Additional PDF docs
that describe the VES and EPS implementations are include in the
LAMMPS distro in "doc/PDF/PDLammps_VES.pdf"_PDF/PDLammps_VES.pdf and
"doc/PDF/PDLammps_EPS.pdf"_PDF/PDLammps_EPS.pdf. For questions
regarding the VES and EPS models in LAMMPS you can contact R. Rahman
(rezwanur.rahman at utsa.edu).
The following coefficients must be defined for each pair of atom types
via the "pair_coeff"_pair_coeff.html command as in the examples above,
or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands, or by mixing as described below.
For the {peri/pmb} style:
c (energy/distance/volume^2 units)
horizon (distance units)
s00 (unitless)
alpha (unitless) :ul
C is the effectively a spring constant for Peridynamic bonds, the
horizon is a cutoff distance for truncating interactions, and s00 and
alpha are used as a bond breaking criteria. The units of c are such
that c/distance = stiffness/volume^2, where stiffness is
energy/distance^2 and volume is distance^3. See the users guide for
more details.
For the {peri/lps} style:
K (force/area units)
G (force/area units)
horizon (distance units)
s00 (unitless)
alpha (unitless) :ul
K is the bulk modulus and G is the shear modulus. The horizon is a
cutoff distance for truncating interactions, and s00 and alpha are
used as a bond breaking criteria. See the users guide for more
details.
For the {peri/ves} style:
K (force/area units)
G (force/area units)
horizon (distance units)
s00 (unitless)
alpha (unitless)
m_lambdai (unitless)
m_taubi (unitless) :ul
K is the bulk modulus and G is the shear modulus. The horizon is a
cutoff distance for truncating interactions, and s00 and alpha are
used as a bond breaking criteria. m_lambdai and m_taubi are the
viscoelastic relaxation parameter and time constant,
respectively. m_lambdai varies within zero to one. For very small
values of m_lambdai the viscoelastic model responds very similar to a
linear elastic model. For details please see the description in
"(Mtchell2011)".
For the {peri/eps} style:
K (force/area units)
G (force/area units)
horizon (distance units)
s00 (unitless)
alpha (unitless)
m_yield_stress (force/area units) :ul
K is the bulk modulus and G is the shear modulus. The horizon is a
cutoff distance and s00 and alpha are used as a bond breaking
criteria. m_yield_stress is the yield stress of the material. For
details please see the description in "(Mtchell2011a)".
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
These pair styles do not support mixing. Thus, coefficients for all
I,J pairs must be specified explicitly.
These pair styles do not support the "pair_modify"_pair_modify.html
shift option.
The "pair_modify"_pair_modify.html table and tail options are not
relevant for these pair styles.
These pair styles write their information to "binary restart
files"_restart.html, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.
These pair styles can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. They do not support the
{inner}, {middle}, {outer} keywords.
:line
[Restrictions:]
All of these styles are part of the PERI package. They are only
enabled if LAMMPS was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
:line
:link(Parks)
[(Parks)] Parks, Lehoucq, Plimpton, Silling, Comp Phys Comm, 179(11),
777-783 (2008).
:link(Silling2000)
[(Silling 2000)] Silling, J Mech Phys Solids, 48, 175-209 (2000).
:link(Silling2007)
[(Silling 2007)] Silling, Epton, Weckner, Xu, Askari, J Elasticity,
88, 151-184 (2007).
:link(Mitchell2011)
[(Mitchell2011)] Mitchell. A non-local, ordinary-state-based
viscoelasticity model for peridynamics. Sandia National Lab Report,
8064:1-28 (2011).
:link(Mitchell2011a)
[(Mitchell2011a)] Mitchell. A Nonlocal, Ordinary, State-Based
Plasticity Model for Peridynamics. Sandia National Lab Report,
3166:1-34 (2011).
diff --git a/doc/src/pair_reaxc.txt b/doc/src/pair_reaxc.txt
index cfa88673d..b9dc6e0ed 100644
--- a/doc/src/pair_reaxc.txt
+++ b/doc/src/pair_reaxc.txt
@@ -1,358 +1,358 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style reax/c command :h3
pair_style reax/c/kk command :h3
pair_style reax/c/omp command :h3
[Syntax:]
pair_style reax/c cfile keyword value :pre
cfile = NULL or name of a control file :ulb,l
zero or more keyword/value pairs may be appended :l
keyword = {checkqeq} or {lgvdw} or {safezone} or {mincap}
{checkqeq} value = {yes} or {no} = whether or not to require qeq/reax fix
{enobonds} value = {yes} or {no} = whether or not to tally energy of atoms with no bonds
{lgvdw} value = {yes} or {no} = whether or not to use a low gradient vdW correction
{safezone} = factor used for array allocation
{mincap} = minimum size for array allocation :pre
:ule
[Examples:]
pair_style reax/c NULL
pair_style reax/c controlfile checkqeq no
pair_style reax/c NULL lgvdw yes
pair_style reax/c NULL safezone 1.6 mincap 100
pair_coeff * * ffield.reax C H O N :pre
[Description:]
Style {reax/c} computes the ReaxFF potential of van Duin, Goddard and
co-workers. ReaxFF uses distance-dependent bond-order functions to
represent the contributions of chemical bonding to the potential
energy. There is more than one version of ReaxFF. The version
implemented in LAMMPS uses the functional forms documented in the
supplemental information of the following paper: "(Chenoweth et al.,
2008)"_#Chenoweth_20082. The version integrated into LAMMPS matches
the most up-to-date version of ReaxFF as of summer 2010. For more
technical details about the pair reax/c implementation of ReaxFF, see
the "(Aktulga)"_#Aktulga paper. The {reax/c} style was initially
implemented as a stand-alone C code and is now integrated into LAMMPS
as a package.
The {reax/c/kk} style is a Kokkos version of the ReaxFF potential that is
derived from the {reax/c} style. The Kokkos version can run on GPUs and
can also use OpenMP multithreading. For more information about the Kokkos package,
see "Section 4"_Section_packages.html#kokkos and "Section 5.3.3"_accelerate_kokkos.html.
One important consideration when using the {reax/c/kk} style is the choice of either
half or full neighbor lists. This setting can be changed using the Kokkos "package"_package.html
command.
The {reax/c} style differs from the "pair_style reax"_pair_reax.html
command in the lo-level implementation details. The {reax} style is a
Fortran library, linked to LAMMPS. The {reax/c} style was initially
implemented as stand-alone C code and is now integrated into LAMMPS as
a package.
LAMMPS provides several different versions of ffield.reax in its
potentials dir, each called potentials/ffield.reax.label. These are
documented in potentials/README.reax. The default ffield.reax
contains parameterizations for the following elements: C, H, O, N.
The format of these files is identical to that used originally by van
Duin. We have tested the accuracy of {pair_style reax/c} potential
against the original ReaxFF code for the systems mentioned above. You
can use other ffield files for specific chemical systems that may be
available elsewhere (but note that their accuracy may not have been
tested).
NOTE: We do not distribute a wide variety of ReaxFF force field files
with LAMMPS. Adri van Duin's group at PSU is the central repository
for this kind of data as they are continuously deriving and updating
parameterizations for different classes of materials. You can submit
a contact request at the Materials Computation Center (MCC) website
"https://www.mri.psu.edu/materials-computation-center/connect-mcc"_https://www.mri.psu.edu/materials-computation-center/connect-mcc,
describing the material(s) you are interested in modeling with ReaxFF.
They can tell
you what is currently available or what it would take to create a
suitable ReaxFF parameterization.
The {cfile} setting can be specified as NULL, in which case default
settings are used. A control file can be specified which defines
values of control variables. Some control variables are
global parameters for the ReaxFF potential. Others define certain
performance and output settings.
Each line in the control file specifies the value for
a control variable. The format of the control file is described
below.
NOTE: The LAMMPS default values for the ReaxFF global parameters
correspond to those used by Adri van Duin's stand-alone serial
code. If these are changed by setting control variables in the control
file, the results from LAMMPS and the serial code will not agree.
Two examples using {pair_style reax/c} are provided in the examples/reax
sub-directory, along with corresponding examples for
"pair_style reax"_pair_reax.html.
Use of this pair style requires that a charge be defined for every
atom. See the "atom_style"_atom_style.html and
"read_data"_read_data.html commands for details on how to specify
charges.
The ReaxFF parameter files provided were created using a charge
equilibration (QEq) model for handling the electrostatic interactions.
Therefore, by default, LAMMPS requires that the "fix
qeq/reax"_fix_qeq_reax.html command be used with {pair_style reax/c}
when simulating a ReaxFF model, to equilibrate charge each timestep.
Using the keyword {checkqeq} with the value {no}
turns off the check for {fix qeq/reax},
allowing a simulation to be run without charge equilibration.
In this case, the static charges you
assign to each atom will be used for computing the electrostatic
interactions in the system.
See the "fix qeq/reax"_fix_qeq_reax.html command for details.
Using the optional keyword {lgvdw} with the value {yes} turns on
the low-gradient correction of the ReaxFF/C for long-range
London Dispersion, as described in the "(Liu)"_#Liu_2011 paper. Force field
file {ffield.reax.lg} is designed for this correction, and is trained
for several energetic materials (see "Liu"). When using lg-correction,
recommended value for parameter {thb} is 0.01, which can be set in the
control file. Note: Force field files are different for the original
or lg corrected pair styles, using wrong ffield file generates an error message.
Using the optional keyword {enobonds} with the value {yes}, the energy
of atoms with no bonds (i.e. isolated atoms) is included in the total
potential energy and the per-atom energy of that atom. If the value
{no} is specified then the energy of atoms with no bonds is set to zero.
The latter behavior is usual not desired, as it causes discontinuities
in the potential energy when the bonding of an atom drops to zero.
Optional keywords {safezone} and {mincap} are used for allocating
reax/c arrays. Increasing these values can avoid memory problems, such
as segmentation faults and bondchk failed errors, that could occur under
certain conditions. These keywords aren't used by the Kokkos version, which
instead uses a more robust memory allocation scheme that checks if the sizes of
the arrays have been exceeded and automatically allocates more memory.
The thermo variable {evdwl} stores the sum of all the ReaxFF potential
energy contributions, with the exception of the Coulombic and charge
equilibration contributions which are stored in the thermo variable
{ecoul}. The output of these quantities is controlled by the
"thermo"_thermo.html command.
This pair style tallies a breakdown of the total ReaxFF potential
energy into sub-categories, which can be accessed via the "compute
pair"_compute_pair.html command as a vector of values of length 14.
The 14 values correspond to the following sub-categories (the variable
names in italics match those used in the original FORTRAN ReaxFF code):
{eb} = bond energy
{ea} = atom energy
{elp} = lone-pair energy
{emol} = molecule energy (always 0.0)
{ev} = valence angle energy
{epen} = double-bond valence angle penalty
{ecoa} = valence angle conjugation energy
{ehb} = hydrogen bond energy
{et} = torsion energy
{eco} = conjugation energy
{ew} = van der Waals energy
{ep} = Coulomb energy
{efi} = electric field energy (always 0.0)
{eqeq} = charge equilibration energy :ol
To print these quantities to the log file (with descriptive column
headings) the following commands could be included in an input script:
compute reax all pair reax/c
variable eb equal c_reax\[1\]
variable ea equal c_reax\[2\]
\[...\]
variable eqeq equal c_reax\[14\]
thermo_style custom step temp epair v_eb v_ea \[...\] v_eqeq :pre
Only a single pair_coeff command is used with the {reax/c} style which
specifies a ReaxFF potential file with parameters for all needed
elements. These are mapped to LAMMPS atom types by specifying N
additional arguments after the filename in the pair_coeff command,
where N is the number of LAMMPS atom types:
filename
N indices = ReaxFF elements :ul
The filename is the ReaxFF potential file. Unlike for the {reax}
pair style, any filename can be used.
In the ReaxFF potential file, near the top, after the general
parameters, is the atomic parameters section that contains element
names, each with a couple dozen numeric parameters. If there are M
elements specified in the {ffield} file, think of these as numbered 1
to M. Each of the N indices you specify for the N atom types of LAMMPS
atoms must be an integer from 1 to M. Atoms with LAMMPS type 1 will
be mapped to whatever element you specify as the first index value,
etc. If a mapping value is specified as NULL, the mapping is not
performed. This can be used when the {reax/c} style is used as part
of the {hybrid} pair style. The NULL values are placeholders for atom
types that will be used with other potentials.
As an example, say your LAMMPS simulation has 4 atom types and the
elements are ordered as C, H, O, N in the {ffield} file. If you want
the LAMMPS atom type 1 and 2 to be C, type 3 to be N, and type 4 to be
H, you would use the following pair_coeff command:
pair_coeff * * ffield.reax C C N H :pre
:line
The format of a line in the control file is as follows:
variable_name value :pre
and it may be followed by an "!" character and a trailing comment.
If the value of a control variable is not specified, then default
values are used. What follows is the list of variables along with a
brief description of their use and default values.
simulation_name: Output files produced by {pair_style reax/c} carry
this name + extensions specific to their contents. Partial energies
are reported with a ".pot" extension, while the trajectory file has
".trj" extension.
tabulate_long_range: To improve performance, long range interactions
can optionally be tabulated (0 means no tabulation). Value of this
variable denotes the size of the long range interaction table. The
range from 0 to long range cutoff (defined in the {ffield} file) is
divided into {tabulate_long_range} points. Then at the start of
simulation, we fill in the entries of the long range interaction table
by computing the energies and forces resulting from van der Waals and
Coulomb interactions between every possible atom type pairs present in
the input system. During the simulation we consult to the long range
interaction table to estimate the energy and forces between a pair of
atoms. Linear interpolation is used for estimation. (default value =
0)
energy_update_freq: Denotes the frequency (in number of steps) of
writes into the partial energies file. (default value = 0)
nbrhood_cutoff: Denotes the near neighbors cutoff (in Angstroms)
regarding the bonded interactions. (default value = 5.0)
hbond_cutoff: Denotes the cutoff distance (in Angstroms) for hydrogen
bond interactions.(default value = 7.5. A value of 0.0 turns off
hydrogen bonds)
bond_graph_cutoff: is the threshold used in determining what is a
physical bond, what is not. Bonds and angles reported in the
trajectory file rely on this cutoff. (default value = 0.3)
thb_cutoff: cutoff value for the strength of bonds to be considered in
three body interactions. (default value = 0.001)
thb_cutoff_sq: cutoff value for the strength of bond order products
to be considered in three body interactions. (default value = 0.00001)
write_freq: Frequency of writes into the trajectory file. (default
value = 0)
traj_title: Title of the trajectory - not the name of the trajectory
file.
atom_info: 1 means print only atomic positions + charge (default = 0)
atom_forces: 1 adds net forces to atom lines in the trajectory file
(default = 0)
atom_velocities: 1 adds atomic velocities to atoms line (default = 0)
bond_info: 1 prints bonds in the trajectory file (default = 0)
angle_info: 1 prints angles in the trajectory file (default = 0)
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
This pair style does not support the "pair_modify"_pair_modify.html
mix, shift, table, and tail options.
This pair style does not write its information to "binary restart
files"_restart.html, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.
This pair style can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. It does not support the
{inner}, {middle}, {outer} keywords.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
This pair style is part of the USER-REAXC package. It is only enabled
if LAMMPS was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
The ReaxFF potential files provided with LAMMPS in the potentials
directory are parameterized for real "units"_units.html. You can use
the ReaxFF potential with any LAMMPS units, but you would need to
create your own potential file with coefficients listed in the
appropriate units if your simulation doesn't use "real" units.
[Related commands:]
"pair_coeff"_pair_coeff.html, "fix qeq/reax"_fix_qeq_reax.html, "fix
reax/c/bonds"_fix_reax_bonds.html, "fix
reax/c/species"_fix_reaxc_species.html, "pair_style
reax"_pair_reax.html
[Default:]
The keyword defaults are checkqeq = yes, enobonds = yes, lgvdw = no, safezone = 1.2,
mincap = 50.
:line
:link(Chenoweth_20082)
[(Chenoweth_2008)] Chenoweth, van Duin and Goddard,
Journal of Physical Chemistry A, 112, 1040-1053 (2008).
:link(Aktulga)
(Aktulga) Aktulga, Fogarty, Pandit, Grama, Parallel Computing, 38,
245-259 (2012).
:link(Liu_2011)
[(Liu)] L. Liu, Y. Liu, S. V. Zybin, H. Sun and W. A. Goddard, Journal
of Physical Chemistry A, 115, 11016-11022 (2011).
diff --git a/doc/src/pair_resquared.txt b/doc/src/pair_resquared.txt
index 2e0034ed3..9ad95eb5f 100644
--- a/doc/src/pair_resquared.txt
+++ b/doc/src/pair_resquared.txt
@@ -1,235 +1,235 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style resquared command :h3
pair_style resquared/gpu command :h3
pair_style resquared/omp command :h3
[Syntax:]
pair_style resquared cutoff :pre
cutoff = global cutoff for interactions (distance units) :ul
[Examples:]
pair_style resquared 10.0
pair_coeff * * 1.0 1.0 1.7 3.4 3.4 1.0 1.0 1.0 :pre
[Description:]
Style {resquared} computes the RE-squared anisotropic interaction
"(Everaers)"_#Everaers3, "(Babadi)"_#Babadi between pairs of
ellipsoidal and/or spherical Lennard-Jones particles. For ellipsoidal
interactions, the potential considers the ellipsoid as being comprised
of small spheres of size sigma. LJ particles are a single sphere of
size sigma. The distinction is made to allow the pair style to make
efficient calculations of ellipsoid/solvent interactions.
Details for the equations used are given in the references below and
in "this supplementary document"_PDF/pair_resquared_extra.pdf.
Use of this pair style requires the NVE, NVT, or NPT fixes with the
{asphere} extension (e.g. "fix nve/asphere"_fix_nve_asphere.html) in
order to integrate particle rotation. Additionally, "atom_style
ellipsoid"_atom_style.html should be used since it defines the
rotational state and the size and shape of each ellipsoidal particle.
The following coefficients must be defined for each pair of atoms
types via the "pair_coeff"_pair_coeff.html command as in the examples
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands:
A12 = Energy Prefactor/Hamaker constant (energy units)
sigma = atomic interaction diameter (distance units)
epsilon_i_a = relative well depth of type I for side-to-side interactions
epsilon_i_b = relative well depth of type I for face-to-face interactions
epsilon_i_c = relative well depth of type I for end-to-end interactions
epsilon_j_a = relative well depth of type J for side-to-side interactions
epsilon_j_b = relative well depth of type J for face-to-face interactions
epsilon_j_c = relative well depth of type J for end-to-end interactions
cutoff (distance units) :ul
The parameters used depend on the type of the interacting particles,
i.e. ellipsoids or LJ spheres. The type of a particle is determined
by the diameters specified for its 3 shape parameters. If all 3 shape
parameters = 0.0, then the particle is treated as an LJ sphere. The
epsilon_i_* or epsilon_j_* parameters are ignored for LJ spheres. If
the 3 shape parameters are > 0.0, then the particle is treated as an
ellipsoid (even if the 3 parameters are equal to each other).
A12 specifies the energy prefactor which depends on the types of the
two interacting particles.
For ellipsoid/ellipsoid interactions, the interaction is computed by
the formulas in the supplementary document referenced above. A12 is
the Hamaker constant as described in "(Everaers)"_#Everaers3. In LJ
units:
:c,image(Eqs/pair_resquared.jpg)
where rho gives the number density of the spherical particles
composing the ellipsoids and epsilon_LJ determines the interaction
strength of the spherical particles.
For ellipsoid/LJ sphere interactions, the interaction is also computed
by the formulas in the supplementary document referenced above. A12
has a modified form (see "here"_PDF/pair_resquared_extra.pdf for
details):
:c,image(Eqs/pair_resquared2.jpg)
For ellipsoid/LJ sphere interactions, a correction to the distance-
of-closest approach equation has been implemented to reduce the error
from two particles of disparate sizes; see "this supplementary
document"_PDF/pair_resquared_extra.pdf.
For LJ sphere/LJ sphere interactions, the interaction is computed
using the standard Lennard-Jones formula, which is much cheaper to
compute than the ellipsoidal formulas. A12 is used as epsilon in the
standard LJ formula:
:c,image(Eqs/pair_resquared3.jpg)
and the specified {sigma} is used as the sigma in the standard LJ
formula.
When one of both of the interacting particles are ellipsoids, then
{sigma} specifies the diameter of the continuous distribution of
constituent particles within each ellipsoid used to model the
RE-squared potential. Note that this is a different meaning for
{sigma} than the "pair_style gayberne"_pair_gayberne.html potential
uses.
The epsilon_i and epsilon_j coefficients are defined for atom types,
not for pairs of atom types. Thus, in a series of pair_coeff
commands, they only need to be specified once for each atom type.
Specifically, if any of epsilon_i_a, epsilon_i_b, epsilon_i_c are
non-zero, the three values are assigned to atom type I. If all the
epsilon_i values are zero, they are ignored. If any of epsilon_j_a,
epsilon_j_b, epsilon_j_c are non-zero, the three values are assigned
to atom type J. If all three epsilon_i values are zero, they are
ignored. Thus the typical way to define the epsilon_i and epsilon_j
coefficients is to list their values in "pair_coeff I J" commands when
I = J, but set them to 0.0 when I != J. If you do list them when I !=
J, you should insure they are consistent with their values in other
pair_coeff commands.
Note that if this potential is being used as a sub-style of
"pair_style hybrid"_pair_hybrid.html, and there is no "pair_coeff I I"
setting made for RE-squared for a particular type I (because I-I
interactions are computed by another hybrid pair potential), then you
still need to insure the epsilon a,b,c coefficients are assigned to
that type in a "pair_coeff I J" command.
For large uniform molecules it has been shown that the epsilon_*_*
energy parameters are approximately representable in terms of local
contact curvatures "(Everaers)"_#Everaers3:
:c,image(Eqs/pair_resquared4.jpg)
where a, b, and c give the particle diameters.
The last coefficient is optional. If not specified, the global cutoff
specified in the pair_style command is used.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance can be mixed, but only for sphere pairs. The
default mix value is {geometric}. See the "pair_modify" command for
details. Other type pairs cannot be mixed, due to the different
meanings of the energy prefactors used to calculate the interactions
and the implicit dependence of the ellipsoid-sphere interaction on the
equation for the Hamaker constant presented here. Mixing of sigma and
epsilon followed by calculation of the energy prefactors using the
equations above is recommended.
This pair styles supports the "pair_modify"_pair_modify.html shift
option for the energy of the Lennard-Jones portion of the pair
interaction, but only for sphere-sphere interactions. There is no
shifting performed for ellipsoidal interactions due to the anisotropic
dependence of the interaction.
The "pair_modify"_pair_modify.html table option is not relevant
for this pair style.
This pair style does not support the "pair_modify"_pair_modify.html
tail option for adding long-range tail corrections to energy and
pressure.
This pair style writes its information to "binary restart
files"_restart.html, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.
This pair style can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. It does not support the
{inner}, {middle}, {outer} keywords of the "run_style
command"_run_style.html.
:line
[Restrictions:]
This style is part of the ASPHERE package. It is only enabled if
LAMMPS was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
This pair style requires that atoms be ellipsoids as defined by the
"atom_style ellipsoid"_atom_style.html command.
Particles acted on by the potential can be finite-size aspherical or
spherical particles, or point particles. Spherical particles have all
3 of their shape parameters equal to each other. Point particles have
all 3 of their shape parameters equal to 0.0.
The distance-of-closest-approach approximation used by LAMMPS becomes
less accurate when high-aspect ratio ellipsoids are used.
[Related commands:]
"pair_coeff"_pair_coeff.html, "fix nve/asphere"_fix_nve_asphere.html,
"compute temp/asphere"_compute_temp_asphere.html, "pair_style
gayberne"_pair_gayberne.html
[Default:] none
:line
:link(Everaers3)
[(Everaers)] Everaers and Ejtehadi, Phys Rev E, 67, 041710 (2003).
:link(Babadi)
[(Berardi)] Babadi, Ejtehadi, Everaers, J Comp Phys, 219, 770-779 (2006).
diff --git a/doc/src/pair_sdk.txt b/doc/src/pair_sdk.txt
index 1c348eaaf..360136a4e 100644
--- a/doc/src/pair_sdk.txt
+++ b/doc/src/pair_sdk.txt
@@ -1,156 +1,156 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style lj/sdk command :h3
pair_style lj/sdk/gpu command :h3
pair_style lj/sdk/kk command :h3
pair_style lj/sdk/omp command :h3
pair_style lj/sdk/coul/long command :h3
pair_style lj/sdk/coul/long/gpu command :h3
pair_style lj/sdk/coul/long/omp command :h3
[Syntax:]
pair_style style args :pre
style = {lj/sdk} or {lj/sdk/coul/long}
args = list of arguments for a particular style :ul
{lj/sdk} args = cutoff
cutoff = global cutoff for Lennard Jones interactions (distance units)
{lj/sdk/coul/long} args = cutoff (cutoff2)
cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
cutoff2 = global cutoff for Coulombic (optional) (distance units) :pre
[Examples:]
pair_style lj/sdk 2.5
pair_coeff 1 1 lj12_6 1 1.1 2.8 :pre
pair_style lj/sdk/coul/long 10.0
pair_style lj/sdk/coul/long 10.0 12.0
pair_coeff 1 1 lj9_6 100.0 3.5 12.0 :pre
[Description:]
The {lj/sdk} styles compute a 9/6, 12/4, or 12/6 Lennard-Jones potential,
given by
:c,image(Eqs/pair_cmm.jpg)
as required for the SDK Coarse-grained MD parametrization discussed in
"(Shinoda)"_#Shinoda3 and "(DeVane)"_#DeVane. Rc is the cutoff.
Style {lj/sdk/coul/long} computes the adds Coulombic interactions
with an additional damping factor applied so it can be used in
conjunction with the "kspace_style"_kspace_style.html command and
its {ewald} or {pppm} or {pppm/cg} option. The Coulombic cutoff
specified for this style means that pairwise interactions within
this distance are computed directly; interactions outside that
distance are computed in reciprocal space.
The following coefficients must be defined for each pair of atoms
types via the "pair_coeff"_pair_coeff.html command as in the examples
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands, or by mixing as described below:
cg_type (lj9_6, lj12_4, or lj12_6)
epsilon (energy units)
sigma (distance units)
cutoff1 (distance units) :ul
Note that sigma is defined in the LJ formula as the zero-crossing
distance for the potential, not as the energy minimum. The prefactors
are chosen so that the potential minimum is at -epsilon.
The latter 2 coefficients are optional. If not specified, the global
LJ and Coulombic cutoffs specified in the pair_style command are used.
If only one cutoff is specified, it is used as the cutoff for both LJ
and Coulombic interactions for this type pair. If both coefficients
are specified, they are used as the LJ and Coulombic cutoffs for this
type pair.
For {lj/sdk/coul/long} only the LJ cutoff can be specified since a
Coulombic cutoff cannot be specified for an individual I,J type pair.
All type pairs use the same global Coulombic cutoff specified in the
pair_style command.
:line
Styles with a {gpu}, {intel}, {kk}, {omp} or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP, and OPT packages respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, and rRESPA info]:
For atom type pairs I,J and I != J, the epsilon and sigma coefficients
and cutoff distance for all of the lj/sdk pair styles {cannot} be mixed,
since different pairs may have different exponents. So all parameters
for all pairs have to be specified explicitly through the "pair_coeff"
command. Defining then in a data file is also not supported, due to
limitations of that file format.
All of the lj/sdk pair styles support the
"pair_modify"_pair_modify.html shift option for the energy of the
Lennard-Jones portion of the pair interaction.
The {lj/sdk/coul/long} pair styles support the
"pair_modify"_pair_modify.html table option since they can tabulate
the short-range portion of the long-range Coulombic interaction.
All of the lj/sdk pair styles write their information to "binary
restart files"_restart.html, so pair_style and pair_coeff commands do
not need to be specified in an input script that reads a restart file.
The lj/sdk and lj/cut/coul/long pair styles do not support
the use of the {inner}, {middle}, and {outer} keywords of the "run_style
respa"_run_style.html command.
:line
[Restrictions:]
All of the lj/sdk pair styles are part of the USER-CGSDK package.
The {lj/sdk/coul/long} style also requires the KSPACE package to be
built (which is enabled by default). They are only enabled if LAMMPS
was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
[Related commands:]
"pair_coeff"_pair_coeff.html, "angle_style sdk"_angle_sdk.html
[Default:] none
:line
:link(Shinoda3)
[(Shinoda)] Shinoda, DeVane, Klein, Mol Sim, 33, 27 (2007).
:link(DeVane)
[(DeVane)] Shinoda, DeVane, Klein, Soft Matter, 4, 2453-2462 (2008).
diff --git a/doc/src/pair_soft.txt b/doc/src/pair_soft.txt
index ec1c06729..08fa88c47 100644
--- a/doc/src/pair_soft.txt
+++ b/doc/src/pair_soft.txt
@@ -1,136 +1,136 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style soft command :h3
pair_style soft/gpu command :h3
pair_style soft/omp command :h3
[Syntax:]
pair_style soft cutoff :pre
cutoff = global cutoff for soft interactions (distance units) :ul
[Examples:]
pair_style soft 1.0
pair_coeff * * 10.0
pair_coeff 1 1 10.0 3.0 :pre
pair_style soft 1.0
pair_coeff * * 0.0
variable prefactor equal ramp(0,30)
fix 1 all adapt 1 pair soft a * * v_prefactor :pre
[Description:]
Style {soft} computes pairwise interactions with the formula
:c,image(Eqs/pair_soft.jpg)
It is useful for pushing apart overlapping atoms, since it does not
blow up as r goes to 0. A is a pre-factor that can be made to vary in
time from the start to the end of the run (see discussion below),
e.g. to start with a very soft potential and slowly harden the
interactions over time. Rc is the cutoff. See the "fix
nve/limit"_fix_nve_limit.html command for another way to push apart
overlapping atoms.
The following coefficients must be defined for each pair of atom types
via the "pair_coeff"_pair_coeff.html command as in the examples above,
or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands, or by mixing as described below:
A (energy units)
cutoff (distance units) :ul
The last coefficient is optional. If not specified, the global soft
cutoff is used.
NOTE: The syntax for "pair_coeff"_pair_coeff.html with a single A
coeff is different in the current version of LAMMPS than in older
versions which took two values, Astart and Astop, to ramp between
them. This functionality is now available in a more general form
through the "fix adapt"_fix_adapt.html command, as explained below.
Note that if you use an old input script and specify Astart and Astop
without a cutoff, then LAMMPS will interpret that as A and a cutoff,
which is probably not what you want.
The "fix adapt"_fix_adapt.html command can be used to vary A for one
or more pair types over the course of a simulation, in which case
pair_coeff settings for A must still be specified, but will be
overridden. For example these commands will vary the prefactor A for
all pairwise interactions from 0.0 at the beginning to 30.0 at the end
of a run:
variable prefactor equal ramp(0,30)
fix 1 all adapt 1 pair soft a * * v_prefactor :pre
Note that a formula defined by an "equal-style variable"_variable.html
can use the current timestep, elapsed time in the current run, elapsed
time since the beginning of a series of runs, as well as access other
variables.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, the A coefficient and cutoff
distance for this pair style can be mixed. A is always mixed via a
{geometric} rule. The cutoff is mixed according to the pair_modify
mix value. The default mix value is {geometric}. See the
"pair_modify" command for details.
This pair style does not support the "pair_modify"_pair_modify.html
shift option, since the pair interaction goes to 0.0 at the cutoff.
The "pair_modify"_pair_modify.html table and tail options are not
relevant for this pair style.
This pair style writes its information to "binary restart
files"_restart.html, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.
This pair style can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. It does not support the
{inner}, {middle}, {outer} keywords.
:line
[Restrictions:] none
[Related commands:]
"pair_coeff"_pair_coeff.html, "fix nve/limit"_fix_nve_limit.html, "fix
adapt"_fix_adapt.html
[Default:] none
diff --git a/doc/src/pair_sw.txt b/doc/src/pair_sw.txt
index 6025b9b11..6ed8f0023 100644
--- a/doc/src/pair_sw.txt
+++ b/doc/src/pair_sw.txt
@@ -1,216 +1,216 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style sw command :h3
pair_style sw/gpu command :h3
pair_style sw/intel command :h3
pair_style sw/kk command :h3
pair_style sw/omp command :h3
[Syntax:]
pair_style sw :pre
[Examples:]
pair_style sw
pair_coeff * * si.sw Si
pair_coeff * * GaN.sw Ga N Ga :pre
[Description:]
The {sw} style computes a 3-body "Stillinger-Weber"_#Stillinger2
potential for the energy E of a system of atoms as
:c,image(Eqs/pair_sw.jpg)
where phi2 is a two-body term and phi3 is a three-body term. The
summations in the formula are over all neighbors J and K of atom I
within a cutoff distance = a*sigma.
Only a single pair_coeff command is used with the {sw} style which
specifies a Stillinger-Weber potential file with parameters for all
needed elements. These are mapped to LAMMPS atom types by specifying
N additional arguments after the filename in the pair_coeff command,
where N is the number of LAMMPS atom types:
filename
N element names = mapping of SW elements to atom types :ul
See the "pair_coeff"_pair_coeff.html doc page for alternate ways
to specify the path for the potential file.
As an example, imagine a file SiC.sw has Stillinger-Weber values for
Si and C. If your LAMMPS simulation has 4 atoms types and you want
the 1st 3 to be Si, and the 4th to be C, you would use the following
pair_coeff command:
pair_coeff * * SiC.sw Si Si Si C :pre
The 1st 2 arguments must be * * so as to span all LAMMPS atom types.
The first three Si arguments map LAMMPS atom types 1,2,3 to the Si
element in the SW file. The final C argument maps LAMMPS atom type 4
to the C element in the SW file. If a mapping value is specified as
NULL, the mapping is not performed. This can be used when a {sw}
potential is used as part of the {hybrid} pair style. The NULL values
are placeholders for atom types that will be used with other
potentials.
Stillinger-Weber files in the {potentials} directory of the LAMMPS
distribution have a ".sw" suffix. Lines that are not blank or
comments (starting with #) define parameters for a triplet of
elements. The parameters in a single entry correspond to the two-body
and three-body coefficients in the formula above:
element 1 (the center atom in a 3-body interaction)
element 2
element 3
epsilon (energy units)
sigma (distance units)
a
lambda
gamma
costheta0
A
B
p
q
tol :ul
The A, B, p, and q parameters are used only for two-body
interactions. The lambda and costheta0 parameters are used only for
three-body interactions. The epsilon, sigma and a parameters are used
for both two-body and three-body interactions. gamma is used only in the
three-body interactions, but is defined for pairs of atoms.
The non-annotated parameters are unitless.
LAMMPS introduces an additional performance-optimization parameter tol
that is used for both two-body and three-body interactions. In the
Stillinger-Weber potential, the interaction energies become negligibly
small at atomic separations substantially less than the theoretical
cutoff distances. LAMMPS therefore defines a virtual cutoff distance
based on a user defined tolerance tol. The use of the virtual cutoff
distance in constructing atom neighbor lists can significantly reduce
the neighbor list sizes and therefore the computational cost. LAMMPS
provides a {tol} value for each of the three-body entries so that they
can be separately controlled. If tol = 0.0, then the standard
Stillinger-Weber cutoff is used.
The Stillinger-Weber potential file must contain entries for all the
elements listed in the pair_coeff command. It can also contain
entries for additional elements not being used in a particular
simulation; LAMMPS ignores those entries.
For a single-element simulation, only a single entry is required
(e.g. SiSiSi). For a two-element simulation, the file must contain 8
entries (for SiSiSi, SiSiC, SiCSi, SiCC, CSiSi, CSiC, CCSi, CCC), that
specify SW parameters for all permutations of the two elements
interacting in three-body configurations. Thus for 3 elements, 27
entries would be required, etc.
As annotated above, the first element in the entry is the center atom
in a three-body interaction. Thus an entry for SiCC means a Si atom
with 2 C atoms as neighbors. The parameter values used for the
two-body interaction come from the entry where the 2nd and 3rd
elements are the same. Thus the two-body parameters for Si
interacting with C, comes from the SiCC entry. The three-body
parameters can in principle be specific to the three elements of the
configuration. In the literature, however, the three-body parameters
are usually defined by simple formulas involving two sets of pair-wise
parameters, corresponding to the ij and ik pairs, where i is the
center atom. The user must ensure that the correct combining rule is
used to calculate the values of the threebody parameters for
alloys. Note also that the function phi3 contains two exponential
screening factors with parameter values from the ij pair and ik
pairs. So phi3 for a C atom bonded to a Si atom and a second C atom
will depend on the three-body parameters for the CSiC entry, and also
on the two-body parameters for the CCC and CSiSi entries. Since the
order of the two neighbors is arbitrary, the threebody parameters for
entries CSiC and CCSi should be the same. Similarly, the two-body
parameters for entries SiCC and CSiSi should also be the same. The
parameters used only for two-body interactions (A, B, p, and q) in
entries whose 2nd and 3rd element are different (e.g. SiCSi) are not
used for anything and can be set to 0.0 if desired.
This is also true for the parameters in phi3 that are
taken from the ij and ik pairs (sigma, a, gamma)
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
When using the USER-INTEL package with this style, there is an
additional 5 to 10 percent performance improvement when the
Stillinger-Weber parameters p and q are set to 4 and 0 respectively.
These parameters are common for modeling silicon and water.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, where types I and J correspond to
two different element types, mixing is performed by LAMMPS as
described above from values in the potential file.
This pair style does not support the "pair_modify"_pair_modify.html
shift, table, and tail options.
This pair style does not write its information to "binary restart
files"_restart.html, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.
This pair style can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. It does not support the
{inner}, {middle}, {outer} keywords.
:line
[Restrictions:]
This pair style is part of the MANYBODY package. It is only enabled
if LAMMPS was built with that package. See
the "Making LAMMPS"_Section_start.html#start_3 section for more info.
This pair style requires the "newton"_newton.html setting to be "on"
for pair interactions.
The Stillinger-Weber potential files provided with LAMMPS (see the
potentials directory) are parameterized for metal "units"_units.html.
You can use the SW potential with any LAMMPS units, but you would need
to create your own SW potential file with coefficients listed in the
appropriate units if your simulation doesn't use "metal" units.
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
:line
:link(Stillinger2)
[(Stillinger)] Stillinger and Weber, Phys Rev B, 31, 5262 (1985).
diff --git a/doc/src/pair_table.txt b/doc/src/pair_table.txt
index 01c577cd9..b99491b47 100644
--- a/doc/src/pair_table.txt
+++ b/doc/src/pair_table.txt
@@ -1,272 +1,272 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style table command :h3
pair_style table/gpu command :h3
pair_style table/kk command :h3
pair_style table/omp command :h3
[Syntax:]
pair_style table style N keyword ... :pre
style = {lookup} or {linear} or {spline} or {bitmap} = method of interpolation
N = use N values in {lookup}, {linear}, {spline} tables
N = use 2^N values in {bitmap} tables
zero or more keywords may be appended
keyword = {ewald} or {pppm} or {msm} or {dispersion} or {tip4p} :ul
[Examples:]
pair_style table linear 1000
pair_style table linear 1000 pppm
pair_style table bitmap 12
pair_coeff * 3 morse.table ENTRY1
pair_coeff * 3 morse.table ENTRY1 7.0 :pre
[Description:]
Style {table} creates interpolation tables from potential energy and
force values listed in a file(s) as a function of distance. When
performing dynamics or minimization, the interpolation tables are used
to evaluate energy and forces for pairwise interactions between
particles, similar to how analytic formulas are used for other pair
styles.
The interpolation tables are created as a pre-computation by fitting
cubic splines to the file values and interpolating energy and force
values at each of {N} distances. During a simulation, the tables are
used to interpolate energy and force values as needed for each pair of
particles separated by a distance {R}. The interpolation is done in
one of 4 styles: {lookup}, {linear}, {spline}, or {bitmap}.
For the {lookup} style, the distance {R} is used to find the nearest
table entry, which is the energy or force.
For the {linear} style, the distance {R} is used to find the 2
surrounding table values from which an energy or force is computed by
linear interpolation.
For the {spline} style, a cubic spline coefficients are computed and
stored for each of the {N} values in the table, one set of splines for
energy, another for force. Note that these splines are different than
the ones used to pre-compute the {N} values. Those splines were fit
to the {Nfile} values in the tabulated file, where often {Nfile} <
{N}. The distance {R} is used to find the appropriate set of spline
coefficients which are used to evaluate a cubic polynomial which
computes the energy or force.
For the {bitmap} style, the specified {N} is used to create
interpolation tables that are 2^N in length. The distance {R} is used
to index into the table via a fast bit-mapping technique due to
"(Wolff)"_#Wolff2, and a linear interpolation is performed between
adjacent table values.
The following coefficients must be defined for each pair of atoms
types via the "pair_coeff"_pair_coeff.html command as in the examples
above.
filename
keyword
cutoff (distance units) :ul
The filename specifies a file containing tabulated energy and force
values. The keyword specifies a section of the file. The cutoff is
an optional coefficient. If not specified, the outer cutoff in the
table itself (see below) will be used to build an interpolation table
that extend to the largest tabulated distance. If specified, only
file values up to the cutoff are used to create the interpolation
table. The format of this file is described below.
If your tabulated potential(s) are designed to be used as the
short-range part of one of the long-range solvers specified by the
"kspace_style"_kspace_style.html command, then you must use one or
more of the optional keywords listed above for the pair_style command.
These are {ewald} or {pppm} or {msm} or {dispersion} or {tip4p}. This
is so LAMMPS can insure the short-range potential and long-range
solver are compatible with each other, as it does for other
short-range pair styles, such as "pair_style
lj/cut/coul/long"_pair_lj.html. Note that it is up to you to insure
the tabulated values for each pair of atom types has the correct
functional form to be compatible with the matching long-range solver.
:line
Here are some guidelines for using the pair_style table command to
best effect:
Vary the number of table points; you may need to use more than you think
to get good resolution. :ulb,l
Always use the "pair_write"_pair_write.html command to produce a plot
of what the final interpolated potential looks like. This can show up
interpolation "features" you may not like. :l
Start with the linear style; it's the style least likely to have problems. :l
Use {N} in the pair_style command equal to the "N" in the tabulation
file, and use the "RSQ" or "BITMAP" parameter, so additional interpolation
is not needed. See discussion below. :l
Make sure that your tabulated forces and tabulated energies are
consistent (dE/dr = -F) over the entire range of r values. LAMMPS
will warn if this is not the case. :l
Use as large an inner cutoff as possible. This avoids fitting splines
to very steep parts of the potential. :l
:ule
:line
The format of a tabulated file is a series of one or more sections,
defined as follows (without the parenthesized comments):
# Morse potential for Fe (one or more comment or blank lines) :pre
MORSE_FE (keyword is first text on line)
N 500 R 1.0 10.0 (N, R, RSQ, BITMAP, FPRIME parameters)
(blank)
1 1.0 25.5 102.34 (index, r, energy, force)
2 1.02 23.4 98.5
...
500 10.0 0.001 0.003 :pre
A section begins with a non-blank line whose 1st character is not a
"#"; blank lines or lines starting with "#" can be used as comments
between sections. The first line begins with a keyword which
identifies the section. The line can contain additional text, but the
initial text must match the argument specified in the pair_coeff
command. The next line lists (in any order) one or more parameters
for the table. Each parameter is a keyword followed by one or more
numeric values.
The parameter "N" is required and its value is the number of table
entries that follow. Note that this may be different than the {N}
specified in the "pair_style table"_pair_style.html command. Let
Ntable = {N} in the pair_style command, and Nfile = "N" in the
tabulated file. What LAMMPS does is a preliminary interpolation by
creating splines using the Nfile tabulated values as nodal points. It
uses these to interpolate energy and force values at Ntable different
points. The resulting tables of length Ntable are then used as
described above, when computing energy and force for individual pair
distances. This means that if you want the interpolation tables of
length Ntable to match exactly what is in the tabulated file (with
effectively no preliminary interpolation), you should set Ntable =
Nfile, and use the "RSQ" or "BITMAP" parameter. This is because the
internal table abscissa is always RSQ (separation distance squared),
for efficient lookup.
All other parameters are optional. If "R" or "RSQ" or "BITMAP" does
not appear, then the distances in each line of the table are used
as-is to perform spline interpolation. In this case, the table values
can be spaced in {r} uniformly or however you wish to position table
values in regions of large gradients.
If used, the parameters "R" or "RSQ" are followed by 2 values {rlo}
and {rhi}. If specified, the distance associated with each energy and
force value is computed from these 2 values (at high accuracy), rather
than using the (low-accuracy) value listed in each line of the table.
The distance values in the table file are ignored in this case.
For "R", distances uniformly spaced between {rlo} and {rhi} are
computed; for "RSQ", squared distances uniformly spaced between
{rlo*rlo} and {rhi*rhi} are computed.
NOTE: If you use "R" or "RSQ", the tabulated distance values in the
file are effectively ignored, and replaced by new values as described
in the previous paragraph. If the distance value in the table is not
very close to the new value (i.e. round-off difference), then you will
be assigning energy/force values to a different distance, which is
probably not what you want. LAMMPS will warn if this is occurring.
If used, the parameter "BITMAP" is also followed by 2 values {rlo} and
{rhi}. These values, along with the "N" value determine the ordering
of the N lines that follow and what distance is associated with each.
This ordering is complex, so it is not documented here, since this
file is typically produced by the "pair_write"_pair_write.html command
with its {bitmap} option. When the table is in BITMAP format, the "N"
parameter in the file must be equal to 2^M where M is the value
specified in the pair_style command. Also, a cutoff parameter cannot
be used as an optional 3rd argument in the pair_coeff command; the
entire table extent as specified in the file must be used.
If used, the parameter "FPRIME" is followed by 2 values {fplo} and
{fphi} which are the derivative of the force at the innermost and
outermost distances listed in the table. These values are needed by
the spline construction routines. If not specified by the "FPRIME"
parameter, they are estimated (less accurately) by the first 2 and
last 2 force values in the table. This parameter is not used by
BITMAP tables.
Following a blank line, the next N lines list the tabulated values.
On each line, the 1st value is the index from 1 to N, the 2nd value is
r (in distance units), the 3rd value is the energy (in energy units),
and the 4th is the force (in force units). The r values must increase
from one line to the next (unless the BITMAP parameter is specified).
Note that one file can contain many sections, each with a tabulated
potential. LAMMPS reads the file section by section until it finds
one that matches the specified keyword.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
This pair style does not support mixing. Thus, coefficients for all
I,J pairs must be specified explicitly.
The "pair_modify"_pair_modify.html shift, table, and tail options are
not relevant for this pair style.
This pair style writes the settings for the "pair_style table" command
to "binary restart files"_restart.html, so a pair_style command does
not need to specified in an input script that reads a restart file.
However, the coefficient information is not stored in the restart
file, since it is tabulated in the potential files. Thus, pair_coeff
commands do need to be specified in the restart input script.
This pair style can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. It does not support the
{inner}, {middle}, {outer} keywords.
:line
[Restrictions:] none
[Related commands:]
"pair_coeff"_pair_coeff.html, "pair_write"_pair_write.html
[Default:] none
:line
:link(Wolff2)
[(Wolff)] Wolff and Rudd, Comp Phys Comm, 120, 200-32 (1999).
diff --git a/doc/src/pair_tersoff.txt b/doc/src/pair_tersoff.txt
index 23a20ad0f..918e88992 100644
--- a/doc/src/pair_tersoff.txt
+++ b/doc/src/pair_tersoff.txt
@@ -1,253 +1,253 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style tersoff command :h3
pair_style tersoff/table command :h3
pair_style tersoff/gpu :h3
pair_style tersoff/intel :h3
pair_style tersoff/kk :h3
pair_style tersoff/omp :h3
pair_style tersoff/table/omp command :h3
[Syntax:]
pair_style style :pre
style = {tersoff} or {tersoff/table} or {tersoff/gpu} or {tersoff/omp} or {tersoff/table/omp} :ul
[Examples:]
pair_style tersoff
pair_coeff * * Si.tersoff Si
pair_coeff * * SiC.tersoff Si C Si :pre
pair_style tersoff/table
pair_coeff * * SiCGe.tersoff Si(D) :pre
[Description:]
The {tersoff} style computes a 3-body Tersoff potential
"(Tersoff_1)"_#Tersoff_11 for the energy E of a system of atoms as
:c,image(Eqs/pair_tersoff_1.jpg)
where f_R is a two-body term and f_A includes three-body interactions.
The summations in the formula are over all neighbors J and K of atom I
within a cutoff distance = R + D.
The {tersoff/table} style uses tabulated forms for the two-body,
environment and angular functions. Linear interpolation is performed
between adjacent table entries. The table length is chosen to be
accurate within 10^-6 with respect to the {tersoff} style energy.
The {tersoff/table} should give better performance in terms of speed.
Only a single pair_coeff command is used with the {tersoff} style
which specifies a Tersoff potential file with parameters for all
needed elements. These are mapped to LAMMPS atom types by specifying
N additional arguments after the filename in the pair_coeff command,
where N is the number of LAMMPS atom types:
filename
N element names = mapping of Tersoff elements to atom types :ul
See the "pair_coeff"_pair_coeff.html doc page for alternate ways
to specify the path for the potential file.
As an example, imagine the SiC.tersoff file has Tersoff values for Si
and C. If your LAMMPS simulation has 4 atoms types and you want the
1st 3 to be Si, and the 4th to be C, you would use the following
pair_coeff command:
pair_coeff * * SiC.tersoff Si Si Si C :pre
The 1st 2 arguments must be * * so as to span all LAMMPS atom types.
The first three Si arguments map LAMMPS atom types 1,2,3 to the Si
element in the Tersoff file. The final C argument maps LAMMPS atom
type 4 to the C element in the Tersoff file. If a mapping value is
specified as NULL, the mapping is not performed. This can be used
when a {tersoff} potential is used as part of the {hybrid} pair style.
The NULL values are placeholders for atom types that will be used with
other potentials.
Tersoff files in the {potentials} directory of the LAMMPS distribution
have a ".tersoff" suffix. Lines that are not blank or comments
(starting with #) define parameters for a triplet of elements. The
parameters in a single entry correspond to coefficients in the formula
above:
element 1 (the center atom in a 3-body interaction)
element 2 (the atom bonded to the center atom)
element 3 (the atom influencing the 1-2 bond in a bond-order sense)
m
gamma
lambda3 (1/distance units)
c
d
costheta0 (can be a value < -1 or > 1)
n
beta
lambda2 (1/distance units)
B (energy units)
R (distance units)
D (distance units)
lambda1 (1/distance units)
A (energy units) :ul
The n, beta, lambda2, B, lambda1, and A parameters are only used for
two-body interactions. The m, gamma, lambda3, c, d, and costheta0
parameters are only used for three-body interactions. The R and D
parameters are used for both two-body and three-body interactions. The
non-annotated parameters are unitless. The value of m must be 3 or 1.
The Tersoff potential file must contain entries for all the elements
listed in the pair_coeff command. It can also contain entries for
additional elements not being used in a particular simulation; LAMMPS
ignores those entries.
For a single-element simulation, only a single entry is required
(e.g. SiSiSi). For a two-element simulation, the file must contain 8
entries (for SiSiSi, SiSiC, SiCSi, SiCC, CSiSi, CSiC, CCSi, CCC), that
specify Tersoff parameters for all permutations of the two elements
interacting in three-body configurations. Thus for 3 elements, 27
entries would be required, etc.
As annotated above, the first element in the entry is the center atom
in a three-body interaction and it is bonded to the 2nd atom and the
bond is influenced by the 3rd atom. Thus an entry for SiCC means Si
bonded to a C with another C atom influencing the bond. Thus
three-body parameters for SiCSi and SiSiC entries will not, in
general, be the same. The parameters used for the two-body
interaction come from the entry where the 2nd element is repeated.
Thus the two-body parameters for Si interacting with C, comes from the
SiCC entry.
The parameters used for a particular
three-body interaction come from the entry with the corresponding
three elements. The parameters used only for two-body interactions
(n, beta, lambda2, B, lambda1, and A) in entries whose 2nd and 3rd
element are different (e.g. SiCSi) are not used for anything and can
be set to 0.0 if desired.
Note that the twobody parameters in entries such as SiCC and CSiSi
are often the same, due to the common use of symmetric mixing rules,
but this is not always the case. For example, the beta and n parameters in
Tersoff_2 "(Tersoff_2)"_#Tersoff_21 are not symmetric.
We chose the above form so as to enable users to define all commonly
used variants of the Tersoff potential. In particular, our form
reduces to the original Tersoff form when m = 3 and gamma = 1, while
it reduces to the form of "Albe et al."_#Albe when beta = 1 and m = 1.
Note that in the current Tersoff implementation in LAMMPS, m must be
specified as either 3 or 1. Tersoff used a slightly different but
equivalent form for alloys, which we will refer to as Tersoff_2
potential "(Tersoff_2)"_#Tersoff_21. The {tersoff/table} style implements
Tersoff_2 parameterization only.
LAMMPS parameter values for Tersoff_2 can be obtained as follows:
gamma_ijk = omega_ik, lambda3 = 0 and the value of
m has no effect. The parameters for species i and j can be calculated
using the Tersoff_2 mixing rules:
:c,image(Eqs/pair_tersoff_2.jpg)
Tersoff_2 parameters R and S must be converted to the LAMMPS
parameters R and D (R is different in both forms), using the following
relations: R=(R'+S')/2 and D=(S'-R')/2, where the primes indicate the
Tersoff_2 parameters.
In the potentials directory, the file SiCGe.tersoff provides the
LAMMPS parameters for Tersoff's various versions of Si, as well as his
alloy parameters for Si, C, and Ge. This file can be used for pure Si,
(three different versions), pure C, pure Ge, binary SiC, and binary
SiGe. LAMMPS will generate an error if this file is used with any
combination involving C and Ge, since there are no entries for the GeC
interactions (Tersoff did not publish parameters for this
cross-interaction.) Tersoff files are also provided for the SiC alloy
(SiC.tersoff) and the GaN (GaN.tersoff) alloys.
Many thanks to Rutuparna Narulkar, David Farrell, and Xiaowang Zhou
for helping clarify how Tersoff parameters for alloys have been
defined in various papers.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, where types I and J correspond to
two different element types, mixing is performed by LAMMPS as
described above from values in the potential file.
This pair style does not support the "pair_modify"_pair_modify.html
shift, table, and tail options.
This pair style does not write its information to "binary restart
files"_restart.html, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.
This pair style can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. It does not support the
{inner}, {middle}, {outer} keywords.
:line
[Restrictions:]
This pair style is part of the MANYBODY package. It is only enabled
if LAMMPS was built with that package. See
the "Making LAMMPS"_Section_start.html#start_3 section for more info.
This pair style requires the "newton"_newton.html setting to be "on"
for pair interactions.
The Tersoff potential files provided with LAMMPS (see the potentials
directory) are parameterized for metal "units"_units.html. You can
use the Tersoff potential with any LAMMPS units, but you would need to
create your own Tersoff potential file with coefficients listed in the
appropriate units if your simulation doesn't use "metal" units.
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
:line
:link(Tersoff_11)
[(Tersoff_1)] J. Tersoff, Phys Rev B, 37, 6991 (1988).
:link(Albe)
[(Albe)] J. Nord, K. Albe, P. Erhart, and K. Nordlund, J. Phys.:
Condens. Matter, 15, 5649(2003).
:link(Tersoff_21)
[(Tersoff_2)] J. Tersoff, Phys Rev B, 39, 5566 (1989); errata (PRB 41, 3248)
diff --git a/doc/src/pair_tersoff_mod.txt b/doc/src/pair_tersoff_mod.txt
index ff703063b..e0c2b5a5c 100644
--- a/doc/src/pair_tersoff_mod.txt
+++ b/doc/src/pair_tersoff_mod.txt
@@ -1,207 +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,Section_commands.html#comm)
:line
pair_style tersoff/mod command :h3
pair_style tersoff/mod/c command :h3
pair_style tersoff/mod/gpu command :h3
pair_style tersoff/mod/kk command :h3
pair_style tersoff/mod/omp command :h3
pair_style tersoff/mod/c/omp command :h3
[Syntax:]
pair_style tersoff/mod :pre
pair_style tersoff/mod/c :pre
[Examples:]
pair_style tersoff/mod
pair_coeff * * Si.tersoff.mod Si Si :pre
pair_style tersoff/mod/c
pair_coeff * * Si.tersoff.modc Si Si :pre
[Description:]
The {tersoff/mod} and {tersoff/mod/c} styles computes a bond-order type
interatomic potential "(Kumagai)"_#Kumagai based on a 3-body Tersoff
potential "(Tersoff_1)"_#Tersoff_12, "(Tersoff_2)"_#Tersoff_22 with
modified cutoff function and angular-dependent term, giving the energy
E of a system of atoms as
:c,image(Eqs/pair_tersoff_mod.jpg)
where f_R is a two-body term and f_A includes three-body interactions.
The summations in the formula are over all neighbors J and K of atom I
within a cutoff distance = R + D.
The {tersoff/mod/c} style differs from {tersoff/mod} only in the
formulation of the V_ij term, where it contains an additional c0 term.
:c,image(Eqs/pair_tersoff_mod_c.jpg)
The modified cutoff function f_C proposed by "(Murty)"_#Murty and
having a continuous second-order differential is employed. The
angular-dependent term g(theta) was modified to increase the
flexibility of the potential.
The {tersoff/mod} potential is fitted to both the elastic constants
and melting point by employing the modified Tersoff potential function
form in which the angular-dependent term is improved. The model
performs extremely well in describing the crystalline, liquid, and
amorphous phases "(Schelling)"_#Schelling.
Only a single pair_coeff command is used with the {tersoff/mod} style
which specifies a Tersoff/MOD potential file with parameters for all
needed elements. These are mapped to LAMMPS atom types by specifying
N additional arguments after the filename in the pair_coeff command,
where N is the number of LAMMPS atom types:
filename
N element names = mapping of Tersoff/MOD elements to atom types :ul
As an example, imagine the Si.tersoff_mod file has Tersoff values for Si.
If your LAMMPS simulation has 3 Si atoms types, you would use the following
pair_coeff command:
pair_coeff * * Si.tersoff_mod Si Si Si :pre
The 1st 2 arguments must be * * so as to span all LAMMPS atom types.
The three Si arguments map LAMMPS atom types 1,2,3 to the Si element
in the Tersoff/MOD file. If a mapping value is specified as NULL, the
mapping is not performed. This can be used when a {tersoff/mod}
potential is used as part of the {hybrid} pair style. The NULL values
are placeholders for atom types that will be used with other
potentials.
Tersoff/MOD file in the {potentials} directory of the LAMMPS
distribution have a ".tersoff.mod" suffix. Potential files for the
{tersoff/mod/c} style have the suffix ".tersoff.modc". Lines that are
not blank or comments (starting with #) define parameters for a triplet
of elements. The parameters in a single entry correspond to
coefficients in the formulae above:
element 1 (the center atom in a 3-body interaction)
element 2 (the atom bonded to the center atom)
element 3 (the atom influencing the 1-2 bond in a bond-order sense)
beta
alpha
h
eta
beta_ters = 1 (dummy parameter)
lambda2 (1/distance units)
B (energy units)
R (distance units)
D (distance units)
lambda1 (1/distance units)
A (energy units)
n
c1
c2
c3
c4
c5
c0 (energy units, tersoff/mod/c only):ul
The n, eta, lambda2, B, lambda1, and A parameters are only used for
two-body interactions. The beta, alpha, c1, c2, c3, c4, c5, h
parameters are only used for three-body interactions. The R and D
parameters are used for both two-body and three-body interactions.
The c0 term applies to {tersoff/mod/c} only. The non-annotated
parameters are unitless.
The Tersoff/MOD potential file must contain entries for all the elements
listed in the pair_coeff command. It can also contain entries for
additional elements not being used in a particular simulation; LAMMPS
ignores those entries.
For a single-element simulation, only a single entry is required
(e.g. SiSiSi). As annotated above, the first element in the entry is
the center atom in a three-body interaction and it is bonded to the
2nd atom and the bond is influenced by the 3rd atom. Thus an entry
for SiSiSi means Si bonded to a Si with another Si atom influencing the bond.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
This pair style does not support the "pair_modify"_pair_modify.html
shift, table, and tail options.
This pair style does not write its information to "binary restart
files"_restart.html, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.
This pair style can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. It does not support the
{inner}, {middle}, {outer} keywords.
:line
[Restrictions:]
This pair style is part of the MANYBODY package. It is only enabled
if LAMMPS was built with that package. See
the "Making LAMMPS"_Section_start.html#start_3 section for more info.
This pair style requires the "newton"_newton.html setting to be "on"
for pair interactions.
The Tersoff/MOD potential files provided with LAMMPS (see the potentials
directory) are parameterized for metal "units"_units.html. You can
use the Tersoff/MOD potential with any LAMMPS units, but you would need to
create your own Tersoff/MOD potential file with coefficients listed in the
appropriate units if your simulation doesn't use "metal" units.
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
:line
:link(Kumagai)
[(Kumagai)] T. Kumagai, S. Izumi, S. Hara, S. Sakai,
Comp. Mat. Science, 39, 457 (2007).
:link(Tersoff_12)
[(Tersoff_1)] J. Tersoff, Phys Rev B, 37, 6991 (1988).
:link(Tersoff_22)
[(Tersoff_2)] J. Tersoff, Phys Rev B, 38, 9902 (1988).
:link(Murty)
[(Murty)] M.V.R. Murty, H.A. Atwater, Phys Rev B, 51, 4889 (1995).
:link(Schelling)
[(Schelling)] Patrick K. Schelling, Comp. Mat. Science, 44, 274 (2008).
diff --git a/doc/src/pair_tersoff_zbl.txt b/doc/src/pair_tersoff_zbl.txt
index 18e54749a..21d57e4e8 100644
--- a/doc/src/pair_tersoff_zbl.txt
+++ b/doc/src/pair_tersoff_zbl.txt
@@ -1,268 +1,268 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style tersoff/zbl command :h3
pair_style tersoff/zbl/gpu command :h3
pair_style tersoff/zbl/kk command :h3
pair_style tersoff/zbl/omp command :h3
[Syntax:]
pair_style tersoff/zbl :pre
[Examples:]
pair_style tersoff/zbl
pair_coeff * * SiC.tersoff.zbl Si C Si :pre
[Description:]
The {tersoff/zbl} style computes a 3-body Tersoff potential
"(Tersoff_1)"_#zbl-Tersoff_1 with a close-separation pairwise modification
based on a Coulomb potential and the Ziegler-Biersack-Littmark
universal screening function "(ZBL)"_#zbl-ZBL, giving the energy E of a
system of atoms as
:c,image(Eqs/pair_tersoff_zbl.jpg)
The f_F term is a fermi-like function used to smoothly connect the ZBL
repulsive potential with the Tersoff potential. There are 2
parameters used to adjust it: A_F and r_C. A_F controls how "sharp"
the transition is between the two, and r_C is essentially the cutoff
for the ZBL potential.
For the ZBL portion, there are two terms. The first is the Coulomb
repulsive term, with Z1, Z2 as the number of protons in each nucleus,
e as the electron charge (1 for metal and real units) and epsilon0 as
the permittivity of vacuum. The second part is the ZBL universal
screening function, with a0 being the Bohr radius (typically 0.529
Angstroms), and the remainder of the coefficients provided by the
original paper. This screening function should be applicable to most
systems. However, it is only accurate for small separations
(i.e. less than 1 Angstrom).
For the Tersoff portion, f_R is a two-body term and f_A includes
three-body interactions. The summations in the formula are over all
neighbors J and K of atom I within a cutoff distance = R + D.
Only a single pair_coeff command is used with the {tersoff/zbl} style
which specifies a Tersoff/ZBL potential file with parameters for all
needed elements. These are mapped to LAMMPS atom types by specifying
N additional arguments after the filename in the pair_coeff command,
where N is the number of LAMMPS atom types:
filename
N element names = mapping of Tersoff/ZBL elements to atom types :ul
See the "pair_coeff"_pair_coeff.html doc page for alternate ways
to specify the path for the potential file.
As an example, imagine the SiC.tersoff.zbl file has Tersoff/ZBL values
for Si and C. If your LAMMPS simulation has 4 atoms types and you
want the 1st 3 to be Si, and the 4th to be C, you would use the
following pair_coeff command:
pair_coeff * * SiC.tersoff Si Si Si C :pre
The 1st 2 arguments must be * * so as to span all LAMMPS atom types.
The first three Si arguments map LAMMPS atom types 1,2,3 to the Si
element in the Tersoff/ZBL file. The final C argument maps LAMMPS
atom type 4 to the C element in the Tersoff/ZBL file. If a mapping
value is specified as NULL, the mapping is not performed. This can be
used when a {tersoff/zbl} potential is used as part of the {hybrid}
pair style. The NULL values are placeholders for atom types that will
be used with other potentials.
Tersoff/ZBL files in the {potentials} directory of the LAMMPS
distribution have a ".tersoff.zbl" suffix. Lines that are not blank
or comments (starting with #) define parameters for a triplet of
elements. The parameters in a single entry correspond to coefficients
in the formula above:
element 1 (the center atom in a 3-body interaction)
element 2 (the atom bonded to the center atom)
element 3 (the atom influencing the 1-2 bond in a bond-order sense)
m
gamma
lambda3 (1/distance units)
c
d
costheta0 (can be a value < -1 or > 1)
n
beta
lambda2 (1/distance units)
B (energy units)
R (distance units)
D (distance units)
lambda1 (1/distance units)
A (energy units)
Z_i
Z_j
ZBLcut (distance units)
ZBLexpscale (1/distance units) :ul
The n, beta, lambda2, B, lambda1, and A parameters are only used for
two-body interactions. The m, gamma, lambda3, c, d, and costheta0
parameters are only used for three-body interactions. The R and D
parameters are used for both two-body and three-body interactions. The
Z_i,Z_j, ZBLcut, ZBLexpscale parameters are used in the ZBL repulsive
portion of the potential and in the Fermi-like function. The
non-annotated parameters are unitless. The value of m must be 3 or 1.
The Tersoff/ZBL potential file must contain entries for all the
elements listed in the pair_coeff command. It can also contain
entries for additional elements not being used in a particular
simulation; LAMMPS ignores those entries.
For a single-element simulation, only a single entry is required
(e.g. SiSiSi). For a two-element simulation, the file must contain 8
entries (for SiSiSi, SiSiC, SiCSi, SiCC, CSiSi, CSiC, CCSi, CCC), that
specify Tersoff parameters for all permutations of the two elements
interacting in three-body configurations. Thus for 3 elements, 27
entries would be required, etc.
As annotated above, the first element in the entry is the center atom
in a three-body interaction and it is bonded to the 2nd atom and the
bond is influenced by the 3rd atom. Thus an entry for SiCC means Si
bonded to a C with another C atom influencing the bond. Thus
three-body parameters for SiCSi and SiSiC entries will not, in
general, be the same. The parameters used for the two-body
interaction come from the entry where the 2nd element is repeated.
Thus the two-body parameters for Si interacting with C, comes from the
SiCC entry.
The parameters used for a particular
three-body interaction come from the entry with the corresponding
three elements. The parameters used only for two-body interactions
(n, beta, lambda2, B, lambda1, and A) in entries whose 2nd and 3rd
element are different (e.g. SiCSi) are not used for anything and can
be set to 0.0 if desired.
Note that the twobody parameters in entries such as SiCC and CSiSi
are often the same, due to the common use of symmetric mixing rules,
but this is not always the case. For example, the beta and n parameters in
Tersoff_2 "(Tersoff_2)"_#zbl-Tersoff_2 are not symmetric.
We chose the above form so as to enable users to define all commonly
used variants of the Tersoff portion of the potential. In particular,
our form reduces to the original Tersoff form when m = 3 and gamma =
1, while it reduces to the form of "Albe et al."_#zbl-Albe when beta = 1
and m = 1. Note that in the current Tersoff implementation in LAMMPS,
m must be specified as either 3 or 1. Tersoff used a slightly
different but equivalent form for alloys, which we will refer to as
Tersoff_2 potential "(Tersoff_2)"_#zbl-Tersoff_2.
LAMMPS parameter values for Tersoff_2 can be obtained as follows:
gamma = omega_ijk, lambda3 = 0 and the value of
m has no effect. The parameters for species i and j can be calculated
using the Tersoff_2 mixing rules:
:c,image(Eqs/pair_tersoff_2.jpg)
Tersoff_2 parameters R and S must be converted to the LAMMPS
parameters R and D (R is different in both forms), using the following
relations: R=(R'+S')/2 and D=(S'-R')/2, where the primes indicate the
Tersoff_2 parameters.
In the potentials directory, the file SiCGe.tersoff provides the
LAMMPS parameters for Tersoff's various versions of Si, as well as his
alloy parameters for Si, C, and Ge. This file can be used for pure Si,
(three different versions), pure C, pure Ge, binary SiC, and binary
SiGe. LAMMPS will generate an error if this file is used with any
combination involving C and Ge, since there are no entries for the GeC
interactions (Tersoff did not publish parameters for this
cross-interaction.) Tersoff files are also provided for the SiC alloy
(SiC.tersoff) and the GaN (GaN.tersoff) alloys.
Many thanks to Rutuparna Narulkar, David Farrell, and Xiaowang Zhou
for helping clarify how Tersoff parameters for alloys have been
defined in various papers. Also thanks to Ram Devanathan for
providing the base ZBL implementation.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, where types I and J correspond to
two different element types, mixing is performed by LAMMPS as
described above from values in the potential file.
This pair style does not support the "pair_modify"_pair_modify.html
shift, table, and tail options.
This pair style does not write its information to "binary restart
files"_restart.html, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.
This pair style can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. It does not support the
{inner}, {middle}, {outer} keywords.
:line
[Restrictions:]
This pair style is part of the MANYBODY package. It is only enabled
if LAMMPS was built with that package. See
the "Making LAMMPS"_Section_start.html#start_3 section for more info.
This pair style requires the "newton"_newton.html setting to be "on"
for pair interactions.
The Tersoff/ZBL potential files provided with LAMMPS (see the
potentials directory) are parameterized for metal "units"_units.html.
You can use the Tersoff potential with any LAMMPS units, but you would
need to create your own Tersoff potential file with coefficients
listed in the appropriate units if your simulation doesn't use "metal"
units.
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
:line
:link(zbl-Tersoff_1)
[(Tersoff_1)] J. Tersoff, Phys Rev B, 37, 6991 (1988).
:link(zbl-ZBL)
[(ZBL)] J.F. Ziegler, J.P. Biersack, U. Littmark, 'Stopping and Ranges
of Ions in Matter' Vol 1, 1985, Pergamon Press.
:link(zbl-Albe)
[(Albe)] J. Nord, K. Albe, P. Erhart and K. Nordlund, J. Phys.:
Condens. Matter, 15, 5649(2003).
:link(zbl-Tersoff_2)
[(Tersoff_2)] J. Tersoff, Phys Rev B, 39, 5566 (1989); errata (PRB 41, 3248)
diff --git a/doc/src/pair_thole.txt b/doc/src/pair_thole.txt
index 61ca0b5c3..41a4059ce 100644
--- a/doc/src/pair_thole.txt
+++ b/doc/src/pair_thole.txt
@@ -1,193 +1,193 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style thole command :h3
pair_style lj/cut/thole/long command :h3
pair_style lj/cut/thole/long/omp command :h3
[Syntax:]
pair_style style args :pre
style = {thole} or {lj/cut/thole/long} or {lj/cut/thole/long/omp}
args = list of arguments for a particular style :ul
{thole} args = damp cutoff
damp = global damping parameter
cutoff = global cutoff (distance units)
{lj/cut/thole/long} or {lj/cut/thole/long/omp} args = damp cutoff (cutoff2)
damp = global damping parameter
cutoff = global cutoff for LJ (and Thole if only 1 arg) (distance units)
cutoff2 = global cutoff for Thole (optional) (distance units) :pre
[Examples:]
pair_style hybrid/overlay ... thole 2.6 12.0
pair_coeff 1 1 thole 1.0
pair_coeff 1 2 thole 1.0 2.6 10.0
pair_coeff * 2 thole 1.0 2.6 :pre
pair_style lj/cut/thole/long 2.6 12.0 :pre
[Description:]
The {thole} pair styles are meant to be used with force fields that
include explicit polarization through Drude dipoles. This link
describes how to use the "thermalized Drude oscillator
model"_tutorial_drude.html in LAMMPS and polarizable models in LAMMPS
are discussed in "this Section"_Section_howto.html#howto_25.
The {thole} pair style should be used as a sub-style within in the
"pair_hybrid/overlay"_pair_hybrid.html command, in conjunction with a
main pair style including Coulomb interactions, i.e. any pair style
containing {coul/cut} or {coul/long} in its style name.
The {lj/cut/thole/long} pair style is equivalent to, but more convenient that
the frequent combination {hybrid/overlay lj/cut/coul/long cutoff thole damp
cutoff2}. It is not only a shorthand for this pair_style combination, but
it also allows for mixing pair coefficients instead of listing them all.
The {lj/cut/thole/long} pair style is also a bit faster because it avoids an
overlay and can benefit from OMP acceleration. Moreover, it uses a more
precise approximation of the direct Coulomb interaction at short range similar
to "coul/long/cs"_pair_cs.html, which stabilizes the temperature of
Drude particles.
The {thole} pair styles compute the Coulomb interaction damped at
short distances by a function
\begin\{equation\} T_\{ij\}(r_\{ij\}) = 1 - \left( 1 +
\frac\{s_\{ij\} r_\{ij\} \}\{2\} \right)
\exp \left( - s_\{ij\} r_\{ij\} \right) \end\{equation\}
This function results from an adaptation to point charges
"(Noskov)"_#Noskov1 of the dipole screening scheme originally proposed
by "Thole"_#Thole1. The scaling coefficient \(s_\{ij\} \) is determined
by the polarizability of the atoms, \( \alpha_i \), and by a Thole
damping parameter \( a \). This Thole damping parameter usually takes
a value of 2.6, but in certain force fields the value can depend upon
the atom types. The mixing rule for Thole damping parameters is the
arithmetic average, and for polarizabilities the geometric average
between the atom-specific values.
\begin\{equation\} s_\{ij\} = \frac\{ a_\{ij\} \}\{
(\alpha_\{ij\})^\{1/3\} \} = \frac\{ (a_i + a_j)/2 \}\{
\[(\alpha_i\alpha_j)^\{1/2\}\]^\{1/3\} \} \end\{equation\}
The damping function is only applied to the interactions between the
point charges representing the induced dipoles on polarizable sites,
that is, charges on Drude particles, \( q_\{D,i\} \), and opposite
charges, \( -q_\{D,i\} \), located on the respective core particles
(to which each Drude particle is bonded). Therefore, Thole screening
is not applied to the full charge of the core particle \( q_i \), but
only to the \( -q_\{D,i\} \) part of it.
The interactions between core charges are subject to the weighting
factors set by the "special_bonds"_special_bonds.html command. The
interactions between Drude particles and core charges or
non-polarizable atoms are also subject to these weighting factors. The
Drude particles inherit the 1-2, 1-3 and 1-4 neighbor relations from
their respective cores.
For pair_style {thole}, the following coefficients must be defined for
each pair of atoms types via the "pair_coeff"_pair_coeff.html command
as in the example above.
alpha (distance units^3)
damp
cutoff (distance units) :ul
The last two coefficients are optional. If not specified the global
Thole damping parameter or global cutoff specified in the pair_style
command are used. In order to specify a cutoff (third argument) a damp
parameter (second argument) must also be specified.
For pair style {lj/cut/thole/long}, the following coefficients must be
defined for each pair of atoms types via the "pair_coeff"_pair_coeff.html
command.
epsilon (energy units)
sigma (length units)
alpha (distance units^3)
damps
LJ cutoff (distance units) :ul
The last two coefficients are optional and default to the global values from
the {pair_style} command line.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
[Mixing]:
The {thole} pair style does not support mixing. Thus, coefficients
for all I,J pairs must be specified explicitly.
The {lj/cut/thole/long} pair style does support mixing. Mixed coefficients
are defined using
\begin\{equation\} \alpha_\{ij\} = \sqrt\{\alpha_i\alpha_j\}\end\{equation\}
\begin\{equation\} a_\{ij\} = \frac 1 2 (a_i + a_j)\end\{equation\}
[Restrictions:]
These pair styles are part of the USER-DRUDE package. They are only
enabled if LAMMPS was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
This pair_style should currently not be used with the "charmm dihedral
style"_dihedral_charmm.html if the latter has non-zero 1-4 weighting
factors. This is because the {thole} pair style does not know which
pairs are 1-4 partners of which dihedrals.
The {lj/cut/thole/long} pair style should be used with a "Kspace solver"_kspace_style.html
like PPPM or Ewald, which is only enabled if LAMMPS was built with the kspace
package.
[Related commands:]
"fix drude"_fix_drude.html, "fix
langevin/drude"_fix_langevin_drude.html, "fix
drude/transform"_fix_drude_transform.html, "compute
temp/drude"_compute_temp_drude.html
"pair_style lj/cut/coul/long"_pair_lj.html
[Default:] none
:line
:link(Noskov1)
[(Noskov)] Noskov, Lamoureux and Roux, J Phys Chem B, 109, 6705 (2005).
:link(Thole1)
[(Thole)] Chem Phys, 59, 341 (1981).
diff --git a/doc/src/pair_vashishta.txt b/doc/src/pair_vashishta.txt
index 9c275a61d..d9c66d45c 100644
--- a/doc/src/pair_vashishta.txt
+++ b/doc/src/pair_vashishta.txt
@@ -1,247 +1,247 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style vashishta command :h3
pair_style vashishta/gpu command :h3
pair_style vashishta/omp command :h3
pair_style vashishta/kk command :h3
pair_style vashishta/table command :h3
pair_style vashishta/table/omp command :h3
[Syntax:]
pair_style style args :pre
style = {vashishta} or {vashishta/table} or {vashishta/omp} or {vashishta/table/omp}
args = list of arguments for a particular style :ul
{vashishta} or {vashishta/omp} args = none
{vashishta/table} or {vashishta/table/omp} args = Ntable cutinner
Ntable = # of tabulation points
cutinner = tablulate from cutinner to cutoff :pre
[Examples:]
pair_style vashishta
pair_coeff * * SiC.vashishta Si C :pre
pair_style vashishta/table 100000 0.2
pair_coeff * * SiC.vashishta Si C :pre
[Description:]
The {vashishta} and {vashishta/table} styles compute the combined
2-body and 3-body family of potentials developed in the group of Priya
Vashishta and collaborators. By combining repulsive, screened
Coulombic, screened charge-dipole, and dispersion interactions with a
bond-angle energy based on the Stillinger-Weber potential, this
potential has been used to describe a variety of inorganic compounds,
including SiO2 "Vashishta1990"_#Vashishta1990, SiC
"Vashishta2007"_#Vashishta2007, and InP "Branicio2009"_#Branicio2009.
The potential for the energy U of a system of atoms is
:c,image(Eqs/pair_vashishta.jpg)
where we follow the notation used in "Branicio2009"_#Branicio2009.
U2 is a two-body term and U3 is a three-body term. The
summation over two-body terms is over all neighbors J within
a cutoff distance = {rc}. The twobody terms are shifted and
tilted by a linear function so that the energy and force are
both zero at {rc}. The summation over three-body terms
is over all neighbors J and K within a cut-off distance = {r0},
where the exponential screening function becomes zero.
The {vashishta} style computes these formulas analytically. The
{vashishta/table} style tabulates the analytic values for {Ntable}
points from cutinner to the cutoff of the potential. The points are
equally spaced in R^2 space from cutinner^2 to cutoff^2. For the
two-body term in the above equation, a linear interpolation for each
pairwise distance between adjacent points in the table. In practice
the tabulated version can run 3-5x faster than the analytic version
with with moderate to little loss of accuracy for Ntable values
between 10000 and 1000000. It is not recommended to use less than
5000 tabulation points.
Only a single pair_coeff command is used with either style which
specifies a Vashishta potential file with parameters for all needed
elements. These are mapped to LAMMPS atom types by specifying N
additional arguments after the filename in the pair_coeff command,
where N is the number of LAMMPS atom types:
filename
N element names = mapping of Vashishta elements to atom types :ul
See the "pair_coeff"_pair_coeff.html doc page for alternate ways
to specify the path for the potential file.
As an example, imagine a file SiC.vashishta has parameters for
Si and C. If your LAMMPS simulation has 4 atoms types and you want
the 1st 3 to be Si, and the 4th to be C, you would use the following
pair_coeff command:
pair_coeff * * SiC.vashishta Si Si Si C :pre
The 1st 2 arguments must be * * so as to span all LAMMPS atom types.
The first three Si arguments map LAMMPS atom types 1,2,3 to the Si
element in the file. The final C argument maps LAMMPS atom type 4
to the C element in the file. If a mapping value is specified as
NULL, the mapping is not performed. This can be used when a {vashishta}
potential is used as part of the {hybrid} pair style. The NULL values
are placeholders for atom types that will be used with other
potentials.
Vashishta files in the {potentials} directory of the LAMMPS
distribution have a ".vashishta" suffix. Lines that are not blank or
comments (starting with #) define parameters for a triplet of
elements. The parameters in a single entry correspond to the two-body
and three-body coefficients in the formulae above:
element 1 (the center atom in a 3-body interaction)
element 2
element 3
H (energy units)
eta
Zi (electron charge units)
Zj (electron charge units)
lambda1 (distance units)
D (energy units)
lambda4 (distance units)
W (energy units)
rc (distance units)
B (energy units)
gamma
r0 (distance units)
C
costheta0 :ul
The non-annotated parameters are unitless. The Vashishta potential
file must contain entries for all the elements listed in the
pair_coeff command. It can also contain entries for additional
elements not being used in a particular simulation; LAMMPS ignores
those entries. For a single-element simulation, only a single entry
is required (e.g. SiSiSi). For a two-element simulation, the file
must contain 8 entries (for SiSiSi, SiSiC, SiCSi, SiCC, CSiSi, CSiC,
CCSi, CCC), that specify parameters for all permutations of the two
elements interacting in three-body configurations. Thus for 3
elements, 27 entries would be required, etc.
Depending on the particular version of the Vashishta potential, the
values of these parameters may be keyed to the identities of zero,
one, two, or three elements. In order to make the input file format
unambiguous, general, and simple to code, LAMMPS uses a slightly
confusing method for specifying parameters. All parameters are
divided into two classes: two-body and three-body. Two-body and
three-body parameters are handled differently, as described below.
The two-body parameters are H, eta, lambda1, D, lambda4, W, rc, gamma,
and r0. They appear in the above formulae with two subscripts. The
parameters Zi and Zj are also classified as two-body parameters, even
though they only have 1 subscript. The three-body parameters are B,
C, costheta0. They appear in the above formulae with three
subscripts. Two-body and three-body parameters are handled
differently, as described below.
The first element in each entry is the center atom in a three-body
interaction, while the second and third elements are two neighbor
atoms. Three-body parameters for a central atom I and two neighbors J
and K are taken from the IJK entry. Note that even though three-body
parameters do not depend on the order of J and K, LAMMPS stores
three-body parameters for both IJK and IKJ. The user must ensure that
these values are equal. Two-body parameters for an atom I interacting
with atom J are taken from the IJJ entry, where the 2nd and 3rd
elements are the same. Thus the two-body parameters for Si interacting
with C come from the SiCC entry. Note that even though two-body
parameters (except possibly gamma and r0 in U3) do not depend on the
order of the two elements, LAMMPS will get the Si-C value from the
SiCC entry and the C-Si value from the CSiSi entry. The user must
ensure that these values are equal. Two-body parameters appearing in
entries where the 2nd and 3rd elements are different are stored but
never used. It is good practice to enter zero for these values. Note
that the three-body function U3 above contains the two-body parameters
gamma and r0. So U3 for a central C atom bonded to an Si atom and a
second C atom will take three-body parameters from the CSiC entry, but
two-body parameters from the CCC and CSiSi entries.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, where types I and J correspond to
two different element types, mixing is performed by LAMMPS as
described above from values in the potential file.
This pair style does not support the "pair_modify"_pair_modify.html
shift, table, and tail options.
This pair style does not write its information to "binary restart
files"_restart.html, since it is stored in potential files. Thus, you
need to re-specify the pair_style and pair_coeff commands in an input
script that reads a restart file.
This pair style can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. It does not support the
{inner}, {middle}, {outer} keywords.
:line
[Restrictions:]
These pair style are part of the MANYBODY package. They is only
enabled if LAMMPS was built with that package. See the
"Making LAMMPS"_Section_start.html#start_3 section for more info.
These pair styles requires the "newton"_newton.html setting to be "on"
for pair interactions.
The Vashishta potential files provided with LAMMPS (see the potentials
directory) are parameterized for metal "units"_units.html. You can
use the Vashishta potential with any LAMMPS units, but you would need
to create your own potential file with coefficients listed in the
appropriate units if your simulation doesn't use "metal" units.
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
:line
:link(Vashishta1990)
[(Vashishta1990)] P. Vashishta, R. K. Kalia, J. P. Rino, Phys. Rev. B
41, 12197 (1990).
:link(Vashishta2007)
[(Vashishta2007)] P. Vashishta, R. K. Kalia, A. Nakano,
J. P. Rino. J. Appl. Phys. 101, 103515 (2007).
:link(Branicio2009)
[(Branicio2009)] Branicio, Rino, Gan and Tsuzuki, J. Phys Condensed
Matter 21 (2009) 095002
diff --git a/doc/src/pair_yukawa.txt b/doc/src/pair_yukawa.txt
index 26acdb2cc..61d6bde6a 100644
--- a/doc/src/pair_yukawa.txt
+++ b/doc/src/pair_yukawa.txt
@@ -1,104 +1,104 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style yukawa command :h3
pair_style yukawa/gpu command :h3
pair_style yukawa/omp command :h3
[Syntax:]
pair_style yukawa kappa cutoff :pre
kappa = screening length (inverse distance units)
cutoff = global cutoff for Yukawa interactions (distance units) :ul
[Examples:]
pair_style yukawa 2.0 2.5
pair_coeff 1 1 100.0 2.3
pair_coeff * * 100.0 :pre
[Description:]
Style {yukawa} computes pairwise interactions with the formula
:c,image(Eqs/pair_yukawa.jpg)
Rc is the cutoff.
The following coefficients must be defined for each pair of atoms
types via the "pair_coeff"_pair_coeff.html command as in the examples
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands, or by mixing as described below:
A (energy*distance units)
cutoff (distance units) :ul
The last coefficient is optional. If not specified, the global yukawa
cutoff is used.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, the A coefficient and cutoff
distance for this pair style can be mixed. A is an energy value mixed
like a LJ epsilon. The default mix value is {geometric}. See the
"pair_modify" command for details.
This pair style supports the "pair_modify"_pair_modify.html shift
option for the energy of the pair interaction.
The "pair_modify"_pair_modify.html table option is not relevant
for this pair style.
This pair style does not support the "pair_modify"_pair_modify.html
tail option for adding long-range tail corrections to energy and
pressure.
This pair style writes its information to "binary restart
files"_restart.html, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.
This pair style can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. It does not support the
{inner}, {middle}, {outer} keywords.
:line
[Restrictions:] none
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
diff --git a/doc/src/pair_yukawa_colloid.txt b/doc/src/pair_yukawa_colloid.txt
index ecdc1496a..2037a9451 100644
--- a/doc/src/pair_yukawa_colloid.txt
+++ b/doc/src/pair_yukawa_colloid.txt
@@ -1,155 +1,155 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style yukawa/colloid command :h3
pair_style yukawa/colloid/gpu command :h3
pair_style yukawa/colloid/omp command :h3
[Syntax:]
pair_style yukawa/colloid kappa cutoff :pre
kappa = screening length (inverse distance units)
cutoff = global cutoff for colloidal Yukawa interactions (distance units) :ul
[Examples:]
pair_style yukawa/colloid 2.0 2.5
pair_coeff 1 1 100.0 2.3
pair_coeff * * 100.0 :pre
[Description:]
Style {yukawa/colloid} computes pairwise interactions with the formula
:c,image(Eqs/pair_yukawa_colloid.jpg)
where Ri and Rj are the radii of the two particles and Rc is the
cutoff.
In contrast to "pair_style yukawa"_pair_yukawa.html, this functional
form arises from the Coulombic interaction between two colloid
particles, screened due to the presence of an electrolyte, see the
book by "Safran"_#Safran for a derivation in the context of DLVO
theory. "Pair_style yukawa"_pair_yukawa.html is a screened Coulombic
potential between two point-charges and uses no such approximation.
This potential applies to nearby particle pairs for which the Derjagin
approximation holds, meaning h << Ri + Rj, where h is the
surface-to-surface separation of the two particles.
When used in combination with "pair_style colloid"_pair_colloid.html,
the two terms become the so-called DLVO potential, which combines
electrostatic repulsion and van der Waals attraction.
The following coefficients must be defined for each pair of atoms
types via the "pair_coeff"_pair_coeff.html command as in the examples
above, or in the data file or restart files read by the
"read_data"_read_data.html or "read_restart"_read_restart.html
commands, or by mixing as described below:
A (energy/distance units)
cutoff (distance units) :ul
The prefactor A is determined from the relationship between surface
charge and surface potential due to the presence of electrolyte. Note
that the A for this potential style has different units than the A
used in "pair_style yukawa"_pair_yukawa.html. For low surface
potentials, i.e. less than about 25 mV, A can be written as:
A = 2 * PI * R*eps*eps0 * kappa * psi^2 :pre
where
R = colloid radius (distance units)
eps0 = permittivity of free space (charge^2/energy/distance units)
eps = relative permittivity of fluid medium (dimensionless)
kappa = inverse screening length (1/distance units)
psi = surface potential (energy/charge units) :ul
The last coefficient is optional. If not specified, the global
yukawa/colloid cutoff is used.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, the A coefficient and cutoff
distance for this pair style can be mixed. A is an energy value mixed
like a LJ epsilon. The default mix value is {geometric}. See the
"pair_modify" command for details.
This pair style supports the "pair_modify"_pair_modify.html shift
option for the energy of the pair interaction.
The "pair_modify"_pair_modify.html table option is not relevant
for this pair style.
This pair style does not support the "pair_modify"_pair_modify.html
tail option for adding long-range tail corrections to energy and
pressure.
This pair style writes its information to "binary restart
files"_restart.html, so pair_style and pair_coeff commands do not need
to be specified in an input script that reads a restart file.
This pair style can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. It does not support the
{inner}, {middle}, {outer} keywords.
:line
[Restrictions:]
This style is part of the COLLOID package. It is only enabled if
LAMMPS was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
This pair style requires that atoms be finite-size spheres with a
diameter, as defined by the "atom_style sphere"_atom_style.html
command.
Per-particle polydispersity is not yet supported by this pair style;
per-type polydispersity is allowed. This means all particles of the
same type must have the same diameter. Each type can have a different
diameter.
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
:line
:link(Safran)
[(Safran)] Safran, Statistical Thermodynamics of Surfaces, Interfaces,
And Membranes, Westview Press, ISBN: 978-0813340791 (2003).
diff --git a/doc/src/pair_zbl.txt b/doc/src/pair_zbl.txt
index 154fdc1c1..5ab672171 100644
--- a/doc/src/pair_zbl.txt
+++ b/doc/src/pair_zbl.txt
@@ -1,139 +1,139 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
pair_style zbl command :h3
pair_style zbl/gpu command :h3
pair_style zbl/omp command :h3
[Syntax:]
pair_style zbl inner outer :pre
inner = distance where switching function begins
outer = global cutoff for ZBL interaction :ul
[Examples:]
pair_style zbl 3.0 4.0
pair_coeff * * 73.0 73.0
pair_coeff 1 1 14.0 14.0 :pre
[Description:]
Style {zbl} computes the Ziegler-Biersack-Littmark (ZBL) screened nuclear
repulsion for describing high-energy collisions between atoms.
"(Ziegler)"_#Ziegler. It includes an additional switching function
that ramps the energy, force, and curvature smoothly to zero
between an inner and outer cutoff. The potential
energy due to a pair of atoms at a distance r_ij is given by:
:c,image(Eqs/pair_zbl.jpg)
where e is the electron charge, epsilon_0 is the electrical
permittivity of vacuum, and Z_i and Z_j are the nuclear charges of the
two atoms. The switching function S(r) is identical to that used by
"pair_style lj/gromacs"_pair_gromacs.html. Here, the inner and outer
cutoff are the same for all pairs of atom types.
The following coefficients must be defined for each pair of atom types
via the "pair_coeff"_pair_coeff.html command as in the examples above,
or in the LAMMPS data file.
Z_i (atomic number for first atom type, e.g. 13.0 for aluminum) :ul
Z_j (ditto for second atom type) :ul
The values of Z_i and Z_j are normally equal to the atomic
numbers of the two atom types. Thus, the user may optionally
specify only the coefficients for each I==I pair, and rely
on the obvious mixing rule for cross interactions (see below).
Note that when I==I it is required that Z_i == Z_j. When used
with "hybrid/overlay"_pair_hybrid.html and pairs are assigned
to more than one sub-style, the mixing rule is not used and
each pair of types interacting with the ZBL sub-style must
be included in a pair_coeff command.
NOTE: The numerical values of the exponential decay constants in the
screening function depend on the unit of distance. In the above
equation they are given for units of angstroms. LAMMPS will
automatically convert these values to the distance unit of the
specified LAMMPS "units"_units.html setting. The values of Z should
always be given as multiples of a proton's charge, e.g. 29.0 for
copper.
:line
Styles with a {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
functionally the same as the corresponding style without the suffix.
They have been optimized to run faster, depending on your available
hardware, as discussed in "Section 5"_Section_accelerate.html
of the manual. The accelerated styles take the same arguments and
should produce the same results, except for round-off and precision
issues.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Mixing, shift, table, tail correction, restart, rRESPA info]:
For atom type pairs I,J and I != J, the Z_i and Z_j coefficients
can be mixed by taking Z_i and Z_j from the values specified for
I == I and J == J cases. When used
with "hybrid/overlay"_pair_hybrid.html and pairs are assigned
to more than one sub-style, the mixing rule is not used and
each pair of types interacting with the ZBL sub-style
must be included in a pair_coeff command.
The "pair_modify"_pair_modify.html mix option has no effect on
the mixing behavior
The ZBL pair style does not support the "pair_modify"_pair_modify.html
shift option, since the ZBL interaction is already smoothed to 0.0 at
the cutoff.
The "pair_modify"_pair_modify.html table option is not relevant for
this pair style.
This pair style does not support the "pair_modify"_pair_modify.html
tail option for adding long-range tail corrections to energy and
pressure, since there are no corrections for a potential that goes to
0.0 at the cutoff.
This pair style does not write information to "binary restart
files"_restart.html, so pair_style and pair_coeff commands must be
specified in an input script that reads a restart file.
This pair style can only be used via the {pair} keyword of the
"run_style respa"_run_style.html command. It does not support the
{inner}, {middle}, {outer} keywords.
:line
[Restrictions:] none
[Related commands:]
"pair_coeff"_pair_coeff.html
[Default:] none
:line
:link(Ziegler)
[(Ziegler)] J.F. Ziegler, J. P. Biersack and U. Littmark, "The
Stopping and Range of Ions in Matter," Volume 1, Pergamon, 1985.
diff --git a/doc/src/partition.txt b/doc/src/partition.txt
index 9c1d560c8..610eee99b 100644
--- a/doc/src/partition.txt
+++ b/doc/src/partition.txt
@@ -1,73 +1,73 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
partition command :h3
[Syntax:]
partition style N command ... :pre
style = {yes} or {no}
N = partition number (see asterisk form below)
command = any LAMMPS command :ul
[Examples:]
partition yes 1 processors 4 10 6
partition no 5 print "Active partition"
partition yes *5 fix all nve
partition yes 6* fix all nvt temp 1.0 1.0 0.1 :pre
[Description:]
This command invokes the specified command on a subset of the
partitions of processors you have defined via the -partition
-command-line switch. See "Section 2.6"_Section_start.html#start_7
+command-line switch. See "Section 2.6"_Section_start.html#start_6
for an explanation of the switch.
Normally, every input script command in your script is invoked by
every partition. This behavior can be modified by defining world- or
universe-style "variables"_variable.html that have different values
for each partition. This mechanism can be used to cause your script
to jump to different input script files on different partitions, if
such a variable is used in a "jump"_jump.html command.
The "partition" command is another mechanism for having as input
script operate differently on different partitions. It is basically a
prefix on any LAMMPS command. The command will only be invoked on
the partition(s) specified by the {style} and {N} arguments.
If the {style} is {yes}, the command will be invoked on any partition
which matches the {N} argument. If the {style} is {no} the command
will be invoked on all the partitions which do not match the Np
argument.
Partitions are numbered from 1 to Np, where Np is the number of
partitions specified by the "-partition command-line
-switch"_Section_start.html#start_7.
+switch"_Section_start.html#start_6.
{N} can be specified in one of two ways. An explicit numeric value
can be used, as in the 1st example above. Or a wild-card asterisk can
be used to span a range of partition numbers. This takes the form "*"
or "*n" or "n*" or "m*n". An asterisk with no numeric values means
all partitions from 1 to Np. A leading asterisk means all partitions
from 1 to n (inclusive). A trailing asterisk means all partitions
from n to Np (inclusive). A middle asterisk means all partitions from
m to n (inclusive).
This command can be useful for the "run_style verlet/split" command
which imposed requirements on how the "processors"_processors.html
command lays out a 3d grid of processors in each of 2 partitions.
[Restrictions:] none
[Related commands:]
"run_style verlet/split"_run_style.html
[Default:] none
diff --git a/doc/src/prd.txt b/doc/src/prd.txt
index 247d422b1..3c0305e31 100644
--- a/doc/src/prd.txt
+++ b/doc/src/prd.txt
@@ -1,324 +1,324 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
prd command :h3
[Syntax:]
prd N t_event n_dephase t_dephase t_correlate compute-ID seed keyword value ... :pre
N = # of timesteps to run (not including dephasing/quenching) :ulb,l
t_event = timestep interval between event checks :l
n_dephase = number of velocity randomizations to perform in each dephase run :l
t_dephase = number of timesteps to run dynamics after each velocity randomization during dephase :l
t_correlate = number of timesteps within which 2 consecutive events are considered to be correlated :l
compute-ID = ID of the compute used for event detection :l
random_seed = random # seed (positive integer) :l
zero or more keyword/value pairs may be appended :l
keyword = {min} or {temp} or {vel} :l
{min} values = etol ftol maxiter maxeval
etol = stopping tolerance for energy, used in quenching
ftol = stopping tolerance for force, used in quenching
maxiter = max iterations of minimize, used in quenching
maxeval = max number of force/energy evaluations, used in quenching
{temp} value = Tdephase
Tdephase = target temperature for velocity randomization, used in dephasing
{vel} values = loop dist
loop = {all} or {local} or {geom}, used in dephasing
dist = {uniform} or {gaussian}, used in dephasing
{time} value = {steps} or {clock}
{steps} = simulation runs for N timesteps on each replica (default)
{clock} = simulation runs for N timesteps across all replicas :pre
:ule
[Examples:]
prd 5000 100 10 10 100 1 54982
prd 5000 100 10 10 100 1 54982 min 0.1 0.1 100 200 :pre
[Description:]
Run a parallel replica dynamics (PRD) simulation using multiple
replicas of a system. One or more replicas can be used. The total
number of steps {N} to run can be interpreted in one of two ways; see
discussion of the {time} keyword below.
PRD is described in "this paper"_#Voter1998 by Art Voter. It is a method
for performing accelerated dynamics that is suitable for
infrequent-event systems that obey first-order kinetics. A good
overview of accelerated dynamics methods for such systems in given in
"this review paper"_#Voter2002prd from the same group. To quote from the
paper: "The dynamical evolution is characterized by vibrational
excursions within a potential basin, punctuated by occasional
transitions between basins." The transition probability is
characterized by p(t) = k*exp(-kt) where k is the rate constant.
Running multiple replicas gives an effective enhancement in the
timescale spanned by the multiple simulations, while waiting for an
event to occur.
Each replica runs on a partition of one or more processors. Processor
partitions are defined at run-time using the -partition command-line
-switch; see "Section 2.7"_Section_start.html#start_7 of the manual.
+switch; see "Section 2.6"_Section_start.html#start_6 of the manual.
Note that if you have MPI installed, you can run a multi-replica
simulation with more replicas (partitions) than you have physical
processors, e.g you can run a 10-replica simulation on one or two
processors. However for PRD, this makes little sense, since running a
replica on virtual instead of physical processors,offers no effective
parallel speed-up in searching for infrequent events. See "Section
6.5"_Section_howto.html#howto_5 of the manual for further discussion.
When a PRD simulation is performed, it is assumed that each replica is
running the same model, though LAMMPS does not check for this.
I.e. the simulation domain, the number of atoms, the interaction
potentials, etc should be the same for every replica.
A PRD run has several stages, which are repeated each time an "event"
occurs in one of the replicas, as defined below. The logic for a PRD
run is as follows:
while (time remains):
dephase for n_dephase*t_dephase steps
until (event occurs on some replica):
run dynamics for t_event steps
quench
check for uncorrelated event on any replica
until (no correlated event occurs):
run dynamics for t_correlate steps
quench
check for correlated event on this replica
event replica shares state with all replicas :pre
Before this loop begins, the state of the system on replica 0 is
shared with all replicas, so that all replicas begin from the same
initial state. The first potential energy basin is identified by
quenching (an energy minimization, see below) the initial state and
storing the resulting coordinates for reference.
In the first stage, dephasing is performed by each replica
independently to eliminate correlations between replicas. This is
done by choosing a random set of velocities, based on the
{random_seed} that is specified, and running {t_dephase} timesteps of
dynamics. This is repeated {n_dephase} times. At each of the
{n_dephase} stages, if an event occurs during the {t_dephase} steps of
dynamics for a particular replica, the replica repeats the stage until
no event occurs.
If the {temp} keyword is not specified, the target temperature for
velocity randomization for each replica is the current temperature of
that replica. Otherwise, it is the specified {Tdephase} temperature.
The style of velocity randomization is controlled using the keyword
{vel} with arguments that have the same meaning as their counterparts
in the "velocity"_velocity.html command.
In the second stage, each replica runs dynamics continuously, stopping
every {t_event} steps to check if a transition event has occurred.
This check is performed by quenching the system and comparing the
resulting atom coordinates to the coordinates from the previous basin.
The first time through the PRD loop, the "previous basin" is the set
of quenched coordinates from the initial state of the system.
A quench is an energy minimization and is performed by whichever
algorithm has been defined by the "min_style"_min_style.html command.
Minimization parameters may be set via the
"min_modify"_min_modify.html command and by the {min} keyword of the
PRD command. The latter are the settings that would be used with the
"minimize"_minimize.html command. Note that typically, you do not
need to perform a highly-converged minimization to detect a transition
event.
The event check is performed by a compute with the specified
{compute-ID}. Currently there is only one compute that works with the
PRD command, which is the "compute
event/displace"_compute_event_displace.html command. Other
event-checking computes may be added. "Compute
event/displace"_compute_event_displace.html checks whether any atom in
the compute group has moved further than a specified threshold
distance. If so, an "event" has occurred.
In the third stage, the replica on which the event occurred (event
replica) continues to run dynamics to search for correlated events.
This is done by running dynamics for {t_correlate} steps, quenching
every {t_event} steps, and checking if another event has occurred.
The first time no correlated event occurs, the final state of the
event replica is shared with all replicas, the new basin reference
coordinates are updated with the quenched state, and the outer loop
begins again. While the replica event is searching for correlated
events, all the other replicas also run dynamics and event checking
with the same schedule, but the final states are always overwritten by
the state of the event replica.
The outer loop of the pseudo-code above continues until {N} steps of
dynamics have been performed. Note that {N} only includes the
dynamics of stages 2 and 3, not the steps taken during dephasing or
the minimization iterations of quenching. The specified {N} is
interpreted in one of two ways, depending on the {time} keyword. If
the {time} value is {steps}, which is the default, then each replica
runs for {N} timesteps. If the {time} value is {clock}, then the
simulation runs until {N} aggregate timesteps across all replicas have
elapsed. This aggregate time is the "clock" time defined below, which
typically advances nearly M times faster than the timestepping on a
single replica, where M is the number of replicas.
:line
Four kinds of output can be generated during a PRD run: event
statistics, thermodynamic output by each replica, dump files, and
restart files.
When running with multiple partitions (each of which is a replica in
this case), the print-out to the screen and master log.lammps file is
limited to event statistics. Note that if a PRD run is performed on
only a single replica then the event statistics will be intermixed
with the usual thermodynamic output discussed below.
The quantities printed each time an event occurs are the timestep, CPU
time, clock, event number, a correlation flag, the number of
coincident events, and the replica number of the chosen event.
The timestep is the usual LAMMPS timestep, except that time does not
advance during dephasing or quenches, but only during dynamics. Note
that are two kinds of dynamics in the PRD loop listed above that
contribute to this timestepping. The first is when all replicas are
performing independent dynamics, waiting for an event to occur. The
second is when correlated events are being searched for, but only one
replica is running dynamics.
The CPU time is the total elapsed time on each processor, since the
start of the PRD run.
The clock is the same as the timestep except that it advances by M
steps per timestep during the first kind of dynamics when the M
replicas are running independently. The clock advances by only 1 step
per timestep during the second kind of dynamics, when only a single
replica is checking for a correlated event. Thus "clock" time
represents the aggregate time (in steps) that has effectively elapsed
during a PRD simulation on M replicas. If most of the PRD run is
spent in the second stage of the loop above, searching for infrequent
events, then the clock will advance nearly M times faster than it
would if a single replica was running. Note the clock time between
successive events should be drawn from p(t).
The event number is a counter that increments with each event, whether
it is uncorrelated or correlated.
The correlation flag will be 0 when an uncorrelated event occurs
during the second stage of the loop listed above, i.e. when all
replicas are running independently. The correlation flag will be 1
when a correlated event occurs during the third stage of the loop
listed above, i.e. when only one replica is running dynamics.
When more than one replica detects an event at the end of the same
event check (every {t_event} steps) during the second stage, then
one of them is chosen at random. The number of coincident events is
the number of replicas that detected an event. Normally, this value
should be 1. If it is often greater than 1, then either the number of
replicas is too large, or {t_event} is too large.
The replica number is the ID of the replica (from 0 to M-1) in which
the event occurred.
:line
When running on multiple partitions, LAMMPS produces additional log
files for each partition, e.g. log.lammps.0, log.lammps.1, etc. For
the PRD command, these contain the thermodynamic output for each
replica. You will see short runs and minimizations corresponding to
the dynamics and quench operations of the loop listed above. The
timestep will be reset appropriately depending on whether the
operation advances time or not.
After the PRD command completes, timing statistics for the PRD run are
printed in each replica's log file, giving a breakdown of how much CPU
time was spent in each stage (dephasing, dynamics, quenching, etc).
:line
Any "dump files"_dump.html defined in the input script, will be
written to during a PRD run at timesteps corresponding to both
uncorrelated and correlated events. This means the requested dump
frequency in the "dump"_dump.html command is ignored. There will be
one dump file (per dump command) created for all partitions.
The atom coordinates of the dump snapshot are those of the minimum
energy configuration resulting from quenching following a transition
event. The timesteps written into the dump files correspond to the
timestep at which the event occurred and NOT the clock. A dump
snapshot corresponding to the initial minimum state used for event
detection is written to the dump file at the beginning of each PRD
run.
:line
If the "restart"_restart.html command is used, a single restart file
for all the partitions is generated, which allows a PRD run to be
continued by a new input script in the usual manner.
The restart file is generated at the end of the loop listed above. If
no correlated events are found, this means it contains a snapshot of
the system at time T + {t_correlate}, where T is the time at which the
uncorrelated event occurred. If correlated events were found, then it
contains a snapshot of the system at time T + {t_correlate}, where T
is the time of the last correlated event.
The restart frequency specified in the "restart"_restart.html command
is interpreted differently when performing a PRD run. It does not
mean the timestep interval between restart files. Instead it means an
event interval for uncorrelated events. Thus a frequency of 1 means
write a restart file every time an uncorrelated event occurs. A
frequency of 10 means write a restart file every 10th uncorrelated
event.
When an input script reads a restart file from a previous PRD run, the
new script can be run on a different number of replicas or processors.
However, it is assumed that {t_correlate} in the new PRD command is
the same as it was previously. If not, the calculation of the "clock"
value for the first event in the new run will be slightly off.
:line
[Restrictions:]
This command can only be used if LAMMPS was built with the REPLICA
package. See the "Making LAMMPS"_Section_start.html#start_3 section
for more info on packages.
The {N} and {t_correlate} settings must be integer multiples of
{t_event}.
Runs restarted from restart file written during a PRD run will not
produce identical results due to changes in the random numbers used
for dephasing.
This command cannot be used when any fixes are defined that keep track
of elapsed time to perform time-dependent operations. Examples
include the "ave" fixes such as "fix ave/chunk"_fix_ave_chunk.html.
Also "fix dt/reset"_fix_dt_reset.html and "fix
deposit"_fix_deposit.html.
[Related commands:]
"compute event/displace"_compute_event_displace.html,
"min_modify"_min_modify.html, "min_style"_min_style.html,
"run_style"_run_style.html, "minimize"_minimize.html,
"velocity"_velocity.html, "temper"_temper.html, "neb"_neb.html,
"tad"_tad.html
[Default:]
The option defaults are min = 0.1 0.1 40 50, no temp setting, vel =
geom gaussian, and time = steps.
:line
:link(Voter1998)
[(Voter1998)] Voter, Phys Rev B, 57, 13985 (1998).
:link(Voter2002prd)
[(Voter2002)] Voter, Montalenti, Germann, Annual Review of Materials
Research 32, 321 (2002).
diff --git a/doc/src/processors.txt b/doc/src/processors.txt
index 781049af9..e54b2cede 100644
--- a/doc/src/processors.txt
+++ b/doc/src/processors.txt
@@ -1,340 +1,340 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
processors command :h3
[Syntax:]
processors Px Py Pz keyword args ... :pre
Px,Py,Pz = # of processors in each dimension of 3d grid overlaying the simulation domain :ulb,l
zero or more keyword/arg pairs may be appended :l
keyword = {grid} or {map} or {part} or {file} :l
{grid} arg = gstyle params ...
gstyle = {onelevel} or {twolevel} or {numa} or {custom}
onelevel params = none
twolevel params = Nc Cx Cy Cz
Nc = number of cores per node
Cx,Cy,Cz = # of cores in each dimension of 3d sub-grid assigned to each node
numa params = none
custom params = infile
infile = file containing grid layout
{map} arg = {cart} or {cart/reorder} or {xyz} or {xzy} or {yxz} or {yzx} or {zxy} or {zyx}
cart = use MPI_Cart() methods to map processors to 3d grid with reorder = 0
cart/reorder = use MPI_Cart() methods to map processors to 3d grid with reorder = 1
xyz,xzy,yxz,yzx,zxy,zyx = map processors to 3d grid in IJK ordering
{numa} arg = none
{part} args = Psend Precv cstyle
Psend = partition # (1 to Np) which will send its processor layout
Precv = partition # (1 to Np) which will recv the processor layout
cstyle = {multiple}
{multiple} = Psend grid will be multiple of Precv grid in each dimension
{file} arg = outfile
outfile = name of file to write 3d grid of processors to :pre
:ule
[Examples:]
processors * * 5
processors 2 4 4
processors * * 8 map xyz
processors * * * grid numa
processors * * * grid twolevel 4 * * 1
processors 4 8 16 grid custom myfile
processors * * * part 1 2 multiple :pre
[Description:]
Specify how processors are mapped as a regular 3d grid to the global
simulation box. The mapping involves 2 steps. First if there are P
processors it means choosing a factorization P = Px by Py by Pz so
that there are Px processors in the x dimension, and similarly for the
y and z dimensions. Second, the P processors are mapped to the
regular 3d grid. The arguments to this command control each of these
2 steps.
The Px, Py, Pz parameters affect the factorization. Any of the 3
parameters can be specified with an asterisk "*", which means LAMMPS
will choose the number of processors in that dimension of the grid.
It will do this based on the size and shape of the global simulation
box so as to minimize the surface-to-volume ratio of each processor's
sub-domain.
Choosing explicit values for Px or Py or Pz can be used to override
the default manner in which LAMMPS will create the regular 3d grid of
processors, if it is known to be sub-optimal for a particular problem.
E.g. a problem where the extent of atoms will change dramatically in a
particular dimension over the course of the simulation.
The product of Px, Py, Pz must equal P, the total # of processors
LAMMPS is running on. For a "2d simulation"_dimension.html, Pz must
equal 1.
Note that if you run on a prime number of processors P, then a grid
such as 1 x P x 1 will be required, which may incur extra
communication costs due to the high surface area of each processor's
sub-domain.
Also note that if multiple partitions are being used then P is the
number of processors in this partition; see "this
-section"_Section_start.html#start_7 for an explanation of the
+section"_Section_start.html#start_6 for an explanation of the
-partition command-line switch. Also note that you can prefix the
processors command with the "partition"_partition.html command to
easily specify different Px,Py,Pz values for different partitions.
You can use the "partition"_partition.html command to specify
different processor grids for different partitions, e.g.
partition yes 1 processors 4 4 4
partition yes 2 processors 2 3 2 :pre
NOTE: This command only affects the initial regular 3d grid created
when the simulation box is first specified via a
"create_box"_create_box.html or "read_data"_read_data.html or
"read_restart"_read_restart.html command. Or if the simulation box is
re-created via the "replicate"_replicate.html command. The same
regular grid is initially created, regardless of which
"comm_style"_comm_style.html command is in effect.
If load-balancing is never invoked via the "balance"_balance.html or
"fix balance"_fix_balance.html commands, then the initial regular grid
will persist for all simulations. If balancing is performed, some of
the methods invoked by those commands retain the logical topology of
the initial 3d grid, and the mapping of processors to the grid
specified by the processors command. However the grid spacings in
different dimensions may change, so that processors own sub-domains of
different sizes. If the "comm_style tiled"_comm_style.html command is
used, methods invoked by the balancing commands may discard the 3d
grid of processors and tile the simulation domain with sub-domains of
different sizes and shapes which no longer have a logical 3d
connectivity. If that occurs, all the information specified by the
processors command is ignored.
:line
The {grid} keyword affects the factorization of P into Px,Py,Pz and it
can also affect how the P processor IDs are mapped to the 3d grid of
processors.
The {onelevel} style creates a 3d grid that is compatible with the
Px,Py,Pz settings, and which minimizes the surface-to-volume ratio of
each processor's sub-domain, as described above. The mapping of
processors to the grid is determined by the {map} keyword setting.
The {twolevel} style can be used on machines with multicore nodes to
minimize off-node communication. It insures that contiguous
sub-sections of the 3d grid are assigned to all the cores of a node.
For example if {Nc} is 4, then 2x2x1 or 2x1x2 or 1x2x2 sub-sections of
the 3d grid will correspond to the cores of each node. This affects
both the factorization and mapping steps.
The {Cx}, {Cy}, {Cz} settings are similar to the {Px}, {Py}, {Pz}
settings, only their product should equal {Nc}. Any of the 3
parameters can be specified with an asterisk "*", which means LAMMPS
will choose the number of cores in that dimension of the node's
sub-grid. As with Px,Py,Pz, it will do this based on the size and
shape of the global simulation box so as to minimize the
surface-to-volume ratio of each processor's sub-domain.
NOTE: For the {twolevel} style to work correctly, it assumes the MPI
ranks of processors LAMMPS is running on are ordered by core and then
by node. E.g. if you are running on 2 quad-core nodes, for a total of
8 processors, then it assumes processors 0,1,2,3 are on node 1, and
processors 4,5,6,7 are on node 2. This is the default rank ordering
for most MPI implementations, but some MPIs provide options for this
ordering, e.g. via environment variable settings.
The {numa} style operates similar to the {twolevel} keyword except
that it auto-detects which cores are running on which nodes.
Currently, it does this in only 2 levels, but it may be extended in
the future to account for socket topology and other non-uniform memory
access (NUMA) costs. It also uses a different algorithm than the
{twolevel} keyword for doing the two-level factorization of the
simulation box into a 3d processor grid to minimize off-node
communication, and it does its own MPI-based mapping of nodes and
cores to the regular 3d grid. Thus it may produce a different layout
of the processors than the {twolevel} options.
The {numa} style will give an error if the number of MPI processes is
not divisible by the number of cores used per node, or any of the Px
or Py of Pz values is greater than 1.
NOTE: Unlike the {twolevel} style, the {numa} style does not require
any particular ordering of MPI ranks i norder to work correctly. This
is because it auto-detects which processes are running on which nodes.
The {custom} style uses the file {infile} to define both the 3d
factorization and the mapping of processors to the grid.
The file should have the following format. Any number of initial
blank or comment lines (starting with a "#" character) can be present.
The first non-blank, non-comment line should have
3 values:
Px Py Py :pre
These must be compatible with the total number of processors
and the Px, Py, Pz settings of the processors command.
This line should be immediately followed by
P = Px*Py*Pz lines of the form:
ID I J K :pre
where ID is a processor ID (from 0 to P-1) and I,J,K are the
processors location in the 3d grid. I must be a number from 1 to Px
(inclusive) and similarly for J and K. The P lines can be listed in
any order, but no processor ID should appear more than once.
:line
The {map} keyword affects how the P processor IDs (from 0 to P-1) are
mapped to the 3d grid of processors. It is only used by the
{onelevel} and {twolevel} grid settings.
The {cart} style uses the family of MPI Cartesian functions to perform
the mapping, namely MPI_Cart_create(), MPI_Cart_get(),
MPI_Cart_shift(), and MPI_Cart_rank(). It invokes the
MPI_Cart_create() function with its reorder flag = 0, so that MPI is
not free to reorder the processors.
The {cart/reorder} style does the same thing as the {cart} style
except it sets the reorder flag to 1, so that MPI can reorder
processors if it desires.
The {xyz}, {xzy}, {yxz}, {yzx}, {zxy}, and {zyx} styles are all
similar. If the style is IJK, then it maps the P processors to the
grid so that the processor ID in the I direction varies fastest, the
processor ID in the J direction varies next fastest, and the processor
ID in the K direction varies slowest. For example, if you select
style {xyz} and you have a 2x2x2 grid of 8 processors, the assignments
of the 8 octants of the simulation domain will be:
proc 0 = lo x, lo y, lo z octant
proc 1 = hi x, lo y, lo z octant
proc 2 = lo x, hi y, lo z octant
proc 3 = hi x, hi y, lo z octant
proc 4 = lo x, lo y, hi z octant
proc 5 = hi x, lo y, hi z octant
proc 6 = lo x, hi y, hi z octant
proc 7 = hi x, hi y, hi z octant :pre
Note that, in principle, an MPI implementation on a particular machine
should be aware of both the machine's network topology and the
specific subset of processors and nodes that were assigned to your
simulation. Thus its MPI_Cart calls can optimize the assignment of
MPI processes to the 3d grid to minimize communication costs. In
practice, however, few if any MPI implementations actually do this.
So it is likely that the {cart} and {cart/reorder} styles simply give
the same result as one of the IJK styles.
Also note, that for the {twolevel} grid style, the {map} setting is
used to first map the nodes to the 3d grid, then again to the cores
within each node. For the latter step, the {cart} and {cart/reorder}
styles are not supported, so an {xyz} style is used in their place.
:line
The {part} keyword affects the factorization of P into Px,Py,Pz.
It can be useful when running in multi-partition mode, e.g. with the
"run_style verlet/split"_run_style.html command. It specifies a
dependency between a sending partition {Psend} and a receiving
partition {Precv} which is enforced when each is setting up their own
mapping of their processors to the simulation box. Each of {Psend}
and {Precv} must be integers from 1 to Np, where Np is the number of
partitions you have defined via the "-partition command-line
-switch"_Section_start.html#start_7.
+switch"_Section_start.html#start_6.
A "dependency" means that the sending partition will create its
regular 3d grid as Px by Py by Pz and after it has done this, it will
send the Px,Py,Pz values to the receiving partition. The receiving
partition will wait to receive these values before creating its own
regular 3d grid and will use the sender's Px,Py,Pz values as a
constraint. The nature of the constraint is determined by the
{cstyle} argument.
For a {cstyle} of {multiple}, each dimension of the sender's processor
grid is required to be an integer multiple of the corresponding
dimension in the receiver's processor grid. This is a requirement of
the "run_style verlet/split"_run_style.html command.
For example, assume the sending partition creates a 4x6x10 grid = 240
processor grid. If the receiving partition is running on 80
processors, it could create a 4x2x10 grid, but it will not create a
2x4x10 grid, since in the y-dimension, 6 is not an integer multiple of
4.
NOTE: If you use the "partition"_partition.html command to invoke
different "processors" commands on different partitions, and you also
use the {part} keyword, then you must insure that both the sending and
receiving partitions invoke the "processors" command that connects the
2 partitions via the {part} keyword. LAMMPS cannot easily check for
this, but your simulation will likely hang in its setup phase if this
error has been made.
:line
The {file} keyword writes the mapping of the factorization of P
processors and their mapping to the 3d grid to the specified file
{outfile}. This is useful to check that you assigned physical
processors in the manner you desired, which can be tricky to figure
out, especially when running on multiple partitions or on, a multicore
machine or when the processor ranks were reordered by use of the
-"-reorder command-line switch"_Section_start.html#start_7 or due to
+"-reorder command-line switch"_Section_start.html#start_6 or due to
use of MPI-specific launch options such as a config file.
If you have multiple partitions you should insure that each one writes
to a different file, e.g. using a "world-style variable"_variable.html
for the filename. The file has a self-explanatory header, followed by
one-line per processor in this format:
world-ID universe-ID original-ID: I J K: name
The IDs are the processor's rank in this simulation (the world), the
universe (of multiple simulations), and the original MPI communicator
used to instantiate LAMMPS, respectively. The world and universe IDs
will only be different if you are running on more than one partition;
-see the "-partition command-line switch"_Section_start.html#start_7.
+see the "-partition command-line switch"_Section_start.html#start_6.
The universe and original IDs will only be different if you used the
-"-reorder command-line switch"_Section_start.html#start_7 to reorder
+"-reorder command-line switch"_Section_start.html#start_6 to reorder
the processors differently than their rank in the original
communicator LAMMPS was instantiated with.
I,J,K are the indices of the processor in the regular 3d grid, each
from 1 to Nd, where Nd is the number of processors in that dimension
of the grid.
The {name} is what is returned by a call to MPI_Get_processor_name()
and should represent an identifier relevant to the physical processors
in your machine. Note that depending on the MPI implementation,
multiple cores can have the same {name}.
:line
[Restrictions:]
This command cannot be used after the simulation box is defined by a
"read_data"_read_data.html or "create_box"_create_box.html command.
It can be used before a restart file is read to change the 3d
processor grid from what is specified in the restart file.
The {grid numa} keyword only currently works with the {map cart}
option.
The {part} keyword (for the receiving partition) only works with the
{grid onelevel} or {grid twolevel} options.
[Related commands:]
-"partition"_partition.html, "-reorder command-line switch"_Section_start.html#start_7
+"partition"_partition.html, "-reorder command-line switch"_Section_start.html#start_6
[Default:]
The option defaults are Px Py Pz = * * *, grid = onelevel, and map =
cart.
diff --git a/doc/src/read_data.txt b/doc/src/read_data.txt
index 6785eb106..a8aca5369 100644
--- a/doc/src/read_data.txt
+++ b/doc/src/read_data.txt
@@ -1,1154 +1,1154 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
read_data command :h3
[Syntax:]
read_data file keyword args ... :pre
file = name of data file to read in :ulb,l
zero or more keyword/arg pairs may be appended :l
keyword = {add} or {offset} or {shift} or {extra/atom/types} or {extra/bond/types} or {extra/angle/types} or {extra/dihedral/types} or {extra/improper/types} or {extra/bond/per/atom} or {extra/angle/per/atom} or {extra/dihedral/per/atom} or {extra/improper/per/atom} or {group} or {nocoeff} or {fix} :l
{add} arg = {append} or {Nstart} or {merge}
append = add new atoms with IDs appended to current IDs
Nstart = add new atoms with IDs starting with Nstart
merge = add new atoms with their IDs unchanged
{offset} args = toff boff aoff doff ioff
toff = offset to add to atom types
boff = offset to add to bond types
aoff = offset to add to angle types
doff = offset to add to dihedral types
ioff = offset to add to improper types
{shift} args = Sx Sy Sz
Sx,Sy,Sz = distance to shift atoms when adding to system (distance units)
{extra/atom/types} arg = # of extra atom types
{extra/bond/types} arg = # of extra bond types
{extra/angle/types} arg = # of extra angle types
{extra/dihedral/types} arg = # of extra dihedral types
{extra/improper/types} arg = # of extra improper types
{extra/bond/per/atom} arg = leave space for this many new bonds per atom
{extra/angle/per/atom} arg = leave space for this many new angles per atom
{extra/dihedral/per/atom} arg = leave space for this many new dihedrals per atom
{extra/improper/per/atom} arg = leave space for this many new impropers per atom
{extra/special/per/atom} arg = leave space for extra 1-2,1-3,1-4 interactions per atom
{group} args = groupID
groupID = add atoms in data file to this group
{nocoeff} = ignore force field parameters
{fix} args = fix-ID header-string section-string
fix-ID = ID of fix to process header lines and sections of data file
header-string = header lines containing this string will be passed to fix
section-string = section names with this string will be passed to fix :pre
:ule
[Examples:]
read_data data.lj
read_data ../run7/data.polymer.gz
read_data data.protein fix mycmap crossterm CMAP
read_data data.water add append offset 3 1 1 1 1 shift 0.0 0.0 50.0
read_data data.water add merge 1 group solvent :pre
[Description:]
Read in a data file containing information LAMMPS needs to run a
simulation. The file can be ASCII text or a gzipped text file
(detected by a .gz suffix). This is one of 3 ways to specify initial
atom coordinates; see the "read_restart"_read_restart.html and
"create_atoms"_create_atoms.html commands for alternative methods.
Also see the explanation of the "-restart command-line
-switch"_Section_start.html#start_7 which can convert a restart file to
+switch"_Section_start.html#start_6 which can convert a restart file to
a data file.
This command can be used multiple times to add new atoms and their
properties to an existing system by using the {add}, {offset}, and
{shift} keywords. See more details below, which includes the use case
for the {extra} keywords.
The {group} keyword adds all the atoms in the data file to the
specified group-ID. The group will be created if it does not already
exist. This is useful if you are reading multiple data files and wish
to put sets of atoms into different groups so they can be operated on
later. E.g. a group of added atoms can be moved to new positions via
the "displace_atoms"_displace_atoms.html command. Note that atoms
read from the data file are also always added to the "all" group. The
"group"_group.html command discusses atom groups, as used in LAMMPS.
The {nocoeff} keyword tells read_data to ignore force field parameters.
The various Coeff sections are still read and have to have the correct
number of lines, but they are not applied. This also allows to read a
data file without having any pair, bond, angle, dihedral or improper
styles defined, or to read a data file for a different force field.
The use of the {fix} keyword is discussed below.
:line
[Reading multiple data files]
The read_data command can be used multiple times with the same or
different data files to build up a complex system from components
contained in individual data files. For example one data file could
contain fluid in a confined domain; a second could contain wall atoms,
and the second file could be read a third time to create a wall on the
other side of the fluid. The third set of atoms could be rotated to
an opposing direction using the "displace_atoms"_displace_atoms.html
command, after the third read_data command is used.
The {add}, {offset}, {shift}, {extra}, and {group} keywords are
useful in this context.
If a simulation box does not yet exist, the {add} keyword
cannot be used; the read_data command is being used for the first
time. If a simulation box does exist, due to using the
"create_box"_create_box.html command, or a previous read_data command,
then the {add} keyword must be used.
NOTE: The simulation box size (xlo to xhi, ylo to yhi, zlo to zhi) in
the new data file will be merged with the existing simulation box to
create a large enough box in each dimension to contain both the
existing and new atoms. Each box dimension never shrinks due to this
merge operation, it only stays the same or grows. Care must be used if
you are growing the existing simulation box in a periodic dimension.
If there are existing atoms with bonds that straddle that periodic
boundary, then the atoms may become far apart if the box size grows.
This will separate the atoms in the bond, which can lead to "lost"
bond atoms or bad dynamics.
The three choices for the {add} argument affect how the IDs of atoms
in the data file are treated. If {append} is specified, atoms in the
data file are added to the current system, with their atom IDs reset
so that an atomID = M in the data file becomes atomID = N+M, where N
is the largest atom ID in the current system. This rule is applied to
all occurrences of atom IDs in the data file, e.g. in the Velocity or
Bonds section. If {Nstart} is specified, then {Nstart} is a numeric
value is given, e.g. 1000, so that an atomID = M in the data file
becomes atomID = 1000+M. If {merge} is specified, the data file atoms
are added to the current system without changing their IDs. They are
assumed to merge (without duplication) with the currently defined
atoms. It is up to you to insure there are no multiply defined atom
IDs, as LAMMPS only performs an incomplete check that this is the case
by insuring the resulting max atomID >= the number of atoms.
The {offset} and {shift} keywords can only be used if the {add}
keyword is also specified.
The {offset} keyword adds the specified offset values to the atom
types, bond types, angle types, dihedral types, and improper types as
they are read from the data file. E.g. if {toff} = 2, and the file
uses atom types 1,2,3, then the added atoms will have atom types
3,4,5. These offsets apply to all occurrences of types in the data
file, e.g. for the Atoms or Masses or Pair Coeffs or Bond Coeffs
sections. This makes it easy to use atoms and molecules and their
attributes from a data file in different simulations, where you want
their types (atom, bond, angle, etc) to be different depending on what
other types already exist. All five offset values must be specified,
but individual values will be ignored if the data file does not use
that attribute (e.g. no bonds).
The {shift} keyword can be used to specify an (Sx, Sy, Sz)
displacement applied to the coordinates of each atom. Sz must be 0.0
for a 2d simulation. This is a mechanism for adding structured
collections of atoms at different locations within the simulation box,
to build up a complex geometry. It is up to you to insure atoms do
not end up overlapping unphysically which would lead to bad dynamics.
Note that the "displace_atoms"_displace_atoms.html command can be used
to move a subset of atoms after they have been read from a data file.
Likewise, the "delete_atoms"_delete_atoms.html command can be used to
remove overlapping atoms. Note that the shift values (Sx, Sy, Sz) are
also added to the simulation box information (xlo, xhi, ylo, yhi, zlo,
zhi) in the data file to shift its boundaries. E.g. xlo_new = xlo +
Sx, xhi_new = xhi + Sx.
The {extra} keywords can only be used the first time the read_data
command is used. They are useful if you intend to add new atom, bond,
angle, etc types later with additional read_data commands. This is
because the maximum number of allowed atom, bond, angle, etc types is
set by LAMMPS when the system is first initialized. If you do not use
the {extra} keywords, then the number of these types will be limited
to what appears in the first data file you read. For example, if the
first data file is a solid substrate of Si, it will likely specify a
single atom type. If you read a second data file with a different
material (water molecules) that sit on top of the substrate, you will
want to use different atom types for those atoms. You can only do
this if you set the {extra/atom/types} keyword to a sufficiently large
value when reading the substrate data file. Note that use of the
{extra} keywords also allows each data file to contain sections like
Masses or Pair Coeffs or Bond Coeffs which are sized appropriately for
the number of types in that data file. If the {offset} keyword is
used appropriately when each data file is read, the values in those
sections will be stored correctly in the larger data structures
allocated by the use of the {extra} keywords. E.g. the substrate file
can list mass and pair coefficients for type 1 silicon atoms. The
water file can list mass and pair coefficients for type 1 and type 2
hydrogen and oxygen atoms. Use of the {extra} and {offset} keywords
will store those mass and pair coefficient values appropriately in
data structures that allow for 3 atom types (Si, H, O). Of course,
you would still need to specify coefficients for H/Si and O/Si
interactions in your input script to have a complete pairwise
interaction model.
An alternative to using the {extra} keywords with the read_data
command, is to use the "create_box"_create_box.html command to
initialize the simulation box and all the various type limits you need
via its {extra} keywords. Then use the read_data command one or more
times to populate the system with atoms, bonds, angles, etc, using the
{offset} keyword if desired to alter types used in the various data
files you read.
:line
[Format of a data file]
The structure of the data file is important, though many settings and
sections are optional or can come in any order. See the examples
directory for sample data files for different problems.
A data file has a header and a body. The header appears first. The
first line of the header is always skipped; it typically contains a
description of the file. Then lines are read one at a time. Lines
can have a trailing comment starting with '#' that is ignored. If the
line is blank (only whitespace after comment is deleted), it is
skipped. If the line contains a header keyword, the corresponding
value(s) is read from the line. If it doesn't contain a header
keyword, the line begins the body of the file.
The body of the file contains zero or more sections. The first line
of a section has only a keyword. This line can have a trailing
comment starting with '#' that is either ignored or can be used to
check for a style match, as described below. The next line is
skipped. The remaining lines of the section contain values. The
number of lines depends on the section keyword as described below.
Zero or more blank lines can be used between sections. Sections can
appear in any order, with a few exceptions as noted below.
The keyword {fix} can be used one or more times. Each usage specifies
a fix that will be used to process a specific portion of the data
file. Any header line containing {header-string} and any section with
a name containing {section-string} will be passed to the specified
fix. See the "fix property/atom"_fix_property_atom.html command for
an example of a fix that operates in this manner. The doc page for
the fix defines the syntax of the header line(s) and section(s) that
it reads from the data file. Note that the {header-string} can be
specified as NULL, in which case no header lines are passed to the
fix. This means that it can infer the length of its Section from
standard header settings, such as the number of atoms.
The formatting of individual lines in the data file (indentation,
spacing between words and numbers) is not important except that header
and section keywords (e.g. atoms, xlo xhi, Masses, Bond Coeffs) must
be capitalized as shown and can't have extra white space between their
words - e.g. two spaces or a tab between the 2 words in "xlo xhi" or
the 2 words in "Bond Coeffs", is not valid.
:line
[Format of the header of a data file]
These are the recognized header keywords. Header lines can come in
any order. The value(s) are read from the beginning of the line.
Thus the keyword {atoms} should be in a line like "1000 atoms"; the
keyword {ylo yhi} should be in a line like "-10.0 10.0 ylo yhi"; the
keyword {xy xz yz} should be in a line like "0.0 5.0 6.0 xy xz yz".
All these settings have a default value of 0, except the lo/hi box
size defaults are -0.5 and 0.5. A line need only appear if the value
is different than the default.
{atoms} = # of atoms in system
{bonds} = # of bonds in system
{angles} = # of angles in system
{dihedrals} = # of dihedrals in system
{impropers} = # of impropers in system
{atom types} = # of atom types in system
{bond types} = # of bond types in system
{angle types} = # of angle types in system
{dihedral types} = # of dihedral types in system
{improper types} = # of improper types in system
{extra bond per atom} = leave space for this many new bonds per atom (deprecated, use extra/bond/per/atom keyword)
{extra angle per atom} = leave space for this many new angles per atom (deprecated, use extra/angle/per/atom keyword)
{extra dihedral per atom} = leave space for this many new dihedrals per atom (deprecated, use extra/dihedral/per/atom keyword)
{extra improper per atom} = leave space for this many new impropers per atom (deprecated, use extra/improper/per/atom keyword)
{extra special per atom} = leave space for this many new special bonds per atom (deprecated, use extra/special/per/atom keyword)
{ellipsoids} = # of ellipsoids in system
{lines} = # of line segments in system
{triangles} = # of triangles in system
{bodies} = # of bodies in system
{xlo xhi} = simulation box boundaries in x dimension
{ylo yhi} = simulation box boundaries in y dimension
{zlo zhi} = simulation box boundaries in z dimension
{xy xz yz} = simulation box tilt factors for triclinic system :ul
The initial simulation box size is determined by the lo/hi settings.
In any dimension, the system may be periodic or non-periodic; see the
"boundary"_boundary.html command. When the simulation box is created
it is also partitioned into a regular 3d grid of rectangular bricks,
one per processor, based on the number of processors being used and
the settings of the "processors"_processors.html command. The
partitioning can later be changed by the "balance"_balance.html or
"fix balance"_fix_balance.html commands.
If the {xy xz yz} line does not appear, LAMMPS will set up an
axis-aligned (orthogonal) simulation box. If the line does appear,
LAMMPS creates a non-orthogonal simulation domain shaped as a
parallelepiped with triclinic symmetry. The parallelepiped has its
"origin" at (xlo,ylo,zlo) and is defined by 3 edge vectors starting
from the origin given by A = (xhi-xlo,0,0); B = (xy,yhi-ylo,0); C =
(xz,yz,zhi-zlo). {Xy,xz,yz} can be 0.0 or positive or negative values
and are called "tilt factors" because they are the amount of
displacement applied to faces of an originally orthogonal box to
transform it into the parallelepiped.
By default, the tilt factors (xy,xz,yz) can not skew the box more than
half the distance of the corresponding parallel box length. For
example, if xlo = 2 and xhi = 12, then the x box length is 10 and the
xy tilt factor must be between -5 and 5. Similarly, both xz and yz
must be between -(xhi-xlo)/2 and +(yhi-ylo)/2. Note that this is not
a limitation, since if the maximum tilt factor is 5 (as in this
example), then configurations with tilt = ..., -15, -5, 5, 15, 25,
... are all geometrically equivalent. If you wish to define a box
with tilt factors that exceed these limits, you can use the "box
tilt"_box.html command, with a setting of {large}; a setting of
{small} is the default.
See "Section 6.12"_Section_howto.html#howto_12 of the doc pages
for a geometric description of triclinic boxes, as defined by LAMMPS,
and how to transform these parameters to and from other commonly used
triclinic representations.
When a triclinic system is used, the simulation domain should normally
be periodic in the dimension that the tilt is applied to, which is
given by the second dimension of the tilt factor (e.g. y for xy tilt).
This is so that pairs of atoms interacting across that boundary will
have one of them shifted by the tilt factor. Periodicity is set by
the "boundary"_boundary.html command. For example, if the xy tilt
factor is non-zero, then the y dimension should be periodic.
Similarly, the z dimension should be periodic if xz or yz is non-zero.
LAMMPS does not require this periodicity, but you may lose atoms if
this is not the case.
Also note that if your simulation will tilt the box, e.g. via the "fix
deform"_fix_deform.html command, the simulation box must be setup to
be triclinic, even if the tilt factors are initially 0.0. You can
also change an orthogonal box to a triclinic box or vice versa by
using the "change box"_change_box.html command with its {ortho} and
{triclinic} options.
For 2d simulations, the {zlo zhi} values should be set to bound the z
coords for atoms that appear in the file; the default of -0.5 0.5 is
valid if all z coords are 0.0. For 2d triclinic simulations, the xz
and yz tilt factors must be 0.0.
If the system is periodic (in a dimension), then atom coordinates can
be outside the bounds (in that dimension); they will be remapped (in a
periodic sense) back inside the box. Note that if the {add} option is
being used to add atoms to a simulation box that already exists, this
periodic remapping will be performed using simulation box bounds that
are the union of the existing box and the box boundaries in the new
data file.
NOTE: If the system is non-periodic (in a dimension), then all atoms
in the data file must have coordinates (in that dimension) that are
"greater than or equal to" the lo value and "less than or equal to"
the hi value. If the non-periodic dimension is of style "fixed" (see
the "boundary"_boundary.html command), then the atom coords must be
strictly "less than" the hi value, due to the way LAMMPS assign atoms
to processors. Note that you should not make the lo/hi values
radically smaller/larger than the extent of the atoms. For example,
if your atoms extend from 0 to 50, you should not specify the box
bounds as -10000 and 10000. This is because LAMMPS uses the specified
box size to layout the 3d grid of processors. A huge (mostly empty)
box will be sub-optimal for performance when using "fixed" boundary
conditions (see the "boundary"_boundary.html command). When using
"shrink-wrap" boundary conditions (see the "boundary"_boundary.html
command), a huge (mostly empty) box may cause a parallel simulation to
lose atoms when LAMMPS shrink-wraps the box around the atoms. The
read_data command will generate an error in this case.
The "extra bond per atom" setting (angle, dihedral, improper) is only
needed if new bonds (angles, dihedrals, impropers) will be added to
the system when a simulation runs, e.g. by using the "fix
bond/create"_fix_bond_create.html command. Using this header flag
is deprecated; please use the {extra/bond/per/atom} keyword (and
correspondingly for angles, dihedrals and impropers) in the
read_data command instead. Either will pre-allocate space in LAMMPS
data structures for storing the new bonds (angles,
dihedrals, impropers).
The "extra special per atom" setting is typically only needed if new
bonds/angles/etc will be added to the system, e.g. by using the "fix
bond/create"_fix_bond_create.html command. Or if entire new molecules
will be added to the system, e.g. by using the
"fix deposit"_fix_deposit.html or "fix pour"_fix_pour.html commands,
which will have more special 1-2,1-3,1-4 neighbors than any other
molecules defined in the data file. Using this header flag is
deprecated; please use the {extra/special/per/atom} keyword instead.
Using this setting will pre-allocate space in the LAMMPS data
structures for storing these neighbors. See the
"special_bonds"_special_bonds.html and "molecule"_molecule.html doc
pages for more discussion of 1-2,1-3,1-4 neighbors.
NOTE: All of the "extra" settings are only applied in the first data
file read and when no simulation box has yet been created; as soon as
the simulation box is created (and read_data implies that), these
settings are {locked} and cannot be changed anymore. Please see the
description of the {add} keyword above for reading multiple data files.
If they appear in later data files, they are ignored.
The "ellipsoids" and "lines" and "triangles" and "bodies" settings are
only used with "atom_style ellipsoid or line or tri or
body"_atom_style.html and specify how many of the atoms are
finite-size ellipsoids or lines or triangles or bodies; the remainder
are point particles. See the discussion of ellipsoidflag and the
{Ellipsoids} section below. See the discussion of lineflag and the
{Lines} section below. See the discussion of triangleflag and the
{Triangles} section below. See the discussion of bodyflag and the
{Bodies} section below.
NOTE: For "atom_style template"_atom_style.html, the molecular
topology (bonds,angles,etc) is contained in the molecule templates
read-in by the "molecule"_molecule.html command. This means you
cannot set the {bonds}, {angles}, etc header keywords in the data
file, nor can you define {Bonds}, {Angles}, etc sections as discussed
below. You can set the {bond types}, {angle types}, etc header
keywords, though it is not necessary. If specified, they must match
the maximum values defined in any of the template molecules.
:line
[Format of the body of a data file]
These are the section keywords for the body of the file.
{Atoms, Velocities, Masses, Ellipsoids, Lines, Triangles, Bodies} = atom-property sections
{Bonds, Angles, Dihedrals, Impropers} = molecular topology sections
{Pair Coeffs, PairIJ Coeffs, Bond Coeffs, Angle Coeffs, Dihedral Coeffs, \
Improper Coeffs} = force field sections
{BondBond Coeffs, BondAngle Coeffs, MiddleBondTorsion Coeffs, \
EndBondTorsion Coeffs, AngleTorsion Coeffs, AngleAngleTorsion Coeffs, \
BondBond13 Coeffs, AngleAngle Coeffs} = class 2 force field sections :ul
These keywords will check an appended comment for a match with the
currently defined style:
{Atoms, Pair Coeffs, PairIJ Coeffs, Bond Coeffs, Angle Coeffs, Dihedral Coeffs, Improper Coeffs} :ul
For example, these lines:
Atoms # sphere
Pair Coeffs # lj/cut :pre
will check if the currently-defined "atom_style"_atom_style.html is
{sphere}, and the current "pair_style"_pair_style.html is {lj/cut}.
If not, LAMMPS will issue a warning to indicate that the data file
section likely does not contain the correct number or type of
parameters expected for the currently-defined style.
Each section is listed below in alphabetic order. The format of each
section is described including the number of lines it must contain and
rules (if any) for where it can appear in the data file.
Any individual line in the various sections can have a trailing
comment starting with "#" for annotation purposes. E.g. in the
Atoms section:
10 1 17 -1.0 10.0 5.0 6.0 # salt ion :pre
:line
{Angle Coeffs} section:
one line per angle type :ulb,l
line syntax: ID coeffs :l
ID = angle type (1-N)
coeffs = list of coeffs :pre
example: :l
6 70 108.5 0 0 :pre
:ule
The number and meaning of the coefficients are specific to the defined
angle style. See the "angle_style"_angle_style.html and
"angle_coeff"_angle_coeff.html commands for details. Coefficients can
also be set via the "angle_coeff"_angle_coeff.html command in the
input script.
:line
{AngleAngle Coeffs} section:
one line per improper type :ulb,l
line syntax: ID coeffs :l
ID = improper type (1-N)
coeffs = list of coeffs (see "improper_coeff"_improper_coeff.html) :pre
:ule
:line
{AngleAngleTorsion Coeffs} section:
one line per dihedral type :ulb,l
line syntax: ID coeffs :l
ID = dihedral type (1-N)
coeffs = list of coeffs (see "dihedral_coeff"_dihedral_coeff.html) :pre
:ule
:line
{Angles} section:
one line per angle :ulb,l
line syntax: ID type atom1 atom2 atom3 :l
ID = number of angle (1-Nangles)
type = angle type (1-Nangletype)
atom1,atom2,atom3 = IDs of 1st,2nd,3rd atoms in angle :pre
example: :b
2 2 17 29 430 :pre
:ule
The 3 atoms are ordered linearly within the angle. Thus the central
atom (around which the angle is computed) is the atom2 in the list.
E.g. H,O,H for a water molecule. The {Angles} section must appear
after the {Atoms} section. All values in this section must be
integers (1, not 1.0).
:line
{AngleTorsion Coeffs} section:
one line per dihedral type :ulb,l
line syntax: ID coeffs :l
ID = dihedral type (1-N)
coeffs = list of coeffs (see "dihedral_coeff"_dihedral_coeff.html) :pre
:ule
:line
{Atoms} section:
one line per atom
line syntax: depends on atom style :ul
An {Atoms} section must appear in the data file if natoms > 0 in the
header section. The atoms can be listed in any order. These are the
line formats for each "atom style"_atom_style.html in LAMMPS. As
discussed below, each line can optionally have 3 flags (nx,ny,nz)
appended to it, which indicate which image of a periodic simulation
box the atom is in. These may be important to include for some kinds
of analysis.
angle: atom-ID molecule-ID atom-type x y z
atomic: atom-ID atom-type x y z
body: atom-ID atom-type bodyflag mass x y z
bond: atom-ID molecule-ID atom-type x y z
charge: atom-ID atom-type q x y z
dipole: atom-ID atom-type q x y z mux muy muz
dpd: atom-ID atom-type theta x y z
electron: atom-ID atom-type q spin eradius x y z
ellipsoid: atom-ID atom-type ellipsoidflag density x y z
full: atom-ID molecule-ID atom-type q x y z
line: atom-ID molecule-ID atom-type lineflag density x y z
meso: atom-ID atom-type rho e cv x y z
molecular: atom-ID molecule-ID atom-type x y z
peri: atom-ID atom-type volume density x y z
smd: atom-ID atom-type molecule volume mass kernel-radius contact-radius x y z
sphere: atom-ID atom-type diameter density x y z
template: atom-ID molecule-ID template-index template-atom atom-type x y z
tri: atom-ID molecule-ID atom-type triangleflag density x y z
wavepacket: atom-ID atom-type charge spin eradius etag cs_re cs_im x y z
hybrid: atom-ID atom-type x y z sub-style1 sub-style2 ... :tb(s=:)
The per-atom values have these meanings and units, listed alphabetically:
atom-ID = integer ID of atom
atom-type = type of atom (1-Ntype)
bodyflag = 1 for body particles, 0 for point particles
contact-radius = ??? (distance units)
cs_re,cs_im = real/imaginary parts of wavepacket coefficients
cv = heat capacity (need units) for SPH particles
density = density of particle (mass/distance^3 or mass/distance^2 or mass/distance units, depending on dimensionality of particle)
diameter = diameter of spherical atom (distance units)
e = energy (need units) for SPH particles
ellipsoidflag = 1 for ellipsoidal particles, 0 for point particles
eradius = electron radius (or fixed-core radius)
etag = integer ID of electron that each wavepacket belongs to
kernel-radius = ??? (distance units)
lineflag = 1 for line segment particles, 0 for point or spherical particles
mass = mass of particle (mass units)
molecule-ID = integer ID of molecule the atom belongs to
mux,muy,muz = components of dipole moment of atom (dipole units)
q = charge on atom (charge units)
rho = density (need units) for SPH particles
spin = electron spin (+1/-1), 0 = nuclei, 2 = fixed-core, 3 = pseudo-cores (i.e. ECP)
template-atom = which atom within a template molecule the atom is
template-index = which molecule within the molecule template the atom is part of
theta = internal temperature of a DPD particle
triangleflag = 1 for triangular particles, 0 for point or spherical particles
volume = volume of Peridynamic particle (distance^3 units)
x,y,z = coordinates of atom (distance units) :ul
The units for these quantities depend on the unit style; see the
"units"_units.html command for details.
For 2d simulations specify z as 0.0, or a value within the {zlo zhi}
setting in the data file header.
The atom-ID is used to identify the atom throughout the simulation and
in dump files. Normally, it is a unique value from 1 to Natoms for
each atom. Unique values larger than Natoms can be used, but they
will cause extra memory to be allocated on each processor, if an atom
map array is used, but not if an atom map hash is used; see the
"atom_modify"_atom_modify.html command for details. If an atom map is
not used (e.g. an atomic system with no bonds), and you don't care if
unique atom IDs appear in dump files, then the atom-IDs can all be set
to 0.
The molecule ID is a 2nd identifier attached to an atom. Normally, it
is a number from 1 to N, identifying which molecule the atom belongs
to. It can be 0 if it is an unbonded atom or if you don't care to
keep track of molecule assignments.
The diameter specifies the size of a finite-size spherical particle.
It can be set to 0.0, which means that atom is a point particle.
The ellipsoidflag, lineflag, triangleflag, and bodyflag determine
whether the particle is a finite-size ellipsoid or line or triangle or
body of finite size, or whether the particle is a point particle.
Additional attributes must be defined for each ellipsoid, line,
triangle, or body in the corresponding {Ellipsoids}, {Lines},
{Triangles}, or {Bodies} section.
The {template-index} and {template-atom} are only defined used by
"atom_style template"_atom_style.html. In this case the
"molecule"_molecule.html command is used to define a molecule template
which contains one or more molecules. If an atom belongs to one of
those molecules, its {template-index} and {template-atom} are both set
to positive integers; if not the values are both 0. The
{template-index} is which molecule (1 to Nmols) the atom belongs to.
The {template-atom} is which atom (1 to Natoms) within the molecule
the atom is.
Some pair styles and fixes and computes that operate on finite-size
particles allow for a mixture of finite-size and point particles. See
the doc pages of individual commands for details.
For finite-size particles, the density is used in conjunction with the
particle volume to set the mass of each particle as mass = density *
volume. In this context, volume can be a 3d quantity (for spheres or
ellipsoids), a 2d quantity (for triangles), or a 1d quantity (for line
segments). If the volume is 0.0, meaning a point particle, then the
density value is used as the mass. One exception is for the body atom
style, in which case the mass of each particle (body or point
particle) is specified explicitly. This is because the volume of the
body is unknown.
Note that for 2d simulations of spheres, this command will treat them
as spheres when converting density to mass. However, they can also be
modeled as 2d discs (circles) if the "set density/disc"_set.html
command is used to reset their mass after the read_data command is
used. A {disc} keyword can also be used with time integration fixes,
such as "fix nve/sphere"_fix_nve_sphere.html and "fix
nvt/sphere"_fix_nve_sphere.html to time integrate their motion as 2d
discs (not 3d spheres), by changing their moment of inertia.
For atom_style hybrid, following the 5 initial values (ID,type,x,y,z),
specific values for each sub-style must be listed. The order of the
sub-styles is the same as they were listed in the
"atom_style"_atom_style.html command. The sub-style specific values
are those that are not the 5 standard ones (ID,type,x,y,z). For
example, for the "charge" sub-style, a "q" value would appear. For
the "full" sub-style, a "molecule-ID" and "q" would appear. These are
listed in the same order they appear as listed above. Thus if
atom_style hybrid charge sphere :pre
were used in the input script, each atom line would have these fields:
atom-ID atom-type x y z q diameter density :pre
Note that if a non-standard value is defined by multiple sub-styles,
it must appear mutliple times in the atom line. E.g. the atom line
for atom_style hybrid dipole full would list "q" twice:
atom-ID atom-type x y z q mux muy myz molecule-ID q :pre
Atom lines specify the (x,y,z) coordinates of atoms. These can be
inside or outside the simulation box. When the data file is read,
LAMMPS wraps coordinates outside the box back into the box for
dimensions that are periodic. As discussed above, if an atom is
outside the box in a non-periodic dimension, it will be lost.
LAMMPS always stores atom coordinates as values which are inside the
simulation box. It also stores 3 flags which indicate which image of
the simulation box (in each dimension) the atom would be in if its
coordinates were unwrapped across periodic boundaries. An image flag
of 0 means the atom is still inside the box when unwrapped. A value
of 2 means add 2 box lengths to get the unwrapped coordinate. A value
of -1 means subtract 1 box length to get the unwrapped coordinate.
LAMMPS updates these flags as atoms cross periodic boundaries during
the simulation. The "dump"_dump.html command can output atom atom
coordinates in wrapped or unwrapped form, as well as the 3 image
flags.
In the data file, atom lines (all lines or none of them) can
optionally list 3 trailing integer values (nx,ny,nz), which are used
to initialize the atom's image flags. If nx,ny,nz values are not
listed in the data file, LAMMPS initializes them to 0. Note that the
image flags are immediately updated if an atom's coordinates need to
wrapped back into the simulation box.
It is only important to set image flags correctly in a data file if a
simulation model relies on unwrapped coordinates for some calculation;
otherwise they can be left unspecified. Examples of LAMMPS commands
that use unwrapped coordinates internally are as follows:
Atoms in a rigid body (see "fix rigid"_fix_rigid.html, "fix
rigid/small"_fix_rigid.html) must have consistent image flags, so that
when the atoms are unwrapped, they are near each other, i.e. as a
single body. :ulb,l
If the "replicate"_replicate.html command is used to generate a larger
system, image flags must be consistent for bonded atoms when the bond
crosses a periodic boundary. I.e. the values of the image flags
should be different by 1 (in the appropriate dimension) for the two
atoms in such a bond. :l
If you plan to "dump"_dump.html image flags and perform post-analysis
that will unwrap atom coordinates, it may be important that a
continued run (restarted from a data file) begins with image flags
that are consistent with the previous run. :l
:ule
NOTE: If your system is an infinite periodic crystal with bonds then
it is impossible to have fully consistent image flags. This is because
some bonds will cross periodic boundaries and connect two atoms with the
same image flag.
Atom velocities and other atom quantities not defined above are set to
0.0 when the {Atoms} section is read. Velocities can be set later by
a {Velocities} section in the data file or by a
"velocity"_velocity.html or "set"_set.html command in the input
script.
:line
{Bodies} section:
one or more lines per body :ulb,l
first line syntax: atom-ID Ninteger Ndouble :l
Ninteger = # of integer quantities for this particle
Ndouble = # of floating-point quantities for this particle :pre
0 or more integer lines with total of Ninteger values :l
0 or more double lines with total of Ndouble values :l
example: :l
12 3 6
2 3 2
1.0 2.0 3.0 1.0 2.0 4.0 :pre
example: :l
12 0 14
1.0 2.0 3.0 1.0 2.0 4.0 1.0
2.0 3.0 1.0 2.0 4.0 4.0 2.0 :pre
:ule
The {Bodies} section must appear if "atom_style body"_atom_style.html
is used and any atoms listed in the {Atoms} section have a bodyflag =
1. The number of bodies should be specified in the header section via
the "bodies" keyword.
Each body can have a variable number of integer and/or floating-point
values. The number and meaning of the values is defined by the body
style, as described in the "body"_body.html doc page. The body style
is given as an argument to the "atom_style body"_atom_style.html
command.
The Ninteger and Ndouble values determine how many integer and
floating-point values are specified for this particle. Ninteger and
Ndouble can be as large as needed and can be different for every body.
Integer values are then listed next on subsequent lines. Lines are
read one at a time until Ninteger values are read. Floating-point
values follow on subsequent lines, Again lines are read one at a time
until Ndouble values are read. Note that if there are no values of a
particular type, no lines appear for that type.
The {Bodies} section must appear after the {Atoms} section.
:line
{Bond Coeffs} section:
one line per bond type :ulb,l
line syntax: ID coeffs :l
ID = bond type (1-N)
coeffs = list of coeffs :pre
example: :l
4 250 1.49 :pre
:ule
The number and meaning of the coefficients are specific to the defined
bond style. See the "bond_style"_bond_style.html and
"bond_coeff"_bond_coeff.html commands for details. Coefficients can
also be set via the "bond_coeff"_bond_coeff.html command in the input
script.
:line
{BondAngle Coeffs} section:
one line per angle type :ulb,l
line syntax: ID coeffs :l
ID = angle type (1-N)
coeffs = list of coeffs (see class 2 section of "angle_coeff"_angle_coeff.html) :pre
:ule
:line
{BondBond Coeffs} section:
one line per angle type :ulb,l
line syntax: ID coeffs :l
ID = angle type (1-N)
coeffs = list of coeffs (see class 2 section of "angle_coeff"_angle_coeff.html) :pre
:ule
:line
{BondBond13 Coeffs} section:
one line per dihedral type :ulb,l
line syntax: ID coeffs :l
ID = dihedral type (1-N)
coeffs = list of coeffs (see class 2 section of "dihedral_coeff"_dihedral_coeff.html) :pre
:ule
:line
{Bonds} section:
one line per bond :ulb,l
line syntax: ID type atom1 atom2 :l
ID = bond number (1-Nbonds)
type = bond type (1-Nbondtype)
atom1,atom2 = IDs of 1st,2nd atoms in bond :pre
example: :l
12 3 17 29 :pre
:ule
The {Bonds} section must appear after the {Atoms} section. All values
in this section must be integers (1, not 1.0).
:line
{Dihedral Coeffs} section:
one line per dihedral type :ulb,l
line syntax: ID coeffs :l
ID = dihedral type (1-N)
coeffs = list of coeffs :pre
example: :l
3 0.6 1 0 1 :pre
:ule
The number and meaning of the coefficients are specific to the defined
dihedral style. See the "dihedral_style"_dihedral_style.html and
"dihedral_coeff"_dihedral_coeff.html commands for details.
Coefficients can also be set via the
"dihedral_coeff"_dihedral_coeff.html command in the input script.
:line
{Dihedrals} section:
one line per dihedral :ulb,l
line syntax: ID type atom1 atom2 atom3 atom4 :l
ID = number of dihedral (1-Ndihedrals)
type = dihedral type (1-Ndihedraltype)
atom1,atom2,atom3,atom4 = IDs of 1st,2nd,3rd,4th atoms in dihedral :pre
example: :l
12 4 17 29 30 21 :pre
:ule
The 4 atoms are ordered linearly within the dihedral. The {Dihedrals}
section must appear after the {Atoms} section. All values in this
section must be integers (1, not 1.0).
:line
{Ellipsoids} section:
one line per ellipsoid :ulb,l
line syntax: atom-ID shapex shapey shapez quatw quati quatj quatk :l
atom-ID = ID of atom which is an ellipsoid
shapex,shapey,shapez = 3 diameters of ellipsoid (distance units)
quatw,quati,quatj,quatk = quaternion components for orientation of atom :pre
example: :l
12 1 2 1 1 0 0 0 :pre
:ule
The {Ellipsoids} section must appear if "atom_style
ellipsoid"_atom_style.html is used and any atoms are listed in the
{Atoms} section with an ellipsoidflag = 1. The number of ellipsoids
should be specified in the header section via the "ellipsoids"
keyword.
The 3 shape values specify the 3 diameters or aspect ratios of a
finite-size ellipsoidal particle, when it is oriented along the 3
coordinate axes. They must all be non-zero values.
The values {quatw}, {quati}, {quatj}, and {quatk} set the orientation
of the atom as a quaternion (4-vector). Note that the shape
attributes specify the aspect ratios of an ellipsoidal particle, which
is oriented by default with its x-axis along the simulation box's
x-axis, and similarly for y and z. If this body is rotated (via the
right-hand rule) by an angle theta around a unit vector (a,b,c), then
the quaternion that represents its new orientation is given by
(cos(theta/2), a*sin(theta/2), b*sin(theta/2), c*sin(theta/2)). These
4 components are quatw, quati, quatj, and quatk as specified above.
LAMMPS normalizes each atom's quaternion in case (a,b,c) is not
specified as a unit vector.
The {Ellipsoids} section must appear after the {Atoms} section.
:line
{EndBondTorsion Coeffs} section:
one line per dihedral type :ulb,l
line syntax: ID coeffs :l
ID = dihedral type (1-N)
coeffs = list of coeffs (see class 2 section of "dihedral_coeff"_dihedral_coeff.html) :pre
:ule
:line
{Improper Coeffs} section:
one line per improper type :ulb,l
line syntax: ID coeffs :l
ID = improper type (1-N)
coeffs = list of coeffs :pre
example: :l
2 20 0.0548311 :pre
:ule
The number and meaning of the coefficients are specific to the defined
improper style. See the "improper_style"_improper_style.html and
"improper_coeff"_improper_coeff.html commands for details.
Coefficients can also be set via the
"improper_coeff"_improper_coeff.html command in the input script.
:line
{Impropers} section:
one line per improper :ulb,l
line syntax: ID type atom1 atom2 atom3 atom4 :l
ID = number of improper (1-Nimpropers)
type = improper type (1-Nimpropertype)
atom1,atom2,atom3,atom4 = IDs of 1st,2nd,3rd,4th atoms in improper :pre
example: :l
12 3 17 29 13 100 :pre
:ule
The ordering of the 4 atoms determines the definition of the improper
angle used in the formula for each "improper
style"_improper_style.html. See the doc pages for individual styles
for details.
The {Impropers} section must appear after the {Atoms} section. All
values in this section must be integers (1, not 1.0).
:line
{Lines} section:
one line per line segment :ulb,l
line syntax: atom-ID x1 y1 x2 y2 :l
atom-ID = ID of atom which is a line segment
x1,y1 = 1st end point
x2,y2 = 2nd end point :pre
example: :l
12 1.0 0.0 2.0 0.0 :pre
:ule
The {Lines} section must appear if "atom_style line"_atom_style.html
is used and any atoms are listed in the {Atoms} section with a
lineflag = 1. The number of lines should be specified in the header
section via the "lines" keyword.
The 2 end points are the end points of the line segment. The ordering
of the 2 points should be such that using a right-hand rule to cross
the line segment with a unit vector in the +z direction, gives an
"outward" normal vector perpendicular to the line segment.
I.e. normal = (c2-c1) x (0,0,1). This orientation may be important
for defining some interactions.
The {Lines} section must appear after the {Atoms} section.
:line
{Masses} section:
one line per atom type :ulb,l
line syntax: ID mass :l
ID = atom type (1-N)
mass = mass value :pre
example: :l
3 1.01 :pre
:ule
This defines the mass of each atom type. This can also be set via the
"mass"_mass.html command in the input script. This section cannot be
used for atom styles that define a mass for individual atoms -
e.g. "atom_style sphere"_atom_style.html.
:line
{MiddleBondTorsion Coeffs} section:
one line per dihedral type :ulb,l
line syntax: ID coeffs :l
ID = dihedral type (1-N)
coeffs = list of coeffs (see class 2 section of "dihedral_coeff"_dihedral_coeff.html) :pre
:ule
:line
{Pair Coeffs} section:
one line per atom type :ulb,l
line syntax: ID coeffs :l
ID = atom type (1-N)
coeffs = list of coeffs :pre
example: :l
3 0.022 2.35197 0.022 2.35197 :pre
:ule
The number and meaning of the coefficients are specific to the defined
pair style. See the "pair_style"_pair_style.html and
"pair_coeff"_pair_coeff.html commands for details. Since pair
coefficients for types I != J are not specified, these will be
generated automatically by the pair style's mixing rule. See the
individual pair_style doc pages and the "pair_modify
mix"_pair_modify.html command for details. Pair coefficients can also
be set via the "pair_coeff"_pair_coeff.html command in the input
script.
:line
{PairIJ Coeffs} section:
one line per pair of atom types for all I,J with I <= J :ulb,l
line syntax: ID1 ID2 coeffs :l
ID1 = atom type I = 1-N
ID2 = atom type J = I-N, with I <= J
coeffs = list of coeffs :pre
examples: :l
3 3 0.022 2.35197 0.022 2.35197
3 5 0.022 2.35197 0.022 2.35197 :pre
:ule
This section must have N*(N+1)/2 lines where N = # of atom types. The
number and meaning of the coefficients are specific to the defined
pair style. See the "pair_style"_pair_style.html and
"pair_coeff"_pair_coeff.html commands for details. Since pair
coefficients for types I != J are all specified, these values will
turn off the default mixing rule defined by the pair style. See the
individual pair_style doc pages and the "pair_modify
mix"_pair_modify.html command for details. Pair coefficients can also
be set via the "pair_coeff"_pair_coeff.html command in the input
script.
:line
{Triangles} section:
one line per triangle :ulb,l
line syntax: atom-ID x1 y1 z1 x2 y2 z2 x3 y3 z3 :l
atom-ID = ID of atom which is a line segment
x1,y1,z1 = 1st corner point
x2,y2,z2 = 2nd corner point
x3,y3,z3 = 3rd corner point :pre
example: :l
12 0.0 0.0 0.0 2.0 0.0 1.0 0.0 2.0 1.0 :pre
:ule
The {Triangles} section must appear if "atom_style
tri"_atom_style.html is used and any atoms are listed in the {Atoms}
section with a triangleflag = 1. The number of lines should be
specified in the header section via the "triangles" keyword.
The 3 corner points are the corner points of the triangle. The
ordering of the 3 points should be such that using a right-hand rule
to go from point1 to point2 to point3 gives an "outward" normal vector
to the face of the triangle. I.e. normal = (c2-c1) x (c3-c1). This
orientation may be important for defining some interactions.
The {Triangles} section must appear after the {Atoms} section.
:line
{Velocities} section:
one line per atom
line syntax: depends on atom style :ul
all styles except those listed: atom-ID vx vy vz
electron: atom-ID vx vy vz ervel
ellipsoid: atom-ID vx vy vz lx ly lz
sphere: atom-ID vx vy vz wx wy wz
hybrid: atom-ID vx vy vz sub-style1 sub-style2 ... :tb(s=:)
where the keywords have these meanings:
vx,vy,vz = translational velocity of atom
lx,ly,lz = angular momentum of aspherical atom
wx,wy,wz = angular velocity of spherical atom
ervel = electron radial velocity (0 for fixed-core):ul
The velocity lines can appear in any order. This section can only be
used after an {Atoms} section. This is because the {Atoms} section
must have assigned a unique atom ID to each atom so that velocities
can be assigned to them.
Vx, vy, vz, and ervel are in "units"_units.html of velocity. Lx, ly,
lz are in units of angular momentum (distance-velocity-mass). Wx, Wy,
Wz are in units of angular velocity (radians/time).
For atom_style hybrid, following the 4 initial values (ID,vx,vy,vz),
specific values for each sub-style must be listed. The order of the
sub-styles is the same as they were listed in the
"atom_style"_atom_style.html command. The sub-style specific values
are those that are not the 5 standard ones (ID,vx,vy,vz). For
example, for the "sphere" sub-style, "wx", "wy", "wz" values would
appear. These are listed in the same order they appear as listed
above. Thus if
atom_style hybrid electron sphere :pre
were used in the input script, each velocity line would have these
fields:
atom-ID vx vy vz ervel wx wy wz :pre
Translational velocities can also be set by the
"velocity"_velocity.html command in the input script.
:line
[Restrictions:]
To read gzipped data files, you must compile LAMMPS with the
-DLAMMPS_GZIP option - see the "Making
LAMMPS"_Section_start.html#start_2 section of the documentation.
[Related commands:]
"read_dump"_read_dump.html, "read_restart"_read_restart.html,
"create_atoms"_create_atoms.html, "write_data"_write_data.html
[Default:]
The default for all the {extra} keywords is 0.
diff --git a/doc/src/read_restart.txt b/doc/src/read_restart.txt
index d0f4b1617..d1091542b 100644
--- a/doc/src/read_restart.txt
+++ b/doc/src/read_restart.txt
@@ -1,272 +1,272 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
read_restart command :h3
[Syntax:]
read_restart file flag :pre
file = name of binary restart file to read in
flag = remap (optional) :ul
[Examples:]
read_restart save.10000
read_restart save.10000 remap
read_restart restart.*
read_restart restart.*.mpiio
read_restart poly.*.% remap :pre
[Description:]
Read in a previously saved system configuration from a restart file.
This allows continuation of a previous run. Details about what
information is stored (and not stored) in a restart file is given
below. Basically this operation will re-create the simulation box
with all its atoms and their attributes as well as some related global
settings, at the point in time it was written to the restart file by a
previous simulation. The simulation box will be partitioned into a
regular 3d grid of rectangular bricks, one per processor, based on the
number of processors in the current simulation and the settings of the
"processors"_processors.html command. The partitioning can later be
changed by the "balance"_balance.html or "fix
balance"_fix_balance.html commands.
NOTE: Normally, restart files are written by the
"restart"_restart.html or "write_restart"_write_restart.html commands
so that all atoms in the restart file are inside the simulation box.
If this is not the case, the read_restart command will print an error
that atoms were "lost" when the file is read. This error should be
reported to the LAMMPS developers so the invalid writing of the
restart file can be fixed. If you still wish to use the restart file,
the optional {remap} flag can be appended to the read_restart command.
This should avoid the error, by explicitly remapping each atom back
into the simulation box, updating image flags for the atom
appropriately.
Restart files are saved in binary format to enable exact restarts,
meaning that the trajectories of a restarted run will precisely match
those produced by the original run had it continued on.
Several things can prevent exact restarts due to round-off effects, in
which case the trajectories in the 2 runs will slowly diverge. These
include running on a different number of processors or changing
certain settings such as those set by the "newton"_newton.html or
"processors"_processors.html commands. LAMMPS will issue a warning in
these cases.
Certain fixes will not restart exactly, though they should provide
statistically similar results. These include "fix
shake"_fix_shake.html and "fix langevin"_fix_langevin.html.
Certain pair styles will not restart exactly, though they should
provide statistically similar results. This is because the forces
they compute depend on atom velocities, which are used at half-step
values every timestep when forces are computed. When a run restarts,
forces are initially evaluated with a full-step velocity, which is
different than if the run had continued. These pair styles include
"granular pair styles"_pair_gran.html, "pair dpd"_pair_dpd.html, and
"pair lubricate"_pair_lubricate.html.
If a restarted run is immediately different than the run which
produced the restart file, it could be a LAMMPS bug, so consider
"reporting it"_Section_errors.html#err_2 if you think the behavior is
wrong.
Because restart files are binary, they may not be portable to other
machines. In this case, you can use the "-restart command-line
-switch"_Section_start.html#start_7 to convert a restart file to a data
+switch"_Section_start.html#start_6 to convert a restart file to a data
file.
Similar to how restart files are written (see the
"write_restart"_write_restart.html and "restart"_restart.html
commands), the restart filename can contain two wild-card characters.
If a "*" appears in the filename, the directory is searched for all
filenames that match the pattern where "*" is replaced with a timestep
value. The file with the largest timestep value is read in. Thus,
this effectively means, read the latest restart file. It's useful if
you want your script to continue a run from where it left off. See
the "run"_run.html command and its "upto" option for how to specify
the run command so it doesn't need to be changed either.
If a "%" character appears in the restart filename, LAMMPS expects a
set of multiple files to exist. The "restart"_restart.html and
"write_restart"_write_restart.html commands explain how such sets are
created. Read_restart will first read a filename where "%" is
replaced by "base". This file tells LAMMPS how many processors
created the set and how many files are in it. Read_restart then reads
the additional files. For example, if the restart file was specified
as save.% when it was written, then read_restart reads the files
save.base, save.0, save.1, ... save.P-1, where P is the number of
processors that created the restart file.
Note that P could be the total number of processors in the previous
simulation, or some subset of those processors, if the {fileper} or
{nfile} options were used when the restart file was written; see the
"restart"_restart.html and "write_restart"_write_restart.html commands
for details. The processors in the current LAMMPS simulation share
the work of reading these files; each reads a roughly equal subset of
the files. The number of processors which created the set can be
different the number of processors in the current LAMMPS simulation.
This can be a fast mode of input on parallel machines that support
parallel I/O.
A restart file can also be read in parallel as one large binary file
via the MPI-IO library, assuming it was also written with MPI-IO.
MPI-IO is part of the MPI standard for versions 2.0 and above. Using
MPI-IO requires two steps. First, build LAMMPS with its MPIIO package
installed, e.g.
make yes-mpiio # installs the MPIIO package
make mpi # build LAMMPS for your platform :pre
Second, use a restart filename which contains ".mpiio". Note that it
does not have to end in ".mpiio", just contain those characters.
Unlike MPI-IO dump files, a particular restart file must be both
written and read using MPI-IO.
:line
Here is the list of information included in a restart file, which
means these quantities do not need to be re-specified in the input
script that reads the restart file, though you can redefine many of
these settings after the restart file is read.
"units"_units.html
"newton bond"_newton.html (see discussion of newton command below)
"atom style"_atom_style.html and "atom_modify"_atom_modify.html settings id, map, sort
"comm style"_comm_style.html and "comm_modify"_comm_modify.html settings mode, cutoff, vel
"timestep"_timestep.html
simulation box size and shape and "boundary"_boundary.html settings
atom "group"_group.html definitions
per-type atom settings such as "mass"_mass.html
per-atom attributes including their group assignments and molecular topology attributes (bonds, angles, etc)
force field styles ("pair"_pair_style.html, "bond"_bond_style.html, "angle"_angle_style.html, etc)
force field coefficients ("pair"_pair_coeff.html, "bond"_bond_coeff.html, "angle"_angle_coeff.html, etc) in some cases (see below)
"pair_modify"_pair_modify.html settings, except the compute option
"special_bonds"_special_bonds.html settings :ul
Here is a list of information not stored in a restart file, which
means you must re-issue these commands in your input script, after
reading the restart file.
"newton pair"_newton.html (see discussion of newton command below)
"fix"_fix.html commands (see below)
"compute"_compute.html commands (see below)
"variable"_variable.html commands
"region"_region.html commands
"neighbor list"_neighbor.html criteria including "neigh_modify"_neigh_modify.html settings
"kspace_style"_kspace_style.html and "kspace_modify"_kspace_modify.html settings
info for "thermodynamic"_thermo_style.html, "dump"_dump.html, or "restart"_restart.html output :ul
The "newton"_newton.html command has two settings, one for pairwise
interactions, the other for bonded. Both settings are stored in the
restart file. For the bond setting, the value in the file will
overwrite the current value (at the time the read_restart command is
issued) and warn if the two values are not the same and the current
value is not the default. For the pair setting, the value in the file
will not overwrite the current value (so that you can override the
previous run's value), but a warning is issued if the two values are
not the same and the current value is not the default.
Note that some force field styles (pair, bond, angle, etc) do not
store their coefficient info in restart files. Typically these are
many-body or tabulated potentials which read their parameters from
separate files. In these cases you will need to re-specify the "pair
"pair_coeff"_pair_coeff.html, "bond_coeff"_bond_coeff.html, etc
commands in your restart input script. The doc pages for individual
force field styles mention if this is the case. This is also true of
"pair_style hybrid"_pair_hybrid.html (bond hybrid, angle hybrid, etc)
commands; they do not store coefficient info.
As indicated in the above list, the "fixes"_fix.html used for a
simulation are not stored in the restart file. This means the new
input script should specify all fixes it will use. However, note that
some fixes store an internal "state" which is written to the restart
file. This allows the fix to continue on with its calculations in a
restarted simulation. To re-enable such a fix, the fix command in the
new input script must be of the same style and use the same fix-ID as
was used in the input script that wrote the restart file.
If a match is found, LAMMPS prints a message indicating that the fix
is being re-enabled. If no match is found before the first run or
minimization is performed by the new script, the "state" information
for the saved fix is discarded. At the time the discard occurs,
LAMMPS will also print a list of fixes for which the information is
being discarded. See the doc pages for individual fixes for info on
which ones can be restarted in this manner. Note that fixes which are
created internally by other LAMMPS commands (computes, fixes, etc)
will have style names which are all-capitalized, and IDs which are
generated internally.
Likewise, the "computes"_fix.html used for a simulation are not stored
in the restart file. This means the new input script should specify
all computes it will use. However, some computes create a fix
internally to store "state" information that persists from timestep to
timestep. An example is the "compute msd"_compute_msd.html command
which uses a fix to store a reference coordinate for each atom, so
that a displacement can be calculated at any later time. If the
compute command in the new input script uses the same compute-ID and
group-ID as was used in the input script that wrote the restart file,
then it will create the same fix in the restarted run. This means the
re-created fix will be re-enabled with the stored state information as
described in the previous paragraph, so that the compute can continue
its calculations in a consistent manner.
NOTE: There are a handful of commands which can be used before or
between runs which may require a system initialization. Examples
include the "balance", "displace_atoms", "delete_atoms", "set" (some
options), and "velocity" (some options) commands. This is because
they can migrate atoms to new processors. Thus they will also discard
unused "state" information from fixes. You will know the discard has
occurred because a list of discarded fixes will be printed to the
screen and log file, as explained above. This means that if you wish
to retain that info in a restarted run, you must re-specify the
relevant fixes and computes (which create fixes) before those commands
are used.
Some pair styles, like the "granular pair styles"_pair_gran.html, also
use a fix to store "state" information that persists from timestep to
timestep. In the case of granular potentials, it is contact
information between pairs of touching particles. This info will also
be re-enabled in the restart script, assuming you re-use the same
granular pair style.
LAMMPS allows bond interactions (angle, etc) to be turned off or
deleted in various ways, which can affect how their info is stored in
a restart file.
If bonds (angles, etc) have been turned off by the "fix
shake"_fix_shake.html or "delete_bonds"_delete_bonds.html command,
their info will be written to a restart file as if they are turned on.
This means they will need to be turned off again in a new run after
the restart file is read.
Bonds that are broken (e.g. by a bond-breaking potential) are written
to the restart file as broken bonds with a type of 0. Thus these
bonds will still be broken when the restart file is read.
Bonds that have been broken by the "fix
bond/break"_fix_bond_break.html command have disappeared from the
system. No information about these bonds is written to the restart
file.
:line
[Restrictions:]
To write and read restart files in parallel with MPI-IO, the MPIIO
package must be installed.
[Related commands:]
"read_data"_read_data.html, "read_dump"_read_dump.html,
"write_restart"_write_restart.html, "restart"_restart.html
[Default:] none
diff --git a/doc/src/region.txt b/doc/src/region.txt
index 885e5e45f..5039e4a51 100644
--- a/doc/src/region.txt
+++ b/doc/src/region.txt
@@ -1,400 +1,400 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
region command :h3
[Syntax:]
region ID style args keyword arg ... :pre
ID = user-assigned name for the region :ulb,l
style = {delete} or {block} or {cone} or {cylinder} or {plane} or {prism} or {sphere} or {union} or {intersect} :l
{delete} = no args
{block} args = xlo xhi ylo yhi zlo zhi
xlo,xhi,ylo,yhi,zlo,zhi = bounds of block in all dimensions (distance units)
{cone} args = dim c1 c2 radlo radhi lo hi
dim = {x} or {y} or {z} = axis of cone
c1,c2 = coords of cone axis in other 2 dimensions (distance units)
radlo,radhi = cone radii at lo and hi end (distance units)
lo,hi = bounds of cone in dim (distance units)
{cylinder} args = dim c1 c2 radius lo hi
dim = {x} or {y} or {z} = axis of cylinder
c1,c2 = coords of cylinder axis in other 2 dimensions (distance units)
radius = cylinder radius (distance units)
radius can be a variable (see below)
lo,hi = bounds of cylinder in dim (distance units)
{plane} args = px py pz nx ny nz
px,py,pz = point on the plane (distance units)
nx,ny,nz = direction normal to plane (distance units)
{prism} args = xlo xhi ylo yhi zlo zhi xy xz yz
xlo,xhi,ylo,yhi,zlo,zhi = bounds of untilted prism (distance units)
xy = distance to tilt y in x direction (distance units)
xz = distance to tilt z in x direction (distance units)
yz = distance to tilt z in y direction (distance units)
{sphere} args = x y z radius
x,y,z = center of sphere (distance units)
radius = radius of sphere (distance units)
radius can be a variable (see below)
{union} args = N reg-ID1 reg-ID2 ...
N = # of regions to follow, must be 2 or greater
reg-ID1,reg-ID2, ... = IDs of regions to join together
{intersect} args = N reg-ID1 reg-ID2 ...
N = # of regions to follow, must be 2 or greater
reg-ID1,reg-ID2, ... = IDs of regions to intersect :pre
zero or more keyword/arg pairs may be appended :l
keyword = {side} or {units} or {move} or {rotate} or {open} :l
{side} value = {in} or {out}
{in} = the region is inside the specified geometry
{out} = the region is outside the specified geometry
{units} value = {lattice} or {box}
{lattice} = the geometry is defined in lattice units
{box} = the geometry is defined in simulation box units
{move} args = v_x v_y v_z
v_x,v_y,v_z = equal-style variables for x,y,z displacement of region over time
{rotate} args = v_theta Px Py Pz Rx Ry Rz
v_theta = equal-style variable for rotaton of region over time (in radians)
Px,Py,Pz = origin for axis of rotation (distance units)
Rx,Ry,Rz = axis of rotation vector
{open} value = integer from 1-6 corresponding to face index (see below)
:pre
accelerated styles (with same args) = {block/kk} :l
:ule
[Examples:]
region 1 block -3.0 5.0 INF 10.0 INF INF
region 2 sphere 0.0 0.0 0.0 5 side out
region void cylinder y 2 3 5 -5.0 EDGE units box
region 1 prism 0 10 0 10 0 10 2 0 0
region outside union 4 side1 side2 side3 side4
region 2 sphere 0.0 0.0 0.0 5 side out move v_left v_up NULL
region openbox block 0 10 0 10 0 10 open 5 open 6 units box
region funnel cone z 10 10 2 5 0 10 open 1 units box :pre
[Description:]
This command defines a geometric region of space. Various other
commands use regions. For example, the region can be filled with
atoms via the "create_atoms"_create_atoms.html command. Or a bounding
box around the region, can be used to define the simulation box via
the "create_box"_create_box.html command. Or the atoms in the region
can be identified as a group via the "group"_group.html command, or
deleted via the "delete_atoms"_delete_atoms.html command. Or the
surface of the region can be used as a boundary wall via the "fix
wall/region"_fix_wall_region.html command.
Commands which use regions typically test whether an atom's position
is contained in the region or not. For this purpose, coordinates
exactly on the region boundary are considered to be interior to the
region. This means, for example, for a spherical region, an atom on
the sphere surface would be part of the region if the sphere were
defined with the {side in} keyword, but would not be part of the
region if it were defined using the {side out} keyword. See more
details on the {side} keyword below.
Normally, regions in LAMMPS are "static", meaning their geometric
extent does not change with time. If the {move} or {rotate} keyword
is used, as described below, the region becomes "dynamic", meaning
it's location or orientation changes with time. This may be useful,
for example, when thermostatting a region, via the compute temp/region
command, or when the fix wall/region command uses a region surface as
a bounding wall on particle motion, i.e. a rotating container.
The {delete} style removes the named region. Since there is little
overhead to defining extra regions, there is normally no need to do
this, unless you are defining and discarding large numbers of regions
in your input script.
The lo/hi values for {block} or {cone} or {cylinder} or {prism} styles
can be specified as EDGE or INF. EDGE means they extend all the way
to the global simulation box boundary. Note that this is the current
box boundary; if the box changes size during a simulation, the region
does not. INF means a large negative or positive number (1.0e20), so
it should encompass the simulation box even if it changes size. If a
region is defined before the simulation box has been created (via
"create_box"_create_box.html or "read_data"_read_data.html or
"read_restart"_read_restart.html commands), then an EDGE or INF
parameter cannot be used. For a {prism} region, a non-zero tilt
factor in any pair of dimensions cannot be used if both the lo/hi
values in either of those dimensions are INF. E.g. if the xy tilt is
non-zero, then xlo and xhi cannot both be INF, nor can ylo and yhi.
NOTE: Regions in LAMMPS do not get wrapped across periodic boundaries,
as specified by the "boundary"_boundary.html command. For example, a
spherical region that is defined so that it overlaps a periodic
boundary is not treated as 2 half-spheres, one on either side of the
simulation box.
NOTE: Regions in LAMMPS are always 3d geometric objects, regardless of
whether the "dimension"_dimension.html of a simulation is 2d or 3d.
Thus when using regions in a 2d simulation, you should be careful to
define the region so that its intersection with the 2d x-y plane of
the simulation has the 2d geometric extent you want.
For style {cone}, an axis-aligned cone is defined which is like a
{cylinder} except that two different radii (one at each end) can be
defined. Either of the radii (but not both) can be 0.0.
For style {cone} and {cylinder}, the c1,c2 params are coordinates in
the 2 other dimensions besides the cylinder axis dimension. For dim =
x, c1/c2 = y/z; for dim = y, c1/c2 = x/z; for dim = z, c1/c2 = x/y.
Thus the third example above specifies a cylinder with its axis in the
y-direction located at x = 2.0 and z = 3.0, with a radius of 5.0, and
extending in the y-direction from -5.0 to the upper box boundary.
For style {plane}, a plane is defined which contain the point
(px,py,pz) and has a normal vector (nx,ny,nz). The normal vector does
not have to be of unit length. The "inside" of the plane is the
half-space in the direction of the normal vector; see the discussion
of the {side} option below.
For style {prism}, a parallelepiped is defined (it's too hard to spell
parallelepiped in an input script!). The parallelepiped has its
"origin" at (xlo,ylo,zlo) and is defined by 3 edge vectors starting
from the origin given by A = (xhi-xlo,0,0); B = (xy,yhi-ylo,0); C =
(xz,yz,zhi-zlo). {Xy,xz,yz} can be 0.0 or positive or negative values
and are called "tilt factors" because they are the amount of
displacement applied to faces of an originally orthogonal box to
transform it into the parallelepiped.
A prism region that will be used with the "create_box"_create_box.html
command to define a triclinic simulation box must have tilt factors
(xy,xz,yz) that do not skew the box more than half the distance of
corresponding the parallel box length. For example, if xlo = 2 and
xhi = 12, then the x box length is 10 and the xy tilt factor must be
between -5 and 5. Similarly, both xz and yz must be between
-(xhi-xlo)/2 and +(yhi-ylo)/2. Note that this is not a limitation,
since if the maximum tilt factor is 5 (as in this example), then
configurations with tilt = ..., -15, -5, 5, 15, 25, ... are all
geometrically equivalent.
The {radius} value for style {sphere} and {cylinder} can be specified
as an equal-style "variable"_variable.html. If the value is a
variable, it should be specified as v_name, where name is the variable
name. In this case, the variable will be evaluated each timestep, and
its value used to determine the radius of the region.
Equal-style variables can specify formulas with various mathematical
functions, and include "thermo_style"_thermo_style.html command
keywords for the simulation box parameters and timestep and elapsed
time. Thus it is easy to specify a time-dependent radius.
See "Section 6.12"_Section_howto.html#howto_12 of the doc pages
for a geometric description of triclinic boxes, as defined by LAMMPS,
and how to transform these parameters to and from other commonly used
triclinic representations.
The {union} style creates a region consisting of the volume of all the
listed regions combined. The {intersect} style creates a region
consisting of the volume that is common to all the listed regions.
NOTE: The {union} and {intersect} regions operate by invoking methods
from their list of sub-regions. Thus you cannot delete the
sub-regions after defining a {union} or {intersection} region.
:line
The {side} keyword determines whether the region is considered to be
inside or outside of the specified geometry. Using this keyword in
conjunction with {union} and {intersect} regions, complex geometries
can be built up. For example, if the interior of two spheres were
each defined as regions, and a {union} style with {side} = out was
constructed listing the region-IDs of the 2 spheres, the resulting
region would be all the volume in the simulation box that was outside
both of the spheres.
The {units} keyword determines the meaning of the distance units used
to define the region for any argument above listed as having distance
units. It also affects the scaling of the velocity vector specified
with the {vel} keyword, the amplitude vector specified with the
{wiggle} keyword, and the rotation point specified with the {rotate}
keyword, since they each involve a distance metric.
A {box} value selects standard distance units as defined by the
"units"_units.html command, e.g. Angstroms for units = real or metal.
A {lattice} value means the distance units are in lattice spacings.
The "lattice"_lattice.html command must have been previously used to
define the lattice spacings which are used as follows:
For style {block}, the lattice spacing in dimension x is applied to
xlo and xhi, similarly the spacings in dimensions y,z are applied to
ylo/yhi and zlo/zhi. :ulb,l
For style {cone}, the lattice spacing in argument {dim} is applied to
lo and hi. The spacings in the two radial dimensions are applied to
c1 and c2. The two cone radii are scaled by the lattice
spacing in the dimension corresponding to c1. :l
For style {cylinder}, the lattice spacing in argument {dim} is applied
to lo and hi. The spacings in the two radial dimensions are applied
to c1 and c2. The cylinder radius is scaled by the lattice
spacing in the dimension corresponding to c1. :l
For style {plane}, the lattice spacing in dimension x is applied to
px and nx, similarly the spacings in dimensions y,z are applied to
py/ny and pz/nz. :l
For style {prism}, the lattice spacing in dimension x is applied to
xlo and xhi, similarly for ylo/yhi and zlo/zhi. The lattice spacing
in dimension x is applied to xy and xz, and the spacing in dimension y
to yz. :l
For style {sphere}, the lattice spacing in dimensions x,y,z are
applied to the sphere center x,y,z. The spacing in dimension x is
applied to the sphere radius. :l,ule
:line
If the {move} or {rotate} keywords are used, the region is "dynamic",
meaning its location or orientation changes with time. These keywords
cannot be used with a {union} or {intersect} style region. Instead,
the keywords should be used to make the individual sub-regions of the
{union} or {intersect} region dynamic. Normally, each sub-region
should be "dynamic" in the same manner (e.g. rotate around the same
point), though this is not a requirement.
The {move} keyword allows one or more "equal-style
variables"_variable.html to be used to specify the x,y,z displacement
of the region, typically as a function of time. A variable is
specified as v_name, where name is the variable name. Any of the
three variables can be specified as NULL, in which case no
displacement is calculated in that dimension.
Note that equal-style variables can specify formulas with various
mathematical functions, and include "thermo_style"_thermo_style.html
command keywords for the simulation box parameters and timestep and
elapsed time. Thus it is easy to specify a region displacement that
change as a function of time or spans consecutive runs in a continuous
fashion. For the latter, see the {start} and {stop} keywords of the
"run"_run.html command and the {elaplong} keyword of "thermo_style
custom"_thermo_style.html for details.
For example, these commands would displace a region from its initial
position, in the positive x direction, effectively at a constant
velocity:
variable dx equal ramp(0,10)
region 2 sphere 10.0 10.0 0.0 5 move v_dx NULL NULL :pre
Note that the initial displacement is 0.0, though that is not required.
Either of these variables would "wiggle" the region back and forth in
the y direction:
variable dy equal swiggle(0,5,100)
variable dysame equal 5*sin(2*PI*elaplong*dt/100)
region 2 sphere 10.0 10.0 0.0 5 move NULL v_dy NULL :pre
The {rotate} keyword rotates the region around a rotation axis {R} =
(Rx,Ry,Rz) that goes thru a point {P} = (Px,Py,Pz). The rotation
angle is calculated, presumably as a function of time, by a variable
specified as v_theta, where theta is the variable name. The variable
should generate its result in radians. The direction of rotation for
the region around the rotation axis is consistent with the right-hand
rule: if your right-hand thumb points along {R}, then your fingers
wrap around the axis in the direction of rotation.
The {move} and {rotate} keywords can be used together. In this case,
the displacement specified by the {move} keyword is applied to the {P}
point of the {rotate} keyword.
:line
The {open} keyword can be used (multiple times) to indicate that one
or more faces of the region are ignored for purposes of particle/wall
interactions. This keyword is only relevant for regions used by the
{fix wall/region} and {fix wall/gran/region} commands. It can be used
to create "open" containers where only some of the region faces are
walls. For example, a funnel can be created with a {cone} style
region that has an open face at the smaller radius for particles to
flow out, or at the larger radius for pouring particles into the cone,
or both.
Note that using the {open} keyword partly overrides the {side}
keyword, since both exterior and interior surfaces of an open region
are tested for particle contacts. The exception to this is a {union}
or {intersect} region which includes an open sub-region. In that case
the {side} keyword is still used to define the union/intersect region
volume, and the {open} settings are only applied to the individual
sub-regions that use them.
The indices specified as part of the {open} keyword have the following
meanings:
For style {block}, indices 1-6 correspond to the xlo, xhi, ylo, yhi,
zlo, zhi surfaces of the block. I.e. 1 is the yz plane at x = xlo, 2
is the yz-plane at x = xhi, 3 is the xz plane at y = ylo, 4 is the xz
plane at y = yhi, 5 is the xy plane at z = zlo, 6 is the xy plane at z
= zhi). In the second-to-last example above, the region is a box open
at both xy planes.
For style {prism}, values 1-6 have the same mapping as for style
{block}. I.e. in an untilted {prism}, {open} indices correspond to
the xlo, xhi, ylo, yhi, zlo, zhi surfaces.
For style {cylinder}, index 1 corresponds to the flat end cap at the
low coordinate along the cylinder axis, index 2 corresponds to the
high-coordinate flat end cap along the cylinder axis, and index 3 is
the curved cylinder surface. For example, a {cylinder} region with
{open 1 open 2} keywords will be open at both ends (e.g. a section of
pipe), regardless of the cylinder orientation.
For style {cone}, the mapping is the same as for style {cylinder}.
Index 1 is the low-coordinate flat end cap, index 2 is the
high-coordinate flat end cap, and index 3 is the curved cone surface.
In the last example above, a {cone} region is defined along the z-axis
that is open at the zlo value (e.g. for use as a funnel).
For all other styles, the {open} keyword is ignored. As indicated
above, this includes the {intersect} and {union} regions, though their
sub-regions can be defined with the {open} keyword.
:line
Styles with a {kk} suffix are functionally the same as the
corresponding style without the suffix. They have been optimized to
run faster, depending on your available hardware, as discussed in
"Section 5"_Section_accelerate.html of the manual. The
accelerated styles take the same arguments and should produce the same
results, except for round-off and precision issues.
The code using the region (such as a fix or compute) must also be supported
by Kokkos or no acceleration will occur. Currently, only {block} style
regions are supported by Kokkos.
These accelerated styles are part of the Kokkos package. They are
only enabled if LAMMPS was built with that package. See the "Making
LAMMPS"_Section_start.html#start_3 section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the "-suffix command-line
-switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
+switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
use the "suffix"_suffix.html command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
A prism cannot be of 0.0 thickness in any dimension; use a small z
thickness for 2d simulations. For 2d simulations, the xz and yz
parameters must be 0.0.
[Related commands:]
"lattice"_lattice.html, "create_atoms"_create_atoms.html,
"delete_atoms"_delete_atoms.html, "group"_group.html
[Default:]
The option defaults are side = in, units = lattice, and no move or
rotation.
diff --git a/doc/src/restart.txt b/doc/src/restart.txt
index 5e0c2a9ea..7c39ae140 100644
--- a/doc/src/restart.txt
+++ b/doc/src/restart.txt
@@ -1,174 +1,174 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
restart command :h3
[Syntax:]
restart 0
restart N root keyword value ...
restart N file1 file2 keyword value ... :pre
N = write a restart file every this many timesteps :ulb,l
N can be a variable (see below) :l
root = filename to which timestep # is appended :l
file1,file2 = two full filenames, toggle between them when writing file :l
zero or more keyword/value pairs may be appended :l
keyword = {fileper} or {nfile} :l
{fileper} arg = Np
Np = write one file for every this many processors
{nfile} arg = Nf
Nf = write this many files, one from each of Nf processors :pre
:ule
[Examples:]
restart 0
restart 1000 poly.restart
restart 1000 poly.restart.mpiio
restart 1000 restart.*.equil
restart 10000 poly.%.1 poly.%.2 nfile 10
restart v_mystep poly.restart :pre
[Description:]
Write out a binary restart file with the current state of the
simulation every so many timesteps, in either or both of two modes, as
a run proceeds. A value of 0 means do not write out any restart
files. The two modes are as follows. If one filename is specified, a
series of filenames will be created which include the timestep in the
filename. If two filenames are specified, only 2 restart files will
be created, with those names. LAMMPS will toggle between the 2 names
as it writes successive restart files.
Note that you can specify the restart command twice, once with a
single filename and once with two filenames. This would allow you,
for example, to write out archival restart files every 100000 steps
using a single filenname, and more frequent temporary restart files
every 1000 steps, using two filenames. Using restart 0 will turn off
both modes of output.
Similar to "dump"_dump.html files, the restart filename(s) can contain
two wild-card characters.
If a "*" appears in the single filename, it is replaced with the
current timestep value. This is only recognized when a single
filename is used (not when toggling back and forth). Thus, the 3rd
example above creates restart files as follows: restart.1000.equil,
restart.2000.equil, etc. If a single filename is used with no "*",
then the timestep value is appended. E.g. the 2nd example above
creates restart files as follows: poly.restart.1000,
poly.restart.2000, etc.
If a "%" character appears in the restart filename(s), then one file
is written for each processor and the "%" character is replaced with
the processor ID from 0 to P-1. An additional file with the "%"
replaced by "base" is also written, which contains global information.
For example, the files written on step 1000 for filename restart.%
would be restart.base.1000, restart.0.1000, restart.1.1000, ...,
restart.P-1.1000. This creates smaller files and can be a fast mode
of output and subsequent input on parallel machines that support
parallel I/O. The optional {fileper} and {nfile} keywords discussed
below can alter the number of files written.
The restart file can also be written in parallel as one large binary
file via the MPI-IO library, which is part of the MPI standard for
versions 2.0 and above. Using MPI-IO requires two steps. First,
build LAMMPS with its MPIIO package installed, e.g.
make yes-mpiio # installs the MPIIO package
make mpi # build LAMMPS for your platform :pre
Second, use a restart filename which contains ".mpiio". Note that it
does not have to end in ".mpiio", just contain those characters.
Unlike MPI-IO dump files, a particular restart file must be both
written and read using MPI-IO.
Restart files are written on timesteps that are a multiple of N but
not on the first timestep of a run or minimization. You can use the
"write_restart"_write_restart.html command to write a restart file
before a run begins. A restart file is not written on the last
timestep of a run unless it is a multiple of N. A restart file is
written on the last timestep of a minimization if N > 0 and the
minimization converges.
Instead of a numeric value, N can be specified as an "equal-style
variable"_variable.html, which should be specified as v_name, where
name is the variable name. In this case, the variable is evaluated at
the beginning of a run to determine the next timestep at which a
restart file will be written out. On that timestep, the variable will
be evaluated again to determine the next timestep, etc. Thus the
variable should return timestep values. See the stagger() and
logfreq() and stride() math functions for "equal-style
variables"_variable.html, as examples of useful functions to use in
this context. Other similar math functions could easily be added as
options for "equal-style variables"_variable.html.
For example, the following commands will write restart files
every step from 1100 to 1200, and could be useful for debugging
a simulation where something goes wrong at step 1163:
variable s equal stride(1100,1200,1)
restart v_s tmp.restart :pre
:line
See the "read_restart"_read_restart.html command for information about
what is stored in a restart file.
Restart files can be read by a "read_restart"_read_restart.html
command to restart a simulation from a particular state. Because the
file is binary (to enable exact restarts), it may not be readable on
another machine. In this case, you can use the "-r command-line
-switch"_Section_start.html#start_7 to convert a restart file to a data
+switch"_Section_start.html#start_6 to convert a restart file to a data
file.
NOTE: Although the purpose of restart files is to enable restarting a
simulation from where it left off, not all information about a
simulation is stored in the file. For example, the list of fixes that
were specified during the initial run is not stored, which means the
new input script must specify any fixes you want to use. Even when
restart information is stored in the file, as it is for some fixes,
commands may need to be re-specified in the new input script, in order
to re-use that information. See the "read_restart"_read_restart.html
command for information about what is stored in a restart file.
:line
The optional {nfile} or {fileper} keywords can be used in conjunction
with the "%" wildcard character in the specified restart file name(s).
As explained above, the "%" character causes the restart file to be
written in pieces, one piece for each of P processors. By default P =
the number of processors the simulation is running on. The {nfile} or
{fileper} keyword can be used to set P to a smaller value, which can
be more efficient when running on a large number of processors.
The {nfile} keyword sets P to the specified Nf value. For example, if
Nf = 4, and the simulation is running on 100 processors, 4 files will
be written, by processors 0,25,50,75. Each will collect information
from itself and the next 24 processors and write it to a restart file.
For the {fileper} keyword, the specified value of Np means write one
file for every Np processors. For example, if Np = 4, every 4th
processor (0,4,8,12,etc) will collect information from itself and the
next 3 processors and write it to a restart file.
:line
[Restrictions:]
To write and read restart files in parallel with MPI-IO, the MPIIO
package must be installed.
[Related commands:]
"write_restart"_write_restart.html, "read_restart"_read_restart.html
[Default:]
restart 0 :pre
diff --git a/doc/src/run_style.txt b/doc/src/run_style.txt
index a67899420..ba836a07d 100644
--- a/doc/src/run_style.txt
+++ b/doc/src/run_style.txt
@@ -1,294 +1,294 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
run_style command :h3
[Syntax:]
run_style style args :pre
style = {verlet} or {verlet/split} or {respa} or {respa/omp} :ulb,l
{verlet} args = none
{verlet/split} args = none
{respa} args = N n1 n2 ... keyword values ...
N = # of levels of rRESPA
n1, n2, ... = loop factors between rRESPA levels (N-1 values)
zero or more keyword/value pairings may be appended to the loop factors
keyword = {bond} or {angle} or {dihedral} or {improper} or
{pair} or {inner} or {middle} or {outer} or {hybrid} or {kspace}
{bond} value = M
M = which level (1-N) to compute bond forces in
{angle} value = M
M = which level (1-N) to compute angle forces in
{dihedral} value = M
M = which level (1-N) to compute dihedral forces in
{improper} value = M
M = which level (1-N) to compute improper forces in
{pair} value = M
M = which level (1-N) to compute pair forces in
{inner} values = M cut1 cut2
M = which level (1-N) to compute pair inner forces in
cut1 = inner cutoff between pair inner and
pair middle or outer (distance units)
cut2 = outer cutoff between pair inner and
pair middle or outer (distance units)
{middle} values = M cut1 cut2
M = which level (1-N) to compute pair middle forces in
cut1 = inner cutoff between pair middle and pair outer (distance units)
cut2 = outer cutoff between pair middle and pair outer (distance units)
{outer} value = M
M = which level (1-N) to compute pair outer forces in
{hybrid} values = M1 M2 ... (as many values as there are hybrid sub-styles
M1 = which level (1-N) to compute the first pair_style hybrid sub-style in
M2 = which level (1-N) to compute the second pair_style hybrid sub-style in
M3,etc
{kspace} value = M
M = which level (1-N) to compute kspace forces in :pre
:ule
[Examples:]
run_style verlet
run_style respa 4 2 2 2 bond 1 dihedral 2 pair 3 kspace 4
run_style respa 4 2 2 2 bond 1 dihedral 2 inner 3 5.0 6.0 outer 4 kspace 4
run_style respa 3 4 2 bond 1 hybrid 2 2 1 kspace 3 :pre
[Description:]
Choose the style of time integrator used for molecular dynamics
simulations performed by LAMMPS.
The {verlet} style is a standard velocity-Verlet integrator.
:line
The {verlet/split} style is also a velocity-Verlet integrator, but it
splits the force calculation within each timestep over 2 partitions of
-processors. See "Section 2.7"_Section_start.html#start_7 for an
+processors. See "Section 2.6"_Section_start.html#start_6 for an
explanation of the -partition command-line switch.
Specifically, this style performs all computation except the
"kspace_style"_kspace_style.html portion of the force field on the 1st
partition. This include the "pair style"_pair_style.html, "bond
style"_bond_style.html, "neighbor list building"_neighbor.html,
"fixes"_fix.html including time integration, and output. The
"kspace_style"_kspace_style.html portion of the calculation is
performed on the 2nd partition.
This is most useful for the PPPM kspace_style when its performance on
a large number of processors degrades due to the cost of communication
in its 3d FFTs. In this scenario, splitting your P total processors
into 2 subsets of processors, P1 in the 1st partition and P2 in the
2nd partition, can enable your simulation to run faster. This is
because the long-range forces in PPPM can be calculated at the same
time as pair-wise and bonded forces are being calculated, and the FFTs
can actually speed up when running on fewer processors.
To use this style, you must define 2 partitions where P1 is a multiple
of P2. Typically having P1 be 3x larger than P2 is a good choice.
The 3d processor layouts in each partition must overlay in the
following sense. If P1 is a Px1 by Py1 by Pz1 grid, and P2 = Px2 by
Py2 by Pz2, then Px1 must be an integer multiple of Px2, and similarly
for Py1 a multiple of Py2, and Pz1 a multiple of Pz2.
Typically the best way to do this is to let the 1st partition choose
its onn optimal layout, then require the 2nd partition's layout to
match the integer multiple constraint. See the
"processors"_processors.html command with its {part} keyword for a way
to control this, e.g.
procssors * * * part 1 2 multiple :pre
You can also use the "partition"_partition.html command to explicitly
specify the processor layout on each partition. E.g. for 2 partitions
of 60 and 15 processors each:
partition yes 1 processors 3 4 5
partition yes 2 processors 3 1 5 :pre
When you run in 2-partition mode with the {verlet/split} style, the
thermodynamic data for the entire simulation will be output to the log
and screen file of the 1st partition, which are log.lammps.0 and
screen.0 by default; see the "-plog and -pscreen command-line
-switches"_Section_start.html#start_7 to change this. The log and
+switches"_Section_start.html#start_6 to change this. The log and
screen file for the 2nd partition will not contain thermodynamic
output beyond the 1st timestep of the run.
See "Section 5"_Section_accelerate.html of the manual for
performance details of the speed-up offered by the {verlet/split}
style. One important performance consideration is the assignment of
logical processors in the 2 partitions to the physical cores of a
parallel machine. The "processors"_processors.html command has
options to support this, and strategies are discussed in
"Section 5"_Section_accelerate.html of the manual.
:line
The {respa} style implements the rRESPA multi-timescale integrator
"(Tuckerman)"_#Tuckerman3 with N hierarchical levels, where level 1 is
the innermost loop (shortest timestep) and level N is the outermost
loop (largest timestep). The loop factor arguments specify what the
looping factor is between levels. N1 specifies the number of
iterations of level 1 for a single iteration of level 2, N2 is the
iterations of level 2 per iteration of level 3, etc. N-1 looping
parameters must be specified.
The "timestep"_timestep.html command sets the timestep for the
outermost rRESPA level. Thus if the example command above for a
4-level rRESPA had an outer timestep of 4.0 fmsec, the inner timestep
would be 8x smaller or 0.5 fmsec. All other LAMMPS commands that
specify number of timesteps (e.g. "neigh_modify"_neigh_modify.html
parameters, "dump"_dump.html every N timesteps, etc) refer to the
outermost timesteps.
The rRESPA keywords enable you to specify at what level of the
hierarchy various forces will be computed. If not specified, the
defaults are that bond forces are computed at level 1 (innermost
loop), angle forces are computed where bond forces are, dihedral
forces are computed where angle forces are, improper forces are
computed where dihedral forces are, pair forces are computed at the
outermost level, and kspace forces are computed where pair forces are.
The inner, middle, outer forces have no defaults.
For fixes that support it, the rRESPA level at which a given fix is
active, can be selected through the "fix_modify"_fix_modify.html command.
The {inner} and {middle} keywords take additional arguments for
cutoffs that are used by the pairwise force computations. If the 2
cutoffs for {inner} are 5.0 and 6.0, this means that all pairs up to
6.0 apart are computed by the inner force. Those between 5.0 and 6.0
have their force go ramped to 0.0 so the overlap with the next regime
(middle or outer) is smooth. The next regime (middle or outer) will
compute forces for all pairs from 5.0 outward, with those from 5.0 to
6.0 having their value ramped in an inverse manner.
Only some pair potentials support the use of the {inner} and {middle}
and {outer} keywords. If not, only the {pair} keyword can be used
with that pair style, meaning all pairwise forces are computed at the
same rRESPA level. See the doc pages for individual pair styles for
details.i
Another option for using pair potentials with rRESPA is with the
{hybrid} keyword, which requires the use of the "pair_style hybrid or
hybrid/overlay"_pair_hybrid.html command. In this scenario, different
sub-styles of the hybrid pair style are evaluated at different rRESPA
levels. This can be useful, for example, to set different timesteps
for hybrid coarse-grained/all-atom models. The {hybrid} keyword
requires as many level assignments as there are hybrid substyles,
which assigns each sub-style to a rRESPA level, following their order
of definition in the pair_style command. Since the {hybrid} keyword
operates on pair style computations, it is mutually exclusive with
either the {pair} or the {inner}/{middle}/{outer} keywords.
When using rRESPA (or for any MD simulation) care must be taken to
choose a timestep size(s) that insures the Hamiltonian for the chosen
ensemble is conserved. For the constant NVE ensemble, total energy
must be conserved. Unfortunately, it is difficult to know {a priori}
how well energy will be conserved, and a fairly long test simulation
(~10 ps) is usually necessary in order to verify that no long-term
drift in energy occurs with the trial set of parameters.
With that caveat, a few rules-of-thumb may be useful in selecting
{respa} settings. The following applies mostly to biomolecular
simulations using the CHARMM or a similar all-atom force field, but
the concepts are adaptable to other problems. Without SHAKE, bonds
involving hydrogen atoms exhibit high-frequency vibrations and require
a timestep on the order of 0.5 fmsec in order to conserve energy. The
relatively inexpensive force computations for the bonds, angles,
impropers, and dihedrals can be computed on this innermost 0.5 fmsec
step. The outermost timestep cannot be greater than 4.0 fmsec without
risking energy drift. Smooth switching of forces between the levels
of the rRESPA hierarchy is also necessary to avoid drift, and a 1-2
angstrom "healing distance" (the distance between the outer and inner
cutoffs) works reasonably well. We thus recommend the following
settings for use of the {respa} style without SHAKE in biomolecular
simulations:
timestep 4.0
run_style respa 4 2 2 2 inner 2 4.5 6.0 middle 3 8.0 10.0 outer 4 :pre
With these settings, users can expect good energy conservation and
roughly a 2.5 fold speedup over the {verlet} style with a 0.5 fmsec
timestep.
If SHAKE is used with the {respa} style, time reversibility is lost,
but substantially longer time steps can be achieved. For biomolecular
simulations using the CHARMM or similar all-atom force field, bonds
involving hydrogen atoms exhibit high frequency vibrations and require
a time step on the order of 0.5 fmsec in order to conserve energy.
These high frequency modes also limit the outer time step sizes since
the modes are coupled. It is therefore desirable to use SHAKE with
respa in order to freeze out these high frequency motions and increase
the size of the time steps in the respa hierarchy. The following
settings can be used for biomolecular simulations with SHAKE and
rRESPA:
fix 2 all shake 0.000001 500 0 m 1.0 a 1
timestep 4.0
run_style respa 2 2 inner 1 4.0 5.0 outer 2 :pre
With these settings, users can expect good energy conservation and
roughly a 1.5 fold speedup over the {verlet} style with SHAKE and a
2.0 fmsec timestep.
For non-biomolecular simulations, the {respa} style can be
advantageous if there is a clear separation of time scales - fast and
slow modes in the simulation. Even a LJ system can benefit from
rRESPA if the interactions are divided by the inner, middle and outer
keywords. A 2-fold or more speedup can be obtained while maintaining
good energy conservation. In real units, for a pure LJ fluid at
liquid density, with a sigma of 3.0 angstroms, and epsilon of 0.1
Kcal/mol, the following settings seem to work well:
timestep 36.0
run_style respa 3 3 4 inner 1 3.0 4.0 middle 2 6.0 7.0 outer 3 :pre
:line
The {respa/omp} styles is a variant of {respa} adapted for use with
pair, bond, angle, dihedral, improper, or kspace styles with an {omp}
suffix. It is functionally equivalent to {respa} but performs additional
operations required for managing {omp} styles. For more on {omp} styles
see the "Section 5"_Section_accelerate.html of the manual.
Accelerated styles take the same arguments and should produce the same
results, except for round-off and precision issues.
You can specify {respa/omp} explicitly in your input script, or
-you can use the "-suffix command-line switch"_Section_start.html#start_7
+you can use the "-suffix command-line switch"_Section_start.html#start_6
when you invoke LAMMPS, or you can use the "suffix"_suffix.html
command in your input script.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
:line
[Restrictions:]
The {verlet/split} style can only be used if LAMMPS was built with the
REPLICA package. Correspondingly the {respa/omp} style is available only
if the USER-OMP package was included. See the "Making LAMMPS"_Section_start.html#start_3
section for more info on packages.
Whenever using rRESPA, the user should experiment with trade-offs in
speed and accuracy for their system, and verify that they are
conserving energy to adequate precision.
[Related commands:]
"timestep"_timestep.html, "run"_run.html
[Default:]
run_style verlet :pre
:line
:link(Tuckerman3)
[(Tuckerman)] Tuckerman, Berne and Martyna, J Chem Phys, 97, p 1990
(1992).
diff --git a/doc/src/suffix.txt b/doc/src/suffix.txt
index 127719cdb..7a4adb50b 100644
--- a/doc/src/suffix.txt
+++ b/doc/src/suffix.txt
@@ -1,110 +1,110 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
suffix command :h3
[Syntax:]
suffix style args :pre
style = {off} or {on} or {gpu} or {intel} or {kk} or {omp} or {opt} or {hybrid}
args = for hybrid style, default suffix to be used and alternative suffix :ul
[Examples:]
suffix off
suffix on
suffix gpu
suffix intel
suffix hybrid intel omp
suffix kk :pre
[Description:]
This command allows you to use variants of various styles if they
exist. In that respect it operates the same as the "-suffix
-command-line switch"_Section_start.html#start_7. It also has options
+command-line switch"_Section_start.html#start_6. It also has options
to turn off or back on any suffix setting made via the command line.
The specified style can be {gpu}, {intel}, {kk}, {omp}, {opt} or
{hybrid}. These refer to optional packages that LAMMPS can be built
with, as described in "this section of the
manual"_Section_start.html#start_3. The "gpu" style corresponds to
the GPU package, the "intel" style to the USER-INTEL package, the "kk"
style to the KOKKOS package, the "omp" style to the USER-OMP package,
and the "opt" style to the OPT package.
These are the variants these packages provide:
GPU = a handful of pair styles and the PPPM kspace_style, optimized to
run on one or more GPUs or multicore CPU/GPU nodes :ulb,l
USER-INTEL = a collection of pair styles and neighbor routines
optimized to run in single, mixed, or double precision on CPUs and
Intel(R) Xeon Phi(TM) coprocessors. :l
KOKKOS = a collection of atom, pair, and fix styles optimized to run
using the Kokkos library on various kinds of hardware, including GPUs
via Cuda and many-core chips via OpenMP or threading. :l
USER-OMP = a collection of pair, bond, angle, dihedral, improper,
kspace, compute, and fix styles with support for OpenMP
multi-threading :l
OPT = a handful of pair styles, cache-optimized for faster CPU
performance :l
HYBRID = a combination of two packages can be specified (see below) :l
:ule
As an example, all of the packages provide a "pair_style
lj/cut"_pair_lj.html variant, with style names lj/cut/opt, lj/cut/omp,
lj/cut/gpu, lj/cut/intel, or lj/cut/kk. A variant styles
can be specified explicitly in your input script, e.g. pair_style
lj/cut/gpu. If the suffix command is used with the appropriate style,
you do not need to modify your input script. The specified suffix
(opt,omp,gpu,intel,kk) is automatically appended whenever your
input script command creates a new "atom"_atom_style.html,
"pair"_pair_style.html, "bond"_bond_style.html,
"angle"_angle_style.html, "dihedral"_dihedral_style.html,
"improper"_improper_style.html, "kspace"_kspace_style.html,
"fix"_fix.html, "compute"_compute.html, or "run"_run_style.html style.
If the variant version does not exist, the standard version is
created.
For "hybrid", two packages are specified. The first is used whenever
available. If a style with the first suffix is not available, the style
with the suffix for the second package will be used if available. For
example, "hybrid intel omp" will use styles from the USER-INTEL package
as a first choice and styles from the USER-OMP package as a second choice
if no USER-INTEL variant is available.
If the specified style is {off}, then any previously specified suffix
is temporarily disabled, whether it was specified by a command-line
switch or a previous suffix command. If the specified style is {on},
a disabled suffix is turned back on. The use of these 2 commands lets
your input script use a standard LAMMPS style (i.e. a non-accelerated
variant), which can be useful for testing or benchmarking purposes.
Of course this is also possible by not using any suffix commands, and
explicitly appending or not appending the suffix to the relevant
commands in your input script.
NOTE: The default "run_style"_run_style.html verlet is invoked prior to
reading the input script and is therefore not affected by a suffix command
in the input script. The KOKKOS package requires "run_style verlet/kk",
so when using the KOKKOS package it is necessary to either use the command
line "-sf kk" command or add an explicit "run_style verlet" command to the
input script.
[Restrictions:] none
[Related commands:]
-"Command-line switch -suffix"_Section_start.html#start_7
+"Command-line switch -suffix"_Section_start.html#start_6
[Default:] none
diff --git a/doc/src/temper.txt b/doc/src/temper.txt
index be7edfba4..b1c47c807 100644
--- a/doc/src/temper.txt
+++ b/doc/src/temper.txt
@@ -1,149 +1,149 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
temper command :h3
[Syntax:]
temper N M temp fix-ID seed1 seed2 index :pre
N = total # of timesteps to run
M = attempt a tempering swap every this many steps
temp = initial temperature for this ensemble
fix-ID = ID of the fix that will control temperature during the run
seed1 = random # seed used to decide on adjacent temperature to partner with
seed2 = random # seed for Boltzmann factor in Metropolis swap
index = which temperature (0 to N-1) I am simulating (optional) :ul
[Examples:]
temper 100000 100 $t tempfix 0 58728
temper 40000 100 $t tempfix 0 32285 $w :pre
[Description:]
Run a parallel tempering or replica exchange simulation using multiple
replicas (ensembles) of a system. Two or more replicas must be used.
Each replica runs on a partition of one or more processors. Processor
partitions are defined at run-time using the -partition command-line
-switch; see "Section 2.7"_Section_start.html#start_7 of the
+switch; see "Section 2.6"_Section_start.html#start_6 of the
manual. Note that if you have MPI installed, you can run a
multi-replica simulation with more replicas (partitions) than you have
physical processors, e.g you can run a 10-replica simulation on one or
two processors. You will simply not get the performance speed-up you
would see with one or more physical processors per replica. See "this
section"_Section_howto.html#howto_5 of the manual for further
discussion.
Each replica's temperature is controlled at a different value by a fix
with {fix-ID} that controls temperature. Most thermostat fix styles
(with and without included time integration) are supported. The command
will print an error message and abort, if the chosen fix is unsupported.
The desired temperature is specified by {temp}, which is typically a
variable previously set in the input script, so that each partition is
assigned a different temperature. See the "variable"_variable.html
command for more details. For example:
variable t world 300.0 310.0 320.0 330.0
fix myfix all nvt temp $t $t 100.0
temper 100000 100 $t myfix 3847 58382 :pre
would define 4 temperatures, and assign one of them to the thermostat
used by each replica, and to the temper command.
As the tempering simulation runs for {N} timesteps, a temperature swap
between adjacent ensembles will be attempted every {M} timesteps. If
{seed1} is 0, then the swap attempts will alternate between odd and
even pairings. If {seed1} is non-zero then it is used as a seed in a
random number generator to randomly choose an odd or even pairing each
time. Each attempted swap of temperatures is either accepted or
rejected based on a Boltzmann-weighted Metropolis criterion which uses
{seed2} in the random number generator.
As a tempering run proceeds, multiple log files and screen output
files are created, one per replica. By default these files are named
log.lammps.M and screen.M where M is the replica number from 0 to N-1,
with N = # of replicas. See the "section on command-line
-switches"_Section_start.html#start_7 for info on how to change these
+switches"_Section_start.html#start_6 for info on how to change these
names.
The main screen and log file (log.lammps) will list information about
which temperature is assigned to each replica at each thermodynamic
output timestep. E.g. for a simulation with 16 replicas:
Running on 16 partitions of processors
Step T0 T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 T13 T14 T15
0 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
500 1 0 3 2 5 4 6 7 8 9 10 11 12 13 14 15
1000 2 0 4 1 5 3 6 7 8 9 10 11 12 14 13 15
1500 2 1 4 0 5 3 6 7 9 8 10 11 12 14 13 15
2000 2 1 3 0 6 4 5 7 10 8 9 11 12 14 13 15
2500 2 1 3 0 6 4 5 7 11 8 9 10 12 14 13 15
... :pre
The column headings T0 to TN-1 mean which temperature is currently
assigned to the replica 0 to N-1. Thus the columns represent replicas
and the value in each column is its temperature (also numbered 0 to
N-1). For example, a 0 in the 4th column (column T3, step 2500) means
that the 4th replica is assigned temperature 0, i.e. the lowest
temperature. You can verify this time sequence of temperature
assignments for the Nth replica by comparing the Nth column of screen
output to the thermodynamic data in the corresponding log.lammps.N or
screen.N files as time proceeds.
You can have each replica create its own dump file in the following
manner:
variable rep world 0 1 2 3 4 5 6 7
dump 1 all atom 1000 dump.temper.${rep} :pre
NOTE: Each replica's dump file will contain a continuous trajectory
for its atoms where the temperature varies over time as swaps take
place involving that replica. If you want a series of dump files,
each with snapshots (from all replicas) that are all at a single
temperature, then you will need to post-process the dump files using
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.
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
for each replica) which had previously swapped to new temperatures.
The {index} value (from 0 to N-1, where N is the # of replicas)
identifies which temperature the replica was simulating on the
timestep the restart files were written. Obviously, this argument
must be a variable so that each partition has the correct value. Set
the variable to the {N} values listed in the log file for the previous
run for the replica temperatures at that timestep. For example if the
log file listed the following for a simulation with 5 replicas:
500000 2 4 0 1 3 :pre
then a setting of
variable w world 2 4 0 1 3 :pre
would be used to restart the run with a tempering command like the
example above with $w as the last argument.
:line
[Restrictions:]
This command can only be used if LAMMPS was built with the REPLICA
package. See the "Making LAMMPS"_Section_start.html#start_3 section
for more info on packages.
[Related commands:]
"variable"_variable.html, "prd"_prd.html, "neb"_neb.html
[Default:] none
diff --git a/doc/src/thermo_style.txt b/doc/src/thermo_style.txt
index 36ec7bf12..6102169ee 100644
--- a/doc/src/thermo_style.txt
+++ b/doc/src/thermo_style.txt
@@ -1,408 +1,408 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
thermo_style command :h3
[Syntax:]
thermo_style style args :pre
style = {one} or {multi} or {custom} :ulb,l
args = list of arguments for a particular style :l
{one} args = none
{multi} args = none
{custom} args = list of keywords
possible keywords = step, elapsed, elaplong, dt, time,
cpu, tpcpu, spcpu, cpuremain, part, timeremain,
atoms, temp, press, pe, ke, etotal, enthalpy,
evdwl, ecoul, epair, ebond, eangle, edihed, eimp,
emol, elong, etail,
vol, density, lx, ly, lz, xlo, xhi, ylo, yhi, zlo, zhi,
xy, xz, yz, xlat, ylat, zlat,
bonds, angles, dihedrals, impropers,
pxx, pyy, pzz, pxy, pxz, pyz,
fmax, fnorm, nbuild, ndanger,
cella, cellb, cellc, cellalpha, cellbeta, cellgamma,
c_ID, c_ID\[I\], c_ID\[I\]\[J\],
f_ID, f_ID\[I\], f_ID\[I\]\[J\],
v_name, v_name\[I\]
step = timestep
elapsed = timesteps since start of this run
elaplong = timesteps since start of initial run in a series of runs
dt = timestep size
time = simulation time
cpu = elapsed CPU time in seconds since start of this run
tpcpu = time per CPU second
spcpu = timesteps per CPU second
cpuremain = estimated CPU time remaining in run
part = which partition (0 to Npartition-1) this is
timeremain = remaining time in seconds on timer timeout.
atoms = # of atoms
temp = temperature
press = pressure
pe = total potential energy
ke = kinetic energy
etotal = total energy (pe + ke)
enthalpy = enthalpy (etotal + press*vol)
evdwl = VanderWaal pairwise energy (includes etail)
ecoul = Coulombic pairwise energy
epair = pairwise energy (evdwl + ecoul + elong)
ebond = bond energy
eangle = angle energy
edihed = dihedral energy
eimp = improper energy
emol = molecular energy (ebond + eangle + edihed + eimp)
elong = long-range kspace energy
etail = VanderWaal energy long-range tail correction
vol = volume
density = mass density of system
lx,ly,lz = box lengths in x,y,z
xlo,xhi,ylo,yhi,zlo,zhi = box boundaries
xy,xz,yz = box tilt for triclinic (non-orthogonal) simulation boxes
xlat,ylat,zlat = lattice spacings as calculated by "lattice"_lattice.html command
bonds,angles,dihedrals,impropers = # of these interactions defined
pxx,pyy,pzz,pxy,pxz,pyz = 6 components of pressure tensor
fmax = max component of force on any atom in any dimension
fnorm = length of force vector for all atoms
nbuild = # of neighbor list builds
ndanger = # of dangerous neighbor list builds
cella,cellb,cellc = periodic cell lattice constants a,b,c
cellalpha, cellbeta, cellgamma = periodic cell angles alpha,beta,gamma
c_ID = global scalar value calculated by a compute with ID
c_ID\[I\] = Ith component of global vector calculated by a compute with ID, I can include wildcard (see below)
c_ID\[I\]\[J\] = I,J component of global array calculated by a compute with ID
f_ID = global scalar value calculated by a fix with ID
f_ID\[I\] = Ith component of global vector calculated by a fix with ID, I can include wildcard (see below)
f_ID\[I\]\[J\] = I,J component of global array calculated by a fix with ID
v_name = value calculated by an equal-style variable with name
v_name\[I\] = value calculated by a vector-style variable with name :pre
:ule
[Examples:]
thermo_style multi
thermo_style custom step temp pe etotal press vol
thermo_style custom step temp etotal c_myTemp v_abc
thermo_style custom step temp etotal c_myTemp\[*\] v_abc :pre
[Description:]
Set the style and content for printing thermodynamic data to the
screen and log file.
Style {one} prints a one-line summary of thermodynamic info that is
the equivalent of "thermo_style custom step temp epair emol etotal
press". The line contains only numeric values.
Style {multi} prints a multiple-line listing of thermodynamic info
that is the equivalent of "thermo_style custom etotal ke temp pe ebond
eangle edihed eimp evdwl ecoul elong press". The listing contains
numeric values and a string ID for each quantity.
Style {custom} is the most general setting and allows you to specify
which of the keywords listed above you want printed on each
thermodynamic timestep. Note that the keywords c_ID, f_ID, v_name are
references to "computes"_compute.html, "fixes"_fix.html, and
equal-style "variables"_variable.html that have been defined
elsewhere in the input script or can even be new styles which users
have added to LAMMPS (see the "Section 10"_Section_modify.html
section of the documentation). Thus the {custom} style provides a
flexible means of outputting essentially any desired quantity as a
simulation proceeds.
All styles except {custom} have {vol} appended to their list of
outputs if the simulation box volume changes during the simulation.
The values printed by the various keywords are instantaneous values,
calculated on the current timestep. Time-averaged quantities, which
include values from previous timesteps, can be output by using the
f_ID keyword and accessing a fix that does time-averaging such as the
"fix ave/time"_fix_ave_time.html command.
Options invoked by the "thermo_modify"_thermo_modify.html command can
be used to set the one- or multi-line format of the print-out, the
normalization of thermodynamic output (total values versus per-atom
values for extensive quantities (ones which scale with the number of
atoms in the system), and the numeric precision of each printed value.
NOTE: When you use a "thermo_style" command, all thermodynamic
settings are restored to their default values, including those
previously set by a "thermo_modify"_thermo_modify.html command. Thus
if your input script specifies a thermo_style command, you should use
the thermo_modify command after it.
:line
Several of the thermodynamic quantities require a temperature to be
computed: "temp", "press", "ke", "etotal", "enthalpy", "pxx", etc. By
default this is done by using a {temperature} compute which is created
when LAMMPS starts up, as if this command had been issued:
compute thermo_temp all temp :pre
See the "compute temp"_compute_temp.html command for details. Note
that the ID of this compute is {thermo_temp} and the group is {all}.
You can change the attributes of this temperature (e.g. its
degrees-of-freedom) via the "compute_modify"_compute_modify.html
command. Alternatively, you can directly assign a new compute (that
calculates temperature) which you have defined, to be used for
calculating any thermodynamic quantity that requires a temperature.
This is done via the "thermo_modify"_thermo_modify.html command.
Several of the thermodynamic quantities require a pressure to be
computed: "press", "enthalpy", "pxx", etc. By default this is done by
using a {pressure} compute which is created when LAMMPS starts up, as
if this command had been issued:
compute thermo_press all pressure thermo_temp :pre
See the "compute pressure"_compute_pressure.html command for details.
Note that the ID of this compute is {thermo_press} and the group is
{all}. You can change the attributes of this pressure via the
"compute_modify"_compute_modify.html command. Alternatively, you can
directly assign a new compute (that calculates pressure) which you
have defined, to be used for calculating any thermodynamic quantity
that requires a pressure. This is done via the
"thermo_modify"_thermo_modify.html command.
Several of the thermodynamic quantities require a potential energy to
be computed: "pe", "etotal", "ebond", etc. This is done by using a
{pe} compute which is created when LAMMPS starts up, as if this
command had been issued:
compute thermo_pe all pe :pre
See the "compute pe"_compute_pe.html command for details. Note that
the ID of this compute is {thermo_pe} and the group is {all}. You can
change the attributes of this potential energy via the
"compute_modify"_compute_modify.html command.
:line
The kinetic energy of the system {ke} is inferred from the temperature
of the system with 1/2 Kb T of energy for each degree of freedom.
Thus, using different "compute commands"_compute.html for calculating
temperature, via the "thermo_modify temp"_thermo_modify.html command,
may yield different kinetic energies, since different computes that
calculate temperature can subtract out different non-thermal
components of velocity and/or include different degrees of freedom
(translational, rotational, etc).
The potential energy of the system {pe} will include contributions
from fixes if the "fix_modify thermo"_fix_modify.html option is set
for a fix that calculates such a contribution. For example, the "fix
wall/lj93"_fix_wall.html fix calculates the energy of atoms
interacting with the wall. See the doc pages for "individual fixes"
to see which ones contribute.
A long-range tail correction {etail} for the VanderWaal pairwise
energy will be non-zero only if the "pair_modify
tail"_pair_modify.html option is turned on. The {etail} contribution
is included in {evdwl}, {epair}, {pe}, and {etotal}, and the
corresponding tail correction to the pressure is included in {press}
and {pxx}, {pyy}, etc.
:line
The {step}, {elapsed}, and {elaplong} keywords refer to timestep
count. {Step} is the current timestep, or iteration count when a
"minimization"_minimize.html is being performed. {Elapsed} is the
number of timesteps elapsed since the beginning of this run.
{Elaplong} is the number of timesteps elapsed since the beginning of
an initial run in a series of runs. See the {start} and {stop}
keywords for the "run"_run.html for info on how to invoke a series of
runs that keep track of an initial starting time. If these keywords
are not used, then {elapsed} and {elaplong} are the same value.
The {dt} keyword is the current timestep size in time
"units"_units.html. The {time} keyword is the current elapsed
simulation time, also in time "units"_units.html, which is simply
(step*dt) if the timestep size has not changed and the timestep has
not been reset. If the timestep has changed (e.g. via "fix
dt/reset"_fix_dt_reset.html) or the timestep has been reset (e.g. via
the "reset_timestep" command), then the simulation time is effectively
a cumulative value up to the current point.
The {cpu} keyword is elapsed CPU seconds since the beginning of this
run. The {tpcpu} and {spcpu} keywords are measures of how fast your
simulation is currently running. The {tpcpu} keyword is simulation
time per CPU second, where simulation time is in time
"units"_units.html. E.g. for metal units, the {tpcpu} value would be
picoseconds per CPU second. The {spcpu} keyword is the number of
timesteps per CPU second. Both quantities are on-the-fly metrics,
measured relative to the last time they were invoked. Thus if you are
printing out thermodynamic output every 100 timesteps, the two keywords
will continually output the time and timestep rate for the last 100
steps. The {tpcpu} keyword does not attempt to track any changes in
timestep size, e.g. due to using the "fix dt/reset"_fix_dt_reset.html
command.
The {cpuremain} keyword estimates the CPU time remaining in the
current run, based on the time elapsed thus far. It will only be a
good estimate if the CPU time/timestep for the rest of the run is
similar to the preceding timesteps. On the initial timestep the value
will be 0.0 since there is no history to estimate from. For a
minimization run performed by the "minimize" command, the estimate is
based on the {maxiter} parameter, assuming the minimization will
proceed for the maximum number of allowed iterations.
The {part} keyword is useful for multi-replica or multi-partition
simulations to indicate which partition this output and this file
corresponds to, or for use in a "variable"_variable.html to append to
a filename for output specific to this partition. See "Section
-2.7"_Section_start.html#start_7 of the manual for details on running
+2.6"_Section_start.html#start_6 of the manual for details on running
in multi-partition mode.
The {timeremain} keyword returns the remaining seconds when a
timeout has been configured via the "timer timeout"_timer.html command.
If the timeout timer is inactive, the value of this keyword is 0.0 and
if the timer is expired, it is negative. This allows for example to exit
loops cleanly, if the timeout is expired with:
if "$(timeremain) < 0.0" then "quit 0" :pre
The {fmax} and {fnorm} keywords are useful for monitoring the progress
of an "energy minimization"_minimize.html. The {fmax} keyword
calculates the maximum force in any dimension on any atom in the
system, or the infinity-norm of the force vector for the system. The
{fnorm} keyword calculates the 2-norm or length of the force vector.
The {nbuild} and {ndanger} keywords are useful for monitoring neighbor
list builds during a run. Note that both these values are also
printed with the end-of-run statistics. The {nbuild} keyword is the
number of re-builds during the current run. The {ndanger} keyword is
the number of re-builds that LAMMPS considered potentially
"dangerous". If atom movement triggered neighbor list rebuilding (see
the "neigh_modify"_neigh_modify.html command), then dangerous
reneighborings are those that were triggered on the first timestep
atom movement was checked for. If this count is non-zero you may wish
to reduce the delay factor to insure no force interactions are missed
by atoms moving beyond the neighbor skin distance before a rebuild
takes place.
The keywords {cella}, {cellb}, {cellc}, {cellalpha}, {cellbeta},
{cellgamma}, correspond to the usual crystallographic quantities that
define the periodic unit cell of a crystal. See "this
section"_Section_howto.html#howto_12 of the doc pages for a geometric
description of triclinic periodic cells, including a precise definition
of these quantities in terms of the internal LAMMPS cell dimensions
{lx}, {ly}, {lz}, {yz}, {xz}, {xy}.
:line
For output values from a compute or fix, the bracketed index I used to
index a vector, as in {c_ID\[I\]} or {f_ID\[I\]}, can be specified
using a wildcard asterisk with the index to effectively specify
multiple values. This takes the form "*" or "*n" or "n*" or "m*n".
If N = the size of the vector (for {mode} = scalar) or the number of
columns in the array (for {mode} = vector), then an asterisk with no
numeric values means all indices from 1 to N. A leading asterisk
means all indices from 1 to n (inclusive). A trailing asterisk means
all indices from n to N (inclusive). A middle asterisk means all
indices from m to n (inclusive).
Using a wildcard is the same as if the individual elements of the
vector had been listed one by one. E.g. these 2 thermo_style commands
are equivalent, since the "compute temp"_compute_temp.html command
creates a global vector with 6 values.
compute myTemp all temp
thermo_style custom step temp etotal c_myTemp\[*\]
thermo_style custom step temp etotal &
c_myTemp\[1\] c_myTemp\[2\] c_myTemp\[3\] &
c_myTemp\[4\] c_myTemp\[5\] c_myTemp\[6\] :pre
:line
The {c_ID} and {c_ID\[I\]} and {c_ID\[I\]\[J\]} keywords allow global
values calculated by a compute to be output. As discussed on the
"compute"_compute.html doc page, computes can calculate global,
per-atom, or local values. Only global values can be referenced by
this command. However, per-atom compute values for an individual atom
can be referenced in a "variable"_variable.html and the variable
referenced by thermo_style custom, as discussed below. See the
discussion above for how the I in {c_ID\[I\]} can be specified with a
wildcard asterisk to effectively specify multiple values from a global
compute vector.
The ID in the keyword should be replaced by the actual ID of a compute
that has been defined elsewhere in the input script. See the
"compute"_compute.html command for details. If the compute calculates
a global scalar, vector, or array, then the keyword formats with 0, 1,
or 2 brackets will reference a scalar value from the compute.
Note that some computes calculate "intensive" global quantities like
temperature; others calculate "extensive" global quantities like
kinetic energy that are summed over all atoms in the compute group.
Intensive quantities are printed directly without normalization by
thermo_style custom. Extensive quantities may be normalized by the
total number of atoms in the simulation (NOT the number of atoms in
the compute group) when output, depending on the "thermo_modify
norm"_thermo_modify.html option being used.
The {f_ID} and {f_ID\[I\]} and {f_ID\[I\]\[J\]} keywords allow global
values calculated by a fix to be output. As discussed on the
"fix"_fix.html doc page, fixes can calculate global, per-atom, or
local values. Only global values can be referenced by this command.
However, per-atom fix values can be referenced for an individual atom
in a "variable"_variable.html and the variable referenced by
thermo_style custom, as discussed below. See the discussion above for
how the I in {f_ID\[I\]} can be specified with a wildcard asterisk to
effectively specify multiple values from a global fix vector.
The ID in the keyword should be replaced by the actual ID of a fix
that has been defined elsewhere in the input script. See the
"fix"_fix.html command for details. If the fix calculates a global
scalar, vector, or array, then the keyword formats with 0, 1, or 2
brackets will reference a scalar value from the fix.
Note that some fixes calculate "intensive" global quantities like
timestep size; others calculate "extensive" global quantities like
energy that are summed over all atoms in the fix group. Intensive
quantities are printed directly without normalization by thermo_style
custom. Extensive quantities may be normalized by the total number of
atoms in the simulation (NOT the number of atoms in the fix group)
when output, depending on the "thermo_modify norm"_thermo_modify.html
option being used.
The {v_name} keyword allow the current value of a variable to be
output. The name in the keyword should be replaced by the variable
name that has been defined elsewhere in the input script. Only
equal-style and vector-style variables can be referenced; the latter
requires a bracketed term to specify the Ith element of the vector
calculated by the variable. However, an atom-style variable can be
referenced for an individual atom by an equal-style variable and that
variable referenced. See the "variable"_variable.html command for
details. Variables of style {equal} and {vector} and {atom} define a
formula which can reference per-atom properties or thermodynamic
keywords, or they can invoke other computes, fixes, or variables when
evaluated, so this is a very general means of creating thermodynamic
output.
Note that equal-style and vector-style variables are assumed to
produce "intensive" global quantities, which are thus printed as-is,
without normalization by thermo_style custom. You can include a
division by "natoms" in the variable formula if this is not the case.
:line
[Restrictions:]
This command must come after the simulation box is defined by a
"read_data"_read_data.html, "read_restart"_read_restart.html, or
"create_box"_create_box.html command.
[Related commands:]
"thermo"_thermo.html, "thermo_modify"_thermo_modify.html,
"fix_modify"_fix_modify.html, "compute temp"_compute_temp.html,
"compute pressure"_compute_pressure.html
[Default:]
thermo_style one :pre
diff --git a/doc/src/timer.txt b/doc/src/timer.txt
index 39a6c542b..768c3e135 100644
--- a/doc/src/timer.txt
+++ b/doc/src/timer.txt
@@ -1,121 +1,121 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
timer command :h3
[Syntax:]
timer args :pre
{args} = one or more of {off} or {loop} or {normal} or {full} or {sync} or {nosync} or {timeout} or {every} :l
{off} = do not collect or print any timing information
{loop} = collect only the total time for the simulation loop
{normal} = collect timer information broken down by sections (default)
{full} = like {normal} but also include CPU and thread utilization
{sync} = explicitly synchronize MPI tasks between sections
{nosync} = do not synchronize MPI tasks between sections (default)
{timeout} elapse = set walltime limit to {elapse}
{every} Ncheck = perform timeout check every {Ncheck} steps :pre
[Examples:]
timer full sync
timer timeout 2:00:00 every 100
timer loop :pre
[Description:]
Select the level of detail at which LAMMPS performs its CPU timings.
Multiple keywords can be specified with the {timer} command. For
keywords that are mutually exclusive, the last one specified takes
precedence.
During a simulation run LAMMPS collects information about how much
time is spent in different sections of the code and thus can provide
information for determining performance and load imbalance problems.
This can be done at different levels of detail and accuracy. For more
information about the timing output, see this "discussion of screen
-output in Section 2.8"_Section_start.html#start_8.
+output in Section 2.7"_Section_start.html#start_7.
The {off} setting will turn all time measurements off. The {loop}
setting will only measure the total time for a run and not collect any
detailed per section information. With the {normal} setting, timing
information for portions of the timestep (pairwise calculations,
neighbor list construction, output, etc) are collected as well as
information about load imbalances for those sections across
processors. The {full} setting adds information about CPU
utilization and thread utilization, when multi-threading is enabled.
With the {sync} setting, all MPI tasks are synchronized at each timer
call which measures load imbalance for each section more accurately,
though it can also slow down the simulation by prohibiting overlapping
independent computations on different MPI ranks Using the {nosync}
setting (which is the default) turns this synchronization off.
With the {timeout} keyword a walltime limit can be imposed, that
affects the "run"_run.html and "minimize"_minimize.html commands.
This can be convenient when calculations have to comply with execution
time limits, e.g. when running under a batch system when you want to
maximize the utilization of the batch time slot, especially for runs
where the time per timestep varies much and thus it becomes difficult
to predict how many steps a simulation can perform for a given walltime
limit. This also applies for difficult to converge minimizations.
The timeout {elapse} value should be somewhat smaller than the maximum
wall time requested from the batch system, as there is usually
some overhead to launch jobs, and it is advisable to write
out a restart after terminating a run due to a timeout.
The timeout timer starts when the command is issued. When the time
limit is reached, the run or energy minimization will exit on the
next step or iteration that is a multiple of the {Ncheck} value
which can be set with the {every} keyword. Default is checking
every 10 steps. After the timer timeout has expired all subsequent
run or minimize commands in the input script will be skipped.
The remaining time or timer status can be accessed with the
"thermo"_thermo_style.html variable {timeremain}, which will be
zero, if the timeout is inactive (default setting), it will be
negative, if the timeout time is expired and positive if there
is time remaining and in this case the value of the variable are
the number of seconds remaining.
When the {timeout} key word is used a second time, the timer is
restarted with a new time limit. The timeout {elapse} value can
be specified as {off} or {unlimited} to impose a no timeout condition
(which is the default). The {elapse} setting can be specified as
a single number for seconds, two numbers separated by a colon (MM:SS)
for minutes and seconds, or as three numbers separated by colons for
hours, minutes, and seconds (H:MM:SS).
The {every} keyword sets how frequently during a run or energy
minimization the wall clock will be checked. This check count applies
to the outer iterations or time steps during minimizations or "r-RESPA
runs"_run_style.html, respectively. Checking for timeout too often,
can slow a calculation down. Checking too infrequently can make the
timeout measurement less accurate, with the run being stopped later
than desired.
NOTE: Using the {full} and {sync} options provides the most detailed
and accurate timing information, but can also have a negative
performance impact due to the overhead of the many required system
calls. It is thus recommended to use these settings only when testing
tests to identify performance bottlenecks. For calculations with few
atoms or a very large number of processors, even the {normal} setting
can have a measurable negative performance impact. In those cases you
can just use the {loop} or {off} setting.
[Restrictions:] none
[Related commands:]
"run post no"_run.html, "kspace_modify fftbench"_kspace_modify.html
[Default:]
timer normal nosync
timer timeout off
timer every 10 :pre
diff --git a/doc/src/variable.txt b/doc/src/variable.txt
index e32e82ef4..e3b7c5de0 100644
--- a/doc/src/variable.txt
+++ b/doc/src/variable.txt
@@ -1,1325 +1,1325 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
variable command :h3
[Syntax:]
variable name style args ... :pre
name = name of variable to define :ulb,l
style = {delete} or {index} or {loop} or {world} or {universe} or {uloop} or {string} or {format} or {getenv} or {file} or {atomfile} or {python} or {internal} or {equal} or {vector} or {atom} :l
{delete} = no args
{index} args = one or more strings
{loop} args = N
N = integer size of loop, loop from 1 to N inclusive
{loop} args = N pad
N = integer size of loop, loop from 1 to N inclusive
pad = all values will be same length, e.g. 001, 002, ..., 100
{loop} args = N1 N2
N1,N2 = loop from N1 to N2 inclusive
{loop} args = N1 N2 pad
N1,N2 = loop from N1 to N2 inclusive
pad = all values will be same length, e.g. 050, 051, ..., 100
{world} args = one string for each partition of processors
{universe} args = one or more strings
{uloop} args = N
N = integer size of loop
{uloop} args = N pad
N = integer size of loop
pad = all values will be same length, e.g. 001, 002, ..., 100
{string} arg = one string
{format} args = vname fstr
vname = name of equal-style variable to evaluate
fstr = C-style format string
{getenv} arg = one string
{file} arg = filename
{atomfile} arg = filename
{python} arg = function
{internal} arg = numeric value
{equal} or {vector} or {atom} args = one formula containing numbers, thermo keywords, math operations, group functions, atom values and vectors, compute/fix/variable references
numbers = 0.0, 100, -5.4, 2.8e-4, etc
constants = PI, version, on, off, true, false, yes, no
thermo keywords = vol, ke, press, etc from "thermo_style"_thermo_style.html
math operators = (), -x, x+y, x-y, x*y, x/y, x^y, x%y,
x == y, x != y, x < y, x <= y, x > y, x >= y, x && y, x || y, x |^ y, !x
math functions = sqrt(x), exp(x), ln(x), log(x), abs(x),
sin(x), cos(x), tan(x), asin(x), acos(x), atan(x), atan2(y,x),
random(x,y,z), normal(x,y,z), ceil(x), floor(x), round(x)
ramp(x,y), stagger(x,y), logfreq(x,y,z), logfreq2(x,y,z),
stride(x,y,z), stride2(x,y,z,a,b,c),
vdisplace(x,y), swiggle(x,y,z), cwiggle(x,y,z)
group functions = count(group), mass(group), charge(group),
xcm(group,dim), vcm(group,dim), fcm(group,dim),
bound(group,dir), gyration(group), ke(group),
angmom(group,dim), torque(group,dim),
inertia(group,dimdim), omega(group,dim)
region functions = count(group,region), mass(group,region), charge(group,region),
xcm(group,dim,region), vcm(group,dim,region), fcm(group,dim,region),
bound(group,dir,region), gyration(group,region), ke(group,reigon),
angmom(group,dim,region), torque(group,dim,region),
inertia(group,dimdim,region), omega(group,dim,region)
special functions = sum(x), min(x), max(x), ave(x), trap(x), slope(x), gmask(x), rmask(x), grmask(x,y), next(x)
feature functions = is_active(category,feature,exact), is_defined(category,id,exact)
atom value = id\[i\], mass\[i\], type\[i\], mol\[i\], x\[i\], y\[i\], z\[i\], vx\[i\], vy\[i\], vz\[i\], fx\[i\], fy\[i\], fz\[i\], q\[i\]
atom vector = id, mass, type, mol, x, y, z, vx, vy, vz, fx, fy, fz, q
compute references = c_ID, c_ID\[i\], c_ID\[i\]\[j\], C_ID, C_ID\[i\]
fix references = f_ID, f_ID\[i\], f_ID\[i\]\[j\], F_ID, F_ID\[i\]
variable references = v_name, v_name\[i\] :pre
:ule
[Examples:]
variable x index run1 run2 run3 run4 run5 run6 run7 run8
variable LoopVar loop $n
variable beta equal temp/3.0
variable b1 equal x\[234\]+0.5*vol
variable b1 equal "x\[234\] + 0.5*vol"
variable b equal xcm(mol1,x)/2.0
variable b equal c_myTemp
variable b atom x*y/vol
variable foo string myfile
variable foo internal 3.5
variable myPy python increase
variable f file values.txt
variable temp world 300.0 310.0 320.0 $\{Tfinal\}
variable x universe 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
variable x uloop 15 pad
variable str format x %.6g
variable x delete :pre
[Description:]
This command assigns one or more strings to a variable name for
evaluation later in the input script or during a simulation.
Variables can thus be useful in several contexts. A variable can be
defined and then referenced elsewhere in an input script to become
part of a new input command. For variable styles that store multiple
strings, the "next"_next.html command can be used to increment which
string is assigned to the variable. Variables of style {equal} store
a formula which when evaluated produces a single numeric value which
can be output either directly (see the "print"_print.html, "fix
print"_fix_print.html, and "run every"_run.html commands) or as part
of thermodynamic output (see the "thermo_style"_thermo_style.html
command), or used as input to an averaging fix (see the "fix
ave/time"_fix_ave_time.html command). Variables of style {vector}
store a formula which produces a vector of such values which can be
used as input to various averaging fixes, or elements of which can be
part of thermodynamic output. Variables of style {atom} store a
formula which when evaluated produces one numeric value per atom which
can be output to a dump file (see the "dump custom"_dump.html command)
or used as input to an averaging fix (see the "fix
ave/chunk"_fix_ave_chunk.html and "fix ave/atom"_fix_ave_atom.html
commands). Variables of style {atomfile} can be used anywhere in an
input script that atom-style variables are used; they get their
per-atom values from a file rather than from a formula. Variables of
style {python} can be hooked to Python functions using code you
provide, so that the variable gets its value from the evaluation of
the Python code. Variables of style {internal} are used by a few
commands which set their value directly.
NOTE: As discussed in "Section 3.2"_Section_commands.html#cmd_2 of the
manual, an input script can use "immediate" variables, specified as
$(formula) with parenthesis, where the formula has the same syntax as
equal-style variables described on this page. This is a convenient
way to evaluate a formula immediately without using the variable
command to define a named variable and then evaluate that
variable. See below for a more detailed discussion of this feature.
In the discussion that follows, the "name" of the variable is the
arbitrary string that is the 1st argument in the variable command.
This name can only contain alphanumeric characters and underscores.
The "string" is one or more of the subsequent arguments. The "string"
can be simple text as in the 1st example above, it can contain other
variables as in the 2nd example, or it can be a formula as in the 3rd
example. The "value" is the numeric quantity resulting from
evaluation of the string. Note that the same string can generate
different values when it is evaluated at different times during a
simulation.
NOTE: When an input script line is encountered that defines a variable
of style {equal} or {vector} or {atom} or {python} that contains a
formula or Python code, the formula is NOT immediately evaluated. It
will be evaluated every time when the variable is [used] instead. If
you simply want to evaluate a formula in place you can use as
so-called. See the section below about "Immediate Evaluation of
Variables" for more details on the topic. This is also true of a
{format} style variable since it evaluates another variable when it is
invoked.
Variables of style {equal} and {vector} and {atom} can be used as
inputs to various other commands which evaluate their formulas as
needed, e.g. at different timesteps during a "run"_run.html.
Variables of style {internal} can be used in place of an equal-style
variable, except by commands that set the value stored by the
internal-style variable. Thus any command that states it can use an
equal-style variable as an argument, can also use an internal-style
variable. This means that when the command evaluates the variable, it
will use the value set (internally) by another command.
Variables of style {python} can be used in place of an equal-style
variable so long as the associated Python function, as defined by the
"python"_python.html command, returns a numeric value. Thus any
command that states it can use an equal-style variable as an argument,
can also use such a python-style variable. This means that when the
LAMMPS command evaluates the variable, the Python function will be
executed.
NOTE: When a variable command is encountered in the input script and
the variable name has already been specified, the command is ignored.
This means variables can NOT be re-defined in an input script (with
two exceptions, read further). This is to allow an input script to be
processed multiple times without resetting the variables; see the
"jump"_jump.html or "include"_include.html commands. It also means
-that using the "command-line switch"_Section_start.html#start_7 -var
+that using the "command-line switch"_Section_start.html#start_6 -var
will override a corresponding index variable setting in the input
script.
There are two exceptions to this rule. First, variables of style
{string}, {getenv}, {internal}, {equal}, {vector}, {atom}, and
{python} ARE redefined each time the command is encountered. This
allows these style of variables to be redefined multiple times in an
input script. In a loop, this means the formula associated with an
{equal} or {atom} style variable can change if it contains a
substitution for another variable, e.g. $x or v_x.
Second, as described below, if a variable is iterated on to the end of
its list of strings via the "next"_next.html command, it is removed
from the list of active variables, and is thus available to be
re-defined in a subsequent variable command. The {delete} style does
the same thing.
:line
"This section"_Section_commands.html#cmd_2 of the manual explains how
occurrences of a variable name in an input script line are replaced by
the variable's string. The variable name can be referenced as $x if
the name "x" is a single character, or as $\{LoopVar\} if the name
"LoopVar" is one or more characters.
As described below, for variable styles {index}, {loop}, {file},
{universe}, and {uloop}, which string is assigned to a variable can be
incremented via the "next"_next.html command. When there are no more
strings to assign, the variable is exhausted and a flag is set that
causes the next "jump"_jump.html command encountered in the input
script to be skipped. This enables the construction of simple loops
in the input script that are iterated over and then exited from.
As explained above, an exhausted variable can be re-used in an input
script. The {delete} style also removes the variable, the same as if
it were exhausted, allowing it to be redefined later in the input
script or when the input script is looped over. This can be useful
when breaking out of a loop via the "if"_if.html and "jump"_jump.html
commands before the variable would become exhausted. For example,
label loop
variable a loop 5
print "A = $a"
if "$a > 2" then "jump in.script break"
next a
jump in.script loop
label break
variable a delete :pre
:line
This section describes how all the various variable styles are defined
and what they store. Except for the {equal} and {vector} and {atom}
styles, which are explained in the next section.
Many of the styles store one or more strings. Note that a single
string can contain spaces (multiple words), if it is enclosed in
quotes in the variable command. When the variable is substituted for
in another input script command, its returned string will then be
interpreted as multiple arguments in the expanded command.
For the {index} style, one or more strings are specified. Initially,
the 1st string is assigned to the variable. Each time a
"next"_next.html command is used with the variable name, the next
string is assigned. All processors assign the same string to the
variable.
{Index} style variables with a single string value can also be set by
using the command-line switch -var; see "this
-section"_Section_start.html#start_7 for details.
+section"_Section_start.html#start_6 for details.
The {loop} style is identical to the {index} style except that the
strings are the integers from 1 to N inclusive, if only one argument N
is specified. This allows generation of a long list of runs
(e.g. 1000) without having to list N strings in the input script.
Initially, the string "1" is assigned to the variable. Each time a
"next"_next.html command is used with the variable name, the next
string ("2", "3", etc) is assigned. All processors assign the same
string to the variable. The {loop} style can also be specified with
two arguments N1 and N2. In this case the loop runs from N1 to N2
inclusive, and the string N1 is initially assigned to the variable.
N1 <= N2 and N2 >= 0 is required.
For the {world} style, one or more strings are specified. There must
be one string for each processor partition or "world". See "this
-section"_Section_start.html#start_7 of the manual for information on
+section"_Section_start.html#start_6 of the manual for information on
running LAMMPS with multiple partitions via the "-partition"
command-line switch. This variable command assigns one string to each
world. All processors in the world are assigned the same string. The
next command cannot be used with {equal} style variables, since there
is only one value per world. This style of variable is useful when
you wish to run different simulations on different partitions, or when
performing a parallel tempering simulation (see the
"temper"_temper.html command), to assign different temperatures to
different partitions.
For the {universe} style, one or more strings are specified. There
must be at least as many strings as there are processor partitions or
-"worlds". See "this page"_Section_start.html#start_7 for information
+"worlds". See "this page"_Section_start.html#start_6 for information
on running LAMMPS with multiple partitions via the "-partition"
command-line switch. This variable command initially assigns one
string to each world. When a "next"_next.html command is encountered
using this variable, the first processor partition to encounter it, is
assigned the next available string. This continues until all the
variable strings are consumed. Thus, this command can be used to run
50 simulations on 8 processor partitions. The simulations will be run
one after the other on whatever partition becomes available, until
they are all finished. {Universe} style variables are incremented
using the files "tmp.lammps.variable" and "tmp.lammps.variable.lock"
which you will see in your directory during such a LAMMPS run.
The {uloop} style is identical to the {universe} style except that the
strings are the integers from 1 to N. This allows generation of long
list of runs (e.g. 1000) without having to list N strings in the input
script.
For the {string} style, a single string is assigned to the variable.
The only difference between this and using the {index} style with a
single string is that a variable with {string} style can be redefined.
E.g. by another command later in the input script, or if the script is
read again in a loop.
For the {format} style, an equal-style variable is specified along
with a C-style format string, e.g. "%f" or "%.10g", which must be
appropriate for formatting a double-precision floating-point value.
This allows an equal-style variable to be formatted specifically for
output as a string, e.g. by the "print"_print.html command, if the
default format "%.15g" has too much precision.
For the {getenv} style, a single string is assigned to the variable
which should be the name of an environment variable. When the
variable is evaluated, it returns the value of the environment
variable, or an empty string if it not defined. This style of
variable can be used to adapt the behavior of LAMMPS input scripts via
environment variable settings, or to retrieve information that has
been previously stored with the "shell putenv"_shell.html command.
Note that because environment variable settings are stored by the
operating systems, they persist beyond a "clear"_clear.html command.
For the {file} style, a filename is provided which contains a list of
strings to assign to the variable, one per line. The strings can be
numeric values if desired. See the discussion of the next() function
below for equal-style variables, which will convert the string of a
file-style variable into a numeric value in a formula.
When a file-style variable is defined, the file is opened and the
string on the first line is read and stored with the variable. This
means the variable can then be evaluated as many times as desired and
will return that string. There are two ways to cause the next string
from the file to be read: use the "next"_next.html command or the
next() function in an equal- or atom-style variable, as discussed
below.
The rules for formatting the file are as follows. A comment character
"#" can be used anywhere on a line; text starting with the comment
character is stripped. Blank lines are skipped. The first "word" of
a non-blank line, delimited by white space, is the "string" assigned
to the variable.
For the {atomfile} style, a filename is provided which contains one or
more sets of values, to assign on a per-atom basis to the variable.
The format of the file is described below.
When an atomfile-style variable is defined, the file is opened and the
first set of per-atom values are read and stored with the variable.
This means the variable can then be evaluated as many times as desired
and will return those values. There are two ways to cause the next
set of per-atom values from the file to be read: use the
"next"_next.html command or the next() function in an atom-style
variable, as discussed below.
The rules for formatting the file are as follows. Each time a set of
per-atom values is read, a non-blank line is searched for in the file.
A comment character "#" can be used anywhere on a line; text starting
with the comment character is stripped. Blank lines are skipped. The
first "word" of a non-blank line, delimited by white space, is read as
the count N of per-atom lines to immediately follow. N can be be the
total number of atoms in the system, or only a subset. The next N
lines have the following format
ID value :pre
where ID is an atom ID and value is the per-atom numeric value that
will be assigned to that atom. IDs can be listed in any order.
NOTE: Every time a set of per-atom lines is read, the value for all
atoms is first set to 0.0. Thus values for atoms whose ID does not
appear in the set, will remain 0.0.
For the {python} style a Python function name is provided. This needs
to match a function name specified in a "python"_python.html command
which returns a value to this variable as defined by its {return}
keyword. For example these two commands would be self-consistent:
variable foo python myMultiply
python myMultiply return v_foo format f file funcs.py :pre
The two commands can appear in either order so long as both are
specified before the Python function is invoked for the first time.
Each time the variable is evaluated, the associated Python function is
invoked, and the value it returns is also returned by the variable.
Since the Python function can use other LAMMPS variables as input, or
query interal LAMMPS quantities to perform its computation, this means
the variable can return a different value each time it is evaluated.
The type of value stored in the variable is determined by the {format}
keyword of the "python"_python.html command. It can be an integer
(i), floating point (f), or string (s) value. As mentioned above, if
it is a numeric value (integer or floating point), then the
python-style variable can be used in place of an equal-style variable
anywhere in an input script, e.g. as an argument to another command
that allows for equal-style variables.
For the {internal} style a numeric value is provided. This value will
be assigned to the variable until a LAMMPS command sets it to a new
value. There are currently only two LAMMPS commands that require
{internal} variables as inputs, because they reset them:
"create_atoms"_create_atoms.html and "fix
controller"_fix_controller.html. As mentioned above, an
internal-style variable can be used in place of an equal-style
variable anywhere else in an input script, e.g. as an argument to
another command that allows for equal-style variables.
:line
For the {equal} and {vector} and {atom} styles, a single string is
specified which represents a formula that will be evaluated afresh
each time the variable is used. If you want spaces in the string,
enclose it in double quotes so the parser will treat it as a single
argument. For {equal}-style variables the formula computes a scalar
quantity, which becomes the value of the variable whenever it is
evaluated. For {vector}-style variables the formula must compute a
vector of quantities, which becomes the value of the variable whenever
it is evaluated. The calculated vector can be on length one, but it
cannot be a simple scalar value like that produced by an equal-style
compute. I.e. the formula for a vector-style variable must have at
least one quantity in it that refers to a global vector produced by a
compute, fix, or other vector-style variable. For {atom}-style
variables the formula computes one quantity for each atom whenever it
is evaluated.
Note that {equal}, {vector}, and {atom} variables can produce
different values at different stages of the input script or at
different times during a run. For example, if an {equal} variable is
used in a "fix print"_fix_print.html command, different values could
be printed each timestep it was invoked. If you want a variable to be
evaluated immediately, so that the result is stored by the variable
instead of the string, see the section below on "Immediate Evaluation
of Variables".
The next command cannot be used with {equal} or {vector} or {atom}
style variables, since there is only one string.
The formula for an {equal}, {vector}, or {atom} variable can contain a
variety of quantities. The syntax for each kind of quantity is
simple, but multiple quantities can be nested and combined in various
ways to build up formulas of arbitrary complexity. For example, this
is a valid (though strange) variable formula:
variable x equal "pe + c_MyTemp / vol^(1/3)" :pre
Specifically, a formula can contain numbers, constants, thermo
keywords, math operators, math functions, group functions, region
functions, atom values, atom vectors, compute references, fix
references, and references to other variables.
Number: 0.2, 100, 1.0e20, -15.4, etc
Constant: PI, version, on, off, true, false, yes, no
Thermo keywords: vol, pe, ebond, etc
Math operators: (), -x, x+y, x-y, x*y, x/y, x^y, x%y, \
x == y, x != y, x < y, x <= y, x > y, x >= y, x && y, x || y, x |^ y, !x
Math functions: sqrt(x), exp(x), ln(x), log(x), abs(x), \
sin(x), cos(x), tan(x), asin(x), acos(x), atan(x), atan2(y,x), \
random(x,y,z), normal(x,y,z), ceil(x), floor(x), round(x), \
ramp(x,y), stagger(x,y), logfreq(x,y,z), logfreq2(x,y,z), \
stride(x,y,z), stride2(x,y,z,a,b,c), vdisplace(x,y), \
swiggle(x,y,z), cwiggle(x,y,z)
Group functions: count(ID), mass(ID), charge(ID), xcm(ID,dim), \
vcm(ID,dim), fcm(ID,dim), bound(ID,dir), \
gyration(ID), ke(ID), angmom(ID,dim), torque(ID,dim), \
inertia(ID,dimdim), omega(ID,dim)
Region functions: count(ID,IDR), mass(ID,IDR), charge(ID,IDR), \
xcm(ID,dim,IDR), vcm(ID,dim,IDR), fcm(ID,dim,IDR), \
bound(ID,dir,IDR), gyration(ID,IDR), ke(ID,IDR), \
angmom(ID,dim,IDR), torque(ID,dim,IDR), \
inertia(ID,dimdim,IDR), omega(ID,dim,IDR)
Special functions: sum(x), min(x), max(x), ave(x), trap(x), \
slope(x), gmask(x), rmask(x), grmask(x,y), next(x)
Atom values: id\[i\], mass\[i\], type\[i\], mol\[i\], x\[i\], y\[i\], z\[i\], \
vx\[i\], vy\[i\], vz\[i\], fx\[i\], fy\[i\], fz\[i\], q\[i\]
Atom vectors: id, mass, type, mol, x, y, z, vx, vy, vz, fx, fy, fz, q
Compute references: c_ID, c_ID\[i\], c_ID\[i\]\[j\], C_ID, C_ID\[i\]
Fix references: f_ID, f_ID\[i\], f_ID\[i\]\[j\], F_ID, F_ID\[i\]
Other variables: v_name, v_name\[i\] :tb(s=:)
Most of the formula elements produce a scalar value. Some produce a
global or per-atom vector of values. Global vectors can be produced
by computes or fixes or by other vector-style variables. Per-atom
vectors are produced by atom vectors, compute references that
represent a per-atom vector, fix references that represent a per-atom
vector, and variables that are atom-style variables. Math functions
that operate on scalar values produce a scalar value; math function
that operate on global or per-atom vectors do so element-by-element
and produce a global or per-atom vector.
A formula for equal-style variables cannot use any formula element
that produces a global or per-atom vector. A formula for a
vector-style variable can use formula elements that produce either a
scalar value or a global vector value, but cannot use a formula
element that produces a per-atom vector. A formula for an atom-style
variable can use formula elements that produce either a scalar value
or a per-atom vector, but not one that produces a global vector.
Atom-style variables are evaluated by other commands that define a
"group"_group.html on which they operate, e.g. a "dump"_dump.html or
"compute"_compute.html or "fix"_fix.html command. When they invoke
the atom-style variable, only atoms in the group are included in the
formula evaluation. The variable evaluates to 0.0 for atoms not in
the group.
:line
Numbers, constants, and thermo keywords :h4
Numbers can contain digits, scientific notation
(3.0e20,3.0e-20,3.0E20,3.0E-20), and leading minus signs.
Constants are set at compile time and cannot be changed. {PI} will
return the number 3.14159265358979323846; {on}, {true} or {yes} will
return 1.0; {off}, {false} or {no} will return 0.0; {version} will
return a numeric version code of the current LAMMPS version (e.g.
version 2 Sep 2015 will return the number 20150902). The corresponding
value for newer versions of LAMMPS will be larger, for older versions
of LAMMPS will be smaller. This can be used to have input scripts
adapt automatically to LAMMPS versions, when non-backwards compatible
syntax changes are introduced. Here is an illustrative example (which
will not work, since the {version} has been introduced more recently):
if $(version<20140513) then "communicate vel yes" else "comm_modify vel yes" :pre
The thermo keywords allowed in a formula are those defined by the
"thermo_style custom"_thermo_style.html command. Thermo keywords that
require a "compute"_compute.html to calculate their values such as
"temp" or "press", use computes stored and invoked by the
"thermo_style"_thermo_style.html command. This means that you can
only use those keywords in a variable if the style you are using with
the thermo_style command (and the thermo keywords associated with that
style) also define and use the needed compute. Note that some thermo
keywords use a compute indirectly to calculate their value (e.g. the
enthalpy keyword uses temp, pe, and pressure). If a variable is
evaluated directly in an input script (not during a run), then the
values accessed by the thermo keyword must be current. See the
discussion below about "Variable Accuracy".
:line
Math Operators :h4
Math operators are written in the usual way, where the "x" and "y" in
the examples can themselves be arbitrarily complex formulas, as in the
examples above. In this syntax, "x" and "y" can be scalar values or
per-atom vectors. For example, "ke/natoms" is the division of two
scalars, where "vy+vz" is the element-by-element sum of two per-atom
vectors of y and z velocities.
Operators are evaluated left to right and have the usual C-style
precedence: unary minus and unary logical NOT operator "!" have the
highest precedence, exponentiation "^" is next; multiplication and
division and the modulo operator "%" are next; addition and
subtraction are next; the 4 relational operators "<", "<=", ">", and
">=" are next; the two remaining relational operators "==" and "!="
are next; then the logical AND operator "&&"; and finally the logical
OR operator "||" and logical XOR (exclusive or) operator "|^" have the
lowest precedence. Parenthesis can be used to group one or more
portions of a formula and/or enforce a different order of evaluation
than what would occur with the default precedence.
NOTE: Because a unary minus is higher precedence than exponentiation,
the formula "-2^2" will evaluate to 4, not -4. This convention is
compatible with some programming languages, but not others. As
mentioned, this behavior can be easily overridden with parenthesis;
the formula "-(2^2)" will evaluate to -4.
The 6 relational operators return either a 1.0 or 0.0 depending on
whether the relationship between x and y is TRUE or FALSE. For
example the expression x<10.0 in an atom-style variable formula will
return 1.0 for all atoms whose x-coordinate is less than 10.0, and 0.0
for the others. The logical AND operator will return 1.0 if both its
arguments are non-zero, else it returns 0.0. The logical OR operator
will return 1.0 if either of its arguments is non-zero, else it
returns 0.0. The logical XOR operator will return 1.0 if one of its
arguments is zero and the other non-zero, else it returns 0.0. The
logical NOT operator returns 1.0 if its argument is 0.0, else it
returns 0.0.
These relational and logical operators can be used as a masking or
selection operation in a formula. For example, the number of atoms
whose properties satisfy one or more criteria could be calculated by
taking the returned per-atom vector of ones and zeroes and passing it
to the "compute reduce"_compute_reduce.html command.
:line
Math Functions :h4
Math functions are specified as keywords followed by one or more
parenthesized arguments "x", "y", "z", each of which can themselves be
arbitrarily complex formulas. In this syntax, the arguments can
represent scalar values or global vectors or per-atom vectors. In the
latter case, the math operation is performed on each element of the
vector. For example, "sqrt(natoms)" is the sqrt() of a scalar, where
"sqrt(y*z)" yields a per-atom vector with each element being the
sqrt() of the product of one atom's y and z coordinates.
Most of the math functions perform obvious operations. The ln() is
the natural log; log() is the base 10 log.
The random(x,y,z) function takes 3 arguments: x = lo, y = hi, and z =
seed. It generates a uniform random number between lo and hi. The
normal(x,y,z) function also takes 3 arguments: x = mu, y = sigma, and
z = seed. It generates a Gaussian variate centered on mu with
variance sigma^2. In both cases the seed is used the first time the
internal random number generator is invoked, to initialize it. For
equal-style and vector-style variables, every processor uses the same
seed so that they each generate the same sequence of random numbers.
For atom-style variables, a unique seed is created for each processor,
based on the specified seed. This effectively generates a different
random number for each atom being looped over in the atom-style
variable.
NOTE: Internally, there is just one random number generator for all
equal-style and vector-style variables and another one for all
atom-style variables. If you define multiple variables (of each
style) which use the random() or normal() math functions, then the
internal random number generators will only be initialized once, which
means only one of the specified seeds will determine the sequence of
generated random numbers.
The ceil(), floor(), and round() functions are those in the C math
library. Ceil() is the smallest integer not less than its argument.
Floor() if the largest integer not greater than its argument. Round()
is the nearest integer to its argument.
The ramp(x,y) function uses the current timestep to generate a value
linearly interpolated between the specified x,y values over the course
of a run, according to this formula:
value = x + (y-x) * (timestep-startstep) / (stopstep-startstep) :pre
The run begins on startstep and ends on stopstep. Startstep and
stopstep can span multiple runs, using the {start} and {stop} keywords
of the "run"_run.html command. See the "run"_run.html command for
details of how to do this.
The stagger(x,y) function uses the current timestep to generate a new
timestep. X,y > 0 and x > y are required. The generated timesteps
increase in a staggered fashion, as the sequence
x,x+y,2x,2x+y,3x,3x+y,etc. For any current timestep, the next
timestep in the sequence is returned. Thus if stagger(1000,100) is
used in a variable by the "dump_modify every"_dump_modify.html
command, it will generate the sequence of output timesteps:
100,1000,1100,2000,2100,3000,etc :pre
The logfreq(x,y,z) function uses the current timestep to generate a
new timestep. X,y,z > 0 and y < z are required. The generated
timesteps are on a base-z logarithmic scale, starting with x, and the
y value is how many of the z-1 possible timesteps within one
logarithmic interval are generated. I.e. the timesteps follow the
sequence x,2x,3x,...y*x,x*z,2x*z,3x*z,...y*x*z,x*z^2,2x*z^2,etc. For
any current timestep, the next timestep in the sequence is returned.
Thus if logfreq(100,4,10) is used in a variable by the "dump_modify
every"_dump_modify.html command, it will generate this sequence of
output timesteps:
100,200,300,400,1000,2000,3000,4000,10000,20000,etc :pre
The logfreq2(x,y,z) function is similar to logfreq, except a single
logarithmic interval is divided into y equally-spaced timesteps and
all of them are output. Y < z is not required. Thus, if
logfreq2(100,18,10) is used in a variable by the "dump_modify
every"_dump_modify.html command, then the interval between 100 and
1000 is divided as 900/18 = 50 steps, and it will generate the
sequence of output timesteps:
100,150,200,...950,1000,1500,2000,...9500,10000,15000,etc :pre
The stride(x,y,z) function uses the current timestep to generate a new
timestep. X,y >= 0 and z > 0 and x <= y are required. The generated
timesteps increase in increments of z, from x to y, i.e. it generates
the sequence x,x+z,x+2z,...,y. If y-x is not a multiple of z, then
similar to the way a for loop operates, the last value will be one
that does not exceed y. For any current timestep, the next timestep
in the sequence is returned. Thus if stride(1000,2000,100) is used
in a variable by the "dump_modify every"_dump_modify.html command, it
will generate the sequence of output timesteps:
1000,1100,1200, ... ,1900,2000 :pre
The stride2(x,y,z,a,b,c) function is similar to the stride() function
except it generates two sets of strided timesteps, one at a coarser
level and one at a finer level. Thus it is useful for debugging,
e.g. to produce output every timestep at the point in simulation when
a problem occurs. X,y >= 0 and z > 0 and x <= y are required, as are
a,b >= 0 and c > 0 and a < b. Also, a >= x and b <= y are required so
that the second stride is inside the first. The generated timesteps
increase in increments of z, starting at x, until a is reached. At
that point the timestep increases in increments of c, from a to b,
then after b, increments by z are resumed until y is reached. For any
current timestep, the next timestep in the sequence is returned. Thus
if stride(1000,2000,100,1350,1360,1) is used in a variable by the
"dump_modify every"_dump_modify.html command, it will generate the
sequence of output timesteps:
1000,1100,1200,1300,1350,1351,1352, ... 1359,1360,1400,1500, ... ,2000 :pre
The vdisplace(x,y) function takes 2 arguments: x = value0 and y =
velocity, and uses the elapsed time to change the value by a linear
displacement due to the applied velocity over the course of a run,
according to this formula:
value = value0 + velocity*(timestep-startstep)*dt :pre
where dt = the timestep size.
The run begins on startstep. Startstep can span multiple runs, using
the {start} keyword of the "run"_run.html command. See the
"run"_run.html command for details of how to do this. Note that the
"thermo_style"_thermo_style.html keyword elaplong =
timestep-startstep.
The swiggle(x,y,z) and cwiggle(x,y,z) functions each take 3 arguments:
x = value0, y = amplitude, z = period. They use the elapsed time to
oscillate the value by a sin() or cos() function over the course of a
run, according to one of these formulas, where omega = 2 PI / period:
value = value0 + Amplitude * sin(omega*(timestep-startstep)*dt)
value = value0 + Amplitude * (1 - cos(omega*(timestep-startstep)*dt)) :pre
where dt = the timestep size.
The run begins on startstep. Startstep can span multiple runs, using
the {start} keyword of the "run"_run.html command. See the
"run"_run.html command for details of how to do this. Note that the
"thermo_style"_thermo_style.html keyword elaplong =
timestep-startstep.
:line
Group and Region Functions :h4
Group functions are specified as keywords followed by one or two
parenthesized arguments. The first argument {ID} is the group-ID.
The {dim} argument, if it exists, is {x} or {y} or {z}. The {dir}
argument, if it exists, is {xmin}, {xmax}, {ymin}, {ymax}, {zmin}, or
{zmax}. The {dimdim} argument, if it exists, is {xx} or {yy} or {zz}
or {xy} or {yz} or {xz}.
The group function count() is the number of atoms in the group. The
group functions mass() and charge() are the total mass and charge of
the group. Xcm() and vcm() return components of the position and
velocity of the center of mass of the group. Fcm() returns a
component of the total force on the group of atoms. Bound() returns
the min/max of a particular coordinate for all atoms in the group.
Gyration() computes the radius-of-gyration of the group of atoms. See
the "compute gyration"_compute_gyration.html command for a definition
of the formula. Angmom() returns components of the angular momentum
of the group of atoms around its center of mass. Torque() returns
components of the torque on the group of atoms around its center of
mass, based on current forces on the atoms. Inertia() returns one of
6 components of the symmetric inertia tensor of the group of atoms
around its center of mass, ordered as Ixx,Iyy,Izz,Ixy,Iyz,Ixz.
Omega() returns components of the angular velocity of the group of
atoms around its center of mass.
Region functions are specified exactly the same way as group functions
except they take an extra final argument {IDR} which is the region ID.
The function is computed for all atoms that are in both the group and
the region. If the group is "all", then the only criteria for atom
inclusion is that it be in the region.
:line
Special Functions :h4
Special functions take specific kinds of arguments, meaning their
arguments cannot be formulas themselves.
The sum(x), min(x), max(x), ave(x), trap(x), and slope(x) functions
each take 1 argument which is of the form "c_ID" or "c_ID\[N\]" or
"f_ID" or "f_ID\[N\]" or "v_name". The first two are computes and the
second two are fixes; the ID in the reference should be replaced by
the ID of a compute or fix defined elsewhere in the input script. The
compute or fix must produce either a global vector or array. If it
produces a global vector, then the notation without "\[N\]" should be
used. If it produces a global array, then the notation with "\[N\]"
should be used, when N is an integer, to specify which column of the
global array is being referenced. The last form of argument "v_name"
is for a vector-style variable where "name" is replaced by the name of
the variable.
These functions operate on a global vector of inputs and reduce it to
a single scalar value. This is analogous to the operation of the
"compute reduce"_compute_reduce.html command, which performs similar
operations on per-atom and local vectors.
The sum() function calculates the sum of all the vector elements. The
min() and max() functions find the minimum and maximum element
respectively. The ave() function is the same as sum() except that it
divides the result by the length of the vector.
The trap() function is the same as sum() except the first and last
elements are multiplied by a weighting factor of 1/2 when performing
the sum. This effectively implements an integration via the
trapezoidal rule on the global vector of data. I.e. consider a set of
points, equally spaced by 1 in their x coordinate: (1,V1), (2,V2),
..., (N,VN), where the Vi are the values in the global vector of
length N. The integral from 1 to N of these points is trap(). When
appropriately normalized by the timestep size, this function is useful
for calculating integrals of time-series data, like that generated by
the "fix ave/correlate"_fix_ave_correlate.html command.
The slope() function uses linear regression to fit a line to the set
of points, equally spaced by 1 in their x coordinate: (1,V1), (2,V2),
..., (N,VN), where the Vi are the values in the global vector of
length N. The returned value is the slope of the line. If the line
has a single point or is vertical, it returns 1.0e20.
The gmask(x) function takes 1 argument which is a group ID. It
can only be used in atom-style variables. It returns a 1 for
atoms that are in the group, and a 0 for atoms that are not.
The rmask(x) function takes 1 argument which is a region ID. It can
only be used in atom-style variables. It returns a 1 for atoms that
are in the geometric region, and a 0 for atoms that are not.
The grmask(x,y) function takes 2 arguments. The first is a group ID,
and the second is a region ID. It can only be used in atom-style
variables. It returns a 1 for atoms that are in both the group and
region, and a 0 for atoms that are not in both.
The next(x) function takes 1 argument which is a variable ID (not
"v_foo", just "foo"). It must be for a file-style or atomfile-style
variable. Each time the next() function is invoked (i.e. each time
the equal-style or atom-style variable is evaluated), the following
steps occur.
For file-style variables, the current string value stored by the
file-style variable is converted to a numeric value and returned by
the function. And the next string value in the file is read and
stored. Note that if the line previously read from the file was not a
numeric string, then it will typically evaluate to 0.0, which is
likely not what you want.
For atomfile-style variables, the current per-atom values stored by
the atomfile-style variable are returned by the function. And the
next set of per-atom values in the file is read and stored.
Since file-style and atomfile-style variables read and store the first
line of the file or first set of per-atoms values when they are
defined in the input script, these are the value(s) that will be
returned the first time the next() function is invoked. If next() is
invoked more times than there are lines or sets of lines in the file,
the variable is deleted, similar to how the "next"_next.html command
operates.
:line
Feature Functions :h4
Feature functions allow to probe the running LAMMPS executable for
whether specific features are either active, defined, or available.
The functions take two arguments, a {category} and a corresponding
{argument}. The arguments are strings thus cannot be formulas
themselves (only $-style immediate variable expansion is possible).
Return value is either 1.0 or 0.0 depending on whether the function
evaluates to true or false, respectively.
The {is_active()} function allows to query for active settings which
are grouped by categories. Currently supported categories and
arguments are:
{package} (argument = {cuda} or {gpu} or {intel} or {kokkos} or {omp})
{newton} (argument = {pair} or {bond} or {any})
{pair} (argument = {single} or {respa} or {manybody} or {tail} or {shift})
{comm_style} (argument = {brick} or {tiled})
{min_style} (argument = any of the compiled in minimizer styles)
{run_style} (argument = any of the compiled in run styles)
{atom_style} (argument = any of the compiled in atom styles)
{pair_style} (argument = any of the compiled in pair styles)
{bond_style} (argument = any of the compiled in bond styles)
{angle_style} (argument = any of the compiled in angle styles)
{dihedral_style} (argument = any of the compiled in dihedral styles)
{improper_style} (argument = any of the compiled in improper styles)
{kspace_style} (argument = any of the compiled in kspace styles) :ul
Most of the settings are self-explanatory, the {single} argument in the
{pair} category allows to check whether a pair style supports a
Pair::single() function as needed by compute group/group and others
features or LAMMPS, {respa} allows to check whether the inner/middle/outer
mode of r-RESPA is supported. In the various style categories,
the checking is also done using suffix flags, if available and enabled.
Example 1: disable use of suffix for pppm when using GPU package (i.e. run it on the CPU concurrently to running the pair style on the GPU), but do use the suffix otherwise (e.g. with USER-OMP).
pair_style lj/cut/coul/long 14.0
if $(is_active(package,gpu)) then "suffix off"
kspace_style pppm :pre
Example 2: use r-RESPA with inner/outer cutoff, if supported by pair style, otherwise fall back to using pair and reducing the outer time step
timestep $(2.0*(1.0+*is_active(pair,respa))
if $(is_active(pair,respa)) then "run_style respa 4 3 2 2 improper 1 inner 2 5.5 7.0 outer 3 kspace 4" else "run_style respa 3 3 2 improper 1 pair 2 kspace 3" :pre
The {is_defined()} function allows to query categories like {compute},
{dump}, {fix}, {group}, {region}, and {variable} whether an entry
with the provided name or id is defined.
The {is_available(category,name)} function allows to query whether
a specific optional feature is available, i.e. compiled in.
This currently works for the following categories: {command},
{compute}, {fix}, {pair_style} and {feature}. For all categories
except {command} and {feature} also appending active suffixes is
tried before reporting failure.
The {feature} category is used to check the availability of compiled in
features such as GZIP support, PNG support, JPEG support, FFMPEG support,
and C++ exceptions for error handling. Corresponding values for name are
{gzip}, {png}, {jpeg}, {ffmpeg} and {exceptions}.
This enables writing input scripts which only dump using a given format if
the compiled binary supports it.
if "$(is_available(feature,png))" then "print 'PNG supported'" else "print 'PNG not supported'" :pre
if "$(is_available(feature,ffmpeg)" then "dump 3 all movie 25 movie.mp4 type type zoom 1.6 adiam 1.0" :pre
:line
Atom Values and Vectors :h4
Atom values take an integer argument I from 1 to N, where I is the
atom-ID, e.g. x\[243\], which means use the x coordinate of the atom
with ID = 243. Or they can take a variable name, specified as v_name,
where name is the name of the variable, like x\[v_myIndex\]. The
variable can be of any style except {vector} or {atom} or {atomfile}
variables. The variable is evaluated and the result is expected to be
numeric and is cast to an integer (i.e. 3.4 becomes 3), to use an an
index, which must be a value from 1 to N. Note that a "formula"
cannot be used as the argument between the brackets, e.g. x\[243+10\]
or x\[v_myIndex+1\] are not allowed. To do this a single variable can
be defined that contains the needed formula.
Note that the 0 < atom-ID <= N, where N is the largest atom ID
in the system. If an ID is specified for an atom that does not
currently exist, then the generated value is 0.0.
Atom vectors generate one value per atom, so that a reference like
"vx" means the x-component of each atom's velocity will be used when
evaluating the variable.
The meaning of the different atom values and vectors is mostly
self-explanatory. {Mol} refers to the molecule ID of an atom, and is
only defined if an "atom_style"_atom_style.html is being used that
defines molecule IDs.
Note that many other atom attributes can be used as inputs to a
variable by using the "compute
property/atom"_compute_property_atom.html command and then specifying
a quantity from that compute.
:line
Compute References :h4
Compute references access quantities calculated by a
"compute"_compute.html. The ID in the reference should be replaced by
the ID of a compute defined elsewhere in the input script. As
discussed in the doc page for the "compute"_compute.html command,
computes can produce global, per-atom, or local values. Only global
and per-atom values can be used in a variable. Computes can also
produce a scalar, vector, or array.
An equal-style variable can only use scalar values, which means a
global scalar, or an element of a global or per-atom vector or array.
A vector-style variable can use scalar values or a global vector of
values, or a column of a global array of values. Atom-style variables
can use global scalar values. They can also use per-atom vector
values, or a column of a per-atom array. See the doc pages for
individual computes to see what kind of values they produce.
Examples of different kinds of compute references are as follows.
There is typically no ambiguity (see exception below) as to what a
reference means, since computes only produce either global or per-atom
quantities, never both.
c_ID: global scalar, or per-atom vector
c_ID\[I\]: Ith element of global vector, or atom I's value in per-atom vector, or Ith column from per-atom array
c_ID\[I\]\[J\]: I,J element of global array, or atom I's Jth value in per-atom array :tb(s=:)
For I and J indices, integers can be specified or a variable name,
specified as v_name, where name is the name of the variable. The
rules for this syntax are the same as for the "Atom Values and
Vectors" discussion above.
One source of ambiguity for compute references is when a vector-style
variable refers to a compute that produces both a global scalar and a
global vector. Consider a compute with ID "foo" that does this,
referenced as follows by variable "a", where "myVec" is another
vector-style variable:
variable a vector c_foo*v_myVec :pre
The reference "c_foo" could refer to either the global scalar or
global vector produced by compute "foo". In this case, "c_foo" will
always refer to the global scalar, and "C_foo" can be used to
reference the global vector. Similarly if the compute produces both a
global vector and global array, then "c_foo\[I\]" will always refer to
an element of the global vector, and "C_foo\[I\]" can be used to
reference the Ith column of the global array.
Note that if a variable containing a compute is evaluated directly in
an input script (not during a run), then the values accessed by the
compute must be current. See the discussion below about "Variable
Accuracy".
:line
Fix References :h4
Fix references access quantities calculated by a "fix"_compute.html.
The ID in the reference should be replaced by the ID of a fix defined
elsewhere in the input script. As discussed in the doc page for the
"fix"_fix.html command, fixes can produce global, per-atom, or local
values. Only global and per-atom values can be used in a variable.
Fixes can also produce a scalar, vector, or array. An equal-style
variable can only use scalar values, which means a global scalar, or
an element of a global or per-atom vector or array. Atom-style
variables can use the same scalar values. They can also use per-atom
vector values. A vector value can be a per-atom vector itself, or a
column of an per-atom array. See the doc pages for individual fixes
to see what kind of values they produce.
The different kinds of fix references are exactly the same as the
compute references listed in the above table, where "c_" is replaced
by "f_". Again, there is typically no ambiguity (see exception below)
as to what a reference means, since fixes only produce either global
or per-atom quantities, never both.
f_ID: global scalar, or per-atom vector
f_ID\[I\]: Ith element of global vector, or atom I's value in per-atom vector, or Ith column from per-atom array
f_ID\[I\]\[J\]: I,J element of global array, or atom I's Jth value in per-atom array :tb(s=:)
For I and J indices, integers can be specified or a variable name,
specified as v_name, where name is the name of the variable. The
rules for this syntax are the same as for the "Atom Values and
Vectors" discussion above.
One source of ambiguity for fix references is the same ambiguity
discussed for compute references above. Namely when a vector-style
variable refers to a fix that produces both a global scalar and a
global vector. The solution is the same as for compute references.
For a fix with ID "foo", "f_foo" will always refer to the global
scalar, and "F_foo" can be used to reference the global vector. And
similarly for distinguishing between a fix's global vector versus
global array with "f_foo\[I\]" versus "F_foo\[I\]".
Note that if a variable containing a fix is evaluated directly in an
input script (not during a run), then the values accessed by the fix
should be current. See the discussion below about "Variable
Accuracy".
Note that some fixes only generate quantities on certain timesteps.
If a variable attempts to access the fix on non-allowed timesteps, an
error is generated. For example, the "fix ave/time"_fix_ave_time.html
command may only generate averaged quantities every 100 steps. See
the doc pages for individual fix commands for details.
:line
Variable References :h4
Variable references access quantities stored or calculated by other
variables, which will cause those variables to be evaluated. The name
in the reference should be replaced by the name of a variable defined
elsewhere in the input script.
As discussed on this doc page, equal-style variables generate a single
global numeric value, vector-style variables generate a vector of
global numeric values, and atom-style and atomfile-style variables
generate a per-atom vector of numeric values. All other variables
store one or more strings.
The formula for an equal-style variable can use any style of variable
including a vector_style or atom-style or atomfile-style. For these
3 styles, a subscript must be used to access a single value from
the vector-, atom-, or atomfile-style variable. If a string-storing
variable is used, the string is converted to a numeric value. Note
that this will typically produce a 0.0 if the string is not a numeric
string, which is likely not what you want.
The formula for a vector-style variable can use any style of variable,
including atom-style or atomfile-style variables. For these 2 styles,
a subscript must be used to access a single value from the atom-, or
atomfile-style variable.
The formula for an atom-style variable can use any style of variable,
including other atom-style or atomfile-style variables. If it uses a
vector-style variable, a subscript must be used to access a single
value from the vector-style variable.
Examples of different kinds of variable references are as follows.
There is no ambiguity as to what a reference means, since variables
produce only a global scalar or global vector or per-atom vector.
v_name: global scalar from equal-style variable
v_name: global vector from vector-style variable
v_name: per-atom vector from atom-style or atomfile-style variable
v_name\[I\]: Ith element of a global vector from vector-style variable
v_name\[I\]: value of atom with ID = I from atom-style or atomfile-style variable :tb(s=:)
For the I index, an integer can be specified or a variable name,
specified as v_name, where name is the name of the variable. The
rules for this syntax are the same as for the "Atom Values and
Vectors" discussion above.
:line
[Immediate Evaluation of Variables:]
If you want an equal-style variable to be evaluated immediately, it
may be the case that you do not need to define a variable at all. See
"Section 3.2"_Section_commands.html#cmd_2 of the manual, which
describes the use of "immediate" variables in an input script,
specified as $(formula) with parenthesis, where the formula has the
same syntax as equal-style variables described on this page. This
effectively evaluates a formula immediately without using the variable
command to define a named variable.
More generally, there is a difference between referencing a variable
with a leading $ sign (e.g. $x or $\{abc\}) versus with a leading "v_"
(e.g. v_x or v_abc). The former can be used in any input script
command, including a variable command. The input script parser
evaluates the reference variable immediately and substitutes its value
into the command. As explained in "Section
3.2"_Section_commands.html#cmd_2 for "Parsing rules", you can also use
un-named "immediate" variables for this purpose. For example, a
string like this $((xlo+xhi)/2+sqrt(v_area)) in an input script
command evaluates the string between the parenthesis as an equal-style
variable formula.
Referencing a variable with a leading "v_" is an optional or required
kind of argument for some commands (e.g. the "fix
ave/chunk"_fix_ave_chunk.html or "dump custom"_dump.html or
"thermo_style"_thermo_style.html commands) if you wish it to evaluate
a variable periodically during a run. It can also be used in a
variable formula if you wish to reference a second variable. The
second variable will be evaluated whenever the first variable is
evaluated.
As an example, suppose you use this command in your input script to
define the variable "v" as
variable v equal vol :pre
before a run where the simulation box size changes. You might think
this will assign the initial volume to the variable "v". That is not
the case. Rather it assigns a formula which evaluates the volume
(using the thermo_style keyword "vol") to the variable "v". If you
use the variable "v" in some other command like "fix
ave/time"_fix_ave_time.html then the current volume of the box will be
evaluated continuously during the run.
If you want to store the initial volume of the system, you can do it
this way:
variable v equal vol
variable v0 equal $v :pre
The second command will force "v" to be evaluated (yielding the
initial volume) and assign that value to the variable "v0". Thus the
command
thermo_style custom step v_v v_v0 :pre
would print out both the current and initial volume periodically
during the run.
Note that it is a mistake to enclose a variable formula in double
quotes if it contains variables preceded by $ signs. For example,
variable vratio equal "$\{vfinal\}/$\{v0\}" :pre
This is because the quotes prevent variable substitution (see "this
section"_Section_commands.html#cmd_2 on parsing input script
commands), and thus an error will occur when the formula for "vratio"
is evaluated later.
:line
[Variable Accuracy:]
Obviously, LAMMPS attempts to evaluate variables containing formulas
({equal} and {atom} style variables) accurately whenever the
evaluation is performed. Depending on what is included in the
formula, this may require invoking a "compute"_compute.html, either
directly or indirectly via a thermo keyword, or accessing a value
previously calculated by a compute, or accessing a value calculated
and stored by a "fix"_fix.html. If the compute is one that calculates
the pressure or energy of the system, then these quantities need to be
tallied during the evaluation of the interatomic potentials (pair,
bond, etc) on timesteps that the variable will need the values.
LAMMPS keeps track of all of this during a "run"_run.html or "energy
minimization"_minimize.html. An error will be generated if you
attempt to evaluate a variable on timesteps when it cannot produce
accurate values. For example, if a "thermo_style
custom"_thermo_style.html command prints a variable which accesses
values stored by a "fix ave/time"_fix_ave_time.html command and the
timesteps on which thermo output is generated are not multiples of the
averaging frequency used in the fix command, then an error will occur.
An input script can also request variables be evaluated before or
after or in between runs, e.g. by including them in a
"print"_print.html command. In this case, if a compute is needed to
evaluate a variable (either directly or indirectly), LAMMPS will not
invoke the compute, but it will use a value previously calculated by
the compute, and can do this only if it was invoked on the current
timestep. Fixes will always provide a quantity needed by a variable,
but the quantity may or may not be current. This leads to one of
three kinds of behavior:
(1) The variable may be evaluated accurately. If it contains
references to a compute or fix, and these values were calculated on
the last timestep of a preceding run, then they will be accessed and
used by the variable and the result will be accurate.
(2) LAMMPS may not be able to evaluate the variable and will generate
an error message stating so. For example, if the variable requires a
quantity from a "compute"_compute.html that has not been invoked on
the current timestep, LAMMPS will generate an error. This means, for
example, that such a variable cannot be evaluated before the first run
has occurred. Likewise, in between runs, a variable containing a
compute cannot be evaluated unless the compute was invoked on the last
timestep of the preceding run, e.g. by thermodynamic output.
One way to get around this problem is to perform a 0-timestep run
before using the variable. For example, these commands
variable t equal temp
print "Initial temperature = $t"
run 1000 :pre
will generate an error if the run is the first run specified in the
input script, because generating a value for the "t" variable requires
a compute for calculating the temperature to be invoked.
However, this sequence of commands would be fine:
run 0
variable t equal temp
print "Initial temperature = $t"
run 1000 :pre
The 0-timestep run initializes and invokes various computes, including
the one for temperature, so that the value it stores is current and
can be accessed by the variable "t" after the run has completed. Note
that a 0-timestep run does not alter the state of the system, so it
does not change the input state for the 1000-timestep run that
follows. Also note that the 0-timestep run must actually use and
invoke the compute in question (e.g. via "thermo"_thermo_style.html or
"dump"_dump.html output) in order for it to enable the compute to be
used in a variable after the run. Thus if you are trying to print a
variable that uses a compute you have defined, you can insure it is
invoked on the last timestep of the preceding run by including it in
thermodynamic output.
Unlike computes, "fixes"_fix.html will never generate an error if
their values are accessed by a variable in between runs. They always
return some value to the variable. However, the value may not be what
you expect if the fix has not yet calculated the quantity of interest
or it is not current. For example, the "fix indent"_fix_indent.html
command stores the force on the indenter. But this is not computed
until a run is performed. Thus if a variable attempts to print this
value before the first run, zeroes will be output. Again, performing
a 0-timestep run before printing the variable has the desired effect.
(3) The variable may be evaluated incorrectly and LAMMPS may have no
way to detect this has occurred. Consider the following sequence of
commands:
pair_coeff 1 1 1.0 1.0
run 1000
pair_coeff 1 1 1.5 1.0
variable e equal pe
print "Final potential energy = $e" :pre
The first run is performed using one setting for the pairwise
potential defined by the "pair_style"_pair_style.html and
"pair_coeff"_pair_coeff.html commands. The potential energy is
evaluated on the final timestep and stored by the "compute
pe"_compute_pe.html compute (this is done by the
"thermo_style"_thermo_style.html command). Then a pair coefficient is
changed, altering the potential energy of the system. When the
potential energy is printed via the "e" variable, LAMMPS will use the
potential energy value stored by the "compute pe"_compute_pe.html
compute, thinking it is current. There are many other commands which
could alter the state of the system between runs, causing a variable
to evaluate incorrectly.
The solution to this issue is the same as for case (2) above, namely
perform a 0-timestep run before the variable is evaluated to insure
the system is up-to-date. For example, this sequence of commands
would print a potential energy that reflected the changed pairwise
coefficient:
pair_coeff 1 1 1.0 1.0
run 1000
pair_coeff 1 1 1.5 1.0
run 0
variable e equal pe
print "Final potential energy = $e" :pre
:line
[Restrictions:]
Indexing any formula element by global atom ID, such as an atom value,
requires the "atom style"_atom_style.html to use a global mapping in
order to look up the vector indices. By default, only atom styles
with molecular information create global maps. The "atom_modify
map"_atom_modify.html command can override the default, e.g. for
atomic-style atom styles.
All {universe}- and {uloop}-style variables defined in an input script
must have the same number of values.
[Related commands:]
"next"_next.html, "jump"_jump.html, "include"_include.html,
"temper"_temper.html, "fix print"_fix_print.html, "print"_print.html
[Default:] none
diff --git a/doc/src/write_data.txt b/doc/src/write_data.txt
index 033199e98..39e5a7f81 100644
--- a/doc/src/write_data.txt
+++ b/doc/src/write_data.txt
@@ -1,123 +1,123 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
write_data command :h3
[Syntax:]
write_data file keyword value ... :pre
file = name of data file to write out :ulb,l
zero or more keyword/value pairs may be appended :l
keyword = {pair} or {nocoeff} :l
{nocoeff} = do not write out force field info
{pair} value = {ii} or {ij}
{ii} = write one line of pair coefficient info per atom type
{ij} = write one line of pair coefficient info per IJ atom type pair :pre
:ule
[Examples:]
write_data data.polymer
write_data data.* :pre
[Description:]
Write a data file in text format of the current state of the
simulation. Data files can be read by the "read data"_read_data.html
command to begin a simulation. The "read_data"_read_data.html command
also describes their format.
Similar to "dump"_dump.html files, the data filename can contain a "*"
wild-card character. The "*" is replaced with the current timestep
value.
NOTE: The write-data command is not yet fully implemented in two
respects. First, most pair styles do not yet write their coefficient
information into the data file. This means you will need to specify
that information in your input script that reads the data file, via
the "pair_coeff"_pair_coeff.html command. Second, a few of the "atom
styles"_atom_style.html (body, ellipsoid, line, tri) that store
auxiliary "bonus" information about aspherical particles, do not yet
write the bonus info into the data file. Both these functionalities
will be added to the write_data command later.
Because a data file is in text format, if you use a data file written
out by this command to restart a simulation, the initial state of the
new run will be slightly different than the final state of the old run
(when the file was written) which was represented internally by LAMMPS
in binary format. A new simulation which reads the data file will
thus typically diverge from a simulation that continued in the
original input script.
If you want to do more exact restarts, using binary files, see the
"restart"_restart.html, "write_restart"_write_restart.html, and
"read_restart"_read_restart.html commands. You can also convert
binary restart files to text data files, after a simulation has run,
-using the "-r command-line switch"_Section_start.html#start_7.
+using the "-r command-line switch"_Section_start.html#start_6.
NOTE: Only limited information about a simulation is stored in a data
file. For example, no information about atom "groups"_group.html and
"fixes"_fix.html are stored. "Binary restart files"_read_restart.html
store more information.
Bond interactions (angle, etc) that have been turned off by the "fix
shake"_fix_shake.html or "delete_bonds"_delete_bonds.html command will
be written to a data file as if they are turned on. This means they
will need to be turned off again in a new run after the data file is
read.
Bonds that are broken (e.g. by a bond-breaking potential) are not
written to the data file. Thus these bonds will not exist when the
data file is read.
:line
The {nocoeff} keyword requests that no force field parameters should
be written to the data file. This can be very helpful, if one wants
to make significant changes to the force field or if the parameters
are read in separately anyway, e.g. from an include file.
The {pair} keyword lets you specify in what format the pair
coefficient information is written into the data file. If the value
is specified as {ii}, then one line per atom type is written, to
specify the coefficients for each of the I=J interactions. This means
that no cross-interactions for I != J will be specified in the data
file and the pair style will apply its mixing rule, as documented on
individual "pair_style"_pair_style.html doc pages. Of course this
behavior can be overridden in the input script after reading the data
file, by specifying additional "pair_coeff"_pair_coeff.html commands
for any desired I,J pairs.
If the value is specified as {ij}, then one line of coefficients is
written for all I,J pairs where I <= J. These coefficients will
include any specific settings made in the input script up to that
point. The presence of these I != J coefficients in the data file
will effectively turn off the default mixing rule for the pair style.
Again, the coefficient values in the data file can can be overridden
in the input script after reading the data file, by specifying
additional "pair_coeff"_pair_coeff.html commands for any desired I,J
pairs.
:line
[Restrictions:]
This command requires inter-processor communication to migrate atoms
before the data file is written. This means that your system must be
ready to perform a simulation before using this command (force fields
setup, atom masses initialized, etc).
[Related commands:]
"read_data"_read_data.html, "write_restart"_write_restart.html
[Default:]
The option defaults are pair = ii.
diff --git a/doc/src/write_restart.txt b/doc/src/write_restart.txt
index 8160eec3d..ff3b652db 100644
--- a/doc/src/write_restart.txt
+++ b/doc/src/write_restart.txt
@@ -1,121 +1,121 @@
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
:link(lws,http://lammps.sandia.gov)
:link(ld,Manual.html)
:link(lc,Section_commands.html#comm)
:line
write_restart command :h3
[Syntax:]
write_restart file keyword value ... :pre
file = name of file to write restart information to :ulb,l
zero or more keyword/value pairs may be appended :l
keyword = {fileper} or {nfile} :l
{fileper} arg = Np
Np = write one file for every this many processors
{nfile} arg = Nf
Nf = write this many files, one from each of Nf processors :pre
:ule
[Examples:]
write_restart restart.equil
write_restart restart.equil.mpiio
write_restart poly.%.* nfile 10 :pre
[Description:]
Write a binary restart file of the current state of the simulation.
During a long simulation, the "restart"_restart.html command is
typically used to output restart files periodically. The
write_restart command is useful after a minimization or whenever you
wish to write out a single current restart file.
Similar to "dump"_dump.html files, the restart filename can contain
two wild-card characters. If a "*" appears in the filename, it is
replaced with the current timestep value. If a "%" character appears
in the filename, then one file is written by each processor and the
"%" character is replaced with the processor ID from 0 to P-1. An
additional file with the "%" replaced by "base" is also written, which
contains global information. For example, the files written for
filename restart.% would be restart.base, restart.0, restart.1, ...
restart.P-1. This creates smaller files and can be a fast mode of
output and subsequent input on parallel machines that support parallel
I/O. The optional {fileper} and {nfile} keywords discussed below can
alter the number of files written.
The restart file can also be written in parallel as one large binary
file via the MPI-IO library, which is part of the MPI standard for
versions 2.0 and above. Using MPI-IO requires two steps. First,
build LAMMPS with its MPIIO package installed, e.g.
make yes-mpiio # installs the MPIIO package
make mpi # build LAMMPS for your platform :pre
Second, use a restart filename which contains ".mpiio". Note that it
does not have to end in ".mpiio", just contain those characters.
Unlike MPI-IO dump files, a particular restart file must be both
written and read using MPI-IO.
Restart files can be read by a "read_restart"_read_restart.html
command to restart a simulation from a particular state. Because the
file is binary (to enable exact restarts), it may not be readable on
another machine. In this case, you can use the "-r command-line
-switch"_Section_start.html#start_7 to convert a restart file to a data
+switch"_Section_start.html#start_6 to convert a restart file to a data
file.
NOTE: Although the purpose of restart files is to enable restarting a
simulation from where it left off, not all information about a
simulation is stored in the file. For example, the list of fixes that
were specified during the initial run is not stored, which means the
new input script must specify any fixes you want to use. Even when
restart information is stored in the file, as it is for some fixes,
commands may need to be re-specified in the new input script, in order
to re-use that information. Details are usually given in the
documentation of the respective command. Also, see the
"read_restart"_read_restart.html command for general information about
what is stored in a restart file.
:line
The optional {nfile} or {fileper} keywords can be used in conjunction
with the "%" wildcard character in the specified restart file name.
As explained above, the "%" character causes the restart file to be
written in pieces, one piece for each of P processors. By default P =
the number of processors the simulation is running on. The {nfile} or
{fileper} keyword can be used to set P to a smaller value, which can
be more efficient when running on a large number of processors.
The {nfile} keyword sets P to the specified Nf value. For example, if
Nf = 4, and the simulation is running on 100 processors, 4 files will
be written, by processors 0,25,50,75. Each will collect information
from itself and the next 24 processors and write it to a restart file.
For the {fileper} keyword, the specified value of Np means write one
file for every Np processors. For example, if Np = 4, every 4th
processor (0,4,8,12,etc) will collect information from itself and the
next 3 processors and write it to a restart file.
:line
[Restrictions:]
This command requires inter-processor communication to migrate atoms
before the restart file is written. This means that your system must
be ready to perform a simulation before using this command (force
fields setup, atom masses initialized, etc).
To write and read restart files in parallel with MPI-IO, the MPIIO
package must be installed.
[Related commands:]
"restart"_restart.html, "read_restart"_read_restart.html,
"write_data"_write_data.html
[Default:] none
diff --git a/examples/README b/examples/README
index e4312e259..702ada790 100644
--- a/examples/README
+++ b/examples/README
@@ -1,178 +1,169 @@
LAMMPS example problems
There are 3 flavors of sub-directories in this file, each with sample
problems you can run with LAMMPS.
lower-case directories = simple test problems for LAMMPS and its packages
upper-case directories = more complex problems
USER directory with its own sub-directories = tests for USER packages
Each is discussed below.
------------------------------------------
Lower-case directories
Each of these sub-directories contains a sample problem you can run
with LAMMPS. Most are 2d models so that they run quickly, requiring a
few seconds to a few minutes to run on a desktop machine. Each
problem has an input script (in.*) and produces a log file (log.*) and
(optionally) a dump file (dump.*) or image files (image.*) or movie
(movie.mpg) when it runs. Some use a data file (data.*) of initial
coordinates as additional input. Some require that you install one or
more optional LAMMPS packages.
A few sample log file outputs on different machines and different
numbers of processors are included in the directories to compare your
answers to. E.g. a log file like log.crack.date.foo.P means it ran on
P processors of machine "foo" with the dated version of LAMMPS. Note
that these problems should get statistically similar answers when run
on different machines or different numbers of processors, but not
identical answers to those in the log of dump files included here.
See the Errors section of the LAMMPS documentation for more
discussion.
Most of the example input scripts have commented-out lines that
produce dump snapshots of the running simulation in any of 3 formats.
If you uncomment the dump command in the input script, a text dump
file will be produced, which can be animated by various visualization
programs (see http://lammps.sandia.gov/viz.html) such as Ovito, VMD,
or AtomEye.
If you uncomment the dump image command in the input script, and
assuming you have built LAMMPS with a JPG library, JPG snapshot images
will be produced when the simulation runs. They can be quickly
post-processed into a movie using commands described on the dump image
doc page.
If you uncomment the dump movie command in the input script, and
assuming you have built LAMMPS with the FFMPEG library, an MPG movie
will be produced when the simulation runs. The movie file can be
played using various viewers, such as mplayer or QuickTime.
Animations of many of these examples can be viewed on the Movies
section of the LAMMPS WWW Site.
These are the sample problems and their output in the various
sub-directories:
accelerate: use of all the various accelerator packages
balance: dynamic load balancing, 2d system
body: body particles, 2d system
cmap: CMAP 5-body contributions to CHARMM force field
colloid: big colloid particles in a small particle solvent, 2d system
comb: models using the COMB potential
coreshell: adiabatic core/shell model
controller: use of fix controller as a thermostat
crack: crack propagation in a 2d solid
deposit: deposition of atoms and molecules onto a 3d substrate
dipole: point dipolar particles, 2d system
dreiding: methanol via Dreiding FF
eim: NaCl using the EIM potential
ellipse: ellipsoidal particles in spherical solvent, 2d system
flow: Couette and Poiseuille flow in a 2d channel
friction: frictional contact of spherical asperities between 2d surfaces
gcmc: Grand Canonical Monte Carlo (GCMC) via the fix gcmc command
granregion: use of fix wall/region/gran as boundary on granular particles
hugoniostat: Hugoniostat shock dynamics
indent: spherical indenter into a 2d solid
kim: use of potentials in Knowledge Base for Interatomic Models (KIM)
meam: MEAM test for SiC and shear (same as shear examples)
melt: rapid melt of 3d LJ system
micelle: self-assembly of small lipid-like molecules into 2d bilayers
min: energy minimization of 2d LJ melt
mscg: parameterize a multi-scale coarse-graining (MSCG) model
msst: MSST shock dynamics
nb3b: use of nonbonded 3-body harmonic pair style
neb: nudged elastic band (NEB) calculation for barrier finding
nemd: non-equilibrium MD of 2d sheared system
obstacle: flow around two voids in a 2d channel
peptide: dynamics of a small solvated peptide chain (5-mer)
peri: Peridynamic model of cylinder impacted by indenter
pour: pouring of granular particles into a 3d box, then chute flow
prd: parallel replica dynamics of vacancy diffusion in bulk Si
python: use of PYTHON package to invoke Python code from input script
qeq: use of QEQ package for charge equilibration
reax: RDX and TATB models using the ReaxFF
rigid: rigid bodies modeled as independent or coupled
shear: sideways shear applied to 2d solid, with and without a void
snap: use of SNAP potential for Ta
srd: stochastic rotation dynamics (SRD) particles as solvent
snap: NVE dynamics for BCC tantalum crystal using SNAP potential
streitz: Streitz-Mintmire potential for Al2O3
tad: temperature-accelerated dynamics of vacancy diffusion in bulk Si
vashishta: models using the Vashishta potential
voronoi: Voronoi tesselation via compute voronoi/atom command
-Here is a src/Make.py command which will perform a parallel build of a
-LAMMPS executable "lmp_mpi" with all the packages needed by all the
-examples, with the exception of the accelerate sub-directory. See the
-accelerate/README for Make.py commands suitable for its example
-scripts.
-
-cd src
-Make.py -j 16 -p none std no-lib reax meam poems reaxc orig -a lib-all mpi
-
Here is how you might run and visualize one of the sample problems:
cd indent
cp ../../src/lmp_mpi . # copy LAMMPS executable to this dir
-lmp_mpi < in.indent # run the problem
+lmp_mpi -in in.indent # run the problem
Running the simulation produces the files {dump.indent} and
{log.lammps}. You can visualize the dump file as follows:
../../tools/xmovie/xmovie -scale dump.indent
If you uncomment the dump image line(s) in the input script a series
of JPG images will be produced by the run. These can be viewed
individually or turned into a movie or animated by tools like
ImageMagick or QuickTime or various Windows-based tools. See the dump
image doc page for more details. E.g. this Imagemagick command would
create a GIF file suitable for viewing in a browser.
% convert -loop 1 *.jpg foo.gif
------------------------------------------
Upper-case directories
The ASPHERE directory has examples of how to model aspherical
particles with or without solvent, in 3 styles LAMMPS provides.
Namely point ellipsoids, rigid bodies, and generalized aspherical
bodies built from line/triangle surface facets in 2d/3d. See the
ASPHERE/README file to get started.
The COUPLE directory has examples of how to use LAMMPS as a library,
either by itself or in tandem with another code or library. See the
COUPLE/README file to get started.
The ELASTIC directory has an example script for computing elastic
constants at zero temperature, using an Si example. See the
ELASTIC/in.elastic file for more info.
The ELASTIC_T directory has an example script for computing elastic
constants at finite temperature, using an Si example. See the
ELASTIC_T/in.elastic file for more info.
The HEAT directory has example scripts for heat exchange algorithms
(e.g. used for establishing a thermal gradient), using two different
methods. See the HEAT/README file for more info.
The KAPPA directory has example scripts for computing the thermal
conductivity (kappa) of a LJ liquid using 5 different methods. See
the KAPPA/README file for more info.
The MC directory has an example script for using LAMMPS as an
energy-evaluation engine in a iterative Monte Carlo energy-relaxation
loop.
The USER directory contains subdirectories of user-provided example
scripts for ser packages. See the README files in those directories
for more info. See the doc/Section_start.html file for more info
about installing and building user packages.
The VISCOSITY directory has example scripts for computing the
viscosity of a LJ liquid using 4 different methods. See the
VISCOSITY/README file for more info.
diff --git a/examples/accelerate/README b/examples/accelerate/README
index 1fab296a5..c4eb5dcc8 100644
--- a/examples/accelerate/README
+++ b/examples/accelerate/README
@@ -1,158 +1,106 @@
These are example scripts that can be run with any of
the acclerator packages in LAMMPS:
-USER-CUDA, GPU, USER-INTEL, KOKKOS, USER-OMP, OPT
+GPU, USER-INTEL, KOKKOS, USER-OMP, OPT
The easiest way to build LAMMPS with these packages
-is via the src/Make.py tool described in Section 2.4
-of the manual. You can also type "Make.py -h" to see
-its options. The easiest way to run these scripts
-is by using the appropriate
-
+is via the flags described in Section 4 of the manual.
+The easiest way to run these scripts is by using the appropriate
Details on the individual accelerator packages
can be found in doc/Section_accelerate.html.
---------------------
Build LAMMPS with one or more of the accelerator packages
-The following command will invoke the src/Make.py tool with one of the
-command-lines from the Make.list file:
-
-../../src/Make.py -r Make.list target
-
-target = one or more of the following:
- cpu, omp, opt
- cuda_double, cuda_mixed, cuda_single
- gpu_double, gpu_mixed, gpu_single
- intel_cpu, intel_phi
- kokkos_omp, kokkos_cuda, kokkos_phi
-
-If successful, the build will produce the file lmp_target in this
-directory.
-
Note that in addition to any accelerator packages, these packages also
need to be installed to run all of the example scripts: ASPHERE,
MOLECULE, KSPACE, RIGID.
These two targets will build a single LAMMPS executable with all the
CPU accelerator packages installed (USER-INTEL for CPU, KOKKOS for
OMP, USER-OMP, OPT) or all the GPU accelerator packages installed
-(USER-CUDA, GPU, KOKKOS for CUDA):
-
-target = all_cpu, all_gpu
-
-Note that the Make.py commands in Make.list assume an MPI environment
-exists on your machine and use mpicxx as the wrapper compiler with
-whatever underlying compiler it wraps by default. If you add "-cc mpi
-wrap=g++" or "-cc mpi wrap=icc" after the target, you can choose the
-underlying compiler for mpicxx to invoke. E.g.
-
-../../src/Make.py -r Make.list intel_cpu -cc mpi wrap=icc
+(GPU, KOKKOS for CUDA):
-You should do this for any build that includes the USER-INTEL
-package, since it will perform best with the Intel compilers.
-
-Note that for kokkos_cuda, it needs to be "-cc nvcc" instead of "mpi",
-since a KOKKOS for CUDA build requires NVIDIA nvcc as the wrapper
-compiler.
-
-Also note that the Make.py commands in Make.list use the default
-FFT support which is via the KISS library. If you want to
-build with another FFT library, e.g. FFTW3, then you can add
-"-fft fftw3" after the target, e.g.
-
-../../src/Make.py -r Make.list gpu -fft fftw3
-
-For any build with USER-CUDA, GPU, or KOKKOS for CUDA, be sure to set
+For any build with GPU, or KOKKOS for CUDA, be sure to set
the arch=XX setting to the appropriate value for the GPUs and Cuda
-environment on your system. What is defined in the Make.list file is
-arch=21 for older Fermi GPUs. This can be overridden as follows,
-e.g. for Kepler GPUs:
-
-../../src/Make.py -r Make.list gpu_double -gpu mode=double arch=35
+environment on your system.
---------------------
Running with each of the accelerator packages
All of the input scripts have a default problem size and number of
timesteps:
in.lj = LJ melt with cutoff of 2.5 = 32K atoms for 100 steps
in.lj.5.0 = same with cutoff of 5.0 = 32K atoms for 100 steps
in.phosphate = 11K atoms for 100 steps
in.rhodo = 32K atoms for 100 steps
in.lc = 33K atoms for 100 steps (after 200 steps equilibration)
These can be reset using the x,y,z and t variables in the command
line. E.g. adding "-v x 2 -v y 2 -v z 4 -t 1000" to any of the run
command below would run a 16x larger problem (2x2x4) for 1000 steps.
Here are example run commands using each of the accelerator packages:
** CPU only
lmp_cpu < in.lj
mpirun -np 4 lmp_cpu -in in.lj
** OPT package
lmp_opt -sf opt < in.lj
mpirun -np 4 lmp_opt -sf opt -in in.lj
** USER-OMP package
lmp_omp -sf omp -pk omp 1 < in.lj
mpirun -np 4 lmp_omp -sf opt -pk omp 1 -in in.lj # 4 MPI, 1 thread/MPI
mpirun -np 2 lmp_omp -sf opt -pk omp 4 -in in.lj # 2 MPI, 4 thread/MPI
** GPU package
lmp_gpu_double -sf gpu < in.lj
mpirun -np 8 lmp_gpu_double -sf gpu < in.lj # 8 MPI, 8 MPI/GPU
mpirun -np 12 lmp_gpu_double -sf gpu -pk gpu 2 < in.lj # 12 MPI, 6 MPI/GPU
mpirun -np 4 lmp_gpu_double -sf gpu -pk gpu 2 tpa 8 < in.lj.5.0 # 4 MPI, 2 MPI/GPU
Note that when running in.lj.5.0 (which has a long cutoff) with the
GPU package, the "-pk tpa" setting should be > 1 (e.g. 8) for best
performance.
-** USER-CUDA package
-
-lmp_machine -c on -sf cuda < in.lj
-mpirun -np 1 lmp_machine -c on -sf cuda < in.lj # 1 MPI, 1 MPI/GPU
-mpirun -np 2 lmp_machine -c on -sf cuda -pk cuda 2 < in.lj # 2 MPI, 1 MPI/GPU
-
** KOKKOS package for OMP
lmp_kokkos_omp -k on t 1 -sf kk -pk kokkos neigh half < in.lj
mpirun -np 2 lmp_kokkos_omp -k on t 4 -sf kk < in.lj # 2 MPI, 4 thread/MPI
Note that when running with just 1 thread/MPI, "-pk kokkos neigh half"
was specified to use half neighbor lists which are faster when running
on just 1 thread.
** KOKKOS package for CUDA
lmp_kokkos_cuda -k on t 1 -sf kk < in.lj # 1 thread, 1 GPU
mpirun -np 2 lmp_kokkos_cuda -k on t 6 g 2 -sf kk < in.lj # 2 MPI, 6 thread/MPI, 1 MPI/GPU
** KOKKOS package for PHI
mpirun -np 1 lmp_kokkos_phi -k on t 240 -sf kk -in in.lj # 1 MPI, 240 threads/MPI
mpirun -np 30 lmp_kokkos_phi -k on t 8 -sf kk -in in.lj # 30 MPI, 8 threads/MPI
** USER-INTEL package for CPU
lmp_intel_cpu -sf intel < in.lj
mpirun -np 4 lmp_intl_cpu -sf intel < in.lj # 4 MPI
mpirun -np 4 lmp_intl_cpu -sf intel -pk omp 2 < in.lj # 4 MPI, 2 thread/MPI
** USER-INTEL package for PHI
lmp_intel_phi -sf intel -pk intel 1 omp 16 < in.lc # 1 MPI, 16 CPU thread/MPI, 1 Phi, 240 Phi thread/MPI
mpirun -np 4 lmp_intel_phi -sf intel -pk intel 1 omp 2 < in.lc # 4 MPI, 2 CPU threads/MPI, 1 Phi, 60 Phi thread/MPI
Note that there is currently no Phi support for pair_style lj/cut in
the USER-INTEL package.
diff --git a/src/Make.py b/src/Make.py
deleted file mode 100755
index 3030183e1..000000000
--- a/src/Make.py
+++ /dev/null
@@ -1,2378 +0,0 @@
-#!/usr/bin/env python2
-
-# Make.py tool for managing packages and their auxiliary libs,
-# auto-editing machine Makefiles, and building LAMMPS
-# Syntax: Make.py -h (for help)
-# Notes: should be compatible with python 2.7 and 3.x thanks to 'futurize'
-
-from __future__ import print_function
-import sys,os,re,copy,subprocess,platform
-
-# switch abbrevs
-# switch classes = created class for each switch
-# lib classes = auxiliary package libs
-# build classes = build options with defaults
-# make classes = makefile options with no defaults
-# setargs = makefile settings
-# actionargs = allowed actions (also lib-dir and machine)
-# lib build flags are set if lib is built, for use with zoutput
-
-abbrevs = "adhjmoprsvz"
-
-switchclasses = ("actions","dir","help","jmake","makefile",
- "output","packages","redo","settings","verbose","zoutput")
-libclasses = ("atc","awpmd","colvars","cuda","gpu","h5md",
- "meam","poems","python","qmmm","reax","voronoi")
-buildclasses = ("intel","kokkos")
-makeclasses = ("cc","flags","mpi","fft","jpg","png")
-
-setargs = ("gzip","#gzip","ffmpeg","#ffmpeg","smallbig","bigbig",
- "smallsmall","exceptions","#exceptions")
-actionargs = ("lib-all","file","clean","exe")
-
-gpubuildflag = 0
-
-# ----------------------------------------------------------------
-# functions
-# ----------------------------------------------------------------
-
-# if flag = 1, print txt and exit
-# if flag = 0, print txt as warning and do not exit
-
-def error(txt,flag=1):
- if flag:
- print("ERROR:",txt)
- sys.exit()
- else:
- print("WARNING:",txt)
-
-# store command-line args as sw = dict of key/value
-# key = switch word, value = list of following args
-# order = list of switches in order specified
-# enforce no switch more than once
-
-def parse_args(args):
- narg = len(args)
- sw = {}
- order = []
- iarg = 0
- while iarg < narg:
- if args[iarg][0] != '-': error("Arg %s is not a switch" % args[iarg])
- switch = args[iarg][1:]
- if switch in sw: error("Duplicate switch %s" % args[iarg])
- order.append(switch)
- first = iarg+1
- last = first
- while last < narg and args[last][0] != '-': last += 1
- sw[switch] = args[first:last]
- iarg = last
- return sw,order
-
-# convert info in switches dict back to a string, in switch_order
-
-def switch2str(switches,switch_order):
- txt = ""
- for switch in switch_order:
- if txt: txt += ' '
- txt += "-%s" % switch
- txt += ' ' + ' '.join(switches[switch])
- return txt
-
-# check if compiler works with ccflags on dummy one-line tmpauto.cpp file
-# return 1 if successful, else 0
-# warn = 1 = print warning if not successful, warn = 0 = no warning
-# NOTE: unrecognized -override-limits can leave verride-limits file
-
-def compile_check(compiler,ccflags,warn):
- open("tmpauto.cpp",'w').write("int main(int, char **) {}\n")
- tmp = "%s %s -c tmpauto.cpp" % (compiler,ccflags)
- try: txt = subprocess.check_output(tmp,stderr=subprocess.STDOUT,
- shell=True).decode()
- except subprocess.CalledProcessError as e: txt = e.output
- flag = 1
- if txt or not os.path.isfile("tmpauto.o"):
- flag = 0
- if warn:
- print(tmp)
- if txt: print(txt)
- else: print("compile produced no output")
- os.remove("tmpauto.cpp")
- if os.path.isfile("tmpauto.o"): os.remove("tmpauto.o")
- return flag
-
-# check if linker works with linkflags and libs on tmpauto.o file
-# return 1 if successful, else 0
-# warn = 1 = print warning if not successful, warn = 0 = no warning
-
-def link_check(linker,linkflags,libs,warn):
- open("tmpauto.cpp",'w').write("int main(int, char **) {}\n")
- tmp = "%s %s -o tmpauto tmpauto.cpp %s" % (linker,linkflags,libs)
- try: txt = subprocess.check_output(tmp,stderr=subprocess.STDOUT,
- shell=True).decode()
- except subprocess.CalledProcessError as e: txt = e.output
- flag = 1
- if txt or not os.path.isfile("tmpauto"):
- flag = 0
- if warn:
- print(tmp)
- if txt: print(txt)
- else: print("link produced no output")
- os.remove("tmpauto.cpp")
- if os.path.isfile("tmpauto"): os.remove("tmpauto")
- return flag
-
-# ----------------------------------------------------------------
-# switch classes, one per single-letter switch
-# ----------------------------------------------------------------
-
-# actions
-
-class Actions(object):
- def __init__(self,list):
- self.inlist = copy.copy(list)
-
- def help(self):
- return """
--a action1 action2 ...
- possible actions = lib-all, lib-dir, file, clean, exe or machine
- machine is a Makefile.machine suffix
- actions can be specified in any order
- each action can appear only once
- lib-dir can appear multiple times for different dirs
- some actions depend on installed packages
- installed packages = currently installed + result of -p switch
- actions are invoked in this order, independent of specified order
- (1) lib-all or lib-dir = build auxiliary libraries
- lib-all builds all auxiliary libs needed by installed packages
- lib-dir builds a specific lib whether package installed or not
- dir is any dir in lib directory (atc, cuda, meam, etc) except linalg
- (2) file = create a new src/MAKE/MINE/Makefile.auto
- if file not specified, existing Makefile.auto is NOT changed
- except by -m switch, which will copy Makefile.machine to Makefile.auto
- note that exe action can add an -m switch, as described below
- if file is specified, new Makefile.auto is created
- if "-m machine" specified (or added by exe),
- start with existing Makefile.machine, else existing Makefile.auto
- if "-m none" specified, start Makefile.auto from scratch
- must use -cc and -mpi switches to specify compiler and MPI
- settings for these switches will alter Makefile.auto
- -s, -intel, -kokkos, -cc, -mpi, -fft, -jpg, -png
- if these accelerator packages are installed, they induce settings
- that will alter Makefile.auto: opt, user-omp, user-intel, kokkos
- use -z switch to copy final Makefile.auto to new filename
- (3) clean = invoke "make clean-auto" to insure clean build on current files
- useful if compiler flags have changed
- (4) exe or machine = build LAMMPS
- machine can be any existing Makefile.machine suffix
- machine is converted to "exe" action, and additionally:
- "-m machine" is added if -m switch is not specified
- "-o machine" is added if -o switch is not specified
- if either "-m" or "-o" are specified, they are not overridden
- does not invoke any lib builds, since libs could be previously built
- exe ALWAYS builds using src/MAKE/MINE/Makefile.auto
- if file action also specified, it creates a new Makefile.auto
- else if -m switch specified,
- existing Makefile.machine is copied to create Makefile.auto
- else Makefile.auto must already exist and is not changed
- build produces src/lmp_auto, or error message if unsuccessful
- use -o switch to copy src/lmp_auto to new filename
- use -z switch to copy src/MAKE/MINE/Makefile.auto to new filename
-"""
-
- def check(self):
- if not self.inlist: error("-a args are invalid")
- libs = []
- cleans = []
- files = []
- exes = []
- for one in self.inlist:
- if one.startswith("lib-"):
- lib = one[4:]
- if lib != "all" and lib not in libclasses: error("Actions are invalid")
- libs.append(one)
- elif one == "file":
- files.append(one)
- elif one == "clean":
- cleans.append(one)
- elif one == "exe":
- exes.append(one)
- # one action can be unknown, must be a machine (checked in setup)
- else:
- exes.append(one)
- if len(set(libs)) != len(libs) or \
- len(cleans) > 1 or len(files) > 1 or len(exes) > 1:
- error("Actions are invalid")
- self.alist = [action for actions in [libs,cleans,files,exes] \
- for action in actions]
-
- # dedup list of actions concatenated from two lists
- # current self.inlist = specified -a switch + redo command -a switch
- # specified exe/machine action replaces redo exe/machine action
- # operates on and replaces self.inlist
-
- def dedup(self):
- alist = []
- exemachine = 0
- for one in self.inlist:
- if one == "exe" or (one not in actionargs and not one.startswith("lib-")):
- if exemachine: continue
- exemachine = 1
- if one not in alist: alist.append(one)
- self.inlist = alist
-
- # if last action is unknown, assume machine and convert to exe
- # only done if action is a suffix for an existing Makefile.machine
- # return machine if conversion done, else None
-
- def setup(self):
- machine = self.alist[-1]
- if machine in actionargs or machine.startswith("lib-"): return None
- make = MakeReader(machine,2)
- self.alist[-1] = "exe"
- return machine
-
- # build one or more auxiliary package libraries
-
- def lib(self,suffix):
- if suffix != "all":
- print("building",suffix,"library ...")
- txt = "%s.build()" % suffix
- exec(txt)
- else:
- final = packages.final
- for one in packages.lib:
- if final[one]:
- if "user" in one: pkg = one[5:]
- else: pkg = one
- print("building",pkg,"library ...")
- txt = "%s.build()" % pkg
- exec(txt)
-
- # read Makefile.machine
- # if caller = "file", edit via switches
- # if caller = "exe", just read
- # write out new Makefile.auto
-
- def file(self,caller):
-
- # if caller="file", create from mpi or read from Makefile.machine or auto
- # if caller="exe" and "file" action already invoked, read from auto
- # if caller="exe" and no "file" action, read from Makefile.machine or auto
-
- if caller == "file":
- if makefile and makefile.machine == "none":
- if cc and mpi: machine = "mpi"
- else: error("Cannot create makefile unless -cc and -mpi are used")
- elif makefile: machine = makefile.machine
- else: machine = "auto"
- elif caller == "exe" and "file" in self.alist:
- machine = "auto"
- elif caller == "exe" and "file" not in self.alist:
- if makefile and makefile.machine == "none":
- error("Cannot build with makefile = none")
- elif makefile: machine = makefile.machine
- else: machine = "auto"
-
- make = MakeReader(machine,1)
-
- # change makefile settings to user specifications
-
- precompiler = ""
- if caller == "file":
-
- # add compiler/linker and default CCFLAGS,LINKFLAGS
- # if cc.wrap, add wrapper setting for mpi = ompi/mpich
- # precompiler = env variable setting for OpenMPI wrapper compiler
-
- if cc:
- make.setvar("CC",cc.compiler)
- make.setvar("LINK",cc.compiler)
- if cc.wrap:
- if cc.wrap == "nvcc":
- wrapper = os.path.abspath("../lib/kokkos/config/nvcc_wrapper")
- else: wrapper = cc.wrap
- abbrev = cc.abbrev
- if abbrev == "mpi":
- if cc.parent == "mpich":
- make.addvar("CC","-cxx=%s" % wrapper)
- make.addvar("LINK","-cxx=%s" % wrapper)
- elif cc.parent == "openmpi":
- make.addvar("export OMPI_CXX",wrapper,"cc")
- precompiler = "env OMPI_CXX=%s " % wrapper
- else: error("Could not add MPI wrapper compiler, " +
- "did not recognize OpenMPI or MPICH")
- make.setvar("CCFLAGS","-g")
- make.addvar("CCFLAGS","-O3")
- make.setvar("LINKFLAGS","-g")
- make.addvar("LINKFLAGS","-O")
-
- # add MPI settings
-
- if mpi:
- make.delvar("MPI_INC","*")
- make.delvar("MPI_PATH","*")
- make.delvar("MPI_LIB","*")
- if mpi.style == "mpi":
- make.addvar("MPI_INC","-DMPICH_SKIP_MPICXX")
- make.addvar("MPI_INC","-DOMPI_SKIP_MPICXX=1")
- elif mpi.style == "mpich":
- make.addvar("MPI_INC","-DMPICH_SKIP_MPICXX")
- make.addvar("MPI_INC","-DOMPI_SKIP_MPICXX=1")
- if mpi.dir: make.addvar("MPI_INC","-I%s/include" % mpi.dir)
- if mpi.dir: make.addvar("MPI_PATH","-L%s/lib" % mpi.dir)
- make.addvar("MPI_LIB","-lmpich")
- make.addvar("MPI_LIB","-lmpl")
- make.addvar("MPI_LIB","-lpthread")
- elif mpi.style == "ompi":
- make.addvar("MPI_INC","-DMPICH_SKIP_MPICXX")
- make.addvar("MPI_INC","-DOMPI_SKIP_MPICXX=1")
- if mpi.dir: make.addvar("MPI_INC","-I%s/include" % mpi.dir)
- if mpi.dir: make.addvar("MPI_PATH","-L%s/lib" % mpi.dir)
- make.addvar("MPI_LIB","-lmpi")
- make.addvar("MPI_LIB","-lmpi_cxx")
- elif mpi.style == "serial":
- make.addvar("MPI_INC","-I../STUBS")
- make.addvar("MPI_PATH","-L../STUBS")
- make.addvar("MPI_LIB","-lmpi_stubs")
-
- # add accelerator package CCFLAGS and LINKFLAGS and variables
-
- compiler = precompiler + ' '.join(make.getvar("CC"))
- linker = precompiler + ' '.join(make.getvar("LINK"))
-
- final = packages.final
- if final["opt"]:
- if compile_check(compiler,"-restrict",0):
- make.addvar("CCFLAGS","-restrict")
-
- if final["user-omp"]:
- if compile_check(compiler,"-fopenmp",1):
- make.addvar("CCFLAGS","-fopenmp")
- make.addvar("LINKFLAGS","-fopenmp")
- if compile_check(compiler,"-restrict",0):
- make.addvar("CCFLAGS","-restrict")
-
- if final["user-intel"]:
- if intel.mode == "cpu":
- make.delvar("CCFLAGS","-O*")
- make.addvar("CCFLAGS","-O2")
- if compile_check(compiler,"-openmp",1):
- make.addvar("CCFLAGS","-openmp")
- if compile_check(compiler,"-restrict",1):
- make.addvar("CCFLAGS","-restrict")
- if compile_check(compiler,"-no-offload",1):
- make.addvar("CCFLAGS","-no-offload")
- if compile_check(compiler,"-fno-alias",1):
- make.addvar("CCFLAGS","-fno-alias")
- if compile_check(compiler,"-ansi-alias",1):
- make.addvar("CCFLAGS","-ansi-alias")
- if compile_check(compiler,"-xAVX",1):
- make.addvar("CCFLAGS","-xAVX")
- if compile_check(compiler,"-fp-model fast=2",1):
- make.addvar("CCFLAGS","-fp-model fast=2")
- if compile_check(compiler,"-no-prec-div",1):
- make.addvar("CCFLAGS","-no-prec-div")
- if compile_check(compiler,"-override-limits",1):
- make.addvar("CCFLAGS","-override-limits")
- make.addvar("CCFLAGS","-DLAMMPS_MEMALIGN=64")
- make.delvar("CCFLAGS","-DLMP_INTEL_OFFLOAD")
-
- make.delvar("LINKFLAGS","-O*")
- make.addvar("LINKFLAGS","-O2")
- if link_check(linker,"-openmp","",1):
- make.addvar("LINKFLAGS","-openmp")
- if link_check(linker,"-xAVX","",1):
- make.addvar("LINKFLAGS","-xAVX")
- if link_check(linker,"-fpmodel fast=2","",1):
- make.addvar("LINKFLAGS","-fpmodel fast=2")
- if link_check(linker,"-no-prec-div","",1):
- make.addvar("LINKFLAGS","-no-prec-div")
- if link_check(linker,"-override-limits","",1):
- make.addvar("LINKFLAGS","-override-limits")
- make.delvar("LINKFLAGS","-offload")
-
- if link_check(linker,"","-ltbbmalloc",1):
- make.addvar("LIB","-ltbbmalloc")
- if link_check(linker,"","-ltbbmalloc_proxy",1):
- make.addvar("LIB","-ltbbmalloc_proxy")
-
- elif intel.mode == "phi":
- if compile_check(compiler,"-fopenmp",1):
- make.addvar("CCFLAGS","-fopenmp")
- make.addvar("LINKFLAGS","-fopenmp")
- make.addvar("CCFLAGS","-DLAMMPS_MEMALIGN=64")
- if compile_check(compiler,"-restrict",1):
- make.addvar("CCFLAGS","-restrict")
- if compile_check(compiler,"-xHost",1):
- make.addvar("CCFLAGS","-xHost")
- make.addvar("CCFLAGS","-DLMP_INTEL_OFFLOAD")
- if compile_check(compiler,"-fno-alias",1):
- make.addvar("CCFLAGS","-fno-alias")
- if compile_check(compiler,"-ansi-alias",1):
- make.addvar("CCFLAGS","-ansi-alias")
- if compile_check(compiler,"-override-limits",1):
- make.addvar("CCFLAGS","-override-limits")
- if compile_check(compiler,'-offload-option,mic,compiler,' +
- '"-fp-model fast=2 -mGLOB_default_function_attrs=' +
- '\\"gather_scatter_loop_unroll=4\\""',1):
- make.addvar("CCFLAGS",'-offload-option,mic,compiler,' +
- '"-fp-model fast=2 -mGLOB_default_function_attrs=' +
- '\\"gather_scatter_loop_unroll=4\\""')
- if link_check(linker,"-offload","",1):
- make.addvar("LINKFLAGS","-offload")
-
- if final["kokkos"]:
- if kokkos.mode == "omp":
- make.delvar("KOKKOS_DEVICES","*")
- make.delvar("KOKKOS_ARCH","*")
- make.addvar("KOKKOS_DEVICES","OpenMP","lmp")
- if kokkos.archcpu:
- make.addvar("KOKKOS_ARCH",kokkos.archcpu,"lmp")
- elif kokkos.mode == "cuda":
- make.delvar("KOKKOS_DEVICES","*")
- make.delvar("KOKKOS_ARCH","*")
- make.addvar("KOKKOS_DEVICES","Cuda, OpenMP","lmp")
- if kokkos.archgpu:
- if kokkos.archgpu[0] == "3": value = "Kepler" + kokkos.archgpu
- elif kokkos.archgpu[0] == "2": value = "Fermi" + kokkos.archgpu
- else: error("Unrecognized Kokkos archgpu setting")
- if kokkos.archcpu: value += ", %s" % kokkos.archcpu
- make.addvar("KOKKOS_ARCH",value,"lmp")
- elif kokkos.mode == "phi":
- make.delvar("KOKKOS_DEVICES","*")
- make.delvar("KOKKOS_ARCH","*")
- make.addvar("KOKKOS_DEVICES","OpenMP","lmp")
- make.addvar("KOKKOS_ARCH","KNC","lmp")
-
- # add LMP_INC ifdef settings
-
- if settings:
- list = settings.inlist
- for one in list:
- if one == "gzip": make.addvar("LMP_INC","-DLAMMPS_GZIP")
- elif one == "#gzip": make.delvar("LMP_INC","-DLAMMPS_GZIP")
- elif one == "ffmpeg": make.addvar("LMP_INC","-DLAMMPS_FFMPEG")
- elif one == "#ffmpeg": make.delvar("LMP_INC","-DLAMMPS_FFMPEG")
- elif one == "smallbig":
- make.delvar("LMP_INC","-DLAMMPS_BIGBIG")
- make.delvar("LMP_INC","-DLAMMPS_SMALLSMALL")
- elif one == "bigbig":
- make.delvar("LMP_INC","-DLAMMPS_SMALLBIG")
- make.delvar("LMP_INC","-DLAMMPS_SMALLSMALL")
- make.addvar("LMP_INC","-DLAMMPS_BIGBIG")
- elif one == "smallsmall":
- make.delvar("LMP_INC","-DLAMMPS_SMALLBIG")
- make.delvar("LMP_INC","-DLAMMPS_BIGBIG")
- make.addvar("LMP_INC","-DLAMMPS_SMALLSMALL")
- elif one == "exceptions": make.addvar("LMP_INC","-DLAMMPS_EXCEPTIONS")
- elif one == "#exception": make.delvar("LMP_INC","-DLAMMPS_EXCEPTIONS")
-
- # add FFT, JPG, PNG settings
-
- if fft:
- make.delvar("FFT_INC","*")
- make.delvar("FFT_PATH","*")
- make.delvar("FFT_LIB","*")
- if fft.mode == "none": make.addvar("FFT_INC","-DFFT_NONE")
- else:
- make.addvar("FFT_INC","-DFFT_%s" % fft.mode.upper())
- make.addvar("FFT_LIB",fft.lib)
- if fft.dir:
- make.addvar("FFT_INC","-I%s/include" % fft.dir)
- make.addvar("FFT_PATH","-L%s/lib" % fft.dir)
- else:
- if fft.incdir: make.addvar("FFT_INC","-I%s" % fft.incdir)
- if fft.libdir: make.addvar("FFT_PATH","-L%s" % fft.libdir)
-
- if jpg:
- if jpg.on == 0:
- make.delvar("LMP_INC","-DLAMMPS_JPEG")
- make.delvar("JPG_LIB","-ljpeg")
- else:
- make.addvar("LMP_INC","-DLAMMPS_JPEG")
- make.addvar("JPG_LIB","-ljpeg")
- if jpg.dir:
- make.addvar("JPG_INC","-I%s/include" % jpg.dir)
- make.addvar("JPG_PATH","-L%s/lib" % jpg.dir)
- else:
- if jpg.incdir: make.addvar("JPG_INC","-I%s" % jpg.incdir)
- if jpg.libdir: make.addvar("JPG_PATH","-L%s" % jpg.libdir)
-
- if png:
- if png.on == 0:
- make.delvar("LMP_INC","-DLAMMPS_PNG")
- make.delvar("JPG_LIB","-lpng")
- else:
- make.addvar("LMP_INC","-DLAMMPS_PNG")
- make.addvar("JPG_LIB","-lpng")
- if png.dir:
- make.addvar("JPG_INC","-I%s/include" % png.dir)
- make.addvar("JPG_PATH","-L%s/lib" % png.dir)
- else:
- if png.incdir: make.addvar("JPG_INC","-I%s" % png.incdir)
- if png.libdir: make.addvar("JPG_PATH","-L%s" % png.libdir)
-
- # finally after all other settings, add explicit flags
-
- if flags:
- for var,action,flist in flags.flags:
- values = make.getvar(var)
- if values == None:
- error("Flags for a non-existent Makefile.auto variable")
- for flag in flist:
- flag = "-" + flag
- if action == "add": make.addvar(var,flag)
- elif action == "del": make.delvar(var,flag)
-
- # set self.stubs if Makefile.auto uses STUBS lib in MPI settings
-
- if make.getvar("MPI_LIB") and "-lmpi_stubs" in make.getvar("MPI_LIB"):
- self.stubs = 1
- else: self.stubs = 0
-
- # write out Makefile.auto
- # unless caller = "exe" and "file" action already invoked
-
- if caller == "file" or "file" not in self.alist:
- # make certain that 'MAKE/MINE' folder exists.
- subprocess.check_output("mkdir -p %s/MAKE/MINE" % dir.src,
- stderr=subprocess.STDOUT,shell=True)
- make.write("%s/MAKE/MINE/Makefile.auto" % dir.src,1)
- print("Created src/MAKE/MINE/Makefile.auto")
-
- # test full compile and link
- # unless caller = "file" and "exe" action will be invoked later
-
- if caller == "file" and "exe" in self.alist: return
- compiler = precompiler + ' '.join(make.getvar("CC"))
- ccflags = ' '.join(make.getvar("CCFLAGS"))
- linker = precompiler + ' '.join(make.getvar("LINK"))
- linkflags = ' '.join(make.getvar("LINKFLAGS"))
- libs = ' '.join(make.getvar("LIB"))
- if not compile_check(compiler,ccflags,1):
- error("Test of compilation failed")
- if not link_check(linker,linkflags,libs,1): error("Test of link failed")
-
- # invoke "make clean-auto" to force clean before build
-
- def clean(self):
- txt = "cd %s; make clean-auto" % dir.src
- subprocess.check_output(txt,stderr=subprocess.STDOUT,shell=True)
- print("Performed make clean-auto")
-
- # build LAMMPS using Makefile.auto and -j setting
- # invoke self.file() first, to test makefile compile/link
- # delete existing lmp_auto, so can detect if build fails
- # build STUBS lib (if unbuilt) if Makefile.auto MPI settings need it
-
- def exe(self):
- self.file("exe")
- subprocess.check_output("cd %s; rm -f lmp_auto" % dir.src,stderr=subprocess.STDOUT,shell=True)
- if self.stubs and not os.path.isfile("%s/STUBS/libmpi_stubs.a" % dir.src):
- print("building serial STUBS library ...")
- tmp = "cd %s/STUBS; make clean; make" % dir.src
- txt = subprocess.check_output(tmp,stderr=subprocess.STDOUT,shell=True).decode()
- if not os.path.isfile("%s/STUBS/libmpi_stubs.a" % dir.src):
- print(txt)
- error('Unsuccessful "make stubs"')
- print("Created src/STUBS/libmpi_stubs.a")
-
- # special hack for shannon GPU cluster
- # must use "srun make" if on it and building w/ GPU package, else just make
- # this is b/c Cuda libs are not all available on host
-
- make = "make"
- if "shannon" == platform.node() and packages.final["gpu"]:
- make = "srun make"
-
- if jmake: tmp = "cd %s; %s -j %d auto" % (dir.src,make,jmake.n)
- else: tmp = "cd %s; %s auto" % (dir.src,make)
-
- # if verbose, print output as build proceeds, else only print if fails
-
- if verbose: subprocess.call(tmp,shell=True)
- else:
- print(tmp)
- try: subprocess.check_output(tmp,stderr=subprocess.STDOUT,shell=True)
- except subprocess.CalledProcessError as e: print(e.output)
-
- if not os.path.isfile("%s/lmp_auto" % dir.src):
- error('Unsuccessful "make auto"')
- elif not output: print("Created src/lmp_auto")
-
-# dir switch
-
-class Dir(object):
- def __init__(self,list):
- self.inlist = copy.copy(list)
-
- def help(self):
- return """
--d dir
- dir = LAMMPS home dir
- if -d not specified, working dir must be lammps/src
-"""
-
- def check(self):
- if self.inlist != None and len(self.inlist) != 1:
- error("-d args are invalid")
-
- # if inlist = None, check that cwd = lammps/src
- # store cwd and lammps dir
- # derive src,make,lib dirs from lammps dir
- # check that they all exist
-
- def setup(self):
- self.cwd = os.getcwd()
- if self.inlist == None: self.lammps = ".."
- else: self.lammps = self.inlist[0]
- self.lammps = os.path.realpath(self.lammps)
- self.src = self.lammps + "/src"
- self.make = self.lammps + "/src/MAKE"
- self.lib = self.lammps + "/lib"
- if not os.path.isdir(self.lammps): error("LAMMPS home dir is invalid")
- if not os.path.isdir(self.src): error("LAMMPS src dir is invalid")
- if not os.path.isdir(self.lib): error("LAMMPS lib dir is invalid")
-
-# help switch
-
-class Help(object):
- def __init__(self,list): pass
-
- def help(self):
- return """
-Syntax: Make.py switch args ...
- switches can be listed in any order
- help switch:
- -h prints help and syntax for all other specified switches
- switch for actions:
- -a lib-all, lib-dir, clean, file, exe or machine
- list one or more actions, in any order
- machine is a Makefile.machine suffix
- one-letter switches:
- -d (dir), -j (jmake), -m (makefile), -o (output), -p (packages),
- -r (redo), -s (settings), -v (verbose), -z (makefile output)
- switches for libs:
- -atc, -awpmd, -colvars, -cuda, -gpu, -h5md,
- -meam, -poems, -python, -qmmm, -reax, -voronoi
- switches for build and makefile options:
- -intel, -kokkos, -cc, -flags, -mpi, -fft, -jpg, -png
-"""
-
-# jmake switch
-
-class Jmake(object):
- def __init__(self,list):
- self.inlist = copy.copy(list)
-
- def help(self):
- return """
--j N
- use N procs for performing parallel make commands
- used when building a lib or LAMMPS itself
- if -j not specified, serial make commands run on single core
-"""
-
- def check(self):
- if len(self.inlist) != 1: error("-j args are invalid")
- if not self.inlist[0].isdigit(): error("-j args are invalid")
- n = int(self.inlist[0])
- if n <= 0: error("-j args are invalid")
- self.n = n
-
-# makefile switch
-
-class Makefile(object):
- def __init__(self,list):
- self.inlist = copy.copy(list)
-
- def help(self):
- return """
--m machine
- use Makefile.machine under src/MAKE as starting point to create Makefile.auto
- if machine = "none", file action will create Makefile.auto from scratch
- must use -cc and -mpi switches to specify compiler and MPI
- if -m not specified, file/exe actions alter existing Makefile.auto
-"""
-
- def check(self):
- if len(self.inlist) != 1: error("-m args are invalid")
- self.machine = self.inlist[0]
-
-# output switch
-
-class Output(object):
- def __init__(self,list):
- self.inlist = copy.copy(list)
-
- def help(self):
- return """
--o machine
- copy final src/lmp_auto to lmp_machine in working dir
- if -o not specified, exe action only produces src/lmp_auto
-"""
-
- def check(self):
- if len(self.inlist) != 1: error("-o args are invalid")
- self.machine = self.inlist[0]
-
-# packages switch
-
-class Packages(object):
- def __init__(self,list):
- self.inlist = copy.copy(list)
-
- def help(self):
- return """
--p = package1 package2 ...
- list of packages to install or uninstall in order specified
- operates on set of packages currently installed
- valid package names:
- any LAMMPS standard or user package (type "make package" to see list)
- prefix by yes/no to install/uninstall (see abbrevs)
- yes-molecule, yes-user-atc, no-molecule, no-user-atc
- can use LAMMPS categories (type "make package" to see list)
- all = all standard and user packages (also none = no-all)
- std (or standard) = all standard packages
- user = all user packages
- lib = all standard and user packages with auxiliary libs
- can abbreviate package names and yes/no
- omp = user-omp = yes-user-omp
- ^omp = ^user-omp = no-user-omp
- user = yes-user, ^user = no-user
- all = yes-all, ^all = none = no-all
- when action performed, list is processed in order,
- as if typed "make yes/no" for each
- if "orig" or "original" is last package in list,
- set of installed packages will be restored to original (current) list
- after "build" action is performed
- if -p not specified, currently installed packages are not changed
-"""
-
- def check(self):
- if self.inlist != None and not self.inlist: error("-p args are invalid")
-
- def setup(self):
-
- # extract package lists from src/Makefile
- # remove names from lib that there are not Make.py lib-classes for
- # most don't actually have libs, so nothing to control from Make.py
-
- make = MakeReader("%s/Makefile" % dir.src)
- std = make.getvar("PACKAGE")
- user = make.getvar("PACKUSER")
- lib = make.getvar("PACKLIB")
- lib.remove("kim")
- lib.remove("kokkos")
- lib.remove("user-molfile")
- lib.remove("python")
- lib.remove("user-quip")
- all = std + user
-
- # plist = command line args expanded to yes-package or no-package
-
- plist = []
- if self.inlist:
- for one in self.inlist:
- if one in std:
- plist.append("yes-%s" % one)
- elif one in user:
- plist.append("yes-%s" % one)
- elif "user-"+one in user:
- plist.append("yes-user-%s" % one)
- elif one == "std" or one == "standard" or one == "user" or \
- one == "lib" or one == "all": plist.append("yes-%s" % one)
- elif one.startswith("yes-"):
- if one[4:] in std: plist.append("yes-%s" % one[4:])
- elif one[4:] in user: plist.append("yes-%s" % one[4:])
- elif "user-"+one[4:] in user: plist.append("yes-user-%s" % one[4:])
- elif one == "yes-std" or one == "yes-standard" or \
- one == "yes-user" or one == "yes-lib" or one == "yes-all":
- plist.append("yes-%s" % one[4:])
- else: error("Invalid package name %s" % one)
- elif one.startswith("no-"):
- if one[3:] in std: plist.append("no-%s" % one[3:])
- elif one[3:] in user: plist.append("no-%s" % one[3:])
- elif "user-"+one[3:] in user: plist.append("no-user-%s" % one[3:])
- elif one == "no-std" or one == "no-standard" or one == "no-user" or \
- one == "no-lib" or one == "no-all":
- plist.append("no-%s" % one[3:])
- else: error("Invalid package name %s" % one)
- elif one.startswith('^'):
- if one[1:] in std: plist.append("no-%s" % one[1:])
- elif one[1:] in user: plist.append("no-%s" % one[1:])
- elif "user-"+one[1:] in user: plist.append("no-user-%s" % one[1:])
- elif one == "^std" or one == "^standard" or one == "^user" or \
- one == "^lib" or one == "^all": plist.append("no-%s" % one[1:])
- else: error("Invalid package name %s" % one)
- elif one == "none": plist.append("no-all")
- elif one == "orig": plist.append(one)
- else: error("Invalid package name %s" % one)
- if "orig" in plist and plist.index("orig") != len(plist)-1:
- error('-p orig arg must be last')
- if plist.count("orig") > 1: error('-p orig arg must be last')
-
- # original = dict of all packages
- # key = package name, value = 1 if currently installed, else 0
-
- original = {}
- tmp = "cd %s; make ps" % dir.src
- output = subprocess.check_output(tmp,stderr=subprocess.STDOUT,shell=True).decode().split('\n')
- pattern = "Installed\s+(\w+): package (\S+)"
- for line in output:
- m = re.search(pattern,line)
- if not m: continue
- pkg = m.group(2).lower()
- if pkg not in all: error('Package list does not match "make ps" results')
- if m.group(1) == "NO": original[pkg] = 0
- elif m.group(1) == "YES": original[pkg] = 1
-
- # final = dict of all packages after plist applied to original
- # key = package name, value = 1 if installed, else 0
-
- final = copy.deepcopy(original)
- for i,one in enumerate(plist):
- if "yes" in one:
- pkg = one[4:]
- yes = 1
- else:
- pkg = one[3:]
- yes = 0
- if pkg in all:
- final[pkg] = yes
- elif pkg == "std" or pkg == "standard":
- for pkg in std: final[pkg] = yes
- elif pkg == "user":
- for pkg in user: final[pkg] = yes
- elif pkg == "lib":
- for pkg in lib: final[pkg] = yes
- elif pkg == "all":
- for pkg in all: final[pkg] = yes
-
- self.std = std
- self.user = user
- self.lib = lib
- self.all = all
- self.plist = plist
- self.original = original
- self.final = final
-
- # install packages in plist
-
- def install(self):
- if self.plist: print("Installing packages ...")
- for one in self.plist:
- if one == "orig": continue
- subprocess.check_output("cd %s; make %s" % (dir.src,one),
- stderr=subprocess.STDOUT,shell=True)
- if self.plist and verbose:
- txt = subprocess.check_output("cd %s; make ps" % dir.src,
- stderr=subprocess.STDOUT,
- shell=True).decode()
- print("Package status after installation:")
- print(txt)
-
- # restore packages to original list if requested
- # order of re-install should not matter matter b/c of Depend.sh
-
- def uninstall(self):
- if not self.plist or self.plist[-1] != "orig": return
- print("Restoring packages to original state ...")
- subprocess.check_output("cd %s; make no-all" % dir.src,
- stderr=subprocess.STDOUT,shell=True)
- for one in self.all:
- if self.original[one]:
- subprocess.check_output("cd %s; make yes-%s" % (dir.src,one),
- stderr=subprocess.STDOUT,shell=True)
- if verbose:
- txt = subprocess.check_output("cd %s; make ps" % dir.src,
- stderr=subprocess.STDOUT,
- shell=True).decode()
- print("Restored package status:")
- print(txt)
-
-# redo switch
-
-class Redo(object):
- def __init__(self,list):
- self.inlist = copy.copy(list)
-
- def help(self):
- return """
--r file label1 label2 ...
- all args are optional
- invoke Make.py commands from a file
- other specified switches are merged with file commands (see below)
- redo file format:
- blank lines and lines starting with "#" are skipped
- other lines are treated as commands
- each command is a list of Make.py args, as if typed at command-line
- commands can have leading label, followed by ":"
- commands cannot contain a "-r" switch
- if no args, execute previous command, which is stored in src/Make.py.last
- if one arg, execute all commands from specified file
- unlabeled or labeled commands are all executed
- if multiple args, execute only matching labeled commands from file
- if other switches are specified,
- if file command does not have the switch, it is added
- if file command has the switch, the specified switch replaces it
- except if -a (action) switch is both specified and in the file command,
- two sets of actions are merged and duplicates removed
- if both switches have "exe or machine" action,
- the specified exe/machine overrides the file exe/machine
-"""
-
- def check(self):
- if len(self.inlist) == 0:
- self.dir = 1
- self.file = "Make.py.last"
- self.labels = []
- else:
- self.dir = 0
- self.file = self.inlist[0]
- self.labels = self.inlist[1:]
-
- # read redo file
- # self.commands = list of commands to execute
-
- def setup(self):
- file = self.file
- if not os.path.isfile(file): error("Redo file %s does not exist" % file)
- lines = open(file,'r').readlines()
-
- cmdlines = []
- for line in lines:
- line = line.strip()
- if not line or line[0] == '#' : continue
- cmdlines.append(line)
-
- # if no labels, add all file commands to command list
- # if labels, make a dict with key = label, value = command
- # and discard unlabeled commands
-
- dict = {}
- commands = []
- for line in cmdlines:
- words = line.split()
- if "-r" in words: error("Redo command cannot contain -r switch")
- if words[0][-1] == ':': label = words[0][:-1]
- else: label = None
- if not self.labels:
- if label: subprocess.append(' '.join(words[1:]))
- else: subprocess.append(line)
- else:
- if not label: continue
- dict[label] = ' '.join(words[1:])
-
- # extract labeled commands from dict and add to command list
-
- for label in self.labels:
- if label not in dict: error("Redo label not in redo file")
- subprocess.append(dict[label])
-
- self.commands = commands
-
-# settings switch
-
-class Settings(object):
- def __init__(self,list):
- self.inlist = copy.copy(list)
-
- def help(self):
- return """
--s set1 set2 ...
- possible settings = gzip #gzip ffmpeg #ffmpeg
- smallbig bigbig smallsmall exceptions #exceptions
- alter LAMMPS ifdef settings in Makefile.auto
- only happens if new Makefile.auto is created by use of "file" action
- gzip and #gzip turn on/off LAMMPS_GZIP setting
- ffmpeg and #ffmpeg turn on/off LAMMPS_FFMPEG setting
- smallbig, bigbig, smallsmall turn on LAMMPS_SMALLBIG, etc
- and turn off other two
- exceptions and #exceptions turn on/off LAMMPS_EXCEPTIONS setting
-"""
-
- def check(self):
- if not self.inlist: error("-s args are invalid")
- for one in self.inlist:
- if one not in setargs: error("-s args are invalid")
-
-# verbose switch
-
-class Verbose(object):
- def __init__(self,list):
- self.inlist = copy.copy(list)
-
- def help(self):
- return """
--v (no arguments)
- produce verbose output as Make.py executes
- if -v not specified, minimal output is produced
-"""
-
- def check(self):
- if len(self.inlist): error("-v args are invalid")
-
-# zoutput switch for making copy of final Makefile.auto
-
-class Zoutput(object):
- def __init__(self,list):
- self.inlist = copy.copy(list)
-
- def help(self):
- return """
--z machine
- copy created/used src/MAKE/MINE/Makefile.auto to Makefile.machine in same dir
- copy created/used lib/*/Makefile.auto and lib/*/Makefile.lammps to
- Makefile_lib.machine and Makefile_lib_lammps.machine in same dir
- this can be used to preserve the machine Makefile and lib Makefiles
-"""
-
- def check(self):
- if len(self.inlist) != 1: error("-z args are invalid")
- self.machine = self.inlist[0]
-
-# ----------------------------------------------------------------
-# lib classes, one per LAMMPS auxiliary lib
-# ----------------------------------------------------------------
-
-# ATC lib
-
-class ATC(object):
- def __init__(self,list):
- self.inlist = copy.copy(list)
- self.make = "g++"
- self.lammpsflag = 0
-
- def help(self):
- return """
--atc make=suffix lammps=suffix2
- all args are optional and can be in any order
- make = use Makefile.suffix (def = g++)
- lammps = use Makefile.lammps.suffix2 (def = EXTRAMAKE in makefile)
-"""
-
- def check(self):
- if self.inlist != None and len(self.inlist) == 0:
- error("-atc args are invalid")
- for one in self.inlist:
- words = one.split('=')
- if len(words) != 2: error("-atc args are invalid")
- if words[0] == "make": self.make = words[1]
- elif words[0] == "lammps":
- self.lammps = words[1]
- self.lammpsflag = 1
- else: error("-atc args are invalid")
-
- def build(self):
- libdir = dir.lib + "/atc"
- make = MakeReader("%s/Makefile.%s" % (libdir,self.make))
- if self.lammpsflag:
- make.setvar("EXTRAMAKE","Makefile.lammps.%s" % self.lammps)
- make.write("%s/Makefile.auto" % libdir)
-
- subprocess.check_output("cd %s; make -f Makefile.auto clean" %
- libdir,stderr=subprocess.STDOUT,shell=True)
- if jmake: txt = "cd %s; make -j %d -f Makefile.auto" % (libdir,jmake.n)
- else: txt = "cd %s; make -f Makefile.auto" % libdir
-
- # if verbose, print output as build proceeds, else only print if fails
-
- if verbose: subprocess.call(txt,shell=True)
- else:
- try: subprocess.check_output(txt,stderr=subprocess.STDOUT,shell=True)
- except subprocess.CalledProcessError as e: print(e.output)
-
- if not os.path.isfile("%s/libatc.a" % libdir) or \
- not os.path.isfile("%s/Makefile.lammps" % libdir):
- error("Unsuccessful build of lib/atc library")
- else: print("Created lib/atc library")
-
-# AWPMD lib
-
-class AWPMD(object):
- def __init__(self,list):
- self.inlist = copy.copy(list)
- self.make = "mpicc"
- self.lammpsflag = 0
-
- def help(self):
- return """
--awpmd make=suffix lammps=suffix2
- all args are optional and can be in any order
- make = use Makefile.suffix (def = mpicc)
- lammps = use Makefile.lammps.suffix2 (def = EXTRAMAKE in makefile)
-"""
-
- def check(self):
- if self.inlist != None and len(self.inlist) == 0:
- error("-awpmd args are invalid")
- for one in self.inlist:
- words = one.split('=')
- if len(words) != 2: error("-awpmd args are invalid")
- if words[0] == "make": self.make = words[1]
- elif words[0] == "lammps":
- self.lammps = words[1]
- self.lammpsflag = 1
- else: error("-awpmd args are invalid")
-
- def build(self):
- libdir = dir.lib + "/awpmd"
- make = MakeReader("%s/Makefile.%s" % (libdir,self.make))
- if self.lammpsflag:
- make.setvar("EXTRAMAKE","Makefile.lammps.%s" % self.lammps)
- make.write("%s/Makefile.auto" % libdir)
-
- subprocess.check_output("cd %s; make -f Makefile.auto clean" %
- libdir,stderr=subprocess.STDOUT,shell=True)
- if jmake: txt = "cd %s; make -j %d -f Makefile.auto" % (libdir,jmake.n)
- else: txt = "cd %s; make -f Makefile.auto" % libdir
-
- # if verbose, print output as build proceeds, else only print if fails
-
- if verbose: subprocess.call(txt,shell=True)
- else:
- try: subprocess.check_output(txt,stderr=subprocess.STDOUT,shell=True)
- except subprocess.CalledProcessError as e: print(e.output)
-
- if not os.path.isfile("%s/libawpmd.a" % libdir) or \
- not os.path.isfile("%s/Makefile.lammps" % libdir):
- error("Unsuccessful build of lib/awpmd library")
- else: print("Created lib/awpmd library")
-
-# COLVARS lib
-
-class COLVARS(object):
- def __init__(self,list):
- self.inlist = copy.copy(list)
- self.make = "g++"
- self.lammpsflag = 0
-
- def help(self):
- return """
--colvars make=suffix lammps=suffix2
- all args are optional and can be in any order
- make = use Makefile.suffix (def = g++)
- lammps = use Makefile.lammps.suffix2 (def = EXTRAMAKE in makefile)
-"""
-
- def check(self):
- if self.inlist != None and len(self.inlist) == 0:
- error("-colvars args are invalid")
- for one in self.inlist:
- words = one.split('=')
- if len(words) != 2: error("-colvars args are invalid")
- if words[0] == "make": self.make = words[1]
- elif words[0] == "lammps":
- self.lammps = words[1]
- self.lammpsflag = 1
- else: error("-colvars args are invalid")
-
- def build(self):
- libdir = dir.lib + "/colvars"
- make = MakeReader("%s/Makefile.%s" % (libdir,self.make))
- if self.lammpsflag:
- make.setvar("EXTRAMAKE","Makefile.lammps.%s" % self.lammps)
- make.write("%s/Makefile.auto" % libdir)
-
- subprocess.check_output("cd %s; make -f Makefile.auto clean" %
- libdir,stderr=subprocess.STDOUT,shell=True)
- if jmake: txt = "cd %s; make -j %d -f Makefile.auto" % (libdir,jmake.n)
- else: txt = "cd %s; make -f Makefile.auto" % libdir
-
- # if verbose, print output as build proceeds, else only print if fails
-
- if verbose: subprocess.call(txt,shell=True)
- else:
- try: subprocess.check_output(txt,stderr=subprocess.STDOUT,shell=True)
- except subprocess.CalledProcessError as e: print(e.output)
-
- if not os.path.isfile("%s/libcolvars.a" % libdir) or \
- not os.path.isfile("%s/Makefile.lammps" % libdir):
- error("Unsuccessful build of lib/colvars library")
- else: print("Created lib/colvars library")
-
-# CUDA lib
-
-class CUDA(object):
- def __init__(self,list):
- self.inlist = copy.copy(list)
- self.mode = "double"
- self.arch = "35"
-
- def help(self):
- return """
--cuda mode=double arch=35
- all args are optional and can be in any order
- mode = double or mixed or single (def = double)
- arch = M (def = 35)
- M = 31,35,37,etc for Kepler
- M = 20 for CC2.0 (GF100/110, e.g. C2050,GTX580,GTX470)
- M = 21 for CC2.1 (GF104/114, e.g. GTX560, GTX460, GTX450)
- M = 13 for CC1.3 (GF200, e.g. C1060, GTX285)
-"""
-
- def check(self):
- if self.inlist != None and len(self.inlist) == 0:
- error("-cuda args are invalid")
- for one in self.inlist:
- words = one.split('=')
- if len(words) != 2: error("-cuda args are invalid")
- if words[0] == "mode": self.mode = words[1]
- elif words[0] == "arch": self.arch = words[1]
- else: error("-cuda args are invalid")
- if self.mode != "double" and self.mode != "mixed" and \
- self.mode != "single":
- error("-cuda args are invalid")
- if not self.arch.isdigit(): error("-cuda args are invalid")
-
- def build(self):
- libdir = dir.lib + "/cuda"
- subprocess.check_output("cd %s; make clean" % libdir,
- stderr=subprocess.STDOUT,shell=True)
- if self.mode == "double": n = 2
- elif self.mode == "mixed": n = 3
- elif self.mode == "single": n = 1
- if jmake: txt = "cd %s; make -j %d precision=%d arch=%s" % \
- (libdir,jmake.n,n,self.arch)
- else: txt = "cd %s; make precision=%d arch=%s" % \
- (libdir,n,self.arch)
-
- # if verbose, print output as build proceeds, else only print if fails
-
- if verbose: subprocess.call(txt,shell=True)
- else:
- try: subprocess.check_output(txt,stderr=subprocess.STDOUT,shell=True)
- except subprocess.CalledProcessError as e: print(e.output)
-
- if not os.path.isfile("%s/liblammpscuda.a" % libdir) or \
- not os.path.isfile("%s/Makefile.lammps" % libdir):
- error("Unsuccessful build of lib/cuda library")
- else: print("Created lib/cuda library")
-
-# GPU lib
-
-class GPU(object):
- def __init__(self,list):
- self.inlist = copy.copy(list)
- self.make = "linux.double"
- self.lammpsflag = self.modeflag = self.archflag = self.homeflag = 0
-
- def help(self):
- return """
--gpu make=suffix lammps=suffix2 mode=double arch=N home=path
- all args are optional and can be in any order
- make = use Makefile.suffix (def = linux.double)
- lammps = use Makefile.lammps.suffix2 (def = EXTRAMAKE in makefile)
- mode = double or mixed or single (def = CUDA_PREC in makefile)
- arch = 3x (x = digit for Kepler) or 2x (x = digit for Fermi)
- (def = CUDA_ARCH in makefile)
- home = path to Cuda, e.g. /usr/local/cuda (def = CUDA_HOME in makefile)
-"""
-
- def check(self):
- if self.inlist != None and len(self.inlist) == 0:
- error("-gpu args are invalid")
- for one in self.inlist:
- words = one.split('=')
- if len(words) != 2: error("-gpu args are invalid")
- if words[0] == "make": self.make = words[1]
- elif words[0] == "lammps":
- self.lammps = words[1]
- self.lammpsflag = 1
- elif words[0] == "mode":
- self.mode = words[1]
- self.modeflag = 1
- elif words[0] == "arch":
- self.arch = words[1]
- self.archflag = 1
- elif words[0] == "home":
- self.home = words[1]
- self.homeflag = 1
- else: error("-gpu args are invalid")
- if self.modeflag and (self.mode != "double" and
- self.mode != "mixed" and
- self.mode != "single"):
- error("-gpu args are invalid")
- if self.archflag and not self.arch.isdigit():
- error("-gpu args are invalid")
-
- def build(self):
- global gpubuildflag
- gpubuildflag = 1
- libdir = dir.lib + "/gpu"
- make = MakeReader("%s/Makefile.%s" % (libdir,self.make))
- if self.modeflag:
- if self.mode == "double":
- make.setvar("CUDA_PRECISION","-D_DOUBLE_DOUBLE")
- elif self.mode == "mixed":
- make.setvar("CUDA_PRECISION","-D_SINGLE_DOUBLE")
- elif self.mode == "single":
- make.setvar("CUDA_PRECISION","-D_SINGLE_SINGLE")
- if self.archflag:
- make.setvar("CUDA_ARCH","-arch=sm_%s" % self.arch)
- if self.homeflag:
- make.setvar("CUDA_HOME",self.home)
- if self.lammpsflag:
- make.setvar("EXTRAMAKE","Makefile.lammps.%s" % self.lammps)
- make.write("%s/Makefile.auto" % libdir)
-
- # special hack for shannon GPU cluster
- # must use "srun make" if on it, else just make
- # this is b/c Cuda libs are not all available on host
-
- make = "make"
- if "shannon" == platform.node(): make = "srun make"
-
- subprocess.check_output("cd %s; %s -f Makefile.auto clean" %
- (libdir,make),stderr=subprocess.STDOUT,shell=True)
- if jmake: txt = "cd %s; %s -j %d -f Makefile.auto" % (libdir,make,jmake.n)
- else: txt = "cd %s; %s -f Makefile.auto" % (libdir,make)
-
- # if verbose, print output as build proceeds, else only print if fails
-
- if verbose: subprocess.call(txt,shell=True)
- else:
- try: subprocess.check_output(txt,stderr=subprocess.STDOUT,shell=True)
- except subprocess.CalledProcessError as e: print(e.output)
-
- if not os.path.isfile("%s/libgpu.a" % libdir) or \
- not os.path.isfile("%s/Makefile.lammps" % libdir):
- error("Unsuccessful build of lib/gpu library")
- else: print("Created lib/gpu library")
-
-# H5MD lib
-
-class H5MD(object):
- def __init__(self,list):
- self.inlist = copy.copy(list)
- self.make = "h5cc"
- self.lammpsflag = 0
-
- def help(self):
- return """
--h5md make=suffix lammps=suffix2
- all args are optional and can be in any order
- make = use Makefile.suffix (def = h5cc)
- lammps = use Makefile.lammps.suffix2 (def = EXTRAMAKE in makefile)
-"""
-
- def check(self):
- if self.inlist != None and len(self.inlist) == 0:
- error("-h5md args are invalid")
- for one in self.inlist:
- words = one.split('=')
- if len(words) != 2: error("-h5md args are invalid")
- if words[0] == "make": self.make = words[1]
- elif words[0] == "lammps":
- self.lammps = words[1]
- self.lammpsflag = 1
- else: error("-h5md args are invalid")
-
- def build(self):
- libdir = dir.lib + "/h5md"
- make = MakeReader("%s/Makefile.%s" % (libdir,self.make))
- if self.lammpsflag:
- make.setvar("EXTRAMAKE","Makefile.lammps.%s" % self.lammps)
- make.write("%s/Makefile.auto" % libdir)
-
- subprocess.check_output("cd %s; make clean" % libdir,
- stderr=subprocess.STDOUT,shell=True)
- txt = "cd %s; make" % libdir
-
- # if verbose, print output as build proceeds, else only print if fails
-
- if verbose: subprocess.call(txt,shell=True)
- else:
- try: subprocess.check_output(txt,stderr=subprocess.STDOUT,shell=True)
- except subprocess.CalledProcessError as e: print(e.output)
-
- if not os.path.isfile("%s/libch5md.a" % libdir) or \
- not os.path.isfile("%s/Makefile.lammps" % libdir):
- error("Unsuccessful build of lib/h5md library")
- else: print("Created lib/h5md library")
-
-# MEAM lib
-
-class MEAM(object):
- def __init__(self,list):
- self.inlist = copy.copy(list)
- self.make = "gfortran"
- self.lammpsflag = 0
-
- def help(self):
- return """
--meam make=suffix lammps=suffix2
- all args are optional and can be in any order
- make = use Makefile.suffix (def = gfortran)
- lammps = use Makefile.lammps.suffix2 (def = EXTRAMAKE in makefile)
-"""
-
- def check(self):
- if self.inlist != None and len(self.inlist) == 0:
- error("-meam args are invalid")
- for one in self.inlist:
- words = one.split('=')
- if len(words) != 2: error("-meam args are invalid")
- if words[0] == "make": self.make = words[1]
- elif words[0] == "lammps":
- self.lammps = words[1]
- self.lammpsflag = 1
- else: error("-meam args are invalid")
-
- def build(self):
- libdir = dir.lib + "/meam"
- make = MakeReader("%s/Makefile.%s" % (libdir,self.make))
- if self.lammpsflag:
- make.setvar("EXTRAMAKE","Makefile.lammps.%s" % self.lammps)
- make.write("%s/Makefile.auto" % libdir)
-
- subprocess.check_output("cd %s; make -f Makefile.auto clean" %
- libdir,stderr=subprocess.STDOUT,shell=True)
- # do not use -j for MEAM build, parallel build does not work
- txt = "cd %s; make -f Makefile.auto" % libdir
-
- # if verbose, print output as build proceeds, else only print if fails
-
- if verbose: subprocess.call(txt,shell=True)
- else:
- try: subprocess.check_output(txt,stderr=subprocess.STDOUT,shell=True)
- except subprocess.CalledProcessError as e: print(e.output)
-
- if not os.path.isfile("%s/libmeam.a" % libdir) or \
- not os.path.isfile("%s/Makefile.lammps" % libdir):
- error("Unsuccessful build of lib/meam library")
- else: print("Created lib/meam library")
-
-# POEMS lib
-
-class POEMS(object):
- def __init__(self,list):
- self.inlist = copy.copy(list)
- self.make = "g++"
- self.lammpsflag = 0
-
- def help(self):
- return """
--poems make=suffix lammps=suffix2
- all args are optional and can be in any order
- make = use Makefile.suffix (def = g++)
- lammps = use Makefile.lammps.suffix2 (def = EXTRAMAKE in makefile)
-"""
-
- def check(self):
- if self.inlist != None and len(self.inlist) == 0:
- error("-poems args are invalid")
- for one in self.inlist:
- words = one.split('=')
- if len(words) != 2: error("-poems args are invalid")
- if words[0] == "make": self.make = words[1]
- elif words[0] == "lammps":
- self.lammps = words[1]
- self.lammpsflag = 1
- else: error("-poems args are invalid")
-
- def build(self):
- libdir = dir.lib + "/poems"
- make = MakeReader("%s/Makefile.%s" % (libdir,self.make))
- if self.lammpsflag:
- make.setvar("EXTRAMAKE","Makefile.lammps.%s" % self.lammps)
- make.write("%s/Makefile.auto" % libdir)
-
- subprocess.check_output("cd %s; make -f Makefile.auto clean" % libdir,
- stderr=subprocess.STDOUT,shell=True)
- if jmake: txt = "cd %s; make -j %d -f Makefile.auto" % (libdir,jmake.n)
- else: txt = "cd %s; make -f Makefile.auto" % libdir
-
- # if verbose, print output as build proceeds, else only print if fails
-
- if verbose: subprocess.call(txt,shell=True)
- else:
- try: subprocess.check_output(txt,stderr=subprocess.STDOUT,shell=True)
- except subprocess.CalledProcessError as e: print(e.output)
-
- if not os.path.isfile("%s/libpoems.a" % libdir) or \
- not os.path.isfile("%s/Makefile.lammps" % libdir):
- error("Unsuccessful build of lib/poems library")
- else: print("Created lib/poems library")
-
-# PYTHON lib
-
-class PYTHON(object):
- def __init__(self,list):
- self.inlist = copy.copy(list)
- self.make = "g++"
- self.lammpsflag = 0
-
- def help(self):
- return """
--python lammps=suffix
- arg is optional, use Makefile.lammps if not specified
- lammps = use Makefile.lammps.suffix
-"""
-
- def check(self):
- if self.inlist != None and len(self.inlist) == 0:
- error("-python args are invalid")
- for one in self.inlist:
- words = one.split('=')
- if len(words) != 2: error("-python args are invalid")
- if words[0] == "lammps":
- self.lammps = words[1]
- self.lammpsflag = 1
- else: error("-python args are invalid")
-
- def build(self):
- libdir = dir.lib + "/python"
- if self.lammpsflag:
- subprocess.check_output("cd %s; cp Makefile.lammps.%s Makefile.lammps" %
- (libdir,self.lammps))
- if not os.path.isfile("%s/Makefile.lammps.%s" % (libdir,self.lammps)):
- error("Unsuccessful creation of lib/python/Makefile.lammps.%s file" %
- self.lammps)
- else: print("Created lib/python/Makefile.lammps file")
-
-# QMMM lib
-
-class QMMM(object):
- def __init__(self,list):
- self.inlist = copy.copy(list)
- self.make = "gfortran"
- self.lammpsflag = 0
-
- def help(self):
- return """
--qmmm make=suffix lammps=suffix2
- all args are optional and can be in any order
- make = use Makefile.suffix (def = gfortran)
- lammps = use Makefile.lammps.suffix2 (def = EXTRAMAKE in makefile)
-"""
-
- def check(self):
- if self.inlist != None and len(self.inlist) == 0:
- error("-qmmm args are invalid")
- for one in self.inlist:
- words = one.split('=')
- if len(words) != 2: error("-qmmm args are invalid")
- if words[0] == "make": self.make = words[1]
- elif words[0] == "lammps":
- self.lammps = words[1]
- self.lammpsflag = 1
- else: error("-qmmm args are invalid")
-
- def build(self):
- libdir = dir.lib + "/qmmm"
- make = MakeReader("%s/Makefile.%s" % (libdir,self.make))
- if self.lammpsflag:
- make.setvar("EXTRAMAKE","Makefile.lammps.%s" % self.lammps)
- make.write("%s/Makefile.auto" % libdir)
-
- subprocess.check_output("cd %s; make -f Makefile.auto clean" %
- libdir,stderr=subprocess.STDOUT,shell=True)
- if jmake: txt = "cd %s; make -j %d -f Makefile.auto" % (libdir,jmake.n)
- else: txt = "cd %s; make -f Makefile.auto" % libdir
-
- # if verbose, print output as build proceeds, else only print if fails
-
- if verbose: subprocess.call(txt,shell=True)
- else:
- try: subprocess.check_output(txt,stderr=subprocess.STDOUT,shell=True)
- except subprocess.CalledProcessError as e: print(e.output)
-
- if not os.path.isfile("%s/libqmmm.a" % libdir) or \
- not os.path.isfile("%s/Makefile.lammps" % libdir):
- error("Unsuccessful build of lib/qmmm library")
- else: print("Created lib/qmmm library")
-
-# REAX lib
-
-class REAX(object):
- def __init__(self,list):
- self.inlist = copy.copy(list)
- self.make = "gfortran"
- self.lammpsflag = 0
-
- def help(self):
- return """
--reax make=suffix lammps=suffix2
- all args are optional and can be in any order
- make = use Makefile.suffix (def = gfortran)
- lammps = use Makefile.lammps.suffix2 (def = EXTRAMAKE in makefile)
-"""
-
- def check(self):
- if self.inlist != None and len(self.inlist) == 0:
- error("-reax args are invalid")
- for one in self.inlist:
- words = one.split('=')
- if len(words) != 2: error("-reax args are invalid")
- if words[0] == "make": self.make = words[1]
- elif words[0] == "lammps":
- self.lammps = words[1]
- self.lammpsflag = 1
- else: error("-reax args are invalid")
-
- def build(self):
- libdir = dir.lib + "/reax"
- make = MakeReader("%s/Makefile.%s" % (libdir,self.make))
- if self.lammpsflag:
- make.setvar("EXTRAMAKE","Makefile.lammps.%s" % self.lammps)
- make.write("%s/Makefile.auto" % libdir)
-
- cmd = "cd %s; make -f Makefile.auto clean" % libdir
- subprocess.check_output(cmd,stderr=subprocess.STDOUT,shell=True)
- if jmake: txt = "cd %s; make -j %d -f Makefile.auto" % (libdir,jmake.n)
- else: txt = "cd %s; make -f Makefile.auto" % libdir
-
- # if verbose, print output as build proceeds, else only print if fails
-
- if verbose: subprocess.call(txt,shell=True)
- else:
- try: subprocess.check_output(txt,stderr=subprocess.STDOUT,shell=True)
- except subprocess.CalledProcessError as e: print(e.output)
-
- if not os.path.isfile("%s/libreax.a" % libdir) or \
- not os.path.isfile("%s/Makefile.lammps" % libdir):
- error("Unsuccessful build of lib/reax library")
- else: print("Created lib/reax library")
-
-# VORONOI lib
-
-class VORONOI(object):
- def __init__(self,list):
- self.inlist = copy.copy(list)
- self.install = ""
-
- def help(self):
- return """
--voronoi install="-d dir -v version -g -b -i installdir -l incdir libdir"
- arg is optional, only needed if want to run install.py script
- install = args to use with lib/voronoi/install.py script
- must enclose in quotes since install.py args have switches
- install.py can download, build, install, setup links to the Voro++ library
- see lib/voronoi/README for details on Voro++ and using install.py
-"""
-
- def check(self):
- if self.inlist != None and len(self.inlist) == 0:
- error("-voronoi args are invalid")
- for one in self.inlist:
- words = one.split('=')
- if len(words) != 2: error("-voronoi args are invalid")
- if words[0] == "install": self.install = words[1]
- else: error("-voronoi args are invalid")
-
- def build(self):
- if not self.install: return
- libdir = dir.lib + "/voronoi"
- cmd = "cd %s; python install.py %s" % (libdir,self.install)
- txt = subprocess.check_output(cmd,stderr=subprocess.STDOUT,
- shell=True).decode()
- if verbose: print(txt)
- print("Created lib/voronoi library")
-
-# ----------------------------------------------------------------
-# build classes for intel, kokkos build options
-# ----------------------------------------------------------------
-
-# Intel class
-
-class Intel(object):
- def __init__(self,list):
- self.inlist = copy.copy(list)
- self.mode = "cpu"
-
- def help(self):
- return """
--intel mode
- mode = cpu or phi (def = cpu)
- build Intel package for CPU or Xeon Phi
-"""
-
- def check(self):
- if self.inlist == None: return
- if len(self.inlist) != 1: error("-intel args are invalid")
- self.mode = self.inlist[0]
- if self.mode != "cpu" and self.mode != "phi":
- error("-intel args are invalid")
-
-# Kokkos class
-
-class Kokkos(object):
- def __init__(self,list):
- self.inlist = copy.copy(list)
- self.mode = ""
- self.archgpu = None
- self.archcpu = None
-
- def help(self):
- return """
--kokkos mode archgpu=N archcpu=SNB
- mode is not optional, arch is optional
- mode = omp or cuda or phi (def = KOKKOS_DEVICES setting in Makefile )
- build Kokkos package for omp or cuda or phi
- sets KOKKOS_DEVICES to "OpenMP" (omp, phi) or "Cuda, OpenMP" (cuda)
- archgpu = number like 35 (Kepler) or 21 (Fermi) (def = none)
- sets KOKKOS_ARCH for GPU to appropriate value
- archcpu = SNB or HSW or BGQ or Power7 or Power8 (def = none)
- for CPU = SandyBridge, Haswell, BGQ, Power7, Power8
- sets KOKKOS_ARCH for GPU to appropriate value
-"""
-
- def check(self):
- print(self.inlist)
- if self.inlist != None and len(self.inlist) == 0:
- error("-kokkos args are invalid")
-
- if self.inlist == None: return
- if len(self.inlist) < 1: error("-kokkos args are invalid")
- self.mode = self.inlist[0]
- if self.mode != "omp" and self.mode != "cuda" and self.mode != "phi":
- error("-kokkos args are invalid")
- for one in self.inlist[1:]:
- words = one.split('=')
- if len(words) != 2: error("-kokkos args are invalid")
- if words[0] == "archgpu": self.archgpu = words[1]
- elif words[0] == "archcpu": self.archcpu = words[1]
- else: error("-kokkos args are invalid")
-
-# ----------------------------------------------------------------
-# makefile classes for CC, FLAGS, MPI, JPG, PNG, FFT settings
-# ----------------------------------------------------------------
-
-# Cc class
-
-class Cc(object):
- def __init__(self,list):
- self.inlist = copy.copy(list)
- self.compiler = self.abbrev = ""
- self.wrap = ""
- self.parent = ""
-
- def help(self):
- return """
--cc compiler wrap=wcompiler,parent
- alter CC setting in Makefile.auto
- only happens if new Makefile.auto is created by use of "file" action
- compiler is required, all other args are optional
- compiler = any string with g++ or icc or icpc
- or mpi (or mpicxx, mpiCC, mpiicpc, etc)
- can be compiler name or full path to compiler
- mpi by itself is changed to mpicxx
- wcompiler = compiler for mpi wrapper to use
- use nvcc for building for Kokkos/cuda with provided nvcc_wrapper
- parent = openmpi or mpich
- parent style determines syntax for setting low-level compiler
-"""
-
- def check(self):
- if len(self.inlist) < 1: error("-cc args are invalid")
- self.compiler = self.inlist[0]
- if self.compiler == "mpi":
- self.compiler = "mpicxx"
- self.abbrev = "mpi"
- elif self.compiler.startswith("mpi"):
- self.abbrev = "mpi"
- elif self.compiler == "g++" or self.compiler == "icc" or \
- self.compiler == "icpc":
- self.abbrev = self.compiler
- elif "mpi" in self.compiler: self.abbrev = "mpi"
- elif "g++" in self.compiler: self.abbrev = "g++"
- elif "icc" in self.compiler: self.abbrev = "icc"
- elif "icpc" in self.compiler: self.abbrev = "icpc"
- else: error("-cc args are invalid")
- for one in self.inlist[1:]:
- words = one.split('=')
- if len(words) != 2: error("-cc args are invalid")
- args = words[1].split(',')
- if len(args) != 2: error("-cc args are invalid")
- if words[0] == "wrap":
- if self.abbrev != "mpi": error("-cc compiler is not a wrapper")
- self.wrap = args[0]
- self.parent = args[1]
- else: error("-cc args are invalid")
-
-# Flags class
-
-class Flags(object):
- def __init__(self,list):
- self.inlist = copy.copy(list)
- self.flags = []
-
- def help(self):
- return """
--flags var action N f1 f2 ... var action N f1 f2 ...
- alter variable settings (flags) in Makefile.auto
- only happens if new Makefile.auto is created by use of "file" action
- var = CCFLAGS, LINKFLAGS, LIB, etc
- any variable in Makefile.auto, must already exist
- action = add or del
- N = # of flags to follow
- f1,f2,etc = flag to add or delete
- "-" char will be prepended to each flag
- for example: add 4 g O3 xHost "fp-model fast=2"
- will add: -g -O3 -xHost -fp-model fast=2
- for add: if flag already exists, no change is made
- for delete: flag of form "-O*", will delete any wildcard match
- for -O,-O2,-O3,etc: existing -O* will first be removed
-"""
-
- def check(self):
- if len(self.inlist) < 1: error("-flags args are invalid")
- narg = len(self.inlist)
- i = 0
- while i < narg:
- if i+3 > narg: error("-flags args are invalid")
- var = self.inlist[i]
- action = self.inlist[i+1]
- if action != "add" and action != "del": error("-flags args are invalid")
- nflag = int(self.inlist[i+2])
- i += 3
- if i+nflag > narg: error("-flags args are invalid")
- flags = self.inlist[i:i+nflag]
- self.flags.append([var,action,flags])
- i += nflag
-
-# Mpi class
-
-class Mpi(object):
- def __init__(self,list):
- self.inlist = copy.copy(list)
- self.style = self.dir = ""
-
- def help(self):
- return """
--mpi style dir=path
- alter MPI settings in Makefile.auto
- only happens if new Makefile.auto is created by use of "file" action
- style is required, all other args are optional
- style = mpi or mpich or ompi or serial
- mpi = no MPI settings (assume compiler is MPI wrapper)
- mpich = use explicit settings for MPICH
- ompi = use explicit settings for OpenMPI
- serial = use settings for src/STUBS library
- dir = path for MPICH or OpenMPI directory
- add -I and -L settings for include and lib sub-dirs
-"""
-
- def check(self):
- if len(self.inlist) < 1: error("-mpi args are invalid")
- self.style = self.inlist[0]
- if self.style != "mpi" and self.style != "mpich" and \
- self.style != "ompi" and self.style != "serial":
- error("-mpi args are invalid")
- for one in self.inlist[1:]:
- words = one.split('=')
- if len(words) != 2: error("-mpi args are invalid")
- if words[0] == "dir": self.dir = words[1]
- else: error("-mpi args are invalid")
-
-# Fft class
-
-class Fft(object):
- def __init__(self,list):
- self.inlist = copy.copy(list)
- self.dir = self.incdir = self.libdir = ""
-
- def help(self):
- return """
--fft mode lib=libname dir=homedir idir=incdir ldir=libdir
- alter FFT settings in Makefile.auto
- only happens if new Makefile.auto is created by use of "file" action
- mode is required, all other args are optional
- first removes all current FFT variable settings
- mode = none or fftw or fftw3 or ...
- adds -DFFT_MODE setting
- lib = name of FFT library to link with (def is libname = mode)
- adds -llib{libname} setting, e.g. -llibfftw3
- dir = home dir for include and library files (def = none)
- adds -Idir/include and -Ldir/lib settings
- if set, overrides idir and ldir args
- idir = dir for include file (def = none)
- adds -Iidir setting
- ldir = dir for library file (def = none)
- adds -Lldir setting
-"""
-
- def check(self):
- if not len(self.inlist): error("-fft args are invalid")
- self.mode = self.inlist[0]
- self.lib = "-l%s" % self.mode
- for one in self.inlist[1:]:
- words = one.split('=')
- if len(words) != 2: error("-fft args are invalid")
- if words[0] == "lib": self.lib = "-l%s" % words[1]
- elif words[0] == "dir": self.dir = words[1]
- elif words[0] == "idir": self.incdir = words[1]
- elif words[0] == "ldir": self.libdir = words[1]
- else: error("-fft args are invalid")
-
-# Jpg class
-
-class Jpg(object):
- def __init__(self,list):
- self.inlist = copy.copy(list)
- self.on = 1
- self.dir = self.incdir = self.libdir = ""
-
- def help(self):
- return """
--jpg flag dir=homedir idir=incdir ldir=libdir
- alter JPG settings in Makefile.auto
- only happens if new Makefile.auto is created by use of "file" action
- change JPG settings in makefile
- all args are optional, flag must come first if specified
- flag = yes or no (def = yes)
- include or exclude JPEG support
- adds/removes -DLAMMPS_JPEG and -ljpeg settings
- dir = home dir for include and library files (def = none)
- adds -Idir/include and -Ldir/lib settings
- if set, overrides idir and ldir args
- idir = dir for include file (def = none)
- adds -Iidir setting
- ldir = dir for library file (def = none)
- adds -Lldir setting
-"""
-
- def check(self):
- for i,one in enumerate(self.inlist):
- if one == "no" and i == 0: self.on = 0
- elif one == "yes" and i == 0: self.on = 1
- else:
- words = one.split('=')
- if len(words) != 2: error("-jpeg args are invalid")
- if words[0] == "dir": self.dir = words[1]
- elif words[0] == "idir": self.incdir = words[1]
- elif words[0] == "ldir": self.libdir = words[1]
- else: error("-jpeg args are invalid")
-
-# Png class
-
-class Png(object):
- def __init__(self,list):
- self.inlist = copy.copy(list)
- self.on = 1
- self.dir = self.incdir = self.libdir = ""
-
- def help(self):
- return """
--png flag dir=homedir idir=incdir ldir=libdir
- alter PNG settings in Makefile.auto
- only happens if new Makefile.auto is created by use of "file" action
- all args are optional, flag must come first if specified
- flag = yes or no (def = yes)
- include or exclude PNG support
- adds/removes -DLAMMPS_PNG and -lpng settings
- dir = home dir for include and library files (def = none)
- adds -Idir/include and -Ldir/lib settings
- if set, overrides idir and ldir args
- idir = dir for include file (def = none)
- adds -Iidir setting
- ldir = dir for library file (def = none)
- adds -Lldir setting
-"""
-
- def check(self):
- for i,one in enumerate(self.inlist):
- if one == "no" and i == 0: self.on = 0
- elif one == "yes" and i == 0: self.on = 1
- else:
- words = one.split('=')
- if len(words) != 2: error("-png args are invalid")
- if words[0] == "dir": self.dir = words[1]
- elif words[0] == "idir": self.incdir = words[1]
- elif words[0] == "ldir": self.libdir = words[1]
- else: error("-png args are invalid")
-
-# ----------------------------------------------------------------
-# auxiliary classes
-# ----------------------------------------------------------------
-
-# read, tweak, and write a Makefile
-
-class MakeReader(object):
-
- # read a makefile
- # flag = 0 if file is full path name
- # flag = 1,2 if file is suffix for any Makefile.machine under src/MAKE
- # look for this file in same order that src/Makefile does
- # if flag = 1, read the file
- # if flag = 2, just check if file exists
-
- def __init__(self,file,flag=0):
- if flag == 0:
- if not os.path.isfile(file): error("Makefile %s does not exist" % file)
- lines = open(file,'r').readlines()
- else:
- mfile = "%s/MAKE/MINE/Makefile.%s" % (dir.src,file)
- if not os.path.isfile(mfile):
- mfile = "%s/MAKE/Makefile.%s" % (dir.src,file)
- if not os.path.isfile(mfile):
- mfile = "%s/MAKE/OPTIONS/Makefile.%s" % (dir.src,file)
- if not os.path.isfile(mfile):
- mfile = "%s/MAKE/MACHINES/Makefile.%s" % (dir.src,file)
- if not os.path.isfile(mfile):
- error("Makefile.%s does not exist" % file)
- if flag == 1: lines = open(mfile,'r').readlines()
- else: return
-
- # scan lines of makefile
- # if not a variable line, just copy to newlines
- # if a variable line, concatenate any continuation lines
- # convert variable to var dict entry: key = name, value = list of words
- # discard any portion of value string with a comment char
- # varinfo = list of variable info: (name, name with whitespace for print)
- # add index into varinfo to newlines
- # ccindex = index of "CC =" line, to add OMPI var before it
- # lmpindex = index of "LAMMPS-specific settings"
- # line to add KOKKOS vars before it
-
- var = {}
- varinfo = []
- newlines = []
- pattern = "(\S+\s+=\s+)(.*)"
- conditional = 0
- multiline = 0
- self.ccindex = self.lmpindex = 0
-
- for line in lines:
- line = line[:-1]
- if "CC =" in line: self.ccindex = len(newlines)
- if "LAMMPS-specific settings" in line: self.lmpindex = len(newlines)
- if "ifeq" in line:
- conditional = 1
- continue
- if conditional:
- if "endif" in line:
- conditional = 0
- continue
- if multiline:
- if '#' in line: line = line[:line.find('#')]
- morevalues = line.split()
- values = values[:-1] + morevalues
- if values[-1] != '\\':
- var[name] = values
- multiline = 0
- newlines.append(str(len(varinfo)))
- varinfo.append((name,namewhite))
- continue
- varflag = 1
- if len(line.strip()) == 0: varflag = 0
- elif line.lstrip()[0] == '#': varflag = 0
- else:
- m = re.match(pattern,line)
- if not m: varflag = 0
- if varflag:
- namewhite = m.group(1)
- name = namewhite.split()[0]
- if name in var:
- error("Makefile variable %s appears more than once" % name)
- remainder = m.group(2)
- if '#' in remainder: remainder = remainder[:remainder.find('#')]
- values = remainder.split()
- if values and values[-1] == '\\': multiline = 1
- else:
- var[name] = values
- newlines.append(str(len(varinfo)))
- varinfo.append((name,namewhite))
- else:
- newlines.append(line)
-
- self.var = var
- self.varinfo = varinfo
- self.lines = newlines
-
- # return list of values associated with var
- # return None if var not defined
-
- def getvar(self,var):
- if var in self.var: return self.var[var]
- else: return None
-
- # set var to single value
- # if var not defined, error
-
- def setvar(self,var,value):
- if var not in self.var: error("Variable %s not in makefile" % var)
- self.var[var] = [value]
-
- # add value to var
- # do not add if value already defined by var
- # if var not defined,
- # create new variable using "where"
- # where="cc", line before "CC =" line, use ":="
- # where="lmp", 2 lines before "LAMMPS-specific settings" line, use "="
-
- def addvar(self,var,value,where=""):
- if var in self.var:
- if value not in self.var[var]: self.var[var].append(value)
- else:
- if not where:
- error("Variable %s with value %s is not in makefile" % (var,value))
- if where == "cc":
- if not self.ccindex: error("No 'CC =' line in makefile to add variable")
- index = self.ccindex
- varwhite = "%s :=\t\t" % var
- elif where == "lmp":
- if not self.lmpindex: error("No 'LAMMPS-specific settings line' " +
- "in makefile to add variable")
- index = self.lmpindex - 2
- varwhite = "%s =\t\t" % var
- self.var[var] = [value]
- varwhite = "%s =\t\t" % var
- self.lines.insert(index,str(len(self.varinfo)))
- self.varinfo.append((var,varwhite))
-
- # if value = None, remove entire var
- # no need to update lines or varinfo, write() will ignore deleted vars
- # else remove value from var
- # value can have trailing '*' to remove wildcard match
- # if var or value not defined, ignore it
-
- def delvar(self,var,value=None):
- #if var == "KOKKOS_DEVICES":
- # print self.var,value
- if var not in self.var: return
- if not value:
- del self.var[var]
- #print "AGAIN",self.var
- elif value and value[-1] != '*':
- if value not in self.var[var]: return
- self.var[var].remove(value)
- else:
- value = value[:-1]
- values = self.var[var]
- dellist = []
- for i,one in enumerate(values):
- if one.startswith(value): dellist.append(i)
- while dellist: values.pop(dellist.pop())
- self.var[var] = values
-
- # write stored makefile lines to file, using vars that may have been updated
- # do not write var if not in dict, since has been deleted
- # wrap var values into multiple lines if needed
- # file = 1 if this is Makefile.auto, change 1st line to use "auto"
-
- def write(self,file,flag=0):
- fp = open(file,'w')
- for i,line in enumerate(self.lines):
- if not line.isdigit():
- if flag and i == 0:
- line = "# auto = makefile auto-generated by Make.py"
- print(line, file=fp)
- else:
- index = int(line)
- name = self.varinfo[index][0]
- txt = self.varinfo[index][1]
- if name not in self.var: continue
- values = self.var[name]
- print("%s%s" % (txt,' '.join(values)), file=fp)
-
-# ----------------------------------------------------------------
-# main program
-# ----------------------------------------------------------------
-
-# parse command-line args
-# switches dict: key = switch letter, value = list of args
-# switch_order = list of switches in order
-# will possibly be merged with redo file args below
-
-cmd_switches,cmd_switch_order = parse_args(sys.argv[1:])
-
-if "v" in cmd_switches:
- # debug
- #print "Command-line parsing:"
- #for switch in cmd_switch_order:
- # print " %s: %s" % (switch,' '.join(cmd_switches[switch]))
- pass
-
-# check for redo switch, process redo file
-# redolist = list of commands to execute
-
-redoflag = 0
-redolist = []
-
-if 'r' in cmd_switches and 'h' not in cmd_switches:
- redoflag = 1
- redo = Redo(cmd_switches['r'])
- redo.check()
- redo.setup()
- redolist = redo.commands
- redoindex = 0
- del redo
- if not redolist: error("No commands to execute from redo file")
-
-# loop over Make.py commands
-# if no redo switch, loop once for command-line command
-# if redo, loop over one or more commands from redo file
-
-while 1:
-
- # if redo:
- # parse next command from redo file
- # use command-line switches to add/replace file command switches
- # do not add -r, since already processed
- # and don't want -r swtich to appear in Make.py.last file
- # if -a in both: concatenate, de-dup,
- # specified exe/machine action replaces file exe/machine action
- # print resulting new command
- # else just use command-line switches
-
- if redoflag:
- if redoindex == len(redolist): break
- args = redolist[redoindex].split()
- switches,switch_order = parse_args(args)
- redoindex += 1
-
- for switch in cmd_switches:
- if switch == 'r': continue
- if switch == 'a' and switch in switches:
- tmp = Actions(cmd_switches[switch] + switches[switch])
- tmp.dedup()
- switches[switch] = tmp.inlist
- continue
- if switch not in switches: switch_order.append(switch)
- switches[switch] = cmd_switches[switch]
-
- argstr = switch2str(switches,switch_order)
- print("Redo command: Make.py",argstr)
- else:
- switches = cmd_switches
- switch_order = cmd_switch_order
-
- # initialize all class variables to None
-
- for one in switchclasses: exec("%s = None" % one)
- for one in libclasses: exec("%s = None" % one)
- for one in buildclasses: exec("%s = None" % one)
- for one in makeclasses: exec("%s = None" % one)
-
- # classes = dictionary of created classes
- # key = switch, value = class instance
-
- classes = {}
- for switch in switches:
- if len(switch) == 1 and switch in abbrevs:
- i = abbrevs.index(switch)
- txt = '%s = classes["%s"] = %s(switches["%s"])' % \
- (switchclasses[i],switch,switchclasses[i].capitalize(),switch)
- exec(txt)
- elif switch in libclasses:
- i = libclasses.index(switch)
- txt = '%s = classes["%s"] = %s(switches["%s"])' % \
- (libclasses[i],switch,libclasses[i].upper(),switch)
- exec(txt)
- elif switch in buildclasses:
- i = buildclasses.index(switch)
- txt = '%s = classes["%s"] = %s(switches["%s"])' % \
- (buildclasses[i],switch,buildclasses[i].capitalize(),switch)
- exec(txt)
- elif switch in makeclasses:
- i = makeclasses.index(switch)
- txt = '%s = classes["%s"] = %s(switches["%s"])' % \
- (makeclasses[i],switch,makeclasses[i].capitalize(),switch)
- exec(txt)
- else: error("Unknown command-line switch -%s" % switch)
-
- # print help messages and exit
-
- if help or (actions and "-h" in actions.inlist) or not switches:
- if not help: help = Help(None)
- print(help.help())
- for switch in switch_order:
- if switch == "h": continue
- print(classes[switch].help()[1:])
- sys.exit()
-
- # create needed default classes if not specified with switch
- # dir and packages plus lib and build classes so defaults are set
-
- if not dir: dir = Dir(None)
- if not packages: packages = Packages(None)
-
- for one in libclasses:
- txt = "if not %s: %s = %s(None)" % (one,one,one.upper())
- exec(txt)
-
- for one in buildclasses:
- txt = "if not %s: %s = %s(None)" % (one,one,one.capitalize())
- exec(txt)
-
- # error check on args for all classes
-
- for switch in classes: classes[switch].check()
-
- # prep for action
- # actions.setup() detects if last action = machine
- # if yes, induce addition of "-m" and "-o" switches
-
- dir.setup()
- packages.setup()
-
- if actions:
- machine = actions.setup()
- if machine:
- switches['a'][-1] = "exe"
- if 'm' not in switches:
- switches['m'] = [machine]
- switch_order.insert(-1,'m')
- makefile = classes['m'] = Makefile(switches['m'])
- makefile.check()
- if 'o' not in switches:
- switches['o'] = [machine]
- switch_order.insert(-1,'o')
- output = classes['o'] = Output(switches['o'])
- output.check()
-
- # perform actions
-
- packages.install()
-
- if actions:
- for action in actions.alist:
- print("Action %s ..." % action)
- if action.startswith("lib-"): actions.lib(action[4:])
- elif action == "file": actions.file("file")
- elif action == "clean": actions.clean()
- elif action == "exe": actions.exe()
-
- packages.uninstall()
-
- # create copy of executable if requested, and exe action performed
-
- if output and actions and "exe" in actions.alist:
- txt = "cp %s/lmp_auto %s/lmp_%s" % (dir.src,dir.cwd,output.machine)
- subprocess.check_output(txt,stderr=subprocess.STDOUT,shell=True)
- print("Created lmp_%s in %s" % (output.machine,dir.cwd))
-
- # create copy of Makefile.auto if requested, and file or exe action performed
- # ditto for library Makefile.auto and Makefile.lammps files
-
- if zoutput and actions and \
- ("file" in actions.alist or "exe" in actions.alist):
- txt = "cp %s/MAKE/MINE/Makefile.auto %s/MAKE/MINE/Makefile.%s" % \
- (dir.src,dir.src,zoutput.machine)
- subprocess.check_output(txt,stderr=subprocess.STDOUT,shell=True)
- print("Created Makefile.%s in %s/MAKE/MINE" % (zoutput.machine,dir.src))
- if gpubuildflag:
- txt = "cp %s/gpu/Makefile.auto %s/MAKE/MINE/Makefile_gpu.%s" % \
- (dir.lib,dir.src,zoutput.machine)
- subprocess.check_output(txt,stderr=subprocess.STDOUT,shell=True)
- print("Created Makefile_gpu.%s in %s/MAKE/MINE" % \
- (zoutput.machine,dir.src))
- txt = "cp %s/gpu/Makefile.lammps %s/MAKE/MINE/Makefile_gpu_lammps.%s" % \
- (dir.lib,dir.src,zoutput.machine)
- subprocess.check_output(txt,stderr=subprocess.STDOUT,shell=True)
- print("Created Makefile_gpu_lammps.%s in %s/MAKE/MINE" % \
- (zoutput.machine,dir.src))
-
- # write current Make.py command to src/Make.py.last
-
- fp = open("%s/Make.py.last" % dir.src,'w')
- print("# last invoked Make.py command", file=fp)
- print(switch2str(switches,switch_order), file=fp)
- fp.close()
-
- # if not redoflag, done
-
- if not redoflag: break