enable specific accelerator support via '-k on' "command-line switch"_Section_start.html#start_7, |
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, |
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
: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
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:
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
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-exlanatory. :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
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 intergers.
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
"USER-EFF"_#USER-EFF, electron force field, Andres Jaramillo-Botero (Caltech), "pair_style eff/cut"_pair_eff.html, USER/eff, "eff"_eff, -
"USER-FEP"_#USER-FEP, free energy perturbation, Agilio Padua (U Blaise Pascal Clermont-Ferrand), "compute fep"_compute_fep.html, USER/fep, -, -
"USER-H5MD"_#USER-H5MD, dump output via HDF5, Pierre de Buyl (KU Leuven), "dump h5md"_dump_h5md.html, -, -, lib/h5md
"USER-INTEL"_#USER-INTEL, Vectorized CPU and Intel(R) coprocessor styles, W. Michael Brown (Intel), "Section 5.3.2"_accelerate_intel.html, examples/intel, -, -
"USER-LB"_#USER-LB, Lattice Boltzmann fluid, Colin Denniston (U Western Ontario), "fix lb/fluid"_fix_lb_fluid.html, USER/lb, -, -
"USER-MGPT"_#USER-MGPT, fast MGPT multi-ion potentials, Tomas Oppelstrup & John Moriarty (LLNL), "pair_style mgpt"_pair_mgpt.html, USER/mgpt, -, -
"USER-MANIFOLD"_#USER-MANIFOLD, motion on 2d surface, Stefan Paquay (Eindhoven U of Technology), "fix manifoldforce"_fix_manifoldforce.html, USER/manifold, "manifold"_manifold, -
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
+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
+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 and "neigh_modify binsize
+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 and "neigh_modify binsize
3"_neigh_modify.html should be added to the input script.
-Long-Range Thread (LRT) mode is an option to the "package
+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
+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
+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
+"-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.
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,
+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
+input script or the "-pk omp Nt" "command-line
+switch"_Section_start.html#start_7 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
+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.
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.
+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
+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
+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
+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,
+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
explictly.
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
+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
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. 2016 International Conference for High Performance Computing. In press. :l
group-ID = ID of the group of atoms to be dumped :l
style = {atom} or {atom/gz} or {atom/mpiio} or {cfg} or {cfg/gz} or {cfg/mpiio} or {dcd} or {xtc} or {xyz} or {xyz/gz} or {xyz/mpiio} or {h5md} or {image} or {movie} or {molfile} or {local} or {custom} or {custom/gz} or {custom/mpiio} :l
N = dump every this many timesteps :l
file = name of file to write dump info to :l
args = list of arguments for a particular style :l
{atom} args = none
{atom/gz} args = none
{atom/mpiio} args = none
{cfg} args = same as {custom} args, see below
{cfg/gz} args = same as {custom} args, see below
{cfg/mpiio} args = same as {custom} args, see below
{dcd} args = none
{xtc} args = none
{xyz} args = none :pre
{xyz/gz} args = none :pre
{xyz/mpiio} args = none :pre
{custom/vtk} args = similar to custom args below, discussed on "dump custom/vtk"_dump_custom_vtk.html doc page :pre
{h5md} args = discussed on "dump h5md"_dump_h5md.html doc page :pre
{image} args = discussed on "dump image"_dump_image.html doc page :pre
{movie} args = discussed on "dump image"_dump_image.html doc page :pre
{molfile} args = discussed on "dump molfile"_dump_molfile.html doc page :pre
{local} args = list of local attributes
possible attributes = index, c_ID, c_ID\[I\], f_ID, f_ID\[I\]
index = enumeration of local values
c_ID = local vector calculated by a compute with ID
c_ID\[I\] = Ith column of local array calculated by a compute with ID, I can include wildcard (see below)
f_ID = local vector calculated by a fix with ID
f_ID\[I\] = Ith column of local array calculated by a fix with ID, I can include wildcard (see below) :pre
{custom} or {custom/gz} or {custom/mpiio} args = list of atom attributes
possible attributes = id, mol, proc, procp1, type, element, mass,
- x, y, z, xs, ys, zs, xu, yu, zu,
+ x, y, z, xs, ys, zs, xu, yu, zu,
xsu, ysu, zsu, ix, iy, iz,
vx, vy, vz, fx, fy, fz,
q, mux, muy, muz, mu,
radius, diameter, omegax, omegay, omegaz,
angmomx, angmomy, angmomz, tqx, tqy, tqz,
c_ID, c_ID\[N\], f_ID, f_ID\[N\], v_name :pre
id = atom ID
mol = molecule ID
proc = ID of processor that owns atom
procp1 = ID+1 of processor that owns atom
type = atom type
element = name of atom element, as defined by "dump_modify"_dump_modify.html command
mass = atom mass
x,y,z = unscaled atom coordinates
xs,ys,zs = scaled atom coordinates
xu,yu,zu = unwrapped atom coordinates
xsu,ysu,zsu = scaled unwrapped atom coordinates
ix,iy,iz = box image that the atom is in
vx,vy,vz = atom velocities
fx,fy,fz = forces on atoms
q = atom charge
mux,muy,muz = orientation of dipole moment of atom
mu = magnitude of dipole moment of atom
radius,diameter = radius,diameter of spherical particle
omegax,omegay,omegaz = angular velocity of spherical particle
angmomx,angmomy,angmomz = angular momentum of aspherical particle
tqx,tqy,tqz = torque on finite-size particles
c_ID = per-atom vector calculated by a compute with ID
c_ID\[I\] = Ith column of per-atom array calculated by a compute with ID, I can include wildcard (see below)
f_ID = per-atom vector calculated by a fix with ID
f_ID\[I\] = Ith column of per-atom array calculated by a fix with ID, I can include wildcard (see below)
v_name = per-atom vector calculated by an atom-style variable with name
d_name = per-atom floating point vector with name, managed by fix property/atom
i_name = per-atom integer vector with name, managed by fix property/atom :pre
:ule
[Examples:]
dump myDump all atom 100 dump.atom
dump myDump all atom/mpiio 100 dump.atom.mpiio
dump myDump all atom/gz 100 dump.atom.gz
dump 2 subgroup atom 50 dump.run.bin
dump 2 subgroup atom 50 dump.run.mpiio.bin
dump 4a all custom 100 dump.myforce.* id type x y vx fx
dump 4b flow custom 100 dump.%.myforce id type c_myF\[3\] v_ke
dump 4b flow custom 100 dump.%.myforce id type c_myF\[*\] v_ke
dump 2 inner cfg 10 dump.snap.*.cfg mass type xs ys zs vx vy vz
dump snap all cfg 100 dump.config.*.cfg mass type xs ys zs id type c_Stress\[2\]
dump 1 all xtc 1000 file.xtc :pre
[Description:]
Dump a snapshot of atom quantities to one or more files every N
timesteps in one of several styles. The {image} and {movie} styles are
the exception: the {image} style renders a JPG, PNG, or PPM image file
of the atom configuration every N timesteps while the {movie} style
combines and compresses them into a movie file; both are discussed in
detail on the "dump image"_dump_image.html doc page. The timesteps on
which dump output is written can also be controlled by a variable.
See the "dump_modify every"_dump_modify.html command.
Only information for atoms in the specified group is dumped. The
"dump_modify thresh and region"_dump_modify.html commands can also
alter what atoms are included. Not all styles support all these
options; see details below.
As described below, the filename determines the kind of output (text
or binary or gzipped, one big file or one per timestep, one big file
or multiple smaller files).
NOTE: Because periodic boundary conditions are enforced only on
timesteps when neighbor lists are rebuilt, the coordinates of an atom
written to a dump file may be slightly outside the simulation box.
Re-neighbor timesteps will not typically coincide with the timesteps
dump snapshots are written. See the "dump_modify
pbc"_dump_modify.html command if you with to force coordinates to be
strictly inside the simulation box.
NOTE: Unless the "dump_modify sort"_dump_modify.html option is
invoked, the lines of atom information written to dump files
(typically one line per atom) will be in an indeterminate order for
each snapshot. This is even true when running on a single processor,
if the "atom_modify sort"_atom_modify.html option is on, which it is
by default. In this case atoms are re-ordered periodically during a
simulation, due to spatial sorting. It is also true when running in
parallel, because data for a single snapshot is collected from
multiple processors, each of which owns a subset of the atoms.
For the {atom}, {custom}, {cfg}, and {local} styles, sorting is off by
default. For the {dcd}, {xtc}, {xyz}, and {molfile} styles, sorting by
atom ID is on by default. See the "dump_modify"_dump_modify.html doc
page for details.
The {atom/gz}, {cfg/gz}, {custom/gz}, and {xyz/gz} styles are identical
in command syntax to the corresponding styles without "gz", however,
they generate compressed files using the zlib library. Thus the filename
suffix ".gz" is mandatory. This is an alternative approach to writing
compressed files via a pipe, as done by the regular dump styles, which
may be required on clusters where the interface to the high-speed network
disallows using the fork() library call (which is needed for a pipe).
For the remainder of this doc page, you should thus consider the {atom}
and {atom/gz} styles (etc) to be inter-changeable, with the exception
of the required filename suffix.
As explained below, the {atom/mpiio}, {cfg/mpiio}, {custom/mpiio}, and
{xyz/mpiio} styles are identical in command syntax and in the format
of the dump files they create, to the corresponding styles without
"mpiio", except the single dump file they produce is written in
parallel via the MPI-IO library. For the remainder of this doc page,
you should thus consider the {atom} and {atom/mpiio} styles (etc) to
be inter-changeable. The one exception is how the filename is
specified for the MPI-IO styles, as explained below.
The precision of values output to text-based dump files can be
controlled by the "dump_modify format"_dump_modify.html command and
its options.
:line
The {style} keyword determines what atom quantities are written to the
file and in what format. Settings made via the
"dump_modify"_dump_modify.html command can also alter the format of
individual values and the file itself.
The {atom}, {local}, and {custom} styles create files in a simple text
format that is self-explanatory when viewing a dump file. Many of the
LAMMPS "post-processing tools"_Section_tools.html, including
"Pizza.py"_http://www.sandia.gov/~sjplimp/pizza.html, work with this
format, as does the "rerun"_rerun.html command.
For post-processing purposes the {atom}, {local}, and {custom} text
files are self-describing in the following sense.
The dimensions of the simulation box are included in each snapshot.
For an orthogonal simulation box this information is is formatted as:
ITEM: BOX BOUNDS xx yy zz
xlo xhi
ylo yhi
zlo zhi :pre
where xlo,xhi are the maximum extents of the simulation box in the
x-dimension, and similarly for y and z. The "xx yy zz" represent 6
characters that encode the style of boundary for each of the 6
simulation box boundaries (xlo,xhi and ylo,yhi and zlo,zhi). Each of
the 6 characters is either p = periodic, f = fixed, s = shrink wrap,
or m = shrink wrapped with a minimum value. See the
"boundary"_boundary.html command for details.
For triclinic simulation boxes (non-orthogonal), 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 xx yy zz
+ITEM: BOX BOUNDS xy xz yz xx yy zz
xlo_bound xhi_bound xy
ylo_bound yhi_bound xz
zlo_bound zhi_bound yz :pre
The presence of the text "xy xz yz" in the ITEM line indicates that
the 3 tilt factors will be included on each of the 3 following lines.
This bounding box is convenient for many visualization programs. The
meaning of the 6 character flags for "xx yy zz" is the same as above.
Note that the first two numbers on each line are now xlo_bound instead
of xlo, etc, since they repesent a bounding box. See "this
section"_Section_howto.html#howto_12 of the doc pages for a geometric
description of triclinic boxes, as defined by LAMMPS, simple formulas
for how the 6 bounding box extents (xlo_bound,xhi_bound,etc) are
calculated from the triclinic parameters, and how to transform those
parameters to and from other commonly used triclinic representations.
The "ITEM: ATOMS" line in each snapshot lists column descriptors for
the per-atom lines that follow. For example, the descriptors would be
"id type xs ys zs" for the default {atom} style, and would be the atom
attributes you specify in the dump command for the {custom} style.
For style {atom}, atom coordinates are written to the file, along with
the atom ID and atom type. By default, atom coords are written in a
scaled format (from 0 to 1). I.e. an x value of 0.25 means the atom
is at a location 1/4 of the distance from xlo to xhi of the box
boundaries. The format can be changed to unscaled coords via the
"dump_modify"_dump_modify.html settings. Image flags can also be
added for each atom via dump_modify.
Style {custom} allows you to specify a list of atom attributes to be
written to the dump file for each atom. Possible attributes are
listed above and will appear in the order specified. You cannot
specify a quantity that is not defined for a particular simulation -
such as {q} for atom style {bond}, since that atom style doesn't
assign charges. Dumps occur at the very end of a timestep, so atom
attributes will include effects due to fixes that are applied during
the timestep. An explanation of the possible dump custom attributes
is given below.
For style {local}, local output generated by "computes"_compute.html
and "fixes"_fix.html is used to generate lines of output that is
written to the dump file. This local data is typically calculated by
each processor based on the atoms it owns, but there may be zero or
more entities per atom, e.g. a list of bond distances. An explanation
of the possible dump local attributes is given below. Note that by
using input from the "compute
property/local"_compute_property_local.html command with dump local,
it is possible to generate information on bonds, angles, etc that can
be cut and pasted directly into a data file read by the
"read_data"_read_data.html command.
Style {cfg} has the same command syntax as style {custom} and writes
dump ID group-ID style N file color diameter keyword value ... :pre
ID = user-assigned name for the dump :ulb,l
group-ID = ID of the group of atoms to be imaged :l
style = {image} or {movie} = style of dump command (other styles {atom} or {cfg} or {dcd} or {xtc} or {xyz} or {local} or {custom} are discussed on the "dump"_dump.html doc page) :l
N = dump every this many timesteps :l
file = name of file to write image to :l
color = atom attribute that determines color of each atom :l
diameter = atom attribute that determines size of each atom :l
zero or more keyword/value pairs may be appended :l
keyword = {atom} or {adiam} or {bond} or {line} or {tri} or {body} or {fix} or {size} or {view} or {center} or {up} or {zoom} or {persp} or {box} or {axes} or {subbox} or {shiny} or {ssao} :l
{atom} = yes/no = do or do not draw atoms
{adiam} size = numeric value for atom diameter (distance units)
{bond} values = color width = color and width of bonds
color = {atom} or {type} or {none}
width = number or {atom} or {type} or {none}
number = numeric value for bond width (distance units)
{line} = color width
color = {type}
width = numeric value for line width (distance units)
{tri} = color tflag width
color = {type}
tflag = 1 for just triangle, 2 for just tri edges, 3 for both
width = numeric value for tringle edge width (distance units)
{body} = color bflag1 bflag2
color = {type}
bflag1,bflag2 = 2 numeric flags to affect how bodies are drawn
{fix} = fixID color fflag1 fflag2
fixID = ID of fix that generates objects to dray
color = {type}
fflag1,fflag2 = 2 numeric flags to affect how fix objects are drawn
{size} values = width height = size of images
width = width of image in # of pixels
height = height of image in # of pixels
{view} values = theta phi = view of simulation box
theta = view angle from +z axis (degrees)
phi = azimuthal view angle (degrees)
theta or phi can be a variable (see below)
{center} values = flag Cx Cy Cz = center point of image
flag = "s" for static, "d" for dynamic
Cx,Cy,Cz = center point of image as fraction of box dimension (0.5 = center of box)
Cx,Cy,Cz can be variables (see below)
{up} values = Ux Uy Uz = direction that is "up" in image
Ux,Uy,Uz = components of up vector
Ux,Uy,Uz can be variables (see below)
{zoom} value = zfactor = size that simulation box appears in image
zfactor = scale image size by factor > 1 to enlarge, factor < 1 to shrink
zfactor can be a variable (see below)
{persp} value = pfactor = amount of "perspective" in image
one or more keyword/value pairs may be appended :l
these keywords apply to various dump styles :l
keyword = {append} or {buffer} or {element} or {every} or {fileper} or {first} or {flush} or {format} or {image} or {label} or {nfile} or {pad} or {precision} or {region} or {scale} or {sort} or {thresh} or {unwrap} :l
{append} arg = {yes} or {no}
{buffer} arg = {yes} or {no}
{element} args = E1 E2 ... EN, where N = # of atom types
E1,...,EN = element name, e.g. C or Fe or Ga
{every} arg = N
N = dump every this many timesteps
N can be a variable (see below)
{fileper} arg = Np
Np = write one file for every this many processors
{first} arg = {yes} or {no}
{format} args = {line} string, {int} string, {float} string, M string, or {none}
string = C-style format string
M = integer from 1 to N, where N = # of per-atom quantities being output
{flush} arg = {yes} or {no}
{image} arg = {yes} or {no}
{label} arg = string
string = character string (e.g. BONDS) to use in header of dump local file
{nfile} arg = Nf
Nf = write this many files, one from each of Nf processors
{pad} arg = Nchar = # of characters to convert timestep to
{pbc} arg = {yes} or {no} = remap atoms via periodic boundary conditions
{precision} arg = power-of-10 value from 10 to 1000000
{region} arg = region-ID or "none"
{scale} arg = {yes} or {no}
{sfactor} arg = coordinate scaling factor (> 0.0)
{tfactor} arg = time scaling factor (> 0.0)
{sort} arg = {off} or {id} or N or -N
off = no sorting of per-atom lines within a snapshot
id = sort per-atom lines by atom ID
N = sort per-atom lines in ascending order by the Nth column
-N = sort per-atom lines in descending order by the Nth column
{thresh} args = attribute operation value
attribute = same attributes (x,fy,etotal,sxx,etc) used by dump custom style
operation = "<" or "<=" or ">" or ">=" or "==" or "!=" or "|^"
value = numeric value to compare to, or LAST
these 3 args can be replaced by the word "none" to turn off thresholding
{unwrap} arg = {yes} or {no} :pre
these keywords apply only to the {image} and {movie} "styles"_dump_image.html :l
-keyword = {acolor} or {adiam} or {amap} or {backcolor} or {bcolor} or {bdiam} or {boxcolor} or {color} or {bitrate} or {framerate} :l
+keyword = {acolor} or {adiam} or {amap} or {backcolor} or {bcolor} or {bdiam} or {boxcolor} or {color} or {bitrate} or {framerate} :l
{acolor} args = type color
type = atom type or range of types (see below)
color = name of color or color1/color2/...
{adiam} args = type diam
type = atom type or range of types (see below)
diam = diameter of atoms of that type (distance units)
{amap} args = lo hi style delta N entry1 entry2 ... entryN
lo = number or {min} = lower bound of range of color map
hi = number or {max} = upper bound of range of color map
style = 2 letters = "c" or "d" or "s" plus "a" or "f"
"c" for continuous
"d" for discrete
"s" for sequential
"a" for absolute
"f" for fractional
delta = binsize (only used for style "s", otherwise ignored)
binsize = range is divided into bins of this width
N = # of subsequent entries
entry = value color (for continuous style)
value = number or {min} or {max} = single value within range
color = name of color used for that value
entry = lo hi color (for discrete style)
lo/hi = number or {min} or {max} = lower/upper bound of subset of range
color = name of color used for that subset of values
entry = color (for sequential style)
color = name of color used for a bin of values
{backcolor} arg = color
color = name of color for background
{bcolor} args = type color
type = bond type or range of types (see below)
color = name of color or color1/color2/...
{bdiam} args = type diam
type = bond type or range of types (see below)
diam = diameter of bonds of that type (distance units)
{boxcolor} arg = color
color = name of color for simulation box lines and processor sub-domain lines
{color} args = name R G B
name = name of color
R,G,B = red/green/blue numeric values from 0.0 to 1.0
{bitrate} arg = rate
rate = target bitrate for movie in kbps
{framerate} arg = fps
fps = frames per second for movie :pre
:ule
[Examples:]
dump_modify 1 format line "%d %d %20.15g %g %g" scale yes
dump_modify 1 format float %20.15g scale yes
dump_modify myDump image yes scale no flush yes
dump_modify 1 region mySphere thresh x < 0.0 thresh epair >= 3.2
dump_modify xtcdump precision 10000 sfactor 0.1
dump_modify 1 every 1000 nfile 20
dump_modify 1 every v_myVar
dump_modify 1 amap min max cf 0.0 3 min green 0.5 yellow max blue boxcolor red :pre
[Description:]
Modify the parameters of a previously defined dump command. Not all
parameters are relevant to all dump styles.
As explained on the "dump"_dump.html doc page, the {atom/mpiio},
{custom/mpiio}, and {xyz/mpiio} dump styles are identical in command
syntax and in the format of the dump files they create, to the
corresponding styles without "mpiio", except the single dump file they
produce is written in parallel via the MPI-IO library. Thus if a
dump_modify option below is valid for the {atom} style, it is also
valid for the {atom/mpiio} style, and similarly for the other styles
which allow for use of MPI-IO.
:line
:line
These keywords apply to various dump styles, including the "dump
image"_dump_image.html and "dump movie"_dump_image.html styles. The
description gives details.
:line
The {append} keyword applies to all dump styles except {cfg} and {xtc}
and {dcd}. It also applies only to text output files, not to binary
or gzipped or image/movie files. If specified as {yes}, then dump
snapshots are appended to the end of an existing dump file. If
specified as {no}, then a new dump file will be created which will
overwrite an existing file with the same name. This keyword can only
take effect if the dump_modify command is used after the
"dump"_dump.html command, but before the first command that causes
dump snapshots to be output, e.g. a "run"_run.html or
"minimize"_minimize.html command. Once the dump file has been opened,
this keyword has no further effect.
:line
The {buffer} keyword applies only to dump styles {atom}, {cfg},
{custom}, {local}, and {xyz}. It also applies only to text output
files, not to binary or gzipped files. If specified as {yes}, which
is the default, then each processor writes its output into an internal
text buffer, which is then sent to the processor(s) which perform file
writes, and written by those processors(s) as one large chunk of text.
If specified as {no}, each processor sends its per-atom data in binary
format to the processor(s) which perform file wirtes, and those
processor(s) format and write it line by line into the output file.
The buffering mode is typically faster since each processor does the
relatively expensive task of formatting the output for its own atoms.
However it requires about twice the memory (per processor) for the
extra buffering.
:line
The {element} keyword applies only to the the dump {cfg}, {xyz}, and
{image} styles. It associates element names (e.g. H, C, Fe) with
LAMMPS atom types. See the list of element names at the bottom of
this page.
In the case of dump {cfg}, this allows the "AtomEye"_atomeye
visualization package to read the dump file and render atoms with the
appropriate size and color.
In the case of dump {image}, the output images will follow the same
"AtomEye"_atomeye convention. An element name is specified for each
atom type (1 to Ntype) in the simulation. The same element name can
be given to multiple atom types.
In the case of {xyz} format dumps, there are no restrictions to what
label can be used as an element name. Any whitespace separated text
type = {thermal} or {two_temperature} or {hardy} or {field} :l
{thermal} = thermal coupling with fields: temperature
{two_temperature} = electron-phonon coupling with field: temperature and electron_temperature
- {hardy} = on-the-fly post-processing using kernel localization functions (see "related" section for possible fields)
- {field} = on-the-fly post-processing using mesh-based localization functions (see "related" section for possible fields) :pre
+ {hardy} = on-the-fly post-processing using kernel localization functions (see "related" section for possible fields)
+ {field} = on-the-fly post-processing using mesh-based localization functions (see "related" section for possible fields) :pre
parameter_file = name of the file with material parameters. Note: Neither hardy nor field requires a parameter file :l
-:ule
+:ule
[Examples:]
-fix AtC internal atc thermal Ar_thermal.dat
+fix AtC internal atc thermal Ar_thermal.dat
fix AtC internal atc two_temperature Ar_ttm.mat
fix AtC internal atc hardy
-fix AtC internal atc field :pre
+fix AtC internal atc field :pre
[Description:]
This fix is the beginning to creating a coupled FE/MD simulation and/or an on-the-fly estimation of continuum fields. The coupled versions of this fix do Verlet integration and the post-processing does not. After instantiating this fix, several other fix_modify commands will be needed to set up the problem, e.g. define the finite element mesh and prescribe initial and boundary conditions.
:c,image(JPG/atc_nanotube.jpg)
The following coupling example is typical, but non-exhaustive:
# ... commands to create and initialize the MD system :pre
- # initial fix to designate coupling type and group to apply it to
- # tag group physics material_file
+ # initial fix to designate coupling type and group to apply it to
+ # tag group physics material_file
fix AtC internal atc thermal Ar_thermal.mat :pre
-
- # create a uniform 12 x 2 x 2 mesh that covers region contain the group
- # nx ny nz region periodicity
+
+ # create a uniform 12 x 2 x 2 mesh that covers region contain the group
+ # nx ny nz region periodicity
fix_modify AtC mesh create 12 2 2 mdRegion f p p :pre
-
- # specify the control method for the type of coupling
- # physics control_type
+
+ # specify the control method for the type of coupling
+ # physics control_type
fix_modify AtC thermal control flux :pre
-
- # specify the initial values for the empirical field "temperature"
- # field node_group value
+
+ # specify the initial values for the empirical field "temperature"
+ # field node_group value
fix_modify AtC initial temperature all 30 :pre
-
- # create an output stream for nodal fields
- # filename output_frequency
+
+ # create an output stream for nodal fields
+ # filename output_frequency
fix_modify AtC output atc_fe_output 100 :pre
-
- run 1000 :pre
-
-likewise for this post-processing example:
+
+ run 1000 :pre
+
+likewise for this post-processing example:
# ... commands to create and initialize the MD system :pre
- # initial fix to designate post-processing and the group to apply it to
- # no material file is allowed nor required
+ # initial fix to designate post-processing and the group to apply it to
+ # no material file is allowed nor required
fix AtC internal atc hardy :pre
-
- # for hardy fix, specific kernel function (function type and range) to # be used as a localization function
+
+ # for hardy fix, specific kernel function (function type and range) to # be used as a localization function
fix AtC kernel quartic_sphere 10.0 :pre
-
- # create a uniform 1 x 1 x 1 mesh that covers region contain the group
- # with periodicity this effectively creats a system average
- fix_modify AtC mesh create 1 1 1 box p p p :pre
- # change from default lagrangian map to eulerian
- # refreshed every 100 steps
+ # create a uniform 1 x 1 x 1 mesh that covers region contain the group
+ # with periodicity this effectively creats a system average
+ fix_modify AtC mesh create 1 1 1 box p p p :pre
+
+ # change from default lagrangian map to eulerian
+ # refreshed every 100 steps
fix_modify AtC atom_element_map eulerian 100 :pre
-
- # start with no field defined
- # add mass density, potential energy density, stress and temperature
+
+ # start with no field defined
+ # add mass density, potential energy density, stress and temperature
fix_modify AtC fields add density energy stress temperature :pre
- # create an output stream for nodal fields
- # filename output_frequency
+ # create an output stream for nodal fields
+ # filename output_frequency
fix_modify AtC output nvtFE 100 text :pre
run 1000 :pre
-
-the mesh's linear interpolation functions can be used as the localization function
- by using the field option:
- fix AtC internal atc field
-
- fix_modify AtC mesh create 1 1 1 box p p p
+the mesh's linear interpolation functions can be used as the localization function
+ by using the field option:
+
+ fix AtC internal atc field
+
+ fix_modify AtC mesh create 1 1 1 box p p p
- ...
+ ...
-Note coupling and post-processing can be combined in the same simulations using separate fixes.
+Note coupling and post-processing can be combined in the same simulations using separate fixes.
: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 options relevant to this fix are listed below. 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 not invoked during "energy minimization"_minimize.html.
[Restrictions:]
-Thermal and two_temperature (coupling) types use a Verlet time-integration algorithm. The hardy type does not contain its own time-integrator and must be used with a separate fix that does contain one, e.g. nve, nvt, etc.
+Thermal and two_temperature (coupling) types use a Verlet time-integration algorithm. The hardy type does not contain its own time-integrator and must be used with a separate fix that does contain one, e.g. nve, nvt, etc.
-Currently,
-- the coupling is restricted to thermal physics
+Currently,
+- the coupling is restricted to thermal physics
- the FE computations are done in serial on each processor. :ul
[Related commands:]
After specifying this fix in your input script, several other "fix_modify"_fix_modify.html commands are used to setup the problem, e.g. define the finite element mesh and prescribe initial and boundary conditions.
-Note: a set of example input files with the attendant material files are included with this package
+Note: a set of example input files with the attendant material files are included with this package
[Default:]
-None
+None
:line
For detailed exposition of the theory and algorithms please see:
:link(Wagner)
-[(Wagner)] Wagner, GJ; Jones, RE; Templeton, JA; Parks, MA, "An atomistic-to-continuum coupling method for heat transfer in solids." Special Issue of Computer Methods and Applied Mechanics (2008) 197:3351.
+[(Wagner)] Wagner, GJ; Jones, RE; Templeton, JA; Parks, MA, "An atomistic-to-continuum coupling method for heat transfer in solids." Special Issue of Computer Methods and Applied Mechanics (2008) 197:3351.
:link(Zimmeman2004)
-[(Zimmerman2004)] Zimmerman, JA; Webb, EB; Hoyt, JJ;. Jones, RE; Klein, PA; Bammann, DJ, "Calculation of stress in atomistic simulation." Special Issue of Modelling and Simulation in Materials Science and Engineering (2004), 12:S319.
+[(Zimmerman2004)] Zimmerman, JA; Webb, EB; Hoyt, JJ;. Jones, RE; Klein, PA; Bammann, DJ, "Calculation of stress in atomistic simulation." Special Issue of Modelling and Simulation in Materials Science and Engineering (2004), 12:S319.
:link(Zimmerman2010)
-[(Zimmerman2010)] Zimmerman, JA; Jones, RE; Templeton, JA, "A material frame approach for evaluating continuum variables in atomistic simulations." Journal of Computational Physics (2010), 229:2364.
+[(Zimmerman2010)] Zimmerman, JA; Jones, RE; Templeton, JA, "A material frame approach for evaluating continuum variables in atomistic simulations." Journal of Computational Physics (2010), 229:2364.
:link(Templeton2010)
-[(Templeton2010)] Templeton, JA; Jones, RE; Wagner, GJ, "Application of a field-based method to spatially varying thermal transport problems in molecular dynamics." Modelling and Simulation in Materials Science and Engineering (2010), 18:085007.
+[(Templeton2010)] Templeton, JA; Jones, RE; Wagner, GJ, "Application of a field-based method to spatially varying thermal transport problems in molecular dynamics." Modelling and Simulation in Materials Science and Engineering (2010), 18:085007.
:link(Jones)
-[(Jones)] Jones, RE; Templeton, JA; Wagner, GJ; Olmsted, D; Modine, JA, "Electron transport enhanced molecular dynamics for metals and semi-metals." International Journal for Numerical Methods in Engineering (2010), 83:940.
+[(Jones)] Jones, RE; Templeton, JA; Wagner, GJ; Olmsted, D; Modine, JA, "Electron transport enhanced molecular dynamics for metals and semi-metals." International Journal for Numerical Methods in Engineering (2010), 83:940.
:link(Templeton2011)
-[(Templeton2011)] Templeton, JA; Jones, RE; Lee, JW; Zimmerman, JA; Wong, BM, "A long-range electric field solver for molecular dynamics based on atomistic-to-continuum modeling." Journal of Chemical Theory and Computation (2011), 7:1736.
+[(Templeton2011)] Templeton, JA; Jones, RE; Lee, JW; Zimmerman, JA; Wong, BM, "A long-range electric field solver for molecular dynamics based on atomistic-to-continuum modeling." Journal of Chemical Theory and Computation (2011), 7:1736.
:link(Mandadapu)
-[(Mandadapu)] Mandadapu, KK; Templeton, JA; Lee, JW, "Polarization as a field variable from molecular dynamics simulations." Journal of Chemical Physics (2013), 139:054115.
+[(Mandadapu)] Mandadapu, KK; Templeton, JA; Lee, JW, "Polarization as a field variable from molecular dynamics simulations." Journal of Chemical Physics (2013), 139:054115.
Please refer to the standard finite element (FE) texts, e.g. T.J.R Hughes " The finite element method ", Dover 2003, for the basics of FE simulation.
ID, group-ID are documented in "fix"_fix.html command :ulb,l
box/relax = style name of this fix command :l
one or more keyword value pairs may be appended
-keyword = {iso} or {aniso} or {tri} or {x} or {y} or {z} or {xy} or {yz} or {xz} or {couple} or {nreset} or {vmax} or {dilate} or {scaleyz} or {scalexz} or {scalexy} or {fixedpoint}
+keyword = {iso} or {aniso} or {tri} or {x} or {y} or {z} or {xy} or {yz} or {xz} or {couple} or {nreset} or {vmax} or {dilate} or {scaleyz} or {scalexz} or {scalexy} or {fixedpoint}
{iso} or {aniso} or {tri} value = Ptarget = desired pressure (pressure units)
{x} or {y} or {z} or {xy} or {yz} or {xz} value = Ptarget = desired pressure (pressure units)
{couple} = {none} or {xyz} or {xy} or {yz} or {xz}
{nreset} value = reset reference cell every this many minimizer iterations
{vmax} value = fraction = max allowed volume change in one iteration
- {dilate} value = {all} or {partial}
+ {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
{fixedpoint} values = x y z
x,y,z = perform relaxation dilation/contraction around this point (distance units) :pre
fix ID group-ID lb/fluid nevery LBtype viscosity density keyword values ... :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
lb/fluid = style name of this fix command :l
nevery = update the lattice-Boltzmann fluid every this many timesteps :l
-LBtype = 1 to use the standard finite difference LB integrator,
+LBtype = 1 to use the standard finite difference LB integrator,
2 to use the LB integrator of "Ollila et al."_#Ollila :l
viscosity = the fluid viscosity (units of mass/(time*length)). :l
-density = the fluid density. :l
+density = the fluid density. :l
zero or more keyword/value pairs may be appended :l
keyword = {setArea} or {setGamma} or {scaleGamma} or {dx} or {dm} or {a0} or {noise} or {calcforce} or {trilinear} or {D3Q19} or {read_restart} or {write_restart} or {zwall_velocity} or {bodyforce} or {printfluid} :l
{setArea} values = type node_area
type = atom type (1-N)
node_area = portion of the surface area of the composite object associated with the particular atom type (used when the force coupling constant is set by default).
{setGamma} values = gamma
gamma = user set value for the force coupling constant.
{scaleGamma} values = type gammaFactor
type = atom type (1-N)
- gammaFactor = factor to scale the {setGamma} gamma value by, for the specified atom type.
+ gammaFactor = factor to scale the {setGamma} gamma value by, for the specified atom type.
{dx} values = dx_LB = the lattice spacing.
{dm} values = dm_LB = the lattice-Boltzmann mass unit.
{a0} values = a_0_real = the square of the speed of sound in the fluid.
- {noise} values = Temperature seed
- Temperature = fluid temperature.
- seed = random number generator seed (positive integer)
- {calcforce} values = N forcegroup-ID
+ {noise} values = Temperature seed
+ Temperature = fluid temperature.
+ seed = random number generator seed (positive integer)
+ {calcforce} values = N forcegroup-ID
N = output the force and torque every N timesteps
forcegroup-ID = ID of the particle group to calculate the force and torque of
{trilinear} values = none (used to switch from the default Peskin interpolation stencil to the trilinear stencil).
{D3Q19} values = none (used to switch from the default D3Q15, 15 velocity lattice, to the D3Q19, 19 velocity lattice).
{read_restart} values = restart file = name of the restart file to use to restart a fluid run.
{write_restart} values = N = write a restart file every N MD timesteps.
{zwall_velocity} values = velocity_bottom velocity_top = velocities along the y-direction of the bottom and top walls (located at z=zmin and z=zmax).
{bodyforce} values = bodyforcex bodyforcey bodyforcez = the x,y and z components of a constant body force added to the fluid.
{printfluid} values = N = print the fluid density and velocity at each grid point every N timesteps. :pre
-By default, the force coupling constant is set according to
+By default, the force coupling constant is set according to
:c,image(Eqs/fix_lb_fluid_gammadefault.jpg)
and an area of dx_lb^2 per node, used to calculate the fluid mass at
the particle node location, is assumed.
-dx is chosen such that tau/(delta t_LB) =
-(3 eta dt_LB)/(rho dx_lb^2) is approximately equal to 1.
-dm is set equal to 1.0.
-a0 is set equal to (1/3)*(dx_lb/dt_lb)^2.
+dx is chosen such that tau/(delta t_LB) =
+(3 eta dt_LB)/(rho dx_lb^2) is approximately equal to 1.
+dm is set equal to 1.0.
+a0 is set equal to (1/3)*(dx_lb/dt_lb)^2.
The Peskin stencil is used as the default interpolation method.
The D3Q15 lattice is used for the lattice-Boltzmann algorithm.
If walls are present, they are assumed to be stationary.
:line
:link(Ollila)
[(Ollila et al.)] Ollila, S.T.T., Denniston, C., Karttunen, M., and Ala-Nissila, T., Fluctuating lattice-Boltzmann model for complex fluids, J. Chem. Phys. 134 (2011) 064902.
-:link(fluid-Mackay)
+:link(fluid-Mackay)
[(Mackay et al.)] Mackay, F. E., Ollila, S.T.T., and Denniston, C., Hydrodynamic Forces Implemented into LAMMPS through a lattice-Boltzmann fluid, Computer Physics Communications 184 (2013) 2021-2031.
:link(Mackay2)
[(Mackay and Denniston)] Mackay, F. E., and Denniston, C., Coupling MD particles to a lattice-Boltzmann fluid through the use of conservative forces, J. Comput. Phys. 237 (2013) 289-298.
:link(Adhikari)
[(Adhikari et al.)] Adhikari, R., Stratford, K., Cates, M. E., and Wagner, A. J., Fluctuating lattice Boltzmann, Europhys. Lett. 71 (2005) 473-479.
ID, group-ID are documented in the "fix"_fix.html command
lb/pc = style name of this fix command :ul
[Examples:]
fix 1 all lb/pc :pre
[Description:]
Update the positions and velocities of the individual particles
described by {group-ID}, experiencing velocity-dependent hydrodynamic
forces, using the integration algorithm described in "Mackay et
al."_#Mackay. This integration algorithm should only be used if a
user-specified value for the force-coupling constant used in "fix
lb/fluid"_fix_lb_fluid.html has been set; do not use this integration
algorithm if the force coupling constant has been set by default.
[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:]
+[Restrictions:]
This fix is part of the USER-LB 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.
Can only be used if a lattice-Boltzmann fluid has been created via the
"fix lb/fluid"_fix_lb_fluid.html command, and must come after this
command.
[Related commands:]
"fix lb/fluid"_fix_lb_fluid.html "fix
lb/rigid/pc/sphere"_fix_lb_rigid_pc_sphere.html
[Default:] None.
:line
-:link(Mackay)
+:link(Mackay)
[(Mackay et al.)] Mackay, F. E., Ollila, S.T.T., and Denniston, C., Hydrodynamic Forces Implemented into LAMMPS through a lattice-Boltzmann fluid, Computer Physics Communications 184 (2013) 2021-2031.
The defaults are force * on on on, and torque * on on on.
:line
:link(Mackay)
[(Mackay et al.)] Mackay, F. E., Ollila, S.T.T., and Denniston, C., Hydrodynamic Forces Implemented into LAMMPS through a lattice-Boltzmann fluid, Computer Physics Communications 184 (2013) 2021-2031.
[(Mackay et al.)] Mackay, F. E., Ollila, S.T.T., and Denniston, C., Hydrodynamic Forces Implemented into LAMMPS through a lattice-Boltzmann fluid, Computer Physics Communications 184 (2013) 2021-2031.
-{dhugoniot} is the departure from the Hugoniot (temperature units).
-{drayleigh} is the departure from the Rayleigh line (pressure units).
+{dhugoniot} is the departure from the Hugoniot (temperature units).
+{drayleigh} is the departure from the Rayleigh line (pressure units).
{lagrangian_speed} is the laboratory-frame Lagrangian speed (particle velocity) of the computational cell (velocity units).
{lagrangian_position} is the computational cell position in the reference frame moving at the shock speed. This is usually a good estimate of distance of the computational cell behind the shock front. :ol
To print these quantities to the log file with descriptive column
headers, the following LAMMPS commands are suggested:
-fix msst all msst z
+fix msst all msst z
fix_modify msst energy yes
variable dhug equal f_msst\[1\]
variable dray equal f_msst\[2\]
variable lgr_vel equal f_msst\[3\]
variable lgr_pos equal f_msst\[4\]
thermo_style custom step temp ke pe lz pzz etotal v_dhug v_dray v_lgr_vel v_lgr_pos f_msst :pre
These fixes compute a global scalar and a global vector of 4
quantities, which can be accessed by various "output
commands"_Section_howto.html#howto_15. The scalar values calculated
by this fix are "extensive"; the vector values are "intensive".
[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 cell dimensions must be periodic. This fix can not be used with a
triclinic cell. The MSST fix has been tested only for the group-ID
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 = 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
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)"_#Ravelo.
These equations compress the system to a state with average
-axial stress or pressure equal to the specified target value
+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
+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
+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}
+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 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
+user-specified target temperature is replaced with a time-dependent
target temperature Tt obtained from the following equation:
-:c,image(Eqs/fix_nphug.jpg)
+: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
+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
+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
+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:
zero or more keyword/value pairs may be appended :l
keyword = {q} or {mu} or {p0} or {v0} or {e0} or {tscale} or {damp} or {seed}or {f_max} or {N_f} or {eta} or {beta} or {T_init} :l
{q} value = cell mass-like parameter (mass^2/distance^4 units)
{mu} value = artificial viscosity (mass/distance/time units)
{p0} value = initial pressure in the shock equations (pressure units)
{v0} value = initial simulation cell volume in the shock equations (distance^3 units)
{e0} value = initial total energy (energy units)
{tscale} value = reduction in initial temperature (unitless fraction between 0.0 and 1.0)
{damp} value = damping parameter (time units) inverse of friction <i>γ</i>
{seed} value = random number seed (positive integer)
{f_max} value = upper cutoff frequency of the vibration spectrum (1/time units)
{N_f} value = number of frequency bins (positive integer)
{eta} value = coupling constant between the shock system and the quantum thermal bath (positive unitless)
{beta} value = the quantum temperature is updated every beta time steps (positive integer)
{T_init} value = quantum temperature for the initial state (temperature units) :pre
:ule
[Examples:]
fix 1 all qbmsst z 0.122 q 25 mu 0.9 tscale 0.01 damp 200 seed 35082 f_max 0.3 N_f 100 eta 1 beta 400 T_init 110 (liquid methane modeled with the REAX force field, real units)
fix 2 all qbmsst z 72 q 40 tscale 0.05 damp 1 seed 47508 f_max 120.0 N_f 100 eta 1.0 beta 500 T_init 300 (quartz modeled with the BKS force field, metal units) :pre
Two example input scripts are given, including shocked alpha quartz
and shocked liquid methane. The input script first equilibrate an
initial state with the quantum thermal bath at the target temperature
and then apply the qbmsst to simulate shock compression with quantum
nuclear correction. The following two figures plot related quantities
for shocked alpha quartz.
:c,image(JPG/qbmsst_init.jpg)
Figure 1. Classical temperature <i>T</i><sup>cl</sup> = ∑
<i>m<sub>i</sub>v<sub>i</sub><sup>2</sup>/3Nk</i><sub>B</sub> vs. time
for coupling the alpha quartz initial state with the quantum thermal
bath at target quantum temperature <i>T</i><sup>qm</sup> = 300 K. The
NpH ensemble is used for time integration while QTB provides the
colored random force. <i>T</i><sup>cl</sup> converges at the timescale
of {damp} which is set to be 1 ps.
:c,image(JPG/qbmsst_shock.jpg)
Figure 2. Quantum temperature and pressure vs. time for simulating
shocked alpha quartz with the QBMSST. The shock propagates along the z
direction. Restart of the QBMSST command is demonstrated in the
example input script. Thermodynamic quantities stay continuous before
and after the restart.
[Description:]
This command performs the Quantum-Bath coupled Multi-Scale Shock
Technique (QBMSST) integration. See "(Qi)"_#Qi for a detailed
description of this method. The QBMSST provides description of the
thermodynamics and kinetics of shock processes while incorporating
quantum nuclear effects. The {shockvel} setting determines the steady
shock velocity that will be simulated along direction {dir}.
Quantum nuclear effects "(fix qtb)"_fix_qtb.html can be crucial
especially when the temperature of the initial state is below the
classical limit or there is a great change in the zero point energies
between the initial and final states. Theoretical post processing
quantum corrections of shock compressed water and methane have been
reported as much as 30% of the temperatures "(Goldman)"_#Goldman. A
self-consistent method that couples the shock to a quantum thermal
bath described by a colored noise Langevin thermostat has been
developed by Qi et al "(Qi)"_#Qi and applied to shocked methane. The
onset of chemistry is reported to be at a pressure on the shock
Hugoniot that is 40% lower than observed with classical molecular
dynamics.
It is highly recommended that the system be already in an equilibrium
state with a quantum thermal bath at temperature of {T_init}. The fix
command "fix qtb"_fix_qtb.html at constant temperature {T_init} could
be used before applying this command to introduce self-consistent
quantum nuclear effects into the initial state.
The parameters {q}, {mu}, {e0}, {p0}, {v0} and {tscale} are described
in the command "fix msst"_fix_msst.html. The values of {e0}, {p0}, or
{v0} will be calculated on the first step if not specified. The
parameter of {damp}, {f_max}, and {N_f} are described in the command
"fix qtb"_fix_qtb.html.
The fix qbmsst command couples the shock system to a quantum thermal
bath with a rate that is proportional to the change of the total
energy of the shock system, <i>etot</i> - <i>etot</i><sub>0</sub>.
Here <i>etot</i> consists of both the system energy and a thermal
term, see "(Qi)"_#Qi, and <i>etot</i><sub>0</sub> = {e0} is the
initial total energy.
The {eta} (<i>η</i>) parameter is a unitless coupling constant
between the shock system and the quantum thermal bath. A small {eta}
value cannot adjust the quantum temperature fast enough during the
temperature ramping period of shock compression while large {eta}
leads to big temperature oscillation. A value of {eta} between 0.3 and
1 is usually appropriate for simulating most systems under shock
compression. We observe that different values of {eta} lead to almost
the same final thermodynamic state behind the shock, as expected.
The quantum temperature is updated every {beta} (<i>β</i>) steps
with an integration time interval {beta} times longer than the
simulation time step. In that case, <i>etot</i> is taken as its
average over the past {beta} steps. The temperature of the quantum
thermal bath <i>T</i><sup>qm</sup> changes dynamically according to
the following equation where Δ<i>t</i> is the MD time step and
<i>γ</i> is the friction constant which is equal to the inverse
-{dhugoniot} is the departure from the Hugoniot (temperature units).
-{drayleigh} is the departure from the Rayleigh line (pressure units).
+{dhugoniot} is the departure from the Hugoniot (temperature units).
+{drayleigh} is the departure from the Rayleigh line (pressure units).
{lagrangian_speed} is the laboratory-frame Lagrangian speed (particle velocity) of the computational cell (velocity units).
{lagrangian_position} is the computational cell position in the reference frame moving at the shock speed. This is the distance of the computational cell behind the shock front.
{quantum_temperature} is the temperature of the quantum thermal bath <i>T</i><sup>qm</sup>. :ol
To print these quantities to the log file with descriptive column
headers, the following LAMMPS commands are suggested. Here the
"fix_modify"_fix_modify.html energy command is also enabled to allow
the thermo keyword {etotal} to print the quantity <i>etot</i>. See
also the "thermo_style"_thermo_style.html command.
-fix fix_id all msst z
+fix fix_id all msst z
fix_modify fix_id energy yes
variable dhug equal f_fix_id\[1\]
variable dray equal f_fix_id\[2\]
variable lgr_vel equal f_fix_id\[3\]
variable lgr_pos equal f_fix_id\[4\]
variable T_qm equal f_fix_id\[5\]
thermo_style custom step temp ke pe lz pzz etotal v_dhug v_dray v_lgr_vel v_lgr_pos v_T_qm f_fix_id :pre
The global scalar under the entry f_fix_id is the quantity of thermo
energy as an extra part of <i>etot</i>. This global scalar and the
vector of 5 quantities can be accessed by various "output
commands"_Section_howto.html#howto_15. It is worth noting that the
temp keyword under the "thermo_style"_thermo_style.html command print
the instantaneous classical temperature <i>T</i><sup>cl</sup> as
described in the command "fix qtb"_fix_qtb.html.
:line
[Restrictions:]
This fix style is part of the USER-QTB 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 cell dimensions must be periodic. This fix can not be used with a
triclinic cell. The QBMSST fix has been tested only for the group-ID
all.
:line
[Related commands:]
"fix qtb"_fix_qtb.html, "fix msst"_fix_msst.html
:line
[Default:]
The keyword defaults are q = 10, mu = 0, tscale = 0.01, damp = 1, seed
= 880302, f_max = 200.0, N_f = 100, eta = 1.0, beta = 100, and
T_init=300.0. e0, p0, and v0 are calculated on the first step.
:line
:link(Goldman)
[(Goldman)] Goldman, Reed and Fried, J. Chem. Phys. 131, 204103 (2009)
:link(Qi)
[(Qi)] Qi and Reed, J. Phys. Chem. A 116, 10451 (2012).
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 {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)
{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
+ 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
fix 1 clump rigid/small molecule
fix 1 clump rigid single force 1 off off on langevin 1.0 1.0 1.0 428984
adjust_radius_factor = factor which scale the smooth/kernel radius
min_nn = minimum number of neighbors
max_nn = maximum number of neighbors
limit_velocity values = max_velocity
- max_velocity = maximum allowed velocity.
-
+ max_velocity = maximum allowed velocity.
+
[Examples:]
fix 1 all smd/integrate_ulsph adjust_radius 1.02 25 50 :pre
fix 1 all smd/integrate_ulsph limit_velocity 1000 :pre
[Description:]
The fix performs explicit time integration for particles which interact with the updated Lagrangian SPH pair style.
See "this PDF guide"_USER/smd/SMD_LAMMPS_userguide.pdf to using Smooth Mach Dynamics in LAMMPS.
The {adjust_radius} keyword activates dynamic adjustment of the per-particle SPH smoothing kernel radius such that the number of neighbors per particles remains
within the interval {min_nn} to {max_nn}. The parameter {adjust_radius_factor} determines the amount of adjustment per timestep. Typical values are
{adjust_radius_factor}=1.02, {min_nn}=15, and {max_nn}=20.
The {limit_velocity} keyword will control the velocity, scaling the norm of
-the velocity vector to max_vel in case it exceeds this velocity limit.
+the velocity vector to max_vel in case it exceeds this velocity limit.
[Restart, fix_modify, output, run start/stop, minimize info:]
Currently, no part of USER-SMD supports restarting nor minimization. This fix has no outputs.
[Restrictions:]
This fix is part of the USER-SMD package. It is only enabled if
LAMMPS was built with that package. See the "Making LAMMPS"_Section_start.html#start_3
fix ID group-ID smd/wall_surface arg type mol-ID :pre
ID, group-ID are documented in "fix"_fix.html command :ulb,l
smd/wall_surface = style name of this fix command :l
arg = {file} :l
{file} = file name of a triangular mesh in stl format :pre
type = particle type to be given to the new particles created by this fix :l
mol-ID = molecule-ID to be given to the new particles created by this fix (must be >= 65535) :l
-
+
:ule
[Examples:]
fix stl_surf all smd/wall_surface tool.stl 2 65535 :pre
[Description:]
This fix creates reads a traingulated surface from a file in .STL format.
For each triangle, a new particle is created which stores the barycenter of the triangle and the vertex positions.
-The radius of the new particle is that of the minimum circle which encompasses the triangle vertices.
+The radius of the new particle is that of the minimum circle which encompasses the triangle vertices.
The triangulated surface can be used as a complex rigid wall via the "smd/tri_surface"_pair_smd_triangulated_surface.html pair style.
It is possible to move the triangulated surface via the "smd/move_tri_surf"_fix_smd_move_triangulated_surface.html fix style.
Immediately after a .STL file has been read, the simulation needs to be run for 0 timesteps in order to properly register the new particles
-in the system. See the "funnel_flow" example in the USER-SMD examples directory.
+in the system. See the "funnel_flow" example in the USER-SMD examples directory.
See "this PDF guide"_USER/smd/SMD_LAMMPS_userguide.pdf to use Smooth Mach Dynamics in LAMMPS.
[Restart, fix_modify, output, run start/stop, minimize info:]
Currently, no part of USER-SMD supports restarting nor minimization. This fix has no outputs.
[Restrictions:]
This fix is part of the USER-SMD 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 molecule ID given to the particles created by this fix have to be equal to or larger than 65535.
-Within each .STL file, only a single triangulated object must be present, even though the STL format allows for the possibility of multiple objects in one file.
+Within each .STL file, only a single triangulated object must be present, even though the STL format allows for the possibility of multiple objects in one file.
one or more keyword/value pairs may be listed :ulb,l
keyword = {mesh} or {order} or {order/disp} or {mix/disp} or {overlap} or {minorder} or {force} or {gewald} or {gewald/disp} or {slab} or (nozforce} or {compute} or {cutoff/adjust} or {fftbench} or {collective} or {diff} or {kmax/ewald} or {force/disp/real} or {force/disp/kspace} or {splittol} or {disp/auto}:l
{mesh} value = x y z
x,y,z = grid size in each dimension for long-range Coulombics
{mesh/disp} value = x y z
x,y,z = grid size in each dimension for 1/r^6 dispersion
{order} value = N
N = extent of Gaussian for PPPM or MSM mapping of charge to grid
{order/disp} value = N
N = extent of Gaussian for PPPM mapping of dispersion term to grid
{mix/disp} value = {pair} or {geom} or {none}
{overlap} = {yes} or {no} = whether the grid stencil for PPPM is allowed to overlap into more than the nearest-neighbor processor
{minorder} value = M
M = min allowed extent of Gaussian when auto-adjusting to minimize grid communication
{force} value = accuracy (force units)
{gewald} value = rinv (1/distance units)
rinv = G-ewald parameter for Coulombics
{gewald/disp} value = rinv (1/distance units)
rinv = G-ewald parameter for dispersion
{slab} value = volfactor or {nozforce}
volfactor = ratio of the total extended volume used in the
2d approximation compared with the volume of the simulation domain
{nozforce} turns off kspace forces in the z direction
- {compute} value = {yes} or {no}
- {cutoff/adjust} value = {yes} or {no}
- {pressure/scalar} value = {yes} or {no}
- {fftbench} value = {yes} or {no}
- {collective} value = {yes} or {no}
- {diff} value = {ad} or {ik} = 2 or 4 FFTs for PPPM in smoothed or non-smoothed mode
- {kmax/ewald} value = kx ky kz
+ {compute} value = {yes} or {no}
+ {cutoff/adjust} value = {yes} or {no}
+ {pressure/scalar} value = {yes} or {no}
+ {fftbench} value = {yes} or {no}
+ {collective} value = {yes} or {no}
+ {diff} value = {ad} or {ik} = 2 or 4 FFTs for PPPM in smoothed or non-smoothed mode
+ {kmax/ewald} value = kx ky kz
kx,ky,kz = number of Ewald sum kspace vectors in each dimension
{force/disp/real} value = accuracy (force units)
{force/disp/kspace} value = accuracy (force units)
{splittol} value = tol
tol = relative size of two eigenvalues (see discussion below)
{disp/auto} value = yes or no :pre
:ule
[Examples:]
kspace_modify mesh 24 24 30 order 6
kspace_modify slab 3.0 :pre
[Description:]
Set parameters used by the kspace solvers defined by the
"kspace_style"_kspace_style.html command. Not all parameters are
relevant to all kspace styles.
The {mesh} keyword sets the grid size for kspace style {pppm} or
{msm}. In the case of PPPM, this is the FFT mesh, and each dimension
must be factorizable into powers of 2, 3, and 5. In the case of MSM,
this is the finest scale real-space mesh, and each dimension must be
factorizable into powers of 2. When this option is not set, the PPPM
or MSM solver chooses its own grid size, consistent with the
user-specified accuracy and pairwise cutoff. Values for x,y,z of
0,0,0 unset the option.
The {mesh/disp} keyword sets the grid size for kspace style
{pppm/disp}. This is the FFT mesh for long-range dispersion and ach
dimension must be factorizable into powers of 2, 3, and 5. When this
-option is not set, the PPPM solver chooses its own grid size,
+option is not set, the PPPM solver chooses its own grid size,
consistent with the user-specified accuracy and pairwise cutoff.
Values for x,y,z of 0,0,0 unset the option.
The {order} keyword determines how many grid spacings an atom's charge
extends when it is mapped to the grid in kspace style {pppm} or {msm}.
The default for this parameter is 5 for PPPM and 8 for MSM, which
means each charge spans 5 or 8 grid cells in each dimension,
respectively. For the LAMMPS implementation of MSM, the order can
range from 4 to 10 and must be even. For PPPM, the minimum allowed
setting is 2 and the maximum allowed setting is 7. The larger the
value of this parameter, the smaller that LAMMPS will set the grid
size, to achieve the requested accuracy. Conversely, the smaller the
order value, the larger the grid size will be. Note that there is an
inherent trade-off involved: a small grid will lower the cost of FFTs
or MSM direct sum, but a larger order parameter will increase the cost
of interpolating charge/fields to/from the grid.
The {order/disp} keyword determines how many grid spacings an atom's
dispersion term extends when it is mapped to the grid in kspace style
{pppm/disp}. It has the same meaning as the {order} setting for
Coulombics.
The {overlap} keyword can be used in conjunction with the {minorder}
keyword with the PPPM styles to adjust the amount of communication
that occurs when values on the FFT grid are exchangeed between
processors. This communication is distinct from the communication
inherent in the parallel FFTs themselves, and is required because
processors interpolate charge and field values using grid point values
owned by neighboring processors (i.e. ghost point communication). If
the {overlap} keyword is set to {yes} then this communication is
allowed to extend beyond nearest-neighbor processors, e.g. when using
lots of processors on a small problem. If it is set to {no} then the
communication will be limited to nearest-neighbor processors and the
{order} setting will be reduced if necessary, as explained by the
{minorder} keyword discussion. The {overlap} keyword is always set to
{yes} in MSM.
The {minorder} keyword allows LAMMPS to reduce the {order} setting if
necessary to keep the communication of ghost grid point limited to
exchanges between nearest-neighbor processors. See the discussion of
the {overlap} keyword for details. If the {overlap} keyword is set to
{yes}, which is the default, this is never needed. If it set to {no}
and overlap occurs, then LAMMPS will reduce the order setting, one
step at a time, until the ghost grid overlap only extends to nearest
neighbor processors. The {minorder} keyword limits how small the
{order} setting can become. The minimum allowed value for PPPM is 2,
which is the default. If {minorder} is set to the same value as
{order} then no reduction is allowed, and LAMMPS will generate an
error if the grid communcation is non-nearest-neighbor and {overlap}
is set to {no}. The {minorder} keyword is not currently supported in
MSM.
The PPPM order parameter may be reset by LAMMPS when it sets up the
FFT grid if the implied grid stencil extends beyond the grid cells
owned by neighboring processors. Typically this will only occur when
small problems are run on large numbers of processors. A warning will
be generated indicating the order parameter is being reduced to allow
LAMMPS to run the problem. Automatic adjustment of the order parameter
-is not supported in MSM.
+is not supported in MSM.
The {force} keyword overrides the relative accuracy parameter set by
the "kspace_style"_kspace_style.html command with an absolute
accuracy. The accuracy determines the RMS error in per-atom forces
calculated by the long-range solver and is thus specified in force
units. A negative value for the accuracy setting means to use the
relative accuracy parameter. The accuracy setting is used in
conjunction with the pairwise cutoff to determine the number of
K-space vectors for style {ewald}, the FFT grid size for style
{pppm}, or the real space grid size for style {msm}.
The {gewald} keyword sets the value of the Ewald or PPPM G-ewald
parameter for charge as {rinv} in reciprocal distance units. Without
this setting, LAMMPS chooses the parameter automatically as a function
of cutoff, precision, grid spacing, etc. This means it can vary from
one simulation to the next which may not be desirable for matching a
KSpace solver to a pre-tabulated pairwise potential. This setting can
also be useful if Ewald or PPPM fails to choose a good grid spacing
and G-ewald parameter automatically. If the value is set to 0.0,
LAMMPS will choose the G-ewald parameter automatically. MSM does not
use the {gewald} parameter.
The {gewald/disp} keyword sets the value of the Ewald or PPPM G-ewald
parameter for dispersion as {rinv} in reciprocal distance units. It
has the same meaning as the {gewald} setting for Coulombics.
The {slab} keyword allows an Ewald or PPPM solver to be used for a
systems that are periodic in x,y but non-periodic in z - a
"boundary"_boundary.html setting of "boundary p p f". This is done by
treating the system as if it were periodic in z, but inserting empty
volume between atom slabs and removing dipole inter-slab interactions
so that slab-slab interactions are effectively turned off. The
volfactor value sets the ratio of the extended dimension in z divided
by the actual dimension in z. The recommended value is 3.0. A larger
value is inefficient; a smaller value introduces unwanted slab-slab
interactions. The use of fixed boundaries in z means that the user
must prevent particle migration beyond the initial z-bounds, typically
by providing a wall-style fix. The methodology behind the {slab}
option is explained in the paper by "(Yeh)"_#Yeh. The {slab} option
is also extended to non-neutral systems "(Ballenegger)"_#Ballenegger.
An alternative slab option can be invoked with the {nozforce} keyword
in lieu of the volfactor. This turns off all kspace forces in the z
direction. The {nozforce} option is not supported by MSM. For MSM,
any combination of periodic, non-periodic, or shrink-wrapped
boundaries can be set using "boundary"_boundary.html (the slab
approximation in not needed). The {slab} keyword is not currently
supported by Ewald or PPPM when using a triclinic simulation cell. The
slab correction has also been extended to point dipole interactions
"(Klapp)"_#Klapp in "kspace_style"_kspace_style.html {ewald/disp}.
NOTE: If you wish to apply an electric field in the Z-direction, in
conjunction with the {slab} keyword, you should do it by adding
explicit charged particles to the +/- Z surfaces. If you do it via
the "fix efield"_fix_efield.html command, it will not give the correct
dielectric constant due to the Yeh/Berkowitz "(Yeh)"_#Yeh correction
not being compatible with how "fix efield"_fix_efield.html works.
The {compute} keyword allows Kspace computations to be turned off,
even though a "kspace_style"_kspace_style.html is defined. This is
not useful for running a real simulation, but can be useful for
debugging purposes or for computing only partial forces that do not
include the Kspace contribution. You can also do this by simply not
defining a "kspace_style"_kspace_style.html, but a Kspace-compatible
"pair_style"_pair_style.html requires a kspace style to be defined.
This keyword gives you that option.
The {cutoff/adjust} keyword applies only to MSM. If this option is
turned on, the Coulombic cutoff will be automatically adjusted at the
beginning of the run to give the desired estimated error. Other
cutoffs such as LJ will not be affected. If the grid is not set using
the {mesh} command, this command will also attempt to use the optimal
grid that minimizes cost using an estimate given by
"(Hardy)"_#Hardy. Note that this cost estimate is not exact, somewhat
experimental, and still may not yield the optimal parameters.
The {pressure/scalar} keyword applies only to MSM. If this option is
turned on, only the scalar pressure (i.e. (Pxx + Pyy + Pzz)/3.0) will
be computed, which can be used, for example, to run an isotropic barostat.
Computing the full pressure tensor with MSM is expensive, and this option
provides a faster alternative. The scalar pressure is computed using a
relationship between the Coulombic energy and pressure "(Hummer)"_#Hummer
instead of using the virial equation. This option cannot be used to access
individual components of the pressure tensor, to compute per-atom virial,
or with suffix kspace/pair styles of MSM, like OMP or GPU.
The {fftbench} keyword applies only to PPPM. It is on by default. If
this option is turned off, LAMMPS will not take the time at the end
of a run to give FFT benchmark timings, and will finish a few seconds
faster than it would if this option were on.
The {collective} keyword applies only to PPPM. It is set to {no} by
default, except on IBM BlueGene machines. If this option is set to
{yes}, LAMMPS will use MPI collective operations to remap data for
3d-FFT operations instead of the default point-to-point communication.
This is faster on IBM BlueGene machines, and may also be faster on
other machines if they have an efficient implementation of MPI
collective operations and adequate hardware.
The {diff} keyword specifies the differentiation scheme used by the
PPPM method to compute forces on particles given electrostatic
potentials on the PPPM mesh. The {ik} approach is the default for
PPPM and is the original formulation used in "(Hockney)"_#Hockney. It
performs differentiation in Kspace, and uses 3 FFTs to transfer each
component of the computed fields back to real space for total of 4
FFTs per timestep.
The analytic differentiation {ad} approach uses only 1 FFT to transfer
information back to real space for a total of 2 FFTs per timestep. It
then performs analytic differentiation on the single quantity to
generate the 3 components of the electric field at each grid point.
This is sometimes referred to as "smoothed" PPPM. This approach
requires a somewhat larger PPPM mesh to achieve the same accuracy as
-the {ik} method. Currently, only the {ik} method (default) can be
-used for a triclinic simulation cell with PPPM. The {ad} method is
+the {ik} method. Currently, only the {ik} method (default) can be
+used for a triclinic simulation cell with PPPM. The {ad} method is
always used for MSM.
NOTE: Currently, not all PPPM styles support the {ad} option. Support
for those PPPM variants will be added later.
The {kmax/ewald} keyword sets the number of kspace vectors in each
dimension for kspace style {ewald}. The three values must be positive
integers, or else (0,0,0), which unsets the option. When this option
is not set, the Ewald sum scheme chooses its own kspace vectors,
consistent with the user-specified accuracy and pairwise cutoff. In
any case, if kspace style {ewald} is invoked, the values used are
printed to the screen and the log file at the start of the run.
With the {mix/disp} keyword one can select the mixing rule for the
dispersion coefficients. With {pair}, the dispersion coefficients of
unlike types are computed as indicated with
"pair_modify"_pair_modify.html. With {geom}, geometric mixing is
enforced on the dispersion coefficients in the kspace
coefficients. When using the arithmetic mixing rule, this will
speed-up the simulations but introduces some error in the force
computations, as shown in "(Wennberg)"_#Wennberg. With {none}, it is
assumed that no mixing rule is applicable. Splitting of the dispersion
coefficients will be performed as described in
"(Isele-Holder)"_#Isele-Holder. This splitting can be influenced with
the {splittol} keywords. Only the eigenvalues that are larger than tol
compared to the largest eigenvalues are included. Using this keywords
the original matrix of dispersion coefficients is approximated. This
leads to faster computations, but the accuracy in the reciprocal space
computations of the dispersion part is decreased.
The {force/disp/real} and {force/disp/kspace} keywords set the force
accuracy for the real and space computations for the dispersion part
of pppm/disp. As shown in "(Isele-Holder)"_#Isele-Holder, optimal
performance and accuracy in the results is obtained when these values
are different.
The {disp/auto} option controlls whether the pppm/disp is allowed to
generate PPPM parameters automatically. If set to {no}, parameters have
to be specified using the {gewald/disp}, {mesh/disp},
{force/disp/real} or {force/disp/kspace} keywords, or
the code will stop with an error message. When this option is set to
{yes}, the error message will not appear and the simulation will start.
For a typical application, using the automatic parameter generation will provide
simulations that are either inaccurate or slow. Using this option is thus not
recommended. For guidelines on how to obtain good parameters, see the "How-To"_Section_howto.html#howto_23 discussion.
style = {none} or {ewald} or {ewald/disp} or {ewald/omp} or {pppm} or {pppm/cg} or {pppm/disp} or {pppm/tip4p} or {pppm/stagger} or {pppm/disp/tip4p} or {pppm/gpu} or {pppm/kk} or {pppm/omp} or {pppm/cg/omp} or {pppm/tip4p/omp} or {msm} or {msm/cg} or {msm/omp} or {msm/cg/omp} :ulb,l
{none} value = none
{ewald} value = accuracy
accuracy = desired relative error in forces
{ewald/disp} value = accuracy
accuracy = desired relative error in forces
{ewald/omp} value = accuracy
accuracy = desired relative error in forces
{pppm} value = accuracy
accuracy = desired relative error in forces
{pppm/cg} value = accuracy (smallq)
accuracy = desired relative error in forces
smallq = cutoff for charges to be considered (optional) (charge units)
{pppm/disp} value = accuracy
accuracy = desired relative error in forces
{pppm/tip4p} value = accuracy
accuracy = desired relative error in forces
{pppm/disp/tip4p} value = accuracy
accuracy = desired relative error in forces
{pppm/gpu} value = accuracy
accuracy = desired relative error in forces
{pppm/kk} value = accuracy
accuracy = desired relative error in forces
{pppm/omp} value = accuracy
accuracy = desired relative error in forces
{pppm/cg/omp} value = accuracy
accuracy = desired relative error in forces
{pppm/tip4p/omp} value = accuracy
accuracy = desired relative error in forces
{pppm/stagger} value = accuracy
accuracy = desired relative error in forces
{msm} value = accuracy
accuracy = desired relative error in forces
{msm/cg} value = accuracy (smallq)
accuracy = desired relative error in forces
smallq = cutoff for charges to be considered (optional) (charge units)
{msm/omp} value = accuracy
accuracy = desired relative error in forces
{msm/cg/omp} value = accuracy (smallq)
accuracy = desired relative error in forces
smallq = cutoff for charges to be considered (optional) (charge units) :pre
:ule
[Examples:]
kspace_style pppm 1.0e-4
kspace_style pppm/cg 1.0e-5 1.0e-6
kspace style msm 1.0e-4
kspace_style none :pre
[Description:]
Define a long-range solver for LAMMPS to use each timestep to compute
long-range Coulombic interactions or long-range 1/r^6 interactions.
Most of the long-range solvers perform their computation in K-space,
hence the name of this command.
When such a solver is used in conjunction with an appropriate pair
style, the cutoff for Coulombic or 1/r^N interactions is effectively
infinite. If the Coulombic case, this means each charge in the system
interacts with charges in an infinite array of periodic images of the
simulation domain.
Note that using a long-range solver requires use of a matching "pair
style"_pair_style.html to perform consistent short-range pairwise
calculations. This means that the name of the pair style contains a
matching keyword to the name of the KSpace style, as in this table:
-Pair style : KSpace style
+Pair style : KSpace style
coul/long : ewald or pppm
coul/msm : msm
lj/long or buck/long : disp (for dispersion)
tip4p/long : tip4p :tb(s=:,ea=c)
:line
The {ewald} style performs a standard Ewald summation as described in
any solid-state physics text.
The {ewald/disp} style adds a long-range dispersion sum option for
1/r^6 potentials and is useful for simulation of interfaces
"(Veld)"_#Veld. It also performs standard Coulombic Ewald summations,
but in a more efficient manner than the {ewald} style. The 1/r^6
capability means that Lennard-Jones or Buckingham potentials can be
used without a cutoff, i.e. they become full long-range potentials.
The {ewald/disp} style can also be used with point-dipoles
"(Toukmaji)"_#Toukmaji and is currently the only kspace solver in
LAMMPS with this capability.
:line
The {pppm} style invokes a particle-particle particle-mesh solver
"(Hockney)"_#Hockney which maps atom charge to a 3d mesh, uses 3d FFTs
to solve Poisson's equation on the mesh, then interpolates electric
fields on the mesh points back to the atoms. It is closely related to
the particle-mesh Ewald technique (PME) "(Darden)"_#Darden used in
AMBER and CHARMM. The cost of traditional Ewald summation scales as
N^(3/2) where N is the number of atoms in the system. The PPPM solver
scales as Nlog(N) due to the FFTs, so it is almost always a faster
choice "(Pollock)"_#Pollock.
The {pppm/cg} style is identical to the {pppm} style except that it
has an optimization for systems where most particles are uncharged.
Similarly the {msm/cg} style implements the same optimization for {msm}.
The optional {smallq} argument defines the cutoff for the absolute
charge value which determines whether a particle is considered charged
or not. Its default value is 1.0e-5.
The {pppm/tip4p} style is identical to the {pppm} style except that it
adds a charge at the massless 4th site in each TIP4P water molecule.
It should be used with "pair styles"_pair_style.html with a
{tip4p/long} in their style name.
The {pppm/stagger} style 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
for a given mesh size. Or a coarser mesh can be used for the same
target accuracy, which saves CPU time. However, there is a trade-off
since FFTs on two meshes are now performed which increases the
compuation required. See "(Cerutti)"_#Cerutti, "(Neelov)"_#Neelov,
and "(Hockney)"_#Hockney for details of the method.
For high relative accuracy, using staggered PPPM allows the mesh size
to be reduced by a factor of 2 in each dimension as compared to
regular PPPM (for the same target accuracy). This can give up to a 4x
speedup in the KSpace time (8x less mesh points, 2x more expensive).
However, for low relative accuracy, the staggered PPPM mesh size may
be essentially the same as for regular PPPM, which means the method
will be up to 2x slower in the KSpace time (simply 2x more expensive).
For more details and timings, see
"Section 5"_Section_accelerate.html.
NOTE: Using {pppm/stagger} may not give the same increase in the
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
The {pppm/disp} and {pppm/disp/tip4p} styles add a mesh-based long-range
dispersion sum option for 1/r^6 potentials "(Isele-Holder)"_#Isele-Holder,
similar to the {ewald/disp} style. The 1/r^6 capability means
that Lennard-Jones or Buckingham potentials can be used without a cutoff,
i.e. they become full long-range potentials.
For these styles, you will possibly want to adjust the default choice of
parameters by using the "kspace_modify"_kspace_modify.html command.
This can be done by either choosing the Ewald and grid parameters, or
by specifying separate accuracies for the real and kspace
calculations. When not making any settings, the simulation will stop with
an error message. Further information on the influence of the parameters
and how to choose them is described in "(Isele-Holder)"_#Isele-Holder,
"(Isele-Holder2)"_#Isele-Holder2 and the
"How-To"_Section_howto.html#howto_24 discussion.
:line
NOTE: All of the PPPM styles can be used with single-precision FFTs by
using the compiler switch -DFFT_SINGLE for the FFT_INC setting in your
lo-level Makefile. This setting also changes some of the PPPM
operations (e.g. mapping charge to mesh and interpolating electric
fields to particles) to be performed in single precision. This option
can speed-up long-range calulations, particularly in parallel or on
GPUs. The use of the -DFFT_SINGLE flag is discussed in "this
section"_Section_start.html#start_2_4 of the manual. MSM does not
currently support the -DFFT_SINGLE compiler switch.
:line
The {msm} style invokes a multi-level summation method MSM solver,
"(Hardy)"_#Hardy or "(Hardy2)"_#Hardy2, which maps atom charge to a 3d
mesh, and uses a multi-level hierarchy of coarser and coarser meshes
on which direct coulomb solves are done. This method does not use
FFTs and scales as N. It may therefore be faster than the other
K-space solvers for relatively large problems when running on large
-core counts. MSM can also be used for non-periodic boundary conditions and
+core counts. MSM can also be used for non-periodic boundary conditions and
for mixed periodic and non-periodic boundaries.
-MSM is most competitive versus Ewald and PPPM when only relatively
-low accuracy forces, about 1e-4 relative error or less accurate,
-are needed. Note that use of a larger coulomb cutoff (i.e. 15
-angstroms instead of 10 angstroms) provides better MSM accuracy for
+MSM is most competitive versus Ewald and PPPM when only relatively
+low accuracy forces, about 1e-4 relative error or less accurate,
+are needed. Note that use of a larger coulomb cutoff (i.e. 15
+angstroms instead of 10 angstroms) provides better MSM accuracy for
both the real space and grid computed forces.
Currently calculation of the full pressure tensor in MSM is expensive.
Using the "kspace_modify"_kspace_modify.html {pressure/scalar yes}
command provides a less expensive way to compute the scalar pressure
(Pxx + Pyy + Pzz)/3.0. The scalar pressure can be used, for example,
to run an isotropic barostat. If the full pressure tensor is needed,
then calculating the pressure at every timestep or using a fixed
pressure simulation with MSM will cause the code to run slower.
:line
The specified {accuracy} determines the relative RMS error in per-atom
forces calculated by the long-range solver. It is set as a
dimensionless number, relative to the force that two unit point
charges (e.g. 2 monovalent ions) exert on each other at a distance of
1 Angstrom. This reference value was chosen as representative of the
magnitude of electrostatic forces in atomic systems. Thus an accuracy
value of 1.0e-4 means that the RMS error will be a factor of 10000
smaller than the reference force.
The accuracy setting is used in conjunction with the pairwise cutoff
to determine the number of K-space vectors for style {ewald} or the
-grid size for style {pppm} or {msm}.
+grid size for style {pppm} or {msm}.
Note that style {pppm} only computes the grid size at the beginning of
a simulation, so if the length or triclinic tilt of the simulation
cell increases dramatically during the course of the simulation, the
accuracy of the simulation may degrade. Likewise, if the
"kspace_modify slab"_kspace_modify.html option is used with
shrink-wrap boundaries in the z-dimension, and the box size changes
dramatically in z. For example, for a triclinic system with all three
tilt factors set to the maximum limit, the PPPM grid should be
increased roughly by a factor of 1.5 in the y direction and 2.0 in the
z direction as compared to the same system using a cubic orthogonal
simulation cell. One way to ensure the accuracy requirement is being
met is to run a short simulation at the maximum expected tilt or
length, note the required grid size, and then use the
"kspace_modify"_kspace_modify.html {mesh} command to manually set the
PPPM grid size to this value.
RMS force errors in real space for {ewald} and {pppm} are estimated
using equation 18 of "(Kolafa)"_#Kolafa, which is also referenced as
equation 9 of "(Petersen)"_#Petersen. RMS force errors in K-space for
{ewald} are estimated using equation 11 of "(Petersen)"_#Petersen,
which is similar to equation 32 of "(Kolafa)"_#Kolafa. RMS force
errors in K-space for {pppm} are estimated using equation 38 of
-"(Deserno)"_#Deserno. RMS force errors for {msm} are estimated
+"(Deserno)"_#Deserno. RMS force errors for {msm} are estimated
using ideas from chapter 3 of "(Hardy)"_#Hardy, with equation 3.197
-of particular note. When using {msm} with non-periodic boundary
+of particular note. When using {msm} with non-periodic boundary
conditions, it is expected that the error estimation will be too
pessimistic. RMS force errors for dipoles when using {ewald/disp}
are estimated using equations 33 and 46 of "(Wang)"_#Wang.
See the "kspace_modify"_kspace_modify.html command for additional
options of the K-space solvers that can be set, including a {force}
option for setting an absoulte RMS error in forces, as opposed to a
relative RMS error.
: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.
More specifically, the {pppm/gpu} style performs charge assignment and
force interpolation calculations on the GPU. These processes are
performed either in single or double precision, depending on whether
the -DFFT_SINGLE setting was specified in your lo-level Makefile, as
discussed above. The FFTs themselves are still calculated on the CPU.
If {pppm/gpu} is used with a GPU-enabled pair style, part of the PPPM
calculation can be performed concurrently on the GPU while other
calculations for non-bonded and bonded force calculation are performed
on the CPU.
The {pppm/kk} style also performs charge assignment and force
interpolation calculations on the GPU while the FFTs themselves are
calculated on the CPU in non-threaded mode.
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.
See "Section 5"_Section_accelerate.html of the manual for
more instructions on how to use the accelerated styles effectively.
[Restrictions:]
Note that the long-range electrostatic solvers in LAMMPS assume conducting
metal (tinfoil) boundary conditions for both charge and dipole
interactions. Vacuum boundary conditions are not currently supported.
The {ewald/disp}, {ewald}, {pppm}, and {msm} styles support
non-orthogonal (triclinic symmetry) simulation boxes. However,
triclinic simulation cells may not yet be supported by suffix versions
of these styles.
All of the kspace 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.
-For MSM, a simulation must be 3d and one can use any combination of
-periodic, non-periodic, or shrink-wrapped boundaries (specified using
-the "boundary"_boundary.html command).
+For MSM, a simulation must be 3d and one can use any combination of
+periodic, non-periodic, or shrink-wrapped boundaries (specified using
+the "boundary"_boundary.html command).
For Ewald and PPPM, a simulation must be 3d and periodic in all
dimensions. The only exception is if the slab option is set with
"kspace_modify"_kspace_modify.html, in which case the xy dimensions
must be periodic and the z dimension must be non-periodic.
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)
This pair stylecomputes a variable charge SMTB-Q (Second-Moment
tight-Binding QEq) potential as described in "SMTB-Q_1"_#SMTB-Q_1 and
"SMTB-Q_2"_#SMTB-Q_2. Briefly, the energy of metallic-oxygen systems
is given by three contributions:
:c,image(Eqs/pair_smtbq1.jpg)
where {E<sub>tot</sub>} is the total potential energy of the system,
{E<sub>ES</sub>} is the electrostatic part of the total energy,
{E<sub>OO</sub>} is the interaction between oxygens and
{E<sub>MO</sub>} is a short-range interaction between metal and oxygen
atoms. This interactions depend on interatomic distance
{r<sub>ij</sub>} and/or the charge {Q<sub>i</sub>} of atoms
{i}. Cut-off function enables smooth convergence to zero interaction.
The parameters appearing in the upper expressions are set in the
ffield.SMTBQ.Syst file where Syst corresponds to the selected system
(e.g. field.SMTBQ.Al2O3). Exemples for TiO<sub>2</sub>,
Al<sub>2</sub>O<sub>3</sub> are provided. A single pair_coeff command
is used with the SMTBQ styles which provides the path to the potential
file with parameters for needed elements. These are mapped to LAMMPS
atom types by specifying additional arguments after the potential
filename in the pair_coeff command. Note that atom type 1 must always
correspond to oxygen atoms. As an example, to simulate a TiO2 system,
atom type 1 has to be oxygen and atom type 2 Ti. The following
-pair_coeff command should then be used:
+pair_coeff command should then be used:
pair_coeff * * PathToLammps/potentials/ffield.smtbq.TiO2 O Ti :pre
The electrostatic part of the energy consists of two components :
self-energy of atom {i} in the form of a second order charge dependent
polynomial and a long-range Coulombic electrostatic interaction. The
latter uses the wolf summation method described in "Wolf"_#Wolf,
spherically truncated at a longer cutoff, {R<sub>coul</sub>}. The
charge of each ion is modeled by an orbital Slater which depends on
the principal quantum number ({n}) of the outer orbital shared by the
ion.
Interaction between oxygen, {E<sub>OO</sub>}, consists of two parts,
an attractive and a repulsive part. The attractive part is effective
only at short range (< r<sub>2</sub><sup>OO</sup>). The attractive
contribution was optimized to study surfaces reconstruction
(e.g. "SMTB-Q_2"_#SMTB-Q_2 in TiO<sub>2</sub>) and is not necessary
for oxide bulk modeling. The repulsive part is the Pauli interaction
between the electron clouds of oxygen. The Pauli repulsion and the
coulombic electrostatic interaction have same cut off value. In the
ffield.SMTBQ.Syst, the keyword {'buck'} allows to consider only the
repulsive O-O interactions. The keyword {'buckPlusAttr'} allows to
consider the repulsive and the attractive O-O interactions.
The short-range interaction between metal-oxygen, {E<sub>MO</sub>} is
based on the second moment approximation of the density of states with
a N-body potential for the band energy term,
{E<sup>i</sup><sub>cov</sub>}, and a Born-Mayer type repulsive terms
as indicated by the keyword {'second_moment'} in the
ffield.SMTBQ.Syst. The energy band term is given by:
:c,image(Eqs/pair_smtbq2.jpg)
where {η<sub>i</sub>} is the stoichiometry of atom {i},
{δQ<sub>i</sub>} is the charge delocalization of atom {i},
compared to its formal charge
{Q<sup>F</sup><sub>i</sub>}. n<sub>0</sub>, the number of hybridized
orbitals, is calculated with to the atomic orbitals shared
{d<sub>i</sub>} and the stoichiometry
{η<sub>i</sub>}. {r<sub>c1</sub>} and {r<sub>c2</sub>} are the two
cutoff radius around the fourth neighbors in the cutoff function.
In the formalism used here, {ξ<sup>0</sup>} is the energy
parameter. {ξ<sup>0</sup>} is in tight-binding approximation the
hopping integral between the hybridized orbitals of the cation and the
anion. In the literature we find many ways to write the hopping
integral depending on whether one takes the point of view of the anion
or cation. These are equivalent vision. The correspondence between the
two visions is explained in appendix A of the article in the
SrTiO<sub>3</sub> "SMTB-Q_3"_#SMTB-Q_3 (parameter {β} shown in
this article is in fact the {β<sub>O</sub>}). To summarize the
relationship between the hopping integral {ξ<sup>0</sup>} and the
others, we have in an oxide C<sub>n</sub>O<sub>m</sub> the following
relationship:
:c,image(Eqs/pair_smtbq3.jpg)
Thus parameter μ, indicated above, is given by : μ = (√n
+ √m) ⁄ 2
The potential offers the possibility to consider the polarizability of
the electron clouds of oxygen by changing the slater radius of the
charge density around the oxygens through the parameters {rBB, rB and
rS} in the ffield.SMTBQ.Syst. This change in radius is performed
according to the method developed by E. Maras
"SMTB-Q_2"_#SMTB-Q_2. This method needs to determine the number of
nearest neighbors around the oxygen. This calculation is based on
first ({r<sub>1n</sub>}) and second ({r<sub>2n</sub>}) distances
neighbors.
The SMTB-Q potential is a variable charge potential. The equilibrium
charge on each atom is calculated by the electronegativity
equalization (QEq) method. See "Rick"_#Rick for further detail. One
can adjust the frequency, the maximum number of iterative loop and the
convergence of the equilibrium charge calculation. To obtain the
energy conservation in NVE thermodynamic ensemble, we recommend to use
a convergence parameter in the interval 10<sup>-5</sup> -
10<sup>-6</sup> eV.
The ffield.SMTBQ.Syst files are provided for few systems. They consist
of nine parts and the lines beginning with '#' are comments (note that
the number of comment lines matter). The first sections are on the
potential parameters and others are on the simulation options and
might be modified. Keywords are character type and must be enclosed in
quotation marks ('').
1) Number of different element in the oxide:
N<sub>elem</sub>= 2 or 3
Divided line :ul
2) Atomic parameters
For the anion (oxygen) :
Name of element (char) and stoichiometry in oxide
-Formal charge and mass of element
-Principal quantic number of outer orbital ({n}), electronegativity ({χ<sup>0</sup><sub>i</simulationub>}) and hardness ({J<sup>0</sup><sub>i</sub>})
+Formal charge and mass of element
+Principal quantic number of outer orbital ({n}), electronegativity ({χ<sup>0</sup><sub>i</simulationub>}) and hardness ({J<sup>0</sup><sub>i</sub>})
Ionic radius parameters : max coordination number ({coordBB} = 6 by default), bulk coordination number {(coordB)}, surface coordination number {(coordS)} and {rBB, rB and rS} the slater radius for each coordination number. (<b>note : If you don't want to change the slater radius, use three identical radius values</b>)
Number of orbital shared by the element in the oxide ({d<sub>i</sub>})
Divided line :ul
For each cations (metal):
Name of element (char) and stoichiometry in oxide
-Formal charge and mass of element
+Formal charge and mass of element
Number of electron in outer orbital {(ne)}, electronegativity ({χ<sup>0</sup><sub>i</simulationub>}), hardness ({J<sup>0</sup><sub>i</sub>}) and {r<sub>Salter</sub>} the slater radius for the cation.
Number of orbitals shared by the elements in the oxide ({d<sub>i</sub>})
Divided line :ul
3) Potential parameters:
-Keyword for element1, element2 and interaction potential ('second_moment' or 'buck' or 'buckPlusAttr') between element 1 and 2. If the potential is 'second_moment', specify 'oxide' or 'metal' for metal-oxygen or metal-metal interactions respectively.
+Keyword for element1, element2 and interaction potential ('second_moment' or 'buck' or 'buckPlusAttr') between element 1 and 2. If the potential is 'second_moment', specify 'oxide' or 'metal' for metal-oxygen or metal-metal interactions respectively.
Potential parameter: <pre><br/> If type of potential is 'second_moment' : {A (eV)}, {p}, {ξ<sup>0</sup>} (eV) and {q} <br/> {r<sub>c1</sub>} (Å), {r<sub>c2</sub>} (Å) and {r<sub>0</sub>} (Å) <br/> If type of potential is 'buck' : {C} (eV) and {ρ} (Å) <br/> If type of potential is 'buckPlusAttr' : {C} (eV) and {ρ} (Å) <br/> {D} (eV), {B} (Å<sup>-1</sup>), {r<sub>1</sub><sup>OO</sup>} (Å) and {r<sub>2</sub><sup>OO</sup>} (Å) </pre>
Divided line :ul
4) Tables parameters:
-Cutoff radius for the Coulomb interaction ({R<sub>coul</sub>})
+Cutoff radius for the Coulomb interaction ({R<sub>coul</sub>})
Starting radius ({r<sub>min</sub>} = 1,18845 Å) and increments ({dr} = 0,001 Å) for creating the potential table.
Divided line :ul
-5) Rick model parameter:
+5) Rick model parameter:
{Nevery} : parameter to set the frequency ({1/Nevery}) of the charge resolution. The charges are evaluated each {Nevery} time steps.
-Max number of iterative loop ({loopmax}) and precision criterion ({prec}) in eV of the charge resolution
+Max number of iterative loop ({loopmax}) and precision criterion ({prec}) in eV of the charge resolution
Divided line :ul
6) Coordination parameter:
First ({r<sub>1n</sub>}) and second ({r<sub>2n</sub>}) neighbor distances in Å
Divided line :ul
7) Charge initialization mode:
-Keyword ({QInitMode}) and initial oxygen charge ({Q<sub>init</sub>}). If keyword = 'true', all oxygen charges are initially set equal to {Q<sub>init</sub>}. The charges on the cations are initially set in order to respect the neutrality of the box. If keyword = 'false', all atom charges are initially set equal to 0 if you use "create_atom"#create_atom command or the charge specified in the file structure using "read_data"_read_data.html command.
-Divided line :ul
+Keyword ({QInitMode}) and initial oxygen charge ({Q<sub>init</sub>}). If keyword = 'true', all oxygen charges are initially set equal to {Q<sub>init</sub>}. The charges on the cations are initially set in order to respect the neutrality of the box. If keyword = 'false', all atom charges are initially set equal to 0 if you use "create_atom"#create_atom command or the charge specified in the file structure using "read_data"_read_data.html command.
+Divided line :ul
8) Mode for the electronegativity equalization (Qeq) :
Keyword mode: <pre> <br/> QEqAll (one QEq group) | no parameters <br/> QEqAllParallel (several QEq groups) | no parameters <br/> Surface | zlim (QEq only for z>zlim) </pre>
-Parameter if necessary
+Parameter if necessary
Divided line :ul
9) Verbose :
If you want the code to work in verbose mode or not : 'true' or 'false'
-If you want to print or not in file 'Energy_component.txt' the three main contributions to the energy of the system according to the description presented above : 'true' or 'false' and {N<sub>Energy</sub>}. This option writes in file every {N<sub>Energy</sub>} time step. If the value is 'false' then {N<sub>Energy</sub>} = 0. The file take into account the possibility to have several QEq group {g} then it writes: time step, number of atoms in group {g}, electrostatic part of energy, {E<sub>ES</sub>}, the interaction between oxygen, {E<sub>OO</sub>}, and short range metal-oxygen interaction, {E<sub>MO</sub>}.
+If you want to print or not in file 'Energy_component.txt' the three main contributions to the energy of the system according to the description presented above : 'true' or 'false' and {N<sub>Energy</sub>}. This option writes in file every {N<sub>Energy</sub>} time step. If the value is 'false' then {N<sub>Energy</sub>} = 0. The file take into account the possibility to have several QEq group {g} then it writes: time step, number of atoms in group {g}, electrostatic part of energy, {E<sub>ES</sub>}, the interaction between oxygen, {E<sub>OO</sub>}, and short range metal-oxygen interaction, {E<sub>MO</sub>}.
If you want to print in file 'Electroneg_component.txt' the electronegativity component ({∂E<sub>tot</sub> ⁄∂Q<sub>i</sub>}) or not: 'true' or 'false' and {N<sub>Electroneg</sub>}.This option writes in file every {N<sub>Electroneg</sub>} time step. If the value is 'false' then {N<sub>Electroneg</sub>} = 0. The file consist in atom number {i}, atom type (1 for oxygen and # higher than 1 for metal), atom position: {x}, {y} and {z}, atomic charge of atom {i}, electrostatic part of atom {i} electronegativity, covalent part of atom {i} electronegativity, the hopping integral of atom {i} {(Zβ<sup>2</sup>)<sub>i<sub>} and box electronegativity. :ul
NOTE: This last option slows down the calculation dramatically. Use
style = {atom} or {type} or {mol} or {group} or {region} :ulb,l
ID = atom ID range or type range or mol ID range or group ID or region ID :l
one or more keyword/value pairs may be appended :l
keyword = {type} or {type/fraction} or {mol} or {x} or {y} or {z} or \
{charge} or {dipole} or {dipole/random} or {quat} or \
{quat/random} or {diameter} or {shape} or \
{length} or {tri} or {theta} or {theta/random} or \
{angmom} or {omega} or \
{mass} or {density} or {volume} or {image} or \
{bond} or {angle} or {dihedral} or {improper} or \
{meso/e} or {meso/cv} or {meso/rho} or \
{smd/contact/radius} or {smd/mass/density} or {dpd/theta} or \
{i_name} or {d_name} :l
{type} value = atom type
value can be an atom-style variable (see below)
{type/fraction} values = type fraction seed
type = new atom type
fraction = fraction of selected atoms to set to new atom type
seed = random # seed (positive integer)
{mol} value = molecule ID
value can be an atom-style variable (see below)
{x},{y},{z} value = atom coordinate (distance units)
value can be an atom-style variable (see below)
{charge} value = atomic charge (charge units)
value can be an atom-style variable (see below)
{dipole} values = x y z
x,y,z = orientation of dipole moment vector
any of x,y,z can be an atom-style variable (see below)
{dipole/random} value = seed Dlen
seed = random # seed (positive integer) for dipole moment orientations
Dlen = magnitude of dipole moment (dipole units)
{quat} values = a b c theta
a,b,c = unit vector to rotate particle around via right-hand rule
theta = rotation angle (degrees)
any of a,b,c,theta can be an atom-style variable (see below)
{quat/random} value = seed
seed = random # seed (positive integer) for quaternion orientations
{diameter} value = diameter of spherical particle (distance units)
value can be an atom-style variable (see below)
{shape} value = Sx Sy Sz
Sx,Sy,Sz = 3 diameters of ellipsoid (distance units)
{length} value = len
len = length of line segment (distance units)
len can be an atom-style variable (see below)
{tri} value = side
side = side length of equilateral triangle (distance units)
side can be an atom-style variable (see below)
{theta} value = angle (degrees)
angle = orientation of line segment with respect to x-axis
angle can be an atom-style variable (see below)
{theta/random} value = seed
seed = random # seed (positive integer) for line segment orienations
{angmom} values = Lx Ly Lz
Lx,Ly,Lz = components of angular momentum vector (distance-mass-velocity units)
any of Lx,Ly,Lz can be an atom-style variable (see below)
{omega} values = Wx Wy Wz
Wx,Wy,Wz = components of angular velocity vector (radians/time units)
any of wx,wy,wz can be an atom-style variable (see below)
{mass} value = per-atom mass (mass units)
value can be an atom-style variable (see below)
{density} value = particle density for sphere or ellipsoid (mass/distance^3 or mass/distance^2 or mass/distance units, depending on dimensionality of particle)
value can be an atom-style variable (see below)
{volume} value = particle volume for Peridynamic particle (distance^3 units)
value can be an atom-style variable (see below)
{image} nx ny nz
nx,ny,nz = which periodic image of the simulation box the atom is in
{bond} value = bond type for all bonds between selected atoms
{angle} value = angle type for all angles between selected atoms
{dihedral} value = dihedral type for all dihedrals between selected atoms
{improper} value = improper type for all impropers between selected atoms
{meso/e} value = energy of SPH particles (need units)
value can be an atom-style variable (see below)
{meso/cv} value = heat capacity of SPH particles (need units)
value can be an atom-style variable (see below)
{meso/rho} value = density of SPH particles (need units)
value can be an atom-style variable (see below)
{smd/contact/radius} = radius for short range interactions, i.e. contact and friction
- value can be an atom-style variable (see below)
+ value can be an atom-style variable (see below)
{smd/mass/density} = set particle mass based on volume by providing a mass density
value can be an atom-style variable (see below)
{dpd/theta} value = internal temperature of DPD particles (temperature units)
value can be an atom-style variable (see below)
value can be NULL which sets internal temp of each particle to KE temp
{i_name} value = value for custom integer vector with name
{d_name} value = value for custom floating-point vector with name :pre
:ule
[Examples:]
set group solvent type 2
set group solvent type/fraction 2 0.5 12393
set group edge bond 4
set region half charge 0.5
set type 3 charge 0.5
set type 1*3 charge 0.5
set atom * charge v_atomfile
set atom 100*200 x 0.5 y 1.0
set atom 1492 type 3 :pre
[Description:]
Set one or more properties of one or more atoms. Since atom
properties are initially assigned by the "read_data"_read_data.html,
"read_restart"_read_restart.html or "create_atoms"_create_atoms.html
commands, this command changes those assignments. This can be useful
for overriding the default values assigned by the
"create_atoms"_create_atoms.html command (e.g. charge = 0.0). It can
be useful for altering pairwise and molecular force interactions,
since force-field coefficients are defined in terms of types. It can
be used to change the labeling of atoms by atom type or molecule ID
when they are output in "dump"_dump.html files. It can also be useful
for debugging purposes; i.e. positioning an atom at a precise location
to compute subsequent forces or energy.
Note that the {style} and {ID} arguments determine which atoms have
their properties reset. The remaining keywords specify which
properties to reset and what the new values are. Some strings like
{type} or {mol} can be used as a style and/or a keyword.
:line
This section describes how to select which atoms to change
the properties of, via the {style} and {ID} arguments.
The style {atom} selects all the atoms in a range of atom IDs. The
style {type} selects all the atoms in a range of types. The style
{mol} selects all the atoms in a range of molecule IDs.
In each of the range cases, the range can be specified as a single
numeric value, or a wildcard asterisk can be used to specify a range
of values. This takes the form "*" or "*n" or "n*" or "m*n". For
example, for the style {type}, if N = the number of atom types, then
an asterisk with no numeric values means all types from 1 to N. A
leading asterisk means all types from 1 to n (inclusive). A trailing
asterisk means all types from n to N (inclusive). A middle asterisk
means all types from m to n (inclusive). For all the styles except
{mol}, the lowest value for the wildcard is 1; for {mol} it is 0.
The style {group} selects all the atoms in the specified group. The
style {region} selects all the atoms in the specified geometric
region. See the "group"_group.html and "region"_region.html commands
for details of how to specify a group or region.
:line
This section describes the keyword options for which properties to
change, for the selected atoms.
Note that except where explicitly prohibited below, all of the
keywords allow an "atom-style or atomfile-style
variable"_variable.html to be used as the specified value(s). 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, and
its resulting per-atom value used to determine the value assigned to
each selected atom. Note that the per-atom value from the variable
will be ignored for atoms that are not selected via the {style} and
{ID} settings explained above. A simple way to use per-atom values
from the variable to reset a property for all atoms is to use style
{atom} with {ID} = "*"; this selects all atom IDs.
Atom-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. They can also include per-atom values, such as atom
coordinates. Thus it is easy to specify a time-dependent or
spatially-dependent set of per-atom values. As explained on the
"variable"_variable.html doc page, atomfile-style variables can be
used in place of atom-style variables, and thus as arguments to the
set command. Atomfile-style variables read their per-atoms values
from a file.
NOTE: Atom-style and atomfile-style variables return floating point
per-atom values. If the values are assigned to an integer variable,
such as the molecule ID, then the floating point value is truncated to
its integer portion, e.g. a value of 2.6 would become 2.
Keyword {type} sets the atom type for all selected atoms. The
specified value must be from 1 to ntypes, where ntypes was set by the
"create_box"_create_box.html command or the {atom types} field in the
header of the data file read by the "read_data"_read_data.html
command.
Keyword {type/fraction} sets the atom type for a fraction of the
selected atoms. The actual number of atoms changed is not guaranteed
to be exactly the requested fraction, but should be statistically
close. Random numbers are used in such a way that a particular atom
is changed or not changed, regardless of how many processors are being
used. This keyword does not allow use of an atom-style variable.
Keyword {mol} sets the molecule ID for all selected atoms. The "atom
style"_atom_style.html being used must support the use of molecule
IDs.
Keywords {x}, {y}, {z}, and {charge} set the coordinates or charge of
all selected atoms. For {charge}, the "atom style"_atom_style.html
being used must support the use of atomic charge.
Keyword {dipole} uses the specified x,y,z values as components of a
vector to set as the orientation of the dipole moment vectors of the
selected atoms. The magnitude of the dipole moment is set
by the length of this orientation vector.
Keyword {dipole/random} randomizes the orientation of the dipole
moment vectors for the selected atoms and sets the magnitude of each
to the specified {Dlen} value. For 2d systems, the z component of the
orientation is set to 0.0. Random numbers are used in such a way that
the orientation of a particular atom is the same, regardless of how
many processors are being used. This keyword does not allow use of an
atom-style variable.
Keyword {quat} uses the specified values to create a quaternion
(4-vector) that represents the orientation of the selected atoms. The
particles must define a quaternion for their orientation
(e.g. ellipsoids, triangles, body particles) as defined by the
"atom_style"_atom_style.html command. Note that particles defined by
"atom_style ellipsoid"_atom_style.html have 3 shape parameters. The 3
values must be non-zero for each particle set by this command. They
are used to 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 rotation 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)). The theta and a,b,c values are the arguments to the
{quat} keyword. LAMMPS normalizes the quaternion in case (a,b,c) was
not specified as a unit vector. For 2d systems, the a,b,c values are
ignored, since a rotation vector of (0,0,1) is the only valid choice.
Keyword {quat/random} randomizes the orientation of the quaternion for
the selected atoms. The particles must define a quaternion for their
orientation (e.g. ellipsoids, triangles, body particles) as defined by
the "atom_style"_atom_style.html command. Random numbers are used in
such a way that the orientation of a particular atom is the same,
regardless of how many processors are being used. For 2d systems,
only orientations in the xy plane are generated. As with keyword
{quat}, for ellipsoidal particles, the 3 shape values must be non-zero
for each particle set by this command. This keyword does not allow
use of an atom-style variable.
Keyword {diameter} sets the size of the selected atoms. The particles
must be finite-size spheres as defined by the "atom_style
sphere"_atom_style.html command. The diameter of a particle can be
set to 0.0, which means they will be treated as point particles. Note
that this command does not adjust the particle mass, even if it was
defined with a density, e.g. via the "read_data"_read_data.html
command.
Keyword {shape} sets the size and shape of the selected atoms. The
particles must be ellipsoids as defined by the "atom_style
ellipsoid"_atom_style.html command. The {Sx}, {Sy}, {Sz} settings are
the 3 diameters of the ellipsoid in each direction. All 3 can be set
to the same value, which means the ellipsoid is effectively a sphere.
They can also all be set to 0.0 which means the particle will be
treated as a point particle. Note that this command does not adjust
the particle mass, even if it was defined with a density, e.g. via the
"read_data"_read_data.html command.
Keyword {length} sets the length of selected atoms. The particles
must be line segments as defined by the "atom_style
line"_atom_style.html command. If the specified value is non-zero the
line segment is (re)set to a length = the specified value, centered
around the particle position, with an orientation along the x-axis.
If the specified value is 0.0, the particle will become a point
particle. Note that this command does not adjust the particle mass,
even if it was defined with a density, e.g. via the
"read_data"_read_data.html command.
Keyword {tri} sets the size of selected atoms. The particles must be
triangles as defined by the "atom_style tri"_atom_style.html command.
If the specified value is non-zero the triangle is (re)set to be an
equilateral triangle in the xy plane with side length = the specified
value, with a centroid at the particle position, with its base
parallel to the x axis, and the y-axis running from the center of the
base to the top point of the triangle. If the specified value is 0.0,
the particle will become a point particle. Note that this command
does not adjust the particle mass, even if it was defined with a
density, e.g. via the "read_data"_read_data.html command.
Keyword {theta} sets the orientation of selected atoms. The particles
must be line segments as defined by the "atom_style
line"_atom_style.html command. The specified value is used to set the
orientation angle of the line segments with respect to the x axis.
-
+
Keyword {theta/random} randomizes the orientation of theta for the
selected atoms. The particles must be line segments as defined by the
"atom_style line"_atom_style.html command. Random numbers are used in
such a way that the orientation of a particular atom is the same,
regardless of how many processors are being used. This keyword does
not allow use of an atom-style variable.
Keyword {angmom} sets the angular momentum of selected atoms. The
particles must be ellipsoids as defined by the "atom_style
ellipsoid"_atom_style.html command or triangles as defined by the
"atom_style tri"_atom_style.html command. The angular momentum vector
of the particles is set to the 3 specified components.
Keyword {omega} sets the angular velocity of selected atoms. The
particles must be spheres as defined by the "atom_style sphere"_
atom_style.html command. The angular velocity vector of the particles
is set to the 3 specified components.
Keyword {mass} sets the mass of all selected particles. The particles
must have a per-atom mass attribute, as defined by the
"atom_style"_atom_style.html command. See the "mass" command for how
to set mass values on a per-type basis.
Keyword {density} also sets the mass of all selected particles, but in
a different way. The particles must have a per-atom mass attribute,
as defined by the "atom_style"_atom_style.html command. If the atom
has a radius attribute (see "atom_style sphere"_atom_style.html) and
its radius is non-zero, its mass is set from the density and particle
volume. If the atom has a shape attribute (see "atom_style
ellipsoid"_atom_style.html) and its 3 shape parameters are non-zero,
then its mass is set from the density and particle volume. If the
atom has a length attribute (see "atom_style line"_atom_style.html)
and its length is non-zero, then its mass is set from the density and
line segment length (the input density is assumed to be in
mass/distance units). If the atom has an area attribute (see
"atom_style tri"_atom_style.html) and its area is non-zero, then its
mass is set from the density and triangle area (the input density is
assumed to be in mass/distance^2 units). If none of these cases are
valid, then the mass is set to the density value directly (the input
density is assumed to be in mass units).
Keyword {volume} sets the volume of all selected particles.
Currently, only the "atom_style peri"_atom_style.html command defines
particles with a volume attribute. Note that this command does not
adjust the particle mass.
Keyword {image} sets which image of the simulation box the atom 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 atoms cross periodic boundaries during
the simulation. The flags can be output with atom snapshots via the
"dump"_dump.html command. If a value of NULL is specified for any of
nx,ny,nz, then the current image value for that dimension is
unchanged. For non-periodic dimensions only a value of 0 can be
specified. This keyword does not allow use of atom-style variables.
This command can be useful after a system has been equilibrated and
atoms have diffused one or more box lengths in various directions.
This command can then reset the image values for atoms so that they
are effectively inside the simulation box, e.g if a diffusion
coefficient is about to be measured via the "compute
msd"_compute_msd.html command. Care should be taken not to reset the
image flags of two atoms in a bond to the same value if the bond
straddles a periodic boundary (rather they should be different by +/-
1). This will not affect the dynamics of a simulation, but may mess
up analysis of the trajectories if a LAMMPS diagnostic or your own
analysis relies on the image flags to unwrap a molecule which
straddles the periodic box.
Keywords {bond}, {angle}, {dihedral}, and {improper}, set the bond
type (angle type, etc) of all bonds (angles, etc) of selected atoms to
the specified value from 1 to nbondtypes (nangletypes, etc). All
atoms in a particular bond (angle, etc) must be selected atoms in
order for the change to be made. The value of nbondtype (nangletypes,
etc) was set by the {bond types} ({angle types}, etc) field in the
header of the data file read by the "read_data"_read_data.html
command. These keywords do not allow use of an atom-style variable.
Keywords {meso/e}, {meso/cv}, and {meso/rho} set the energy, heat
capacity, and density of smmothed particle hydrodynamics (SPH)
particles. See "this PDF guide"_USER/sph/SPH_LAMMPS_userguide.pdf to
using SPH in LAMMPS.
Keyword {smd/mass/density} sets the mass of all selected particles,
but it is only applicable to the Smooth Mach Dynamics package
USER-SMD. It assumes that the particle volume has already been
correctly set and calculates particle mass from the provided mass
density value.
Keyword {smd/contact/radius} only applies to simulations with the
Smooth Mach Dynamics package USER-SMD. Itsets an interaction radius
for computing short-range interactions, e.g. repulsive forces to
prevent different individual physical bodies from penetrating each
other. Note that the SPH smoothing kernel diameter used for computing
long range, nonlocal interactions, is set using the {diameter}
keyword.
Keyword {dpd/theta} sets the internal temperature of a DPD particle as
defined by the USER-DPD package. If the specified value is a number
it must be >= 0.0. If the specified value is NULL, then the kinetic
temperature Tkin of each particle is computed as 3/2 k Tkin = KE = 1/2
m v^2 = 1/2 m (vx*vx+vy*vy+vz*vz). Each particle's internal
temperature is set to Tkin. If the specified value is an atom-style
variable, then the variable is evaluated for each particle. If a
value >= 0.0, the internal temperature is set to that value. If it is
< 0.0, the computation of Tkin is performed and the internal
temperature is set to that value.
Keywords {i_name} and {d_name} refer to custom integer and
floating-point properties that have been added to each atom via the
"fix property/atom"_fix_property_atom.html command. When that command
is used specific names are given to each attribute which are what is
specified as the "name" portion of {i_name} or {d_name}.
[Restrictions:]
You cannot set an atom attribute (e.g. {mol} or {q} or {volume}) if
the "atom_style"_atom_style.html does not have that attribute.
This command requires inter-processor communication to coordinate the
setting of bond types (angle types, etc). This means that your system
must be ready to perform a simulation before using one of these
keywords (force fields set, atom mass set, etc). This is not
necessary for other keywords.
Using the {region} style with the bond (angle, etc) keywords can give
unpredictable results if there are bonds (angles, etc) that straddle
periodic boundaries. This is because the region may only extend up to
the boundary and partner atoms in the bond (angle, etc) may have
coordinates outside the simulation box if they are ghost atoms.
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
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 analagous 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
print "TEST_4d $(round(v_t4d))% Error. Edge histogram of a body centered cubic lattice (truncated octahedron, 6 sides with 4 edges, 8 sides with 6 edges)"
TEST_4d 0% Error. Edge histogram of a body centered cubic lattice (truncated octahedron, 6 sides with 4 edges, 8 sides with 6 edges)
print "TEST_4d $(round(v_t4d))% Error. Edge histogram of a body centered cubic lattice (truncated octahedron, 6 sides with 4 edges, 8 sides with 6 edges)"
TEST_4d 0% Error. Edge histogram of a body centered cubic lattice (truncated octahedron, 6 sides with 4 edges, 8 sides with 6 edges)