forked from lijiext/lammps
Third batch of spelling fixes in manual
This commit is contained in:
parent
32708860a9
commit
007f3c66a0
|
@ -464,7 +464,7 @@ the angletype option can only be assigned to a "fix style" of "shake",
|
|||
entirely rigid (e.g. water)
|
||||
the angletype option enables an additional check when SHAKE constraints
|
||||
are computed: if a cluster is of size 3 and both bonds in
|
||||
the cluster are of a bondtype specified by the 2nd paramter of
|
||||
the cluster are of a bondtype specified by the 2nd parameter of
|
||||
angletype, then the cluster is SHAKEn with an additional angle
|
||||
constraint that makes it rigid, using the equilibrium angle appropriate
|
||||
to the specified angletype
|
||||
|
@ -1566,7 +1566,7 @@ mesh dimensions that are power-of-two are fastest for FFTs, but any sizes
|
|||
can be used that are supported by native machine libraries
|
||||
this command is optional - if not used, a default
|
||||
mesh size will be chosen to satisfy accuracy criterion - if used, the
|
||||
specifed mesh size will override the default
|
||||
specified mesh size will override the default
|
||||
</PRE>
|
||||
<HR>
|
||||
<H3>
|
||||
|
|
|
@ -201,7 +201,7 @@ The tools directory also has a F77 program called setup_chain.f
|
|||
(compile and link with print.c) which can be used to generate random
|
||||
initial polymer configurations for bead-spring models like those used
|
||||
in examples/polymer. It uses an input polymer definition file (see
|
||||
examples/polymer for two sample def files) that specfies how many
|
||||
examples/polymer for two sample def files) that specifies how many
|
||||
chains of what length, a random number seed, etc.</P>
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
|
|
@ -40,7 +40,7 @@ Note: this file is somewhat out-of-date for LAMMPS 99.</P>
|
|||
<LI>
|
||||
maxtype = max # of atom types
|
||||
<LI>
|
||||
maxbond = max # of bonds to compute on one procesor
|
||||
maxbond = max # of bonds to compute on one processor
|
||||
<LI>
|
||||
maxangle = max # of angles to compute on one processor
|
||||
<LI>
|
||||
|
|
|
@ -1124,7 +1124,7 @@ mesh dimensions that are power-of-two are fastest for FFTs, but any size
|
|||
can be used that are supported by native machine libraries
|
||||
this command is optional - if not used, a default
|
||||
mesh size will be chosen to satisfy accuracy criterion - if used, the
|
||||
specifed mesh size will override the default
|
||||
specified mesh size will override the default
|
||||
|
||||
Default = none
|
||||
</PRE>
|
||||
|
|
|
@ -7552,7 +7552,7 @@ Self-explanatory. :dd
|
|||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Molecule toplogy/atom exceeds system topology/atom} :dt
|
||||
{Molecule topology/atom exceeds system topology/atom} :dt
|
||||
|
||||
The number of bonds, angles, etc per-atom in the molecule exceeds the
|
||||
system setting. See the create_box command for how to specify these
|
||||
|
@ -10707,7 +10707,7 @@ Self-explanatory. :dd
|
|||
{Variable has circular dependency} :dt
|
||||
|
||||
A circular dependency is when variable "a" in used by variable "b" and
|
||||
variable "b" is also used by varaible "a". Circular dependencies with
|
||||
variable "b" is also used by variable "a". Circular dependencies with
|
||||
longer chains of dependence are also not allowed. :dd
|
||||
|
||||
{Variable name between brackets must be alphanumeric or underscore characters} :dt
|
||||
|
@ -11452,7 +11452,7 @@ i.e. the first molecule in the template. :dd
|
|||
|
||||
{Molecule template for fix shake has multiple molecules} :dt
|
||||
|
||||
The fix shake command will only recoginze molecules of a single
|
||||
The fix shake command will only recognize molecules of a single
|
||||
type, i.e. the first molecule in the template. :dd
|
||||
|
||||
{More than one compute centro/atom} :dt
|
||||
|
@ -11589,7 +11589,7 @@ This may not be what you intended. :dd
|
|||
|
||||
{One or more dynamic groups may not be updated at correct point in timestep} :dt
|
||||
|
||||
If there are other fixes that act immediately after the intitial stage
|
||||
If there are other fixes that act immediately after the initial stage
|
||||
of time integration within a timestep (i.e. after atoms move), then
|
||||
the command that sets up the dynamic group should appear after those
|
||||
fixes. This will insure that dynamic group assignments are made
|
||||
|
|
|
@ -37,7 +37,7 @@ pitfalls or alternatives.
|
|||
|
||||
Please see some of the closed issues for examples of how to
|
||||
suggest code enhancements, submit proposed changes, or report
|
||||
possible bugs and how they are resoved.
|
||||
possible bugs and how they are resolved.
|
||||
|
||||
As an alternative to using GitHub, you may e-mail the
|
||||
"core developers"_http://lammps.sandia.gov/authors.html or send
|
||||
|
|
|
@ -573,7 +573,7 @@ LJ epsilon of O-O = 0.16275
|
|||
LJ sigma of O-O = 3.16435
|
||||
LJ epsilon, sigma of OH, HH = 0.0 :all(b),p
|
||||
|
||||
Note that the when using the TIP4P pair style, the neighobr list
|
||||
Note that the when using the TIP4P pair style, the neighbor list
|
||||
cutoff for Coulomb interactions is effectively extended by a distance
|
||||
2 * (OM distance), to account for the offset distance of the
|
||||
fictitious charges on O atoms in water molecules. Thus it is
|
||||
|
@ -863,7 +863,7 @@ boundary conditions in specific dimensions. See the command doc pages
|
|||
for details.
|
||||
|
||||
The 9 parameters (xlo,xhi,ylo,yhi,zlo,zhi,xy,xz,yz) are defined at the
|
||||
time the simluation box is created. This happens in one of 3 ways.
|
||||
time the simulation box is created. This happens in one of 3 ways.
|
||||
If the "create_box"_create_box.html command is used with a region of
|
||||
style {prism}, then a triclinic box is setup. See the
|
||||
"region"_region.html command for details. If the
|
||||
|
@ -1525,7 +1525,7 @@ Variables that generate values to output :h5,link(variable)
|
|||
"Variables"_variable.html defined in an input script can store one or
|
||||
more strings. But equal-style, vector-style, and atom-style or
|
||||
atomfile-style variables generate a global scalar value, global vector
|
||||
or values, or a per-atom vector, resepctively, when accessed. The
|
||||
or values, or a per-atom vector, respectively, when accessed. The
|
||||
formulas used to define these variables can contain references to the
|
||||
thermodynamic keywords and to global and per-atom data generated by
|
||||
computes, fixes, and other variables. The values generated by
|
||||
|
@ -1585,7 +1585,7 @@ Temperature is computed as kinetic energy divided by some number of
|
|||
degrees of freedom (and the Boltzmann constant). Since kinetic energy
|
||||
is a function of particle velocity, there is often a need to
|
||||
distinguish between a particle's advection velocity (due to some
|
||||
aggregate motiion of particles) and its thermal velocity. The sum of
|
||||
aggregate motion of particles) and its thermal velocity. The sum of
|
||||
the two is the particle's total velocity, but the latter is often what
|
||||
is wanted to compute a temperature.
|
||||
|
||||
|
@ -1888,7 +1888,7 @@ instances of LAMMPS to perform different calculations.
|
|||
|
||||
The lammps_open_no_mpi() function is similar except that no MPI
|
||||
communicator is passed from the caller. Instead, MPI_COMM_WORLD is
|
||||
used to instantiate LAMMPS, and MPI is initialzed if necessary.
|
||||
used to instantiate LAMMPS, and MPI is initialized if necessary.
|
||||
|
||||
The lammps_close() function is used to shut down an instance of LAMMPS
|
||||
and free all its memory.
|
||||
|
@ -1976,7 +1976,7 @@ The lammps_get_natoms() function returns the total number of atoms in
|
|||
the system and can be used by the caller to allocate space for the
|
||||
lammps_gather_atoms() and lammps_scatter_atoms() functions. The
|
||||
gather function collects atom info of the requested type (atom coords,
|
||||
types, forces, etc) from all procsesors, orders them by atom ID, and
|
||||
types, forces, etc) from all processors, orders them by atom ID, and
|
||||
returns a full list to each calling processor. The scatter function
|
||||
does the inverse. It distributes the same kinds of values,
|
||||
passed by the caller, to each atom owned by individual processors.
|
||||
|
@ -2268,7 +2268,7 @@ atoms with same local defect structure | chunk ID = output of "compute centro/at
|
|||
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.
|
||||
scales the floating point value to spread it across multiple integers.
|
||||
|
||||
Spatial bins can be of various kinds, e.g. 1d bins = slabs, 2d bins =
|
||||
pencils, 3d bins = boxes, spherical bins, cylindrical bins.
|
||||
|
@ -2444,7 +2444,7 @@ performance. This approach provides a fast initialization of the
|
|||
simulation. However, it is sensitive to errors: A combination of
|
||||
parameters that will perform well for one system might result in
|
||||
far-from-optimal conditions for other simulations. For example,
|
||||
parametes that provide accurate and fast computations for
|
||||
parameters that provide accurate and fast computations for
|
||||
all-atomistic force fields can provide insufficient accuracy or
|
||||
united-atomistic force fields (which is related to that the latter
|
||||
typically have larger dispersion coefficients).
|
||||
|
@ -2551,7 +2551,7 @@ this is done by "fix qeq/dynamic"_fix_qeq.html, and for the
|
|||
charge-on-spring models by the methods outlined in the next two
|
||||
sections. The assignment of masses to the additional degrees of
|
||||
freedom can lead to unphysical trajectories if care is not exerted in
|
||||
choosing the parameters of the poarizable models and the simulation
|
||||
choosing the parameters of the polarizable models and the simulation
|
||||
conditions.
|
||||
|
||||
In the core-shell model the vibration of the shells is kept faster
|
||||
|
@ -2727,12 +2727,12 @@ If "compute temp/cs"_compute_temp_cs.html is used, the decoupled
|
|||
relative motion of the core and the shell should in theory be
|
||||
stable. However numerical fluctuation can introduce a small
|
||||
momentum to the system, which is noticable over long trajectories.
|
||||
Therefore it is recomendable to use the "fix
|
||||
Therefore it is recommendable to use the "fix
|
||||
momentum"_fix_momentum.html command in combination with "compute
|
||||
temp/cs"_compute_temp_cs.html when equilibrating the system to
|
||||
prevent any drift.
|
||||
|
||||
When intializing the velocities of a system with core/shell pairs, it
|
||||
When initializing the velocities of a system with core/shell pairs, it
|
||||
is also desirable to not introduce energy into the relative motion of
|
||||
the core/shell particles, but only assign a center-of-mass velocity to
|
||||
the pairs. This can be done by using the {bias} keyword of the
|
||||
|
@ -2808,7 +2808,7 @@ CS-Info # header of additional section :pre
|
|||
6.27 Drude induced dipoles :link(howto_27),h4
|
||||
|
||||
The thermalized Drude model, similarly to the "core-shell"_#howto_26
|
||||
model, representes induced dipoles by a pair of charges (the core atom
|
||||
model, represents induced dipoles by a pair of charges (the core atom
|
||||
and the Drude particle) connected by a harmonic spring. The Drude
|
||||
model has a number of features aimed at its use in molecular systems
|
||||
("Lamoureux and Roux"_#howto-Lamoureux):
|
||||
|
|
|
@ -369,7 +369,7 @@ pre_force_respa: same as pre_force, but for rRESPA (optional)
|
|||
post_force_respa: same as post_force, but for rRESPA (optional)
|
||||
final_integrate_respa: same as final_integrate, but for rRESPA (optional)
|
||||
min_pre_force: called after pair & molecular forces are computed in minimizer (optional)
|
||||
min_post_force: called after pair & molecular forces are computed and communicated in minmizer (optional)
|
||||
min_post_force: called after pair & molecular forces are computed and communicated in minimizer (optional)
|
||||
min_store: store extra data for linesearch based minimization on a LIFO stack (optional)
|
||||
min_pushstore: push the minimization LIFO stack one element down (optional)
|
||||
min_popstore: pop the minimization LIFO stack one element up (optional)
|
||||
|
@ -785,10 +785,10 @@ file for how to format the cite itself. The "Restrictions" section of
|
|||
the doc page should indicate that your command is only available if
|
||||
LAMMPS is built with the appropriate USER-MISC or USER-FOO package.
|
||||
See other user package doc files for examples of how to do this. The
|
||||
prerequiste for building the HTML format files are Python 3.x and
|
||||
prerequisite for building the HTML format files are Python 3.x and
|
||||
virtualenv, the requirement for generating the PDF format manual
|
||||
is the "htmldoc"_http://www.htmldoc.org/ software. Please run at least
|
||||
"make html" and carefully inspect and proofread the resuling HTML format
|
||||
"make html" and carefully inspect and proofread the resulting HTML format
|
||||
doc page before submitting your code. :l
|
||||
|
||||
For a new package (or even a single command) you should include one or
|
||||
|
|
|
@ -94,7 +94,7 @@ Package, Description, Author(s), Doc page, Example, Library
|
|||
:tb(ea=c)
|
||||
|
||||
The "Authors" column lists a name(s) if a specific person is
|
||||
responible for creating and maintaining the package.
|
||||
responsible for creating and maintaining the package.
|
||||
|
||||
(1) The COLLOID package includes Fast Lubrication Dynamics pair styles
|
||||
which were created by Amit Kumar and Michael Bybee from Jonathan
|
||||
|
@ -955,8 +955,8 @@ multi-replica simulations in LAMMPS. Multi-replica methods included
|
|||
in the package are nudged elastic band (NEB), parallel replica
|
||||
dynamics (PRD), temperature accelerated dynamics (TAD), parallel
|
||||
tempering, and a verlet/split algorithm for performing long-range
|
||||
Coulombics on one set of processors, and the remainded of the force
|
||||
field calcalation on another set.
|
||||
Coulombics on one set of processors, and the remainder of the force
|
||||
field calculation on another set.
|
||||
|
||||
To install via make or Make.py:
|
||||
|
||||
|
@ -1176,7 +1176,7 @@ Package, Description, Author(s), Doc page, Example, Pic/movie, Library
|
|||
:link(VMD,http://www.ks.uiuc.edu/Research/vmd)
|
||||
|
||||
The "Authors" column lists a name(s) if a specific person is
|
||||
responible for creating and maintaining the package.
|
||||
responsible for creating and maintaining the package.
|
||||
|
||||
(1) The ATC package was created by Reese Jones, Jeremy Templeton, and
|
||||
Jon Zimmerman (Sandia).
|
||||
|
@ -1778,7 +1778,7 @@ particularly with respect to the charge equilibration calculation. It
|
|||
should also be easier to build and use since there are no complicating
|
||||
issues with Fortran memory allocation or linking to a Fortran library.
|
||||
|
||||
For technical details about this implemention of ReaxFF, see
|
||||
For technical details about this implementation of ReaxFF, see
|
||||
this paper:
|
||||
|
||||
Parallel and Scalable Reactive Molecular Dynamics: Numerical Methods
|
||||
|
|
|
@ -69,7 +69,7 @@ bench/in.lj input script.
|
|||
|
||||
For all the benchmarks, a useful metric is the CPU cost per atom per
|
||||
timestep. Since performance scales roughly linearly with problem size
|
||||
and timesteps for all LAMMPS models (i.e. inteatomic or coarse-grained
|
||||
and timesteps for all LAMMPS models (i.e. interatomic or coarse-grained
|
||||
potentials), the run time of any problem using the same model (atom
|
||||
style, force field, cutoff, etc) can then be estimated.
|
||||
|
||||
|
|
|
@ -97,7 +97,7 @@ current LAMMPS library interface and how to call them from Python.
|
|||
Section 11.8 gives some examples of coupling LAMMPS to other tools via
|
||||
Python. For example, LAMMPS can easily be coupled to a GUI or other
|
||||
visualization tools that display graphs or animations in real time as
|
||||
LAMMPS runs. Examples of such scripts are inlcluded in the python
|
||||
LAMMPS runs. Examples of such scripts are included in the python
|
||||
directory.
|
||||
|
||||
Two advantages of using Python to run LAMMPS are how concise the
|
||||
|
@ -177,7 +177,7 @@ of Python and your machine to successfully build LAMMPS. See the
|
|||
lib/python/README file for more info.
|
||||
|
||||
If you want to write Python code with callbacks to LAMMPS, then you
|
||||
must also follow the steps overviewed in the preceeding section (11.1)
|
||||
must also follow the steps overviewed in the preceding section (11.1)
|
||||
for running LAMMPS from Python. I.e. you must build LAMMPS as a
|
||||
shared library and insure that Python can find the python/lammps.py
|
||||
file and the shared library.
|
||||
|
@ -325,7 +325,7 @@ sudo python setup.py install :pre
|
|||
Again, the "sudo" is only needed if required to copy PyPar files into
|
||||
your Python distribution's site-packages directory.
|
||||
|
||||
If you have successully installed PyPar, you should be able to run
|
||||
If you have successfully installed PyPar, you should be able to run
|
||||
Python and type
|
||||
|
||||
import pypar :pre
|
||||
|
@ -369,7 +369,7 @@ user privilege into the user local directory type
|
|||
|
||||
python setup.py install --user :pre
|
||||
|
||||
If you have successully installed mpi4py, you should be able to run
|
||||
If you have successfully installed mpi4py, you should be able to run
|
||||
Python and type
|
||||
|
||||
from mpi4py import MPI :pre
|
||||
|
@ -610,7 +610,7 @@ lmp = lammps() :pre
|
|||
|
||||
create an instance of LAMMPS, wrapped in a Python class by the lammps
|
||||
Python module, and return an instance of the Python class as lmp. It
|
||||
is used to make all subequent calls to the LAMMPS library.
|
||||
is used to make all subsequent calls to the LAMMPS library.
|
||||
|
||||
Additional arguments to lammps() can be used to tell Python the name
|
||||
of the shared library to load or to pass arguments to the LAMMPS
|
||||
|
@ -774,7 +774,7 @@ demo.py, invoke various LAMMPS library interface routines,
|
|||
simple.py, run in parallel, similar to examples/COUPLE/simple/simple.cpp,
|
||||
split.py, same as simple.py but running in parallel on a subset of procs,
|
||||
gui.py, GUI go/stop/temperature-slider to control LAMMPS,
|
||||
plot.py, real-time temeperature plot with GnuPlot via Pizza.py,
|
||||
plot.py, real-time temperature plot with GnuPlot via Pizza.py,
|
||||
viz_tool.py, real-time viz via some viz package,
|
||||
vizplotgui_tool.py, combination of viz_tool.py and plot.py and gui.py :tb(c=2)
|
||||
|
||||
|
|
|
@ -80,7 +80,7 @@ This section has the following sub-sections:
|
|||
|
||||
Read this first :h5,link(start_2_1)
|
||||
|
||||
If you want to avoid building LAMMPS yourself, read the preceeding
|
||||
If you want to avoid building LAMMPS yourself, read the preceding
|
||||
section about options available for downloading and installing
|
||||
executables. Details are discussed on the "download"_download page.
|
||||
|
||||
|
@ -251,7 +251,7 @@ re-compile, after typing "make clean" (which will describe different
|
|||
clean options).
|
||||
|
||||
The LMP_INC variable is used to include options that turn on ifdefs
|
||||
within the LAMMPS code. The options that are currently recogized are:
|
||||
within the LAMMPS code. The options that are currently recognized are:
|
||||
|
||||
-DLAMMPS_GZIP
|
||||
-DLAMMPS_JPEG
|
||||
|
@ -682,7 +682,7 @@ various make commands that can be used to manipulate packages.
|
|||
If you use a command in a LAMMPS input script that is part of a
|
||||
package, you must have built LAMMPS with that package, else you will
|
||||
get an error that the style is invalid or the command is unknown.
|
||||
Every command's doc page specfies if it is part of a package. You can
|
||||
Every command's doc page specifies if it is part of a package. You can
|
||||
also type
|
||||
|
||||
lmp_machine -h :pre
|
||||
|
@ -1416,8 +1416,8 @@ LAMMPS is compiled with CUDA=yes.
|
|||
numa Nm :pre
|
||||
|
||||
This option is only relevant when using pthreads with hwloc support.
|
||||
In this case Nm defines the number of NUMA regions (typicaly sockets)
|
||||
on a node which will be utilizied by a single MPI rank. By default Nm
|
||||
In this case Nm defines the number of NUMA regions (typically sockets)
|
||||
on a node which will be utilized by a single MPI rank. By default Nm
|
||||
= 1. If this option is used the total number of worker-threads per
|
||||
MPI rank is threads*numa. Currently it is always almost better to
|
||||
assign at least one MPI rank per NUMA region, and leave numa set to
|
||||
|
@ -1481,7 +1481,7 @@ replica runs on on one or a few processors. Note that with MPI
|
|||
installed on a machine (e.g. your desktop), you can run on more
|
||||
(virtual) processors than you have physical processors.
|
||||
|
||||
To run multiple independent simulatoins from one input script, using
|
||||
To run multiple independent simulations from one input script, using
|
||||
multiple partitions, see "Section 6.4"_Section_howto.html#howto_4
|
||||
of the manual. World- and universe-style "variables"_variable.html
|
||||
are useful in this context.
|
||||
|
@ -1760,7 +1760,7 @@ The first section provides a global loop timing summary. The {loop time}
|
|||
is the total wall time for the section. The {Performance} line is
|
||||
provided for convenience to help predicting the number of loop
|
||||
continuations required and for comparing performance with other,
|
||||
similar MD codes. The {CPU use} line provides the CPU utilzation per
|
||||
similar MD codes. The {CPU use} line provides the CPU utilization per
|
||||
MPI task; it should be close to 100% times the number of OpenMP
|
||||
threads (or 1 of no OpenMP). Lower numbers correspond to delays due
|
||||
to file I/O or insufficient thread utilization.
|
||||
|
|
|
@ -27,7 +27,7 @@
|
|||
syntax</a></h2>
|
||||
<p>fix_modify AtC consistent_fe_initialization <on | off></p>
|
||||
<ul>
|
||||
<li><on|off> = switch to activiate/deactiviate the intial setting of FE intrinsic field to match the projected MD field </li>
|
||||
<li><on|off> = switch to activiate/deactiviate the initial setting of FE intrinsic field to match the projected MD field </li>
|
||||
</ul>
|
||||
<h2><a class="anchor" id="examples">
|
||||
examples</a></h2>
|
||||
|
|
|
@ -20,7 +20,7 @@ coprocessors via offloading neighbor list and non-bonded force
|
|||
calculations to the Phi. The same C++ code is used in both cases.
|
||||
When offloading to a coprocessor from a CPU, the same routine is run
|
||||
twice, once on the CPU and once with an offload flag. This allows
|
||||
LAMMPS to run on the CPU cores and coprocessor cores simulataneously.
|
||||
LAMMPS to run on the CPU cores and coprocessor cores simultaneously.
|
||||
|
||||
[Currently Available USER-INTEL Styles:]
|
||||
|
||||
|
@ -115,7 +115,7 @@ coprocessor and an Intel compiler are required. For this, the
|
|||
recommended version of the Intel compiler is 14.0.1.106 or
|
||||
versions 15.0.2.044 and higher.
|
||||
|
||||
Although any compiler can be used with the USER-INTEL pacakge,
|
||||
Although any compiler can be used with the USER-INTEL package,
|
||||
currently, vectorization directives are disabled by default when
|
||||
not using Intel compilers due to lack of standard support and
|
||||
observations of decreased performance. The OpenMP standard now
|
||||
|
|
|
@ -217,7 +217,7 @@ best performance its CCFLAGS setting should use -O3 and have a
|
|||
KOKKOS_ARCH setting that matches the compute capability of your NVIDIA
|
||||
hardware and software installation, e.g. KOKKOS_ARCH=Kepler30. Note
|
||||
the minimal required compute capability is 2.0, but this will give
|
||||
signicantly reduced performance compared to Kepler generation GPUs
|
||||
significantly reduced performance compared to Kepler generation GPUs
|
||||
with compute capability 3.x. For the LINK setting, "nvcc" should not
|
||||
be used; instead use g++ or another compiler suitable for linking C++
|
||||
applications. Often you will want to use your MPI compiler wrapper
|
||||
|
|
|
@ -81,7 +81,7 @@ LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
|||
|
||||
Unlike other angle styles, the hybrid angle style does not store angle
|
||||
coefficient info for individual sub-styles in a "binary restart
|
||||
files"_restart.html. Thus when retarting a simulation from a restart
|
||||
files"_restart.html. Thus when restarting a simulation from a restart
|
||||
file, you need to re-specify angle_coeff commands.
|
||||
|
||||
[Related commands:]
|
||||
|
|
|
@ -103,7 +103,7 @@ turns off the {first} option.
|
|||
|
||||
It is OK to use the {first} keyword with a group that has not yet been
|
||||
defined, e.g. to use the atom_modify first command at the beginning of
|
||||
your input script. LAMMPS does not use the group until a simullation
|
||||
your input script. LAMMPS does not use the group until a simulation
|
||||
is run.
|
||||
|
||||
The {sort} keyword turns on a spatial sorting or reordering of atoms
|
||||
|
@ -116,7 +116,7 @@ various other factors. As a general rule, sorting is typically more
|
|||
effective at speeding up simulations of liquids as opposed to solids.
|
||||
In tests we have done, the speed-up can range from zero to 3-4x.
|
||||
|
||||
Reordering is peformed every {Nfreq} timesteps during a dynamics run
|
||||
Reordering is performed every {Nfreq} timesteps during a dynamics run
|
||||
or iterations during a minimization. More precisely, reordering
|
||||
occurs at the first reneighboring that occurs after the target
|
||||
timestep. The reordering is performed locally by each processor,
|
||||
|
@ -130,7 +130,7 @@ the processor's 1d list of atoms.
|
|||
The goal of this procedure is for atoms to put atoms close to each
|
||||
other in the processor's one-dimensional list of atoms that are also
|
||||
near to each other spatially. This can improve cache performance when
|
||||
pairwise intereractions and neighbor lists are computed. Note that if
|
||||
pairwise interactions and neighbor lists are computed. Note that if
|
||||
bins are too small, there will be few atoms/bin. Likewise if bins are
|
||||
too large, there will be many atoms/bin. In both cases, the goal of
|
||||
cache locality will be undermined.
|
||||
|
@ -138,7 +138,7 @@ cache locality will be undermined.
|
|||
NOTE: Running a simulation with sorting on versus off should not
|
||||
change the simulation results in a statistical sense. However, a
|
||||
different ordering will induce round-off differences, which will lead
|
||||
to diverging trajectories over time when comparing two simluations.
|
||||
to diverging trajectories over time when comparing two simulations.
|
||||
Various commands, particularly those which use random numbers
|
||||
(e.g. "velocity create"_velocity.html, and "fix
|
||||
langevin"_fix_langevin.html), may generate (statistically identical)
|
||||
|
|
|
@ -149,7 +149,7 @@ Hydrodynamics. Both fluids and solids can be modeled. Particles
|
|||
store the mass and volume of an integration point, a kernel diameter
|
||||
used for calculating the field variables (e.g. stress and deformation)
|
||||
and a contact radius for calculating repulsive forces which prevent
|
||||
individual physical bodies from penetretating each other.
|
||||
individual physical bodies from penetrating each other.
|
||||
|
||||
The {wavepacket} style is similar to {electron}, but the electrons may
|
||||
consist of several Gaussian wave packets, summed up with coefficients
|
||||
|
@ -165,7 +165,7 @@ For the {tri} style, the particles are planar triangles and each
|
|||
stores a per-particle mass and size and orientation (i.e. the corner
|
||||
points of the triangle).
|
||||
|
||||
The {template} style allows molecular topolgy (bonds,angles,etc) to be
|
||||
The {template} style allows molecular topology (bonds,angles,etc) to be
|
||||
defined via a molecule template using the "molecule"_molecule.html
|
||||
command. The template stores one or more molecules with a single copy
|
||||
of the topology info (bonds,angles,etc) of each. Individual atoms
|
||||
|
|
|
@ -76,13 +76,13 @@ sub-domain sizes and shapes on-the-fly during a "run"_run.html.
|
|||
|
||||
Load-balancing is typically most useful if the particles in the
|
||||
simulation box have a spatially-varying density distribution or when
|
||||
the computational cost varies signficantly between different
|
||||
the computational cost varies significantly between different
|
||||
particles. E.g. a model of a vapor/liquid interface, or a solid with
|
||||
an irregular-shaped geometry containing void regions, or "hybrid pair
|
||||
style simulations"_pair_hybrid.html which combine pair styles with
|
||||
different computational cost. In these cases, the LAMMPS default of
|
||||
dividing the simulation box volume into a regular-spaced grid of 3d
|
||||
bricks, with one equal-volume sub-domain per procesor, may assign
|
||||
bricks, with one equal-volume sub-domain per processor, may assign
|
||||
numbers of particles per processor in a way that the computational
|
||||
effort varies significantly. This can lead to poor performance when
|
||||
the simulation is run in parallel.
|
||||
|
@ -91,7 +91,7 @@ The balancing can be performed with or without per-particle weighting.
|
|||
With no weighting, the balancing attempts to assign an equal number of
|
||||
particles to each processor. With weighting, the balancing attempts
|
||||
to assign an equal aggregate computational weight to each processor,
|
||||
which typically inducces a different number of atoms assigned to each
|
||||
which typically induces a different number of atoms assigned to each
|
||||
processor. Details on the various weighting options and examples for
|
||||
how they can be used are "given below"_#weighted_balance.
|
||||
|
||||
|
@ -222,7 +222,7 @@ listed in ascending order. They represent the fractional position of
|
|||
the cutting place. The left (or lower) edge of the box is 0.0, and
|
||||
the right (or upper) edge is 1.0. Neither of these values is
|
||||
specified. Only the interior Ps-1 positions are specified. Thus is
|
||||
there are 2 procesors in the x dimension, you specify a single value
|
||||
there are 2 processors in the x dimension, you specify a single value
|
||||
such as 0.75, which would make the left processor's sub-domain 3x
|
||||
larger than the right processor's sub-domain.
|
||||
|
||||
|
@ -266,7 +266,7 @@ assigned, particles are migrated to their new owning processor, and
|
|||
the balance procedure ends.
|
||||
|
||||
NOTE: At each rebalance operation, the bisectioning for each cutting
|
||||
plane (line in 2d) typcially starts with low and high bounds separated
|
||||
plane (line in 2d) typically starts with low and high bounds separated
|
||||
by the extent of a processor's sub-domain in one dimension. The size
|
||||
of this bracketing region shrinks by 1/2 every iteration. Thus if
|
||||
{Niter} is specified as 10, the cutting plane will typically be
|
||||
|
@ -301,7 +301,7 @@ processors at each iteration.
|
|||
That is the procedure for the first cut. Subsequent cuts are made
|
||||
recursively, in exactly the same manner. The subset of processors
|
||||
assigned to each box make a new cut in the longest dimension of that
|
||||
box, splitting the box, the subset of processsors, and the particles
|
||||
box, splitting the box, the subset of processors, and the particles
|
||||
in the box in two. The recursion continues until every processor is
|
||||
assigned a sub-box of the entire simulation domain, and owns the
|
||||
particles in that sub-box.
|
||||
|
@ -368,7 +368,7 @@ of about 0.8 often results in the best performance, since the number
|
|||
of neighbors is likely to overestimate the ideal weight.
|
||||
|
||||
This weight style is useful for systems where there are different
|
||||
cutoffs used for different pairs of interations, or the density
|
||||
cutoffs used for different pairs of interactions, or the density
|
||||
fluctuates, or a large number of particles are in the vicinity of a
|
||||
wall, or a combination of these effects. If a simulation uses
|
||||
multiple neighbor lists, this weight style will use the first suitable
|
||||
|
@ -402,7 +402,7 @@ decrease the weights so that the ratio of max weight to min weight
|
|||
decreases by {factor}. In both cases the intermediate weight values
|
||||
increase/decrease proportionally as well. A value = 1.0 has no effect
|
||||
on the {time} weights. As a rule of thumb, effective values to use
|
||||
are typicall between 0.5 and 1.2. Note that the timer quantities
|
||||
are typically between 0.5 and 1.2. Note that the timer quantities
|
||||
mentioned above can be affected by communication which occurs in the
|
||||
middle of the operations, e.g. pair styles with intermediate exchange
|
||||
of data witin the force computation, and likewise for KSpace solves.
|
||||
|
|
|
@ -82,7 +82,7 @@ internal stress that induces fragmentation :ul
|
|||
then the interaction between pairs of particles is likely to be more
|
||||
complex than the summation of simple sub-particle interactions. An
|
||||
example is contact or frictional forces between particles with planar
|
||||
sufaces that inter-penetrate.
|
||||
surfaces that inter-penetrate.
|
||||
|
||||
These are additional LAMMPS commands that can be used with body
|
||||
particles of different styles
|
||||
|
@ -105,7 +105,7 @@ in the sections below.
|
|||
|
||||
The {nparticle} body style represents body particles as a rigid body
|
||||
with a variable number N of sub-particles. It is provided as a
|
||||
vanillia, prototypical example of a body particle, although as
|
||||
vanilla, prototypical example of a body particle, although as
|
||||
mentioned above, the "fix rigid"_fix_rigid.html command already
|
||||
duplicates its functionality.
|
||||
|
||||
|
|
|
@ -64,7 +64,7 @@ LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
|||
|
||||
Unlike other bond styles, the hybrid bond style does not store bond
|
||||
coefficient info for individual sub-styles in a "binary restart
|
||||
files"_restart.html. Thus when retarting a simulation from a restart
|
||||
files"_restart.html. Thus when restarting a simulation from a restart
|
||||
file, you need to re-specify bond_coeff commands.
|
||||
|
||||
[Related commands:]
|
||||
|
|
|
@ -258,8 +258,8 @@ command.
|
|||
:line
|
||||
|
||||
The {ortho} and {triclinic} keywords convert the simulation box to be
|
||||
orthogonal or triclinic (non-orthongonal). See "this
|
||||
section"_Section_howto#howto_13 for a discussion of how non-orthongal
|
||||
orthogonal or triclinic (non-orthogonal). See "this
|
||||
section"_Section_howto#howto_13 for a discussion of how non-orthogonal
|
||||
boxes are represented in LAMMPS.
|
||||
|
||||
The simulation box is defined as either orthogonal or triclinic when
|
||||
|
|
|
@ -39,7 +39,7 @@ sizes and shapes. Again there is one tile per processor. To acquire
|
|||
information for nearby atoms, communication must now be done with a
|
||||
more complex pattern of neighboring processors.
|
||||
|
||||
Note that this command does not actually define a partitoining of the
|
||||
Note that this command does not actually define a partitioning of the
|
||||
simulation box (a domain decomposition), rather it determines what
|
||||
kinds of decompositions are allowed and the pattern of communication
|
||||
used to enable the decomposition. A decomposition is created when the
|
||||
|
|
|
@ -22,7 +22,7 @@ compute 1 fluid angmom/chunk molchunk :pre
|
|||
|
||||
[Description:]
|
||||
|
||||
Define a computation that calculates the angular momemtum of multiple
|
||||
Define a computation that calculates the angular momentum of multiple
|
||||
chunks of atoms.
|
||||
|
||||
In LAMMPS, chunks are collections of atoms defined by a "compute
|
||||
|
|
|
@ -386,7 +386,7 @@ If {compress yes} is set, and the {compress} keyword comes before the
|
|||
{limit} keyword, the compression operation is performed first, as
|
||||
described below, which resets {Nchunk}. The {limit} keyword is then
|
||||
applied to the new {Nchunk} value, exactly as described in the
|
||||
preceeding paragraph. Note that in this case, all atoms will end up
|
||||
preceding paragraph. Note that in this case, all atoms will end up
|
||||
with chunk IDs <= {Nc}, but their original values (e.g. molecule ID or
|
||||
compute/fix/variable value) may have been > {Nc}, because of the
|
||||
compression operation.
|
||||
|
|
|
@ -42,7 +42,7 @@ performed on mono-component systems.
|
|||
|
||||
The CNA calculation can be sensitive to the specified cutoff value.
|
||||
You should insure the appropriate nearest neighbors of an atom are
|
||||
found within the cutoff distance for the presumed crystal strucure.
|
||||
found within the cutoff distance for the presumed crystal structure.
|
||||
E.g. 12 nearest neighbor for perfect FCC and HCP crystals, 14 nearest
|
||||
neighbors for perfect BCC crystals. These formulas can be used to
|
||||
obtain a good cutoff distance:
|
||||
|
|
|
@ -25,7 +25,7 @@ Define a computation that calculates the center-of-mass of the group
|
|||
of atoms, including all effects due to atoms passing thru periodic
|
||||
boundaries.
|
||||
|
||||
A vector of three quantites is calculated by this compute, which
|
||||
A vector of three quantities is calculated by this compute, which
|
||||
are the x,y,z coordinates of the center of mass.
|
||||
|
||||
NOTE: The coordinates of an atom contribute to the center-of-mass in
|
||||
|
|
|
@ -47,7 +47,7 @@ any command that uses per-atom values from a compute as input. See
|
|||
"Section 6.15"_Section_howto.html#howto_15 for an overview of
|
||||
LAMMPS output options.
|
||||
|
||||
The per-atom vector values are unitlesss numbers (damage) >= 0.0.
|
||||
The per-atom vector values are unitless numbers (damage) >= 0.0.
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
|
|
|
@ -50,7 +50,7 @@ This compute calculates a per-atom vector, which can be accessed by
|
|||
any command that uses per-atom values from a compute as input. See
|
||||
Section_howto 15 for an overview of LAMMPS output options.
|
||||
|
||||
The per-atom vector values are unitlesss numbers (theta) >= 0.0.
|
||||
The per-atom vector values are unitless numbers (theta) >= 0.0.
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
|
|
|
@ -25,7 +25,7 @@ Define a computation that calculates the current displacement of each
|
|||
atom in the group from its original coordinates, including all effects
|
||||
due to atoms passing thru periodic boundaries.
|
||||
|
||||
A vector of four quantites per atom is calculated by this compute.
|
||||
A vector of four quantities per atom is calculated by this compute.
|
||||
The first 3 elements of the vector are the dx,dy,dz displacements.
|
||||
The 4th component is the total displacement, i.e. sqrt(dx*dx + dy*dy +
|
||||
dz*dz).
|
||||
|
|
|
@ -37,7 +37,7 @@ further than the threshold distance.
|
|||
NOTE: If the system is undergoing significant center-of-mass motion,
|
||||
due to thermal motion, an external force, or an initial net momentum,
|
||||
then this compute will not be able to distinguish that motion from
|
||||
local atom displacements and may generate "false postives."
|
||||
local atom displacements and may generate "false positives."
|
||||
|
||||
[Output info:]
|
||||
|
||||
|
|
|
@ -33,7 +33,7 @@ passing thru periodic boundaries. For computation of the non-Gaussian
|
|||
parameter of mean-squared displacement, see the "compute
|
||||
msd/nongauss"_compute_msd_nongauss.html command.
|
||||
|
||||
A vector of four quantites is calculated by this compute. The first 3
|
||||
A vector of four quantities is calculated by this compute. The first 3
|
||||
elements of the vector are the squared dx,dy,dz displacements, summed
|
||||
and averaged over atoms in the group. The 4th element is the total
|
||||
squared displacement, i.e. (dx*dx + dy*dy + dz*dz), summed and
|
||||
|
|
|
@ -35,7 +35,7 @@ chunk/atom"_compute_chunk_atom.html doc page and "Section
|
|||
defined and examples of how they can be used to measure properties of
|
||||
a system.
|
||||
|
||||
Four quantites are calculated by this compute for each chunk. The
|
||||
Four quantities are calculated by this compute for each chunk. The
|
||||
first 3 quantities are the squared dx,dy,dz displacements of the
|
||||
center-of-mass. The 4th component is the total squared displacement,
|
||||
i.e. (dx*dx + dy*dy + dz*dz) of the center-of-mass. These
|
||||
|
|
|
@ -30,12 +30,12 @@ Define a computation that calculates the mean-squared displacement
|
|||
(MSD) and non-Gaussian parameter (NGP) of the group of atoms,
|
||||
including all effects due to atoms passing thru periodic boundaries.
|
||||
|
||||
A vector of three quantites is calculated by this compute. The first
|
||||
A vector of three quantities is calculated by this compute. The first
|
||||
element of the vector is the total squared dx,dy,dz displacements
|
||||
drsquared = (dx*dx + dy*dy + dz*dz) of atoms, and the second is the
|
||||
fourth power of these displacements drfourth = (dx*dx + dy*dy +
|
||||
dz*dz)*(dx*dx + dy*dy + dz*dz), summed and averaged over atoms in the
|
||||
group. The 3rd component is the nonGaussian diffusion paramter NGP =
|
||||
group. The 3rd component is the nonGaussian diffusion parameter NGP =
|
||||
3*drfourth/(5*drsquared*drsquared), i.e.
|
||||
|
||||
:c,image(Eqs/compute_msd_nongauss.jpg)
|
||||
|
|
|
@ -43,7 +43,7 @@ style van der Waals interaction or not) is tallied in {evdwl}. If
|
|||
as a global scalar by this compute. This is useful when using
|
||||
"pair_style hybrid"_pair_hybrid.html if you want to know the portion
|
||||
of the total energy contributed by one sub-style. If {evalue} is
|
||||
specfied as {evdwl} or {ecoul}, then just that portion of the energy
|
||||
specified as {evdwl} or {ecoul}, then just that portion of the energy
|
||||
is stored as a global scalar.
|
||||
|
||||
NOTE: The energy returned by the {evdwl} keyword does not include tail
|
||||
|
|
|
@ -44,7 +44,7 @@ This compute calculates a per-atom vector, which can be accessed by
|
|||
any command that uses per-atom values from a compute as input. See
|
||||
Section_howto 15 for an overview of LAMMPS output options.
|
||||
|
||||
The per-atom vector values are unitlesss numbers (lambda) >= 0.0.
|
||||
The per-atom vector values are unitless numbers (lambda) >= 0.0.
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
|
|
|
@ -73,7 +73,7 @@ post-process a dump file to calculate it. This is because using the
|
|||
which may slow down your simulation. If you specify a {Rcut} <= force
|
||||
cutoff, you will force an additional neighbor list to be built at
|
||||
every timestep this command is invoked (or every reneighboring
|
||||
timestep, whichever is less frequent), which is inefficent. LAMMPS
|
||||
timestep, whichever is less frequent), which is inefficient. LAMMPS
|
||||
will warn you if this is the case. If you specify a {Rcut} > force
|
||||
cutoff, you must insure ghost atom information out to {Rcut} + {skin}
|
||||
is communicated, via the "comm_modify cutoff"_comm_modify.html
|
||||
|
|
|
@ -93,7 +93,7 @@ parameters will denote the z1=h, z2=k, and z3=l (in a global since)
|
|||
zone axis of an intersecting Ewald sphere. Diffraction intensities
|
||||
will only be computed at the intersection of the reciprocal lattice
|
||||
mesh and a {dR_Ewald} thick surface of the Ewald sphere. See the
|
||||
example 3D intestiety data and the intersection of a \[010\] zone axis
|
||||
example 3D intensity data and the intersection of a \[010\] zone axis
|
||||
in the below image.
|
||||
|
||||
:c,image(JPG/saed_ewald_intersect_small.jpg,JPG/saed_ewald_intersect.jpg)
|
||||
|
|
|
@ -208,7 +208,7 @@ This compute also optionally calculates a global array, if one or more
|
|||
of the optional values are specified. The number of rows in the array
|
||||
= the number of chunks {Nchunk} as calculated by the specified
|
||||
"compute chunk/atom"_compute_chunk_atom.html command. The number of
|
||||
columns is the number of specifed values (1 or more). These values
|
||||
columns is the number of specified values (1 or more). These values
|
||||
can be accessed by any command that uses global array values from a
|
||||
compute as input. Again, see "Section
|
||||
6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
|
||||
|
|
|
@ -118,7 +118,7 @@ needed, the subtracted degrees-of-freedom can be altered using the
|
|||
|
||||
NOTE: When using the {out} keyword with a value of {bin}, the
|
||||
calculated temperature for each bin does not include the
|
||||
degrees-of-freedom adjustment described in the preceeding paragraph,
|
||||
degrees-of-freedom adjustment described in the preceding paragraph,
|
||||
for fixes that constrain molecular motion. It does include the
|
||||
adjustment due to the {extra} option, which is applied to each bin.
|
||||
|
||||
|
|
|
@ -27,7 +27,7 @@ function (VACF), averaged over a group of atoms. Each atom's
|
|||
contribution to the VACF is its current velocity vector dotted into
|
||||
its initial velocity vector at the time the compute was specified.
|
||||
|
||||
A vector of four quantites is calculated by this compute. The first 3
|
||||
A vector of four quantities is calculated by this compute. The first 3
|
||||
elements of the vector are vx * vx0 (and similarly for the y and z
|
||||
components), summed and averaged over atoms in the group. Vx is the
|
||||
current x-component of velocity for the atom, vx0 is the initial
|
||||
|
|
|
@ -101,7 +101,7 @@ positions.
|
|||
For the {random} style, N particles are added to the system at
|
||||
randomly generated coordinates, which can be useful for generating an
|
||||
amorphous system. The particles are created one by one using the
|
||||
speficied random number {seed}, resulting in the same set of particles
|
||||
specified random number {seed}, resulting in the same set of particles
|
||||
coordinates, independent of how many processors are being used in the
|
||||
simulation. If the {region-ID} argument is specified as NULL, then
|
||||
the created particles will be anywhere in the simulation box. If a
|
||||
|
|
|
@ -82,7 +82,7 @@ LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
|||
|
||||
Unlike other dihedral styles, the hybrid dihedral style does not store
|
||||
dihedral coefficient info for individual sub-styles in a "binary
|
||||
restart files"_restart.html. Thus when retarting a simulation from a
|
||||
restart files"_restart.html. Thus when restarting a simulation from a
|
||||
restart file, you need to re-specify dihedral_coeff commands.
|
||||
|
||||
[Related commands:]
|
||||
|
|
|
@ -225,7 +225,7 @@ 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
|
||||
of xlo, etc, since they represent 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
|
||||
|
|
|
@ -237,7 +237,7 @@ diameter, which can be used as the {diameter} setting.
|
|||
|
||||
:line
|
||||
|
||||
The various kewords listed above control how the image is rendered.
|
||||
The various keywords listed above control how the image is rendered.
|
||||
As listed below, all of the keywords have defaults, most of which you
|
||||
will likely not need to change. The "dump modify"_dump_modify.html
|
||||
also has options specific to the dump image style, particularly for
|
||||
|
@ -442,7 +442,7 @@ degrees.
|
|||
|
||||
The {center} keyword determines the point in simulation space that
|
||||
will be at the center of the image. {Cx}, {Cy}, and {Cz} are
|
||||
speficied as fractions of the box dimensions, so that (0.5,0.5,0.5) is
|
||||
specified as fractions of the box dimensions, so that (0.5,0.5,0.5) is
|
||||
the center of the simulation box. These values do not have to be
|
||||
between 0.0 and 1.0, if you want the simulation box to be offset from
|
||||
the center of the image. Note, however, that if you choose strange
|
||||
|
@ -476,8 +476,8 @@ smaller. {Zfactor} must be a value > 0.0.
|
|||
The {persp} keyword determines how much depth perspective is present
|
||||
in the image. Depth perspective makes lines that are parallel in
|
||||
simulation space appear non-parallel in the image. A {pfactor} value
|
||||
of 0.0 means that parallel lines will meet at infininty (1.0/pfactor),
|
||||
which is an orthographic rendering with no persepctive. A {pfactor}
|
||||
of 0.0 means that parallel lines will meet at infinity (1.0/pfactor),
|
||||
which is an orthographic rendering with no perspective. A {pfactor}
|
||||
value between 0.0 and 1.0 will introduce more perspective. A {pfactor}
|
||||
value > 1 will create a highly skewed image with a large amount of
|
||||
perspective.
|
||||
|
|
|
@ -426,7 +426,7 @@ regions.
|
|||
|
||||
The {scale} keyword applies only to the dump {atom} style. A scale
|
||||
value of {yes} means atom coords are written in normalized units from
|
||||
0.0 to 1.0 in each box dimension. If the simluation box is triclinic
|
||||
0.0 to 1.0 in each box dimension. If the simulation box is triclinic
|
||||
(tilted), then all atom coords will still be between 0.0 and 1.0. A
|
||||
value of {no} means they are written in absolute distance units
|
||||
(e.g. Angstroms or sigma).
|
||||
|
|
|
@ -301,7 +301,7 @@ sample values" divided by {Nrepeat}. In other words it is an average
|
|||
of an average.
|
||||
|
||||
If the {norm} setting is {none}, a similar computation as for the
|
||||
{sample} seting is done, except the individual "average sample values"
|
||||
{sample} setting is done, except the individual "average sample values"
|
||||
are "summed sample values". A summed sample value is simply the chunk
|
||||
value summed over atoms in the sample, without dividing by the number
|
||||
of atoms in the sample. The output value for the chunk on the
|
||||
|
|
|
@ -219,7 +219,7 @@ to {upper} then each input value is correlated with every succeeding
|
|||
value. I.e. Cij = Vi*Vj, for i < j, so Npair = N*(N-1)/2. :l
|
||||
|
||||
If {type} is set
|
||||
to {lower} then each input value is correlated with every preceeding
|
||||
to {lower} then each input value is correlated with every preceding
|
||||
value. I.e. Cij = Vi*Vj, for i > j, so Npair = N*(N-1)/2. :l
|
||||
|
||||
If {type} is set to {auto/upper} then each input value is correlated
|
||||
|
|
|
@ -320,7 +320,7 @@ input values are averaged and {mode} = vector. The global array has #
|
|||
of rows = length of the input vectors and # of columns = number of
|
||||
inputs.
|
||||
|
||||
If the fix prouduces a scalar or vector, then the scalar and each
|
||||
If the fix produces a scalar or vector, then the scalar and each
|
||||
element of the vector can be either "intensive" or "extensive",
|
||||
depending on whether the values contributing to the scalar or vector
|
||||
element are "intensive" or "extensive". If the fix produces an array,
|
||||
|
|
|
@ -63,14 +63,14 @@ perform "static" balancing, before or between runs, see the
|
|||
|
||||
Load-balancing is typically most useful if the particles in the
|
||||
simulation box have a spatially-varying density distribution or
|
||||
where the computational cost varies signficantly between different
|
||||
where the computational cost varies significantly between different
|
||||
atoms. E.g. a model of a vapor/liquid interface, or a solid with
|
||||
an irregular-shaped geometry containing void regions, or
|
||||
"hybrid pair style simulations"_pair_hybrid.html which combine
|
||||
pair styles with different computational cost. In these cases, the
|
||||
LAMMPS default of dividing the simulation box volume into a
|
||||
regular-spaced grid of 3d bricks, with one equal-volume sub-domain
|
||||
per procesor, may assign numbers of particles per processor in a
|
||||
per processor, may assign numbers of particles per processor in a
|
||||
way that the computational effort varies significantly. This can
|
||||
lead to poor performance when the simulation is run in parallel.
|
||||
|
||||
|
@ -78,7 +78,7 @@ The balancing can be performed with or without per-particle weighting.
|
|||
With no weighting, the balancing attempts to assign an equal number of
|
||||
particles to each processor. With weighting, the balancing attempts
|
||||
to assign an equal aggregate computational weight to each processor,
|
||||
which typically inducces a different number of atoms assigned to each
|
||||
which typically induces a different number of atoms assigned to each
|
||||
processor.
|
||||
|
||||
NOTE: The weighting options listed above are documented with the
|
||||
|
@ -216,7 +216,7 @@ for a single value, except that the bounds used for each bisectioning
|
|||
take advantage of information from neighboring cuts if possible, as
|
||||
well as counts of particles at the bounds on either side of each cuts,
|
||||
which themselves were cuts in previous iterations. The latter is used
|
||||
to infer a density of pariticles near each of the current cuts. At
|
||||
to infer a density of particles near each of the current cuts. At
|
||||
each iteration, the count of particles on either side of each plane is
|
||||
tallied. If the counts do not match the target value for the plane,
|
||||
the position of the cut is adjusted based on the local density. The
|
||||
|
@ -239,7 +239,7 @@ assigned, particles migrate to their new owning processor as part of
|
|||
the normal reneighboring procedure.
|
||||
|
||||
NOTE: At each rebalance operation, the bisectioning for each cutting
|
||||
plane (line in 2d) typcially starts with low and high bounds separated
|
||||
plane (line in 2d) typically starts with low and high bounds separated
|
||||
by the extent of a processor's sub-domain in one dimension. The size
|
||||
of this bracketing region shrinks based on the local density, as
|
||||
described above, which should typically be 1/2 or more every
|
||||
|
@ -275,7 +275,7 @@ at each iteration.
|
|||
That is the procedure for the first cut. Subsequent cuts are made
|
||||
recursively, in exactly the same manner. The subset of processors
|
||||
assigned to each box make a new cut in the longest dimension of that
|
||||
box, splitting the box, the subset of processsors, and the atoms in
|
||||
box, splitting the box, the subset of processors, and the atoms in
|
||||
the box in two. The recursion continues until every processor is
|
||||
assigned a sub-box of the entire simulation domain, and owns the atoms
|
||||
in that sub-box.
|
||||
|
|
|
@ -79,8 +79,8 @@ part of bonds, angles, etc.
|
|||
|
||||
NOTE: One data structure that is not updated when a bond breaks are
|
||||
the molecule IDs stored by each atom. Even though one molecule
|
||||
becomes two moleclues due to the broken bond, all atoms in both new
|
||||
moleclues retain their original molecule IDs.
|
||||
becomes two molecules due to the broken bond, all atoms in both new
|
||||
molecules retain their original molecule IDs.
|
||||
|
||||
Computationally, each timestep this fix operates, it loops over all
|
||||
the bonds in the system and computes distances between pairs of bonded
|
||||
|
|
|
@ -118,8 +118,8 @@ of new bonds, angles, etc.
|
|||
|
||||
NOTE: One data structure that is not updated when a bond breaks are
|
||||
the molecule IDs stored by each atom. Even though two molecules
|
||||
become one moleclue due to the created bond, all atoms in the new
|
||||
moleclue retain their original molecule IDs.
|
||||
become one molecule due to the created bond, all atoms in the new
|
||||
molecule retain their original molecule IDs.
|
||||
|
||||
If the {atype} keyword is used and if an angle potential is defined
|
||||
via the "angle_style"_angle_style.html command, then any new 3-body
|
||||
|
|
|
@ -168,7 +168,7 @@ This fix is part of the MC 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 setings of the "special_bond" command must be 0,1,1 in order to
|
||||
The settings of the "special_bond" command must be 0,1,1 in order to
|
||||
use this fix, which is typical of bead-spring chains with FENE or
|
||||
harmonic bonds. This means that pairwise interactions between bonded
|
||||
atoms are turned off, but are turned on between atoms two or three
|
||||
|
|
|
@ -54,7 +54,7 @@ The external pressure tensor is specified using one or more of the
|
|||
keywords. These keywords give you the ability to specify all 6
|
||||
components of an external stress tensor, and to couple various of
|
||||
these components together so that the dimensions they represent are
|
||||
varied together during the mimimization.
|
||||
varied together during the minimization.
|
||||
|
||||
Orthogonal simulation boxes have 3 adjustable dimensions (x,y,z).
|
||||
Triclinic (non-orthogonal) simulation boxes have 6 adjustable
|
||||
|
@ -122,7 +122,7 @@ well-defined minimization problem. This is because the objective
|
|||
function being minimized changes if the box size/shape changes. In
|
||||
practice this means the minimizer can get "stuck" before you have
|
||||
reached the desired tolerance. The solution to this is to restart the
|
||||
minmizer from the new adjusted box size/shape, since that creates a
|
||||
minimizer from the new adjusted box size/shape, since that creates a
|
||||
new objective function valid for the new box size/shape. Repeat as
|
||||
necessary until the box size/shape has reached its new equilibrium.
|
||||
|
||||
|
|
|
@ -44,7 +44,7 @@ lammps/potentials directory: charmm22.cmap and charmm36.cmap.
|
|||
|
||||
The data file read by the "read_data" must contain the topology of all
|
||||
the CMAP interactions, similar to the topology data for bonds, angles,
|
||||
dihedrals, etc. Specically it should have a line like this
|
||||
dihedrals, etc. Specially it should have a line like this
|
||||
in its header section:
|
||||
|
||||
N crossterms :pre
|
||||
|
|
|
@ -107,7 +107,7 @@ When choosing the values of the four constants, it is best to first
|
|||
pick a value and sign for {alpha} that is consistent with the
|
||||
magnitudes and signs of {pvar} and {cvar}. The magnitude of {Kp}
|
||||
should then be tested over a large positive range keeping {Ki}={Kd}=0.
|
||||
A good value for {Kp} will produce a fast reponse in {pvar}, without
|
||||
A good value for {Kp} will produce a fast response in {pvar}, without
|
||||
overshooting the {setpoint}. For many applications, proportional
|
||||
feedback is sufficient, and so {Ki}={Kd}=0 can be used. In cases where
|
||||
there is a substantial lag time in the response of {pvar} to a change
|
||||
|
|
|
@ -15,7 +15,7 @@ fix ID group-ID deposit N type M seed keyword values ... :pre
|
|||
ID, group-ID are documented in "fix"_fix.html command :ulb,l
|
||||
deposit = style name of this fix command :l
|
||||
N = # of atoms or molecules to insert :l
|
||||
type = atom type to assign to inserted atoms (offset for moleclue insertion) :l
|
||||
type = atom type to assign to inserted atoms (offset for molecule insertion) :l
|
||||
M = insert a single atom or molecule every M steps :l
|
||||
seed = random # seed (positive integer) :l
|
||||
one or more keyword/value pairs may be appended to args :l
|
||||
|
@ -140,7 +140,7 @@ the molecule.
|
|||
|
||||
If the molecule template contains more than one molecule, the relative
|
||||
probability of depositing each molecule can be specified by the
|
||||
{molfrac} keyword. N relative probablities, each from 0.0 to 1.0, are
|
||||
{molfrac} keyword. N relative probabilities, each from 0.0 to 1.0, are
|
||||
specified, where N is the number of molecules in the template. Each
|
||||
time a molecule is deposited, a random number is used to sample from
|
||||
the list of relative probabilities. The N values must sum to 1.0.
|
||||
|
@ -192,7 +192,7 @@ LAMMPS prints a warning message.
|
|||
NOTE: If you are inserting finite size particles or a molecule or
|
||||
rigid body consisting of finite-size particles, then you should
|
||||
typically set R larger than the distance at which any inserted
|
||||
particle may overlap with either a previouly inserted particle or an
|
||||
particle may overlap with either a previously inserted particle or an
|
||||
existing particle. LAMMPS will issue a warning if R is smaller than
|
||||
this value, based on the radii of existing and inserted particles.
|
||||
|
||||
|
|
|
@ -31,9 +31,9 @@ fix 1 solvent evaporate 1000 10 surface 38277 molecule yes :pre
|
|||
[Description:]
|
||||
|
||||
Remove M atoms from the simulation every N steps. This can be used,
|
||||
for example, to model evaporation of solvent particles or moleclues
|
||||
for example, to model evaporation of solvent particles or molecules
|
||||
(i.e. drying) of a system. Every N steps, the number of atoms in the
|
||||
fix group and within the specifed region are counted. M of these are
|
||||
fix group and within the specified region are counted. M of these are
|
||||
chosen at random and deleted. If there are less than M eligible
|
||||
particles, then all of them are deleted.
|
||||
|
||||
|
|
|
@ -107,7 +107,7 @@ fashion. For the latter, see the {start} and {stop} keywords of the
|
|||
"run"_run.html command and the {elaplong} keyword of "thermo_style
|
||||
custom"_thermo_style.html for details.
|
||||
|
||||
For example, if a spherical indenter's x-position is specfied as v_x,
|
||||
For example, if a spherical indenter's x-position is specified as v_x,
|
||||
then this variable definition will keep it's center at a relative
|
||||
position in the simulation box, 1/4 of the way from the left edge to
|
||||
the right edge, even if the box size changes:
|
||||
|
@ -121,7 +121,7 @@ variable x equal "2.5 + 5*elaplong*dt"
|
|||
variable x equal vdisplace(2.5,5) :pre
|
||||
|
||||
If a spherical indenter's radius is specified as v_r, then these
|
||||
variable definitions will grow the size of the indenter at a specfied
|
||||
variable definitions will grow the size of the indenter at a specified
|
||||
rate.
|
||||
|
||||
variable r0 equal 0.0
|
||||
|
|
|
@ -328,7 +328,7 @@ fix must be used in conjunction with the
|
|||
"lb/viscous"_fix_lb_viscous.html fix if the force coupling constant is
|
||||
set by default, or either the "lb/viscous"_fix_lb_viscous.html fix or
|
||||
one of the "lb/rigid/pc/sphere"_fix_lb_rigid_pc_sphere.html or
|
||||
"lb/pc"_fix_lb_pc.html integrators, if the user chooses to specifiy
|
||||
"lb/pc"_fix_lb_pc.html integrators, if the user chooses to specify
|
||||
their own value for the force coupling constant.
|
||||
|
||||
[Related commands:]
|
||||
|
|
|
@ -53,7 +53,7 @@ default method for computing P.
|
|||
For fixes that calculate a contribution to the potential energy of the
|
||||
system, the {energy} keyword will include that contribution in
|
||||
thermodynamic output of potential energy. This is because the {energy
|
||||
yes} setting must be specfied to include the fix's global or per-atom
|
||||
yes} setting must be specified to include the fix's global or per-atom
|
||||
energy in the calculation performed by the "compute
|
||||
pe"_compute_pe.html or "compute pe/atom"_compute_pe_atom.html
|
||||
commands. See the "thermo_style"_thermo_style.html command for info
|
||||
|
|
|
@ -131,7 +131,7 @@ This style also sets the velocity of each atom to (omega cross Rperp)
|
|||
where omega is its angular velocity around the rotation axis and Rperp
|
||||
is a perpendicular vector from the rotation axis to the atom. If the
|
||||
defined "atom_style"_atom_style.html assigns an angular velocity or
|
||||
angular moementum or orientation to each atom ("atom
|
||||
angular momentum or orientation to each atom ("atom
|
||||
styles"_atom_style.html sphere, ellipsoid, line, tri, body), then
|
||||
those properties are also updated appropriately to correspond to the
|
||||
atom's motion and rotation over time.
|
||||
|
|
|
@ -83,7 +83,7 @@ produces additional output files. The range finder functionality
|
|||
(step 4) outputs files defining pair and bonded interaction ranges.
|
||||
The force matching functionality (step 5) outputs tabulated force
|
||||
files for every interaction in the system. Other diagnostic files can
|
||||
also be output depending on the paramters in the MS-CG library input
|
||||
also be output depending on the parameters in the MS-CG library input
|
||||
script. Again, see the documentation provided with the MS-CG library
|
||||
for more info.
|
||||
|
||||
|
|
|
@ -43,7 +43,7 @@ fix 1 all phonon 10 5000 500000 GAMMA EAM0D nasr 100 :pre
|
|||
Calculate the dynamical matrix from molecular dynamics simulations
|
||||
based on fluctuation-dissipation theory for a group of atoms.
|
||||
|
||||
Consider a crystal with \(N\) unit cells in three dimensions labelled
|
||||
Consider a crystal with \(N\) unit cells in three dimensions labeled
|
||||
\(l = (l_1, l_2, l_3)\) where \(l_i\) are integers. Each unit cell is
|
||||
defined by three linearly independent vectors \(\mathbf\{a\}_1\),
|
||||
\(\mathbf\{a\}_2\), \(\mathbf\{a\}_3\) forming a parallelipiped,
|
||||
|
|
|
@ -107,7 +107,7 @@ atoms in the molecule.
|
|||
|
||||
If the molecule template contains more than one molecule, the relative
|
||||
probability of depositing each molecule can be specified by the
|
||||
{molfrac} keyword. N relative probablities, each from 0.0 to 1.0, are
|
||||
{molfrac} keyword. N relative probabilities, each from 0.0 to 1.0, are
|
||||
specified, where N is the number of molecules in the template. Each
|
||||
time a molecule is inserted, a random number is used to sample from
|
||||
the list of relative probabilities. The N values must sum to 1.0.
|
||||
|
@ -144,7 +144,7 @@ command for the temperature compute you are using.
|
|||
|
||||
All other keywords are optional with defaults as shown below.
|
||||
|
||||
The {diam} option is only used when inserting atoms and specifes the
|
||||
The {diam} option is only used when inserting atoms and specifies the
|
||||
diameters of inserted particles. There are 3 styles: {one}, {range},
|
||||
or {poly}. For {one}, all particles will have diameter {D}. For
|
||||
{range}, the diameter of each particle will be chosen randomly and
|
||||
|
|
|
@ -121,7 +121,7 @@ as described below.
|
|||
Per-atom properties that are defined by the "atom
|
||||
style"_atom_style.html are initialized when atoms are created, e.g. by
|
||||
the "read_data"_read_data.html or "create_atoms"_create_atoms.html
|
||||
commands. The per-atom properaties defined by this fix are not. So
|
||||
commands. The per-atom properties defined by this fix are not. So
|
||||
you need to initialize them explicitly. This can be done by the
|
||||
"read_data"_read_data.html command, using its {fix} keyword and
|
||||
passing it the fix-ID of this fix.
|
||||
|
|
|
@ -167,7 +167,7 @@ zero net charge.
|
|||
NOTE: Developing QEq parameters (chi, eta, gamma, zeta, and qcore) is
|
||||
non-trivial. Charges on atoms are not guaranteed to equilibrate with
|
||||
arbitrary choices of these parameters. We do not develop these QEq
|
||||
paramters. See the examples/qeq directory for some examples.
|
||||
parameters. See the examples/qeq directory for some examples.
|
||||
|
||||
[Restart, fix_modify, output, run start/stop, minimize info:]
|
||||
|
||||
|
|
|
@ -42,12 +42,12 @@ Only charges on the atoms in the specified group are equilibrated.
|
|||
The fix relies on the pair style (COMB in this case) to calculate the
|
||||
per-atom electronegativity (effective force on the charges). An
|
||||
electronegativity equalization calculation (or QEq) is performed in an
|
||||
interative fashion, which in parallel requires communication at each
|
||||
iterative fashion, which in parallel requires communication at each
|
||||
iteration for processors to exchange charge information about nearby
|
||||
atoms with each other. See "Rappe_and_Goddard"_#Rappe_and_Goddard and
|
||||
"Rick_and_Stuart"_#Rick_and_Stuart for details.
|
||||
|
||||
During a run, charge equilibration is peformed every {Nevery} time
|
||||
During a run, charge equilibration is performed every {Nevery} time
|
||||
steps. Charge equilibration is also always enforced on the first step
|
||||
of each run. The {precision} argument controls the tolerance for the
|
||||
difference in electronegativity for all atoms during charge
|
||||
|
@ -55,7 +55,7 @@ equilibration. {Precision} is a trade-off between the cost of
|
|||
performing charge equilibration (more iterations) and accuracy.
|
||||
|
||||
If the {file} keyword is used, then information about each
|
||||
equilibration calculation is written to the specifed file.
|
||||
equilibration calculation is written to the specified file.
|
||||
|
||||
:line
|
||||
|
||||
|
|
|
@ -88,7 +88,7 @@ conformation. You may need to experiment to determine what value of K
|
|||
works best for a given application.
|
||||
|
||||
For the case of finding a minimum energy structure for a single
|
||||
molecule with particular restratins (e.g. for fitting forcefield
|
||||
molecule with particular restraints (e.g. for fitting forcefield
|
||||
parameters or constructing a potential energy surface), commands such
|
||||
as the following may be useful:
|
||||
|
||||
|
|
|
@ -325,7 +325,7 @@ simulation. The effects of these keywords are similar to those
|
|||
defined in "fix npt/nph"_fix_nh.html
|
||||
|
||||
NOTE: Currently the {rigid/npt}, {rigid/nph}, {rigid/npt/small}, and
|
||||
{rigid/nph/small} styles do not support triclinic (non-orthongonal)
|
||||
{rigid/nph/small} styles do not support triclinic (non-orthogonal)
|
||||
boxes.
|
||||
|
||||
The target pressures for each of the 6 components of the stress tensor
|
||||
|
|
|
@ -21,7 +21,7 @@ solver = {lammps_rk4,rkf45} = rk4 is an explicit 4th order Runge-Kutta method; r
|
|||
minSteps = # of steps for rk4 solver or minimum # of steps for rkf45 (rk4 or rkf45)
|
||||
maxSteps = maximum number of steps for the rkf45 solver (rkf45 only)
|
||||
relTol = relative tolerance for the rkf45 solver (rkf45 only)
|
||||
absTol = absolute tolernace for the rkf45 solver (rkf45 only)
|
||||
absTol = absolute tolerance for the rkf45 solver (rkf45 only)
|
||||
diag = Diagnostics frequency for the rkf45 solver (optional, rkf45 only) :ul
|
||||
|
||||
[Examples:]
|
||||
|
|
|
@ -52,7 +52,7 @@ intensities at a single snapshot.
|
|||
To produce output in the image data vtk format ghost data is added
|
||||
outside the {Kmax} range assigned in the compute saed. The ghost data is
|
||||
assigned a value of -1 and can be removed setting a minimum isovolume
|
||||
of 0 within the vizualiziton software. SAED images can be created by
|
||||
of 0 within the visualization software. SAED images can be created by
|
||||
visualizing a spherical slice of the data that is centered at
|
||||
R_Ewald*\[h k l\]/norm(\[h k l\]), where R_Ewald=1/lambda.
|
||||
|
||||
|
@ -88,7 +88,7 @@ averaging is done; values are simply generated on timesteps
|
|||
|
||||
:line
|
||||
|
||||
The output for fix ave/time/saed is a file writen with the 3rd generation
|
||||
The output for fix ave/time/saed is a file written with the 3rd generation
|
||||
vtk image data formatting. The filename assigned by the {file} keyword is
|
||||
appended with _N.vtk where N is an index (0,1,2...) to account for multiple
|
||||
diffraction intensity outputs.
|
||||
|
|
|
@ -27,7 +27,7 @@ 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.
|
||||
This fix creates reads a triangulated 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.
|
||||
|
||||
|
|
|
@ -30,7 +30,7 @@ location at the time the fix command was issued. At each timestep,
|
|||
the magnitude of the force on each atom is -Kr, where r is the
|
||||
displacement of the atom from its current position to its initial
|
||||
position. The distance r correctly takes into account any crossings
|
||||
of periodic boundary by the atom since it was in its intitial
|
||||
of periodic boundary by the atom since it was in its initial
|
||||
position.
|
||||
|
||||
With the (optional) dir flag, one can select in which direction the
|
||||
|
|
|
@ -54,18 +54,18 @@ fix 1 srd srd 10 big 0.5 0.25 482984 collision slip search 0.5 :pre
|
|||
|
||||
[Description:]
|
||||
|
||||
Treat a group of partilces as stochastic rotation dynamics (SRD)
|
||||
Treat a group of particles as stochastic rotation dynamics (SRD)
|
||||
particles that serve as a background solvent when interacting with big
|
||||
(colloidal) particles in groupbig-ID. The SRD formalism is described
|
||||
in "(Hecht)"_#Hecht. The key idea behind using SRD particles as a
|
||||
cheap coarse-grained solvent is that SRD particles do not interact
|
||||
with each other, but only with the solute particles, which in LAMMPS
|
||||
can be spheroids, ellipsoids, or line segments, or triangles, or rigid
|
||||
bodies containing multiple spherioids or ellipsoids or line segments
|
||||
bodies containing multiple spheriods or ellipsoids or line segments
|
||||
or triangles. The collision and rotation properties of the model
|
||||
imbue the SRD particles with fluid-like properties, including an
|
||||
effective viscosity. Thus simulations with large solute particles can
|
||||
be run more quickly, to measure solute propoerties like diffusivity
|
||||
be run more quickly, to measure solute properties like diffusivity
|
||||
and viscosity in a background fluid. The usual LAMMPS fixes for such
|
||||
simulations, such as "fix deform"_fix_deform.html, "fix
|
||||
viscosity"_fix_viscosity.html, and "fix nvt/sllod"_fix_nvt_sllod.html,
|
||||
|
@ -230,7 +230,7 @@ error or warning is generated. Similarly, if the ratio of any bin
|
|||
dimension with {hgrid} exceeds (1 +/- tolerance), then an error or
|
||||
warning is generated.
|
||||
|
||||
NOTE: The fix srd command can be used with simluations the size and/or
|
||||
NOTE: The fix srd command can be used with simulations the size and/or
|
||||
shape of the simulation box changes. This can be due to non-periodic
|
||||
boundary conditions or the use of fixes such as the "fix
|
||||
deform"_fix_deform.html or "fix wall/srd"_fix_wall_srd.html commands
|
||||
|
|
|
@ -39,7 +39,7 @@ scaling factor from a suitably chosen (gaussian) distribution rather
|
|||
than having it determined from the time constant directly. In the case
|
||||
of {temp/csld} the velocities are updated to a linear combination of
|
||||
the current velocities with a gaussian distribution of velocities at
|
||||
the desired temperature. Both termostats are applied every timestep.
|
||||
the desired temperature. Both thermostats are applied every timestep.
|
||||
|
||||
The thermostat is applied to only the translational degrees of freedom
|
||||
for the particles, which is an important consideration for finite-size
|
||||
|
|
|
@ -44,7 +44,7 @@ ramped value between the {Tstart} and {Tstop} temperatures at the
|
|||
beginning and end of the run.
|
||||
|
||||
NOTE: This thermostat will generate an error if the current
|
||||
temperature is zero at the end of a timestep it is inovoked on. It
|
||||
temperature is zero at the end of a timestep it is invoked on. It
|
||||
cannot rescale a zero temperature.
|
||||
|
||||
{Tstart} can be specified as an equal-style "variable"_variable.html.
|
||||
|
|
|
@ -41,7 +41,7 @@ can be used to extend the time scale of atomistic simulations, in
|
|||
particular when long time scale relaxation effects must be considered;
|
||||
some interesting examples are given in the review by "(Neyts)"_#Neyts.
|
||||
An example of a typical use case would be the modelling of chemical
|
||||
vapour deposition (CVD) processes on a surface, in which impacts by
|
||||
vapor deposition (CVD) processes on a surface, in which impacts by
|
||||
gas-phase species can be performed using MD, but subsequent relaxation
|
||||
of the surface is too slow to be done using MD only. Using tfMC can
|
||||
allow for a much faster relaxation of the surface, so that higher
|
||||
|
|
|
@ -106,7 +106,7 @@ electron stopping coupling parameter. C_e, rho_e, and kappa_e are
|
|||
specified as parameters to the fix. The other quantities are derived.
|
||||
The form of the heat diffusion equation used here is almost the same
|
||||
as that in equation 6 of "(Duffy)"_#Duffy, with the exception that the
|
||||
electronic density is explicitly reprensented, rather than being part
|
||||
electronic density is explicitly represented, rather than being part
|
||||
of the specific heat parameter.
|
||||
|
||||
Currently, fix ttm assumes that none of the user-supplied parameters
|
||||
|
@ -151,7 +151,7 @@ output timestep. The timestep itself is given in the first column.
|
|||
The next Nx*Ny*Nz columns contain the temperatures for the atomic
|
||||
subsystem, and the final Nx*Ny*Nz columns contain the temperatures for
|
||||
the electronic subsystem. The ordering of the Nx*Ny*Nz columns is
|
||||
with the z index varing fastest, y the next fastest, and x the
|
||||
with the z index varying fastest, y the next fastest, and x the
|
||||
slowest.
|
||||
|
||||
These fixes do not change the coordinates of their atoms; they only
|
||||
|
|
|
@ -136,7 +136,7 @@ An array is produced if multiple input values are specified.
|
|||
The length of the vector or the number of rows in the array grows
|
||||
by 1 every {Nevery} timesteps.
|
||||
|
||||
If the fix prouduces a vector, then the entire vector will be either
|
||||
If the fix produces a vector, then the entire vector will be either
|
||||
"intensive" or "extensive", depending on whether the values stored in
|
||||
the vector are "intensive" or "extensive". If the fix produces an
|
||||
array, then all elements in the array must be the same, either
|
||||
|
|
|
@ -102,7 +102,7 @@ parameter.
|
|||
An alternative method for calculating a viscosity is to run a NEMD
|
||||
simulation, as described in "Section
|
||||
6.13"_Section_howto.html#howto_13 of the manual. NEMD simulations
|
||||
deform the simmulation box via the "fix deform"_fix_deform.html
|
||||
deform the simulation box via the "fix deform"_fix_deform.html
|
||||
command. Thus they cannot be run on a charged system using a "PPPM
|
||||
solver"_kspace_style.html since PPPM does not currently support
|
||||
non-orthogonal boxes. Using fix viscosity keeps the box orthogonal;
|
||||
|
|
|
@ -136,7 +136,7 @@ of 1/volume.
|
|||
The {wall/colloid} interaction is derived by integrating over
|
||||
constituent LJ particles of size {sigma} within the colloid particle
|
||||
and a 3d half-lattice of Lennard-Jones 12/6 particles of size {sigma}
|
||||
in the wall. As mentioned in the preceeding paragraph, the density of
|
||||
in the wall. As mentioned in the preceding paragraph, the density of
|
||||
particles in the wall and colloid can be different, as specified by
|
||||
the {epsilon} pre-factor.
|
||||
|
||||
|
|
|
@ -85,7 +85,7 @@ versions used Kn and Kt from the pairwise interaction and hardwired
|
|||
dampflag to 1, rather than letting them be specified directly. This
|
||||
means you can set the values of the wall/particle coefficients
|
||||
appropriately in the current code to reproduce the results of a
|
||||
prevoius Hertzian monodisperse calculation. For example, for the
|
||||
previous Hertzian monodisperse calculation. For example, for the
|
||||
common case of a monodisperse system with particles of diameter 1, Kn,
|
||||
Kt, gamma_n, and gamma_s should be set sqrt(2.0) larger than they were
|
||||
previously.
|
||||
|
|
|
@ -153,7 +153,7 @@ material.
|
|||
|
||||
[Restart, fix_modify, output, run start/stop, minimize info:]
|
||||
|
||||
Similiar to "fix wall/gran"_fix_wall_gran.html command, this fix
|
||||
Similar to "fix wall/gran"_fix_wall_gran.html command, this fix
|
||||
writes the shear friction state of atoms interacting with the wall to
|
||||
"binary restart files"_restart.html, so that a simulation can continue
|
||||
correctly if granular potentials with shear "history" effects are
|
||||
|
@ -169,7 +169,7 @@ So you must re-define your region and if it is a moving region, define
|
|||
its motion attributes in a way that is consistent with the simulation
|
||||
that wrote the restart file. In particular, if you want to change the
|
||||
region motion attributes (e.g. its velocity), then you should ensure
|
||||
the postition/orientation of the region at the initial restart
|
||||
the position/orientation of the region at the initial restart
|
||||
timestep is the same as it was on the timestep the restart file was
|
||||
written. If this is not possible, you may need to ignore info in the
|
||||
restart file by defining a new fix wall/gran/region command in your
|
||||
|
|
|
@ -24,7 +24,7 @@ keyword = {pos} or {vel} or {ramp} or {units} :l
|
|||
{ramp} = use a linear velocity ramp from 0 to vz
|
||||
{temp} args = target damp seed extent
|
||||
target = target velocity for region immediately ahead of the piston
|
||||
damp = damping paramter (time units)
|
||||
damp = damping parameter (time units)
|
||||
seed = random number seed for langevin kicks
|
||||
extent = extent of thermostated region (distance units)
|
||||
{units} value = {lattice} or {box}
|
||||
|
|
|
@ -93,7 +93,7 @@ system temperature has reached a certain value, and if so, breaks out
|
|||
of the loop to finish the run. Note that any variable could be
|
||||
checked, so long as it is current on the timestep when the run
|
||||
completes. As explained on the "variable"_variable.html doc page,
|
||||
this can be insured by includig the variable in thermodynamic output.
|
||||
this can be insured by including the variable in thermodynamic output.
|
||||
|
||||
variable myTemp equal temp
|
||||
label loop
|
||||
|
|
|
@ -60,7 +60,7 @@ LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
|||
|
||||
Unlike other improper styles, the hybrid improper style does not store
|
||||
improper coefficient info for individual sub-styles in a "binary
|
||||
restart files"_restart.html. Thus when retarting a simulation from a
|
||||
restart files"_restart.html. Thus when restarting a simulation from a
|
||||
restart file, you need to re-specify improper_coeff commands.
|
||||
|
||||
[Related commands:]
|
||||
|
|
|
@ -87,7 +87,7 @@ system temperature has reached a certain value, and if so, breaks out
|
|||
of the loop to finish the run. Note that any variable could be
|
||||
checked, so long as it is current on the timestep when the run
|
||||
completes. As explained on the "variable"_variable.html doc page,
|
||||
this can be insured by includig the variable in thermodynamic output.
|
||||
this can be insured by including the variable in thermodynamic output.
|
||||
|
||||
variable myTemp equal temp
|
||||
label loop
|
||||
|
|
|
@ -341,7 +341,7 @@ kspace_style none :pre
|
|||
Adam Hilger, NY (1989).
|
||||
|
||||
:link(Kolafa)
|
||||
[(Kolafa)] Kolafa and Perram, Molecular Simualtion, 9, 351 (1992).
|
||||
[(Kolafa)] Kolafa and Perram, Molecular Simulation, 9, 351 (1992).
|
||||
|
||||
:link(Petersen)
|
||||
[(Petersen)] Petersen, J Chem Phys, 103, 3668 (1995).
|
||||
|
|
|
@ -201,7 +201,7 @@ minimum to the specified energy or force tolerance.
|
|||
Note that a cutoff Lennard-Jones potential (and others) can be shifted
|
||||
so that its energy is 0.0 at the cutoff via the
|
||||
"pair_modify"_pair_modify.html command. See the doc pages for
|
||||
inidividual "pair styles"_pair_style.html for details. Note that
|
||||
individual "pair styles"_pair_style.html for details. Note that
|
||||
Coulombic potentials always have a cutoff, unless versions with a
|
||||
long-range component are used (e.g. "pair_style
|
||||
lj/cut/coul/long"_pair_lj.html). The CHARMM potentials go to 0.0 at
|
||||
|
|
|
@ -58,7 +58,7 @@ would see with one or more physical processors per replica. See
|
|||
discussion.
|
||||
|
||||
NOTE: As explained below, a NEB calculation perfoms a damped dynamics
|
||||
minimization across all the replicas. The mimimizer uses whatever
|
||||
minimization across all the replicas. The minimizer uses whatever
|
||||
timestep you have defined in your input script, via the
|
||||
"timestep"_timestep.html command. Often NEB will converge more
|
||||
quickly if you use a timestep about 10x larger than you would normally
|
||||
|
@ -81,7 +81,7 @@ inter-replica springs and the forces they feel and their motion is
|
|||
computed in the usual way due only to other atoms within their
|
||||
replica. Conceptually, the non-NEB atoms provide a background force
|
||||
field for the NEB atoms. They can be allowed to move during the NEB
|
||||
minimiation procedure (which will typically induce different
|
||||
minimization procedure (which will typically induce different
|
||||
coordinates for non-NEB atoms in different replicas), or held fixed
|
||||
using other LAMMPS commands such as "fix setforce"_fix_setforce.html.
|
||||
Note that the "partition"_partition.html command can be used to invoke
|
||||
|
@ -97,7 +97,7 @@ Conceptually, the initial configuration for the first replica should
|
|||
be a state with all the atoms (NEB and non-NEB) having coordinates on
|
||||
one side of the energy barrier. A perfect energy minimum is not
|
||||
required, since atoms in the first replica experience no spring forces
|
||||
from the 2nd replica. Thus the damped dynamics minimizaiton will
|
||||
from the 2nd replica. Thus the damped dynamics minimization will
|
||||
drive the first replica to an energy minimum if it is not already
|
||||
there. However, you will typically get better convergence if the
|
||||
initial state is already at a minimum. For example, for a system with
|
||||
|
@ -366,7 +366,7 @@ parameters.
|
|||
There are 2 Python scripts provided in the tools/python directory,
|
||||
neb_combine.py and neb_final.py, which are useful in analyzing output
|
||||
from a NEB calculation. Assume a NEB simulation with M replicas, and
|
||||
the NEB atoms labelled with a specific atom type.
|
||||
the NEB atoms labeled with a specific atom type.
|
||||
|
||||
The neb_combine.py script extracts atom coords for the NEB atoms from
|
||||
all M dump files and creates a single dump file where each snapshot
|
||||
|
|
|
@ -110,7 +110,7 @@ USER-OMP.
|
|||
If this command is specified in an input script, it must be near the
|
||||
top of the script, before the simulation box has been defined. This
|
||||
is because it specifies settings that the accelerator packages use in
|
||||
their intialization, before a simultion is defined.
|
||||
their initialization, before a simulation is defined.
|
||||
|
||||
This command can also be specified from the command-line when
|
||||
launching LAMMPS, using the "-pk" "command-line
|
||||
|
@ -199,7 +199,7 @@ the default.
|
|||
The {split} keyword can be used for load balancing force calculations
|
||||
between CPU and GPU cores in GPU-enabled pair styles. If 0 < {split} <
|
||||
1.0, a fixed fraction of particles is offloaded to the GPU while force
|
||||
calculation for the other particles occurs simulataneously on the CPU.
|
||||
calculation for the other particles occurs simultaneously on the CPU.
|
||||
If {split} < 0.0, the optimal fraction (based on CPU and GPU timings)
|
||||
is calculated every 25 timesteps, i.e. dynamic load-balancing across
|
||||
the CPU and GPU is performed. If {split} = 1.0, all force
|
||||
|
@ -295,7 +295,7 @@ For more details, including examples of how to set the OMP_NUM_THREADS
|
|||
environment variable, see the discussion of the {Nthreads} setting on
|
||||
this doc page for the "package omp" command. Nthreads is a required
|
||||
argument for the USER-OMP package. Its meaning is exactly the same
|
||||
for the USER-INTEL pacakge.
|
||||
for the USER-INTEL package.
|
||||
|
||||
NOTE: If you build LAMMPS with both the USER-INTEL and USER-OMP
|
||||
packages, be aware that both packages allow setting of the {Nthreads}
|
||||
|
@ -347,7 +347,7 @@ automatically throughout the run. This typically give performance
|
|||
within 5 to 10 percent of the optimal fixed fraction.
|
||||
|
||||
The {ghost} keyword determines whether or not ghost atoms, i.e. atoms
|
||||
at the boundaries of proessor sub-domains, are offloaded for neighbor
|
||||
at the boundaries of processor sub-domains, are offloaded for neighbor
|
||||
and force calculations. When the value = "no", ghost atoms are not
|
||||
offloaded. This option can reduce the amount of data transfer with
|
||||
the coprocessor and can also overlap MPI communication of forces with
|
||||
|
@ -516,7 +516,7 @@ for OpenMPI. Check your MPI documentation for additional details.
|
|||
What combination of threads and MPI tasks gives the best performance
|
||||
is difficult to predict and can depend on many components of your
|
||||
input. Not all features of LAMMPS support OpenMP threading via the
|
||||
USER-OMP packaage and the parallel efficiency can be very different,
|
||||
USER-OMP package and the parallel efficiency can be very different,
|
||||
too.
|
||||
|
||||
Optional keyword/value pairs can also be specified. Each has a
|
||||
|
@ -527,7 +527,7 @@ multi-threaded in addition to force calculations. If {neigh} is set
|
|||
to {no} then neighbor list calculation is performed only by MPI tasks
|
||||
with no OpenMP threading. If {mode} is {yes} (the default), a
|
||||
multi-threaded neighbor list build is used. Using {neigh} = {yes} is
|
||||
almost always faster and should produce idential neighbor lists at the
|
||||
almost always faster and should produce identical neighbor lists at the
|
||||
expense of using more memory. Specifically, neighbor list pages are
|
||||
allocated for all threads at the same time and each thread works
|
||||
within its own pages.
|
||||
|
|
|
@ -53,7 +53,7 @@ The {rebo} pair style computes the Reactive Empirical Bond Order (REBO)
|
|||
Potential of "(Brenner)"_#Brenner. Note that this is the so-called
|
||||
2nd generation REBO from 2002, not the original REBO from 1990.
|
||||
As discussed below, 2nd generation REBO is closely related to the
|
||||
intial AIREBO; it is just a subset of the potential energy terms.
|
||||
initial AIREBO; it is just a subset of the potential energy terms.
|
||||
|
||||
The AIREBO potential consists of three terms:
|
||||
|
||||
|
|
|
@ -36,11 +36,11 @@ developed by Pettifor ("Pettifor_1"_#Pettifor_1,
|
|||
"Pettifor_2"_#Pettifor_2, "Pettifor_3"_#Pettifor_3) and later updated
|
||||
by Murdick, Zhou, and Ward ("Murdick"_#Murdick, "Ward"_#Ward).
|
||||
Currently, BOP potential files for these systems are provided with
|
||||
LAMMPS: AlCu, CCu, CdTe, CdTeSe, CdZnTe, CuH, GaAs. A sysstem with
|
||||
LAMMPS: AlCu, CCu, CdTe, CdTeSe, CdZnTe, CuH, GaAs. A system with
|
||||
only a subset of these elements, including a single element (e.g. C or
|
||||
Cu or Al or Ga or Zn or CdZn), can also be modeled by using the
|
||||
appropriate alloy file and assigning all atom types to the
|
||||
singleelement or subset of elements via the pair_coeff command, as
|
||||
single element or subset of elements via the pair_coeff command, as
|
||||
discussed below.
|
||||
|
||||
The BOP potential consists of three terms:
|
||||
|
@ -49,7 +49,7 @@ The BOP potential consists of three terms:
|
|||
|
||||
where phi_ij(r_ij) is a short-range two-body function representing the
|
||||
repulsion between a pair of ion cores, beta_(sigma,ij)(r_ij) and
|
||||
beta_(sigma,ij)(r_ij) are respectively sigma and pi bond ingtegrals,
|
||||
beta_(sigma,ij)(r_ij) are respectively sigma and pi bond integrals,
|
||||
THETA_(sigma,ij) and THETA_(pi,ij) are sigma and pi bond-orders, and
|
||||
U_prom is the promotion energy for sp-valent systems.
|
||||
|
||||
|
@ -299,7 +299,7 @@ of the g_(sigma,jik)(THETA_ijk) for e_1-e_1-e_1 interaction. The
|
|||
function can contain up to 10 term thus 10 constants. The first line
|
||||
can contain up to five constants. If the spline has more than five
|
||||
terms the second line will contain the remaining constants The
|
||||
following lines will then contain the constants for the remainaing g0,
|
||||
following lines will then contain the constants for the remaining g0,
|
||||
g1, g2... (for e_1-e_1-e_2) and the other three body
|
||||
interactions :l
|
||||
:ule
|
||||
|
|
|
@ -86,7 +86,7 @@ For style {comb}, the provided potential file {ffield.comb} contains
|
|||
all currently-available 2nd generation COMB parameterizations: for Si,
|
||||
Cu, Hf, Ti, O, their oxides and Zr, Zn and U metals. For style
|
||||
{comb3}, the potential file {ffield.comb3} contains all
|
||||
currently-available 3rd generation COMB paramterizations: O, Cu, N, C,
|
||||
currently-available 3rd generation COMB parameterizations: O, Cu, N, C,
|
||||
H, Ti, Zn and Zr. The status of the optimization of the compounds, for
|
||||
example Cu<sub>2</sub>O, TiN and hydrocarbons, are given in the
|
||||
following table:
|
||||
|
|
|
@ -130,7 +130,7 @@ where {alpha} is the damping parameter, and erc() and erfc() are
|
|||
error-function and complementary error-function terms. This potential
|
||||
is essentially a short-range, spherically-truncated,
|
||||
charge-neutralized, shifted, pairwise {1/r} summation. With a
|
||||
manipulation of adding and substracting a self term (for i = j) to the
|
||||
manipulation of adding and subtracting a self term (for i = j) to the
|
||||
first and second term on the right-hand-side, respectively, and a
|
||||
small enough {alpha} damping parameter, the second term shrinks and
|
||||
the potential becomes a rapidly-converging real-space summation. With
|
||||
|
@ -188,7 +188,7 @@ but there is no conceptual problem with extending it to nitrides and
|
|||
carbides (such as SiC, TiN). Pair coul/strietz used by itself or with
|
||||
any other pair style such as EAM, MEAM, Tersoff, or LJ in
|
||||
hybrid/overlay mode. To do this, you would need to provide a
|
||||
Streitz-Mintmire parameterizaion for the material being modeled.
|
||||
Streitz-Mintmire parameterization for the material being modeled.
|
||||
|
||||
:line
|
||||
|
||||
|
@ -222,7 +222,7 @@ molecule is 500, then its 2 H atoms must have IDs 501 and 502.
|
|||
|
||||
See the "howto section"_Section_howto.html#howto_8 for more
|
||||
information on how to use the TIP4P pair styles and lists of
|
||||
parameters to set. Note that the neighobr list cutoff for Coulomb
|
||||
parameters to set. Note that the neighbor list cutoff for Coulomb
|
||||
interactions is effectively extended by a distance 2*qdist when using
|
||||
the TIP4P pair style, to account for the offset distance of the
|
||||
fictitious charges on O atoms in water molecules. Thus it is
|
||||
|
|
|
@ -23,11 +23,11 @@ pair_coeff 1 4 78. 1.375 0.112 :pre
|
|||
|
||||
[Description:]
|
||||
|
||||
Style {coul/diel} computes a Coulomb correction for implict solvent
|
||||
ion interactions in which the dielectric perimittivity is distance dependent.
|
||||
Style {coul/diel} computes a Coulomb correction for implicit solvent
|
||||
ion interactions in which the dielectric permittivity is distance dependent.
|
||||
The dielectric permittivity epsilon_D(r) connects to limiting regimes:
|
||||
One limit is defined by a small dielectric permittivity (close to vacuum)
|
||||
at or close to contact seperation between the ions. At larger separations
|
||||
at or close to contact separation between the ions. At larger separations
|
||||
the dielectric permittivity reaches a bulk value used in the regular Coulomb
|
||||
interaction coul/long or coul/cut.
|
||||
The transition is modeled by a hyperbolic function which is incorporated
|
||||
|
|
|
@ -95,7 +95,7 @@ entries would be required, etc.
|
|||
|
||||
At the moment, only a single element parametrization is
|
||||
implemented. However, the author is not aware of other
|
||||
multi-element EDIP parametrizations. If you know any and
|
||||
multi-element EDIP parameterization. If you know any and
|
||||
you are interest in that, please contact the author of
|
||||
the EDIP package.
|
||||
|
||||
|
|
|
@ -149,7 +149,7 @@ command.
|
|||
|
||||
:line
|
||||
|
||||
The {limit/eradius} and {pressure/evirials} keywrods are optional.
|
||||
The {limit/eradius} and {pressure/evirials} keywords are optional.
|
||||
Neither or both must be specified. If not specified they are unset.
|
||||
|
||||
The {limit/eradius} keyword is used to restrain electron size from
|
||||
|
@ -197,7 +197,7 @@ partitioning changes, the total energy remains similar).
|
|||
|
||||
:line
|
||||
|
||||
NOTE: This implemention of eFF gives a reasonably accurate description
|
||||
NOTE: This implementation of eFF gives a reasonably accurate description
|
||||
for systems containing nuclei from Z = 1-6 in "all electron"
|
||||
representations. For systems with increasingly non-spherical
|
||||
electrons, Users should use the ECP representations. ECPs are now
|
||||
|
@ -284,7 +284,7 @@ that package. See the "Making LAMMPS"_Section_start.html#start_3
|
|||
section for more info.
|
||||
|
||||
These pair styles require that particles store electron attributes
|
||||
such as radius, radial velocity, and radital force, as defined by the
|
||||
such as radius, radial velocity, and radial force, as defined by the
|
||||
"atom_style"_atom_style.html. The {electron} atom style does all of
|
||||
this.
|
||||
|
||||
|
|
|
@ -97,7 +97,7 @@ pair_coeff * * Na Cl ffield.eim Na Na Na Cl :pre
|
|||
The 1st 2 arguments must be * * so as to span all LAMMPS atom types.
|
||||
The filename is the EIM potential file. The Na and Cl arguments
|
||||
(before the file name) are the two elements for which info will be
|
||||
extracted from the potentail file. The first three trailing Na
|
||||
extracted from the potential file. The first three trailing Na
|
||||
arguments map LAMMPS atom types 1,2,3 to the EIM Na element. The
|
||||
final Cl argument maps LAMMPS atom type 4 to the EIM Cl element.
|
||||
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue