forked from lijiext/lammps
Merge pull request #1214 from akohlmey/collected-small-changes
Collected small changes and many spelling fixes for next release candidate
This commit is contained in:
commit
421f97e444
|
@ -791,6 +791,13 @@ foreach(PKG ${DEFAULT_PACKAGES})
|
|||
endif()
|
||||
endforeach()
|
||||
|
||||
# packages that need defines set
|
||||
foreach(PKG MPIIO)
|
||||
if(PKG_${PKG})
|
||||
add_definitions(-DLMP_${PKG})
|
||||
endif()
|
||||
endforeach()
|
||||
|
||||
# dedicated check for entire contents of accelerator packages
|
||||
foreach(PKG ${ACCEL_PACKAGES})
|
||||
set(${PKG}_SOURCES_DIR ${LAMMPS_SOURCE_DIR}/${PKG})
|
||||
|
|
|
@ -107,7 +107,9 @@ Here are some items to check:
|
|||
* new style docs should be added to the "overview" files in
|
||||
`doc/src/Commands_*.txt`, `doc/src/{fixes,computes,pairs,bonds,...}.txt`
|
||||
and `doc/src/lammps.book`
|
||||
* new files in packages should be added to `src/.gitignore`
|
||||
* check whether manual cleanly translates with `make html` and `make pdf`
|
||||
* check spelling of manual with `make spelling` in doc folder
|
||||
* new source files in packages should be added to `src/.gitignore`
|
||||
* removed or renamed files in packages should be added to `src/Purge.list`
|
||||
* C++ source files should use C++ style include files for accessing
|
||||
C-library APIs, e.g. `#include <cstdlib>` instead of `#include <stdlib.h>`.
|
||||
|
|
|
@ -292,7 +292,7 @@ This will create a lammps/doc/html dir with the HTML doc pages so that
|
|||
you can browse them locally on your system. Type "make" from the
|
||||
lammps/doc dir to see other options.
|
||||
|
||||
NOTE: You can also download a tarball of the documention for the
|
||||
NOTE: You can also download a tarball of the documentation for the
|
||||
current LAMMPS version (HTML and PDF files), from the website
|
||||
"download page"_http://lammps.sandia.gov/download.html.
|
||||
|
||||
|
|
|
@ -732,7 +732,7 @@ can be shared across multiple MD packages and can be updated, for as
|
|||
long as the shared PLUMED library is ABI-compatible. The third linkage
|
||||
mode is "runtime" which allows to switch the PLUMED kernel at runtime
|
||||
between different variants through setting the PLUMED_KERNEL environment
|
||||
varible, which has to point to the location of the libplumedKernel.so
|
||||
variable, which has to point to the location of the libplumedKernel.so
|
||||
dynamical shared object, which is then loaded at runtime. This is
|
||||
particularly convenient for doing PLUMED development and comparing
|
||||
multiple PLUMED versions without having to recompile the hosting MD
|
||||
|
@ -750,7 +750,7 @@ a global PLUMED installation or downloading it during building LAMMPS.
|
|||
-D PLUMED_MODE=value # Linkage mode for PLUMED, value = static (default), shared, or runtime :pre
|
||||
|
||||
If DOWNLOAD_PLUMED is set to "yes", the PLUMED library will be
|
||||
downloaded (the version of that is hardcoded to a vetted version of
|
||||
downloaded (the version of that is hard-coded to a vetted version of
|
||||
PLUMED, usually a recent stable release version) and built inside the
|
||||
CMake build directory. If DOWNLOAD_PLUMED is set to "no" (the default),
|
||||
CMake will try to detect an installed version of PLUMED and link to
|
||||
|
@ -788,7 +788,7 @@ Note that 2 symbolic (soft) links, "includelink" and "liblink" are
|
|||
created in lib/plumed to point into the location of the PLUMED build to
|
||||
use and also a new file lib/plumed/Makefile.lammps is created with
|
||||
settings suitable for LAMMPS to compile and link PLUMED in the desired
|
||||
linkage mode. After this step is compleded, you can install the
|
||||
linkage mode. After this step is completed, you can install the
|
||||
USER-PLUMED package and compile LAMMPS in the usual manner:
|
||||
|
||||
make yes-user-plumed
|
||||
|
@ -804,7 +804,7 @@ operating systems, using the static linkage is expected to be the most
|
|||
portable, and thus set to be the default.
|
||||
|
||||
If you want to change the linkage mode, you have to re-run "make
|
||||
lib-plumed" with the desired settings [and] do a reinstall if the
|
||||
lib-plumed" with the desired settings [and] do a re-install if the
|
||||
USER-PLUMED package with "make yes-user-plumed" to update the required
|
||||
makefile settings with the changes in the lib/plumed folder.
|
||||
|
||||
|
|
|
@ -139,7 +139,7 @@ adequate.
|
|||
[Makefile.machine setting]:
|
||||
|
||||
LMP_INC = -DLAMMPS_SMALLBIG # or -DLAMMPS_BIGBIG or -DLAMMPS_SMALLSMALL :pre
|
||||
# default is LAMMMPS_SMALLBIG if not specified
|
||||
# default is LAMMPS_SMALLBIG if not specified
|
||||
[CMake and make info]:
|
||||
|
||||
The default "smallbig" setting allows for simulations with:
|
||||
|
|
|
@ -66,7 +66,7 @@ In case of problems, you are recommended to contact somebody with
|
|||
experience in using cygwin. If you do come across portability problems
|
||||
requiring changes to the LAMMPS source code, or figure out corrections
|
||||
yourself, please report them on the lammps-users mailing list, or file
|
||||
them as an issue or pull request on the LAMMPS github project.
|
||||
them as an issue or pull request on the LAMMPS GitHub project.
|
||||
|
||||
|
||||
Using a cross-compiler :h4,link(cross)
|
||||
|
|
|
@ -42,10 +42,10 @@ END_RST -->
|
|||
"Input script structure"_Commands_structure.html
|
||||
"Commands by category"_Commands_category.html :all(b)
|
||||
|
||||
"All commands"_Commands_all.html
|
||||
"Fix commands"_Commands_fix.html
|
||||
"Compute commands"_Commands_compute.html
|
||||
"Pair commands"_Commands_pair.html
|
||||
"General commands"_Commands_all.html
|
||||
"Fix commands"_Commands_fix.html
|
||||
"Compute commands"_Commands_compute.html
|
||||
"Pair commands"_Commands_pair.html
|
||||
"Bond, angle, dihedral, improper commands"_Commands_bond.html
|
||||
"KSpace solvers"_Commands_kspace.html :all(b)
|
||||
|
||||
|
|
|
@ -7,7 +7,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
|
|||
|
||||
:line
|
||||
|
||||
"All commands"_Commands_all.html,
|
||||
"General commands"_Commands_all.html,
|
||||
"Fix styles"_Commands_fix.html,
|
||||
"Compute styles"_Commands_compute.html,
|
||||
"Pair styles"_Commands_pair.html,
|
||||
|
@ -17,9 +17,9 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
|
|||
"Improper styles"_Commands_bond.html#improper,
|
||||
"KSpace styles"_Commands_kspace.html :tb(c=3,ea=c)
|
||||
|
||||
All commands :h3
|
||||
General commands :h3
|
||||
|
||||
An alphabetic list of all LAMMPS commands.
|
||||
An alphabetic list of all general LAMMPS commands.
|
||||
|
||||
"angle_coeff"_angle_coeff.html,
|
||||
"angle_style"_angle_style.html,
|
||||
|
|
|
@ -5,7 +5,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
|
|||
:link(ld,Manual.html)
|
||||
:link(lc,Commands_all.html)
|
||||
|
||||
"All commands"_Commands_all.html,
|
||||
"General commands"_Commands_all.html,
|
||||
"Fix styles"_Commands_fix.html,
|
||||
"Compute styles"_Commands_compute.html,
|
||||
"Pair styles"_Commands_pair.html,
|
||||
|
|
|
@ -10,10 +10,9 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
|
|||
Commands by category :h3
|
||||
|
||||
This page lists most of the LAMMPS commands, grouped by category. The
|
||||
"Commands all"_Commands_all.html doc page lists all commands
|
||||
alphabetically. It also includes long lists of style options for
|
||||
entries that appear in the following categories as a single command
|
||||
(fix, compute, pair, etc).
|
||||
"General commands"_Commands_all.html doc page lists all general commands
|
||||
alphabetically. Style options for entries like fix, compute, pair etc.
|
||||
have their own pages where they are listed alphabetically.
|
||||
|
||||
Initialization:
|
||||
|
||||
|
|
|
@ -7,7 +7,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
|
|||
|
||||
:line
|
||||
|
||||
"All commands"_Commands_all.html,
|
||||
"General commands"_Commands_all.html,
|
||||
"Fix styles"_Commands_fix.html,
|
||||
"Compute styles"_Commands_compute.html,
|
||||
"Pair styles"_Commands_pair.html,
|
||||
|
|
|
@ -7,7 +7,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
|
|||
|
||||
:line
|
||||
|
||||
"All commands"_Commands_all.html,
|
||||
"General commands"_Commands_all.html,
|
||||
"Fix styles"_Commands_fix.html,
|
||||
"Compute styles"_Commands_compute.html,
|
||||
"Pair styles"_Commands_pair.html,
|
||||
|
@ -235,4 +235,4 @@ OPT.
|
|||
"wall/reflect (k)"_fix_wall_reflect.html,
|
||||
"wall/region"_fix_wall_region.html,
|
||||
"wall/region/ees"_fix_wall_ees.html,
|
||||
"wall/srd"_fix_wall_srd.html :tb(c=8,ea=c)
|
||||
"wall/srd"_fix_wall_srd.html :tb(c=6,ea=c)
|
||||
|
|
|
@ -7,7 +7,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
|
|||
|
||||
:line
|
||||
|
||||
"All commands"_Commands_all.html,
|
||||
"General commands"_Commands_all.html,
|
||||
"Fix styles"_Commands_fix.html,
|
||||
"Compute styles"_Commands_compute.html,
|
||||
"Pair styles"_Commands_pair.html,
|
||||
|
|
|
@ -7,7 +7,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
|
|||
|
||||
:line
|
||||
|
||||
"All commands"_Commands_all.html,
|
||||
"General commands"_Commands_all.html,
|
||||
"Fix styles"_Commands_fix.html,
|
||||
"Compute styles"_Commands_compute.html,
|
||||
"Pair styles"_Commands_pair.html,
|
||||
|
|
|
@ -91,7 +91,7 @@ See the "variable"_variable.html command for more details of how
|
|||
strings are assigned to variables and evaluated, and how they can be
|
||||
used in input script commands.
|
||||
|
||||
(4) The line is broken into "words" separated by whitespace (tabs,
|
||||
(4) The line is broken into "words" separated by white-space (tabs,
|
||||
spaces). Note that words can thus contain letters, digits,
|
||||
underscores, or punctuation characters.
|
||||
|
||||
|
|
|
@ -421,9 +421,9 @@ This is an internal error. It should normally not occur. :dd
|
|||
|
||||
This is an internal error. It should normally not occur. :dd
|
||||
|
||||
{Bad real space Coulomb cutoff in fix tune/kspace} :dt
|
||||
{Bad real space Coulombic cutoff in fix tune/kspace} :dt
|
||||
|
||||
Fix tune/kspace tried to find the optimal real space Coulomb cutoff using
|
||||
Fix tune/kspace tried to find the optimal real space Coulombic cutoff using
|
||||
the Newton-Rhaphson method, but found a non-positive or NaN cutoff :dd
|
||||
|
||||
{Balance command before simulation box is defined} :dt
|
||||
|
@ -460,7 +460,7 @@ compute. :dd
|
|||
|
||||
{Big particle in fix srd cannot be point particle} :dt
|
||||
|
||||
Big particles must be extended spheriods or ellipsoids. :dd
|
||||
Big particles must be extended spheroids or ellipsoids. :dd
|
||||
|
||||
{Bigint setting in lmptype.h is invalid} :dt
|
||||
|
||||
|
@ -780,7 +780,7 @@ Cannot use tilt factors unless the simulation box is non-orthogonal. :dd
|
|||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Cannot change box z boundary to nonperiodic for a 2d simulation} :dt
|
||||
{Cannot change box z boundary to non-periodic for a 2d simulation} :dt
|
||||
|
||||
Self-explanatory. :dd
|
||||
|
||||
|
@ -1288,7 +1288,7 @@ are defined. :dd
|
|||
You cannot reset the timestep when a fix that keeps track of elapsed
|
||||
time is in place. :dd
|
||||
|
||||
{Cannot run 2d simulation with nonperiodic Z dimension} :dt
|
||||
{Cannot run 2d simulation with non-periodic Z dimension} :dt
|
||||
|
||||
Use the boundary command to make the z dimension periodic in order to
|
||||
run a 2d simulation. :dd
|
||||
|
@ -2116,29 +2116,29 @@ Self-explanatory. :dd
|
|||
Fix setforce cannot be used in this manner. Use fix addforce
|
||||
instead. :dd
|
||||
|
||||
{Cannot use nonperiodic boundares with fix ttm} :dt
|
||||
{Cannot use non-periodic boundares with fix ttm} :dt
|
||||
|
||||
This fix requires a fully periodic simulation box. :dd
|
||||
|
||||
{Cannot use nonperiodic boundaries with Ewald} :dt
|
||||
{Cannot use non-periodic boundaries with Ewald} :dt
|
||||
|
||||
For kspace style ewald, all 3 dimensions must have periodic boundaries
|
||||
unless you use the kspace_modify command to define a 2d slab with a
|
||||
non-periodic z dimension. :dd
|
||||
|
||||
{Cannot use nonperiodic boundaries with EwaldDisp} :dt
|
||||
{Cannot use non-periodic boundaries with EwaldDisp} :dt
|
||||
|
||||
For kspace style ewald/disp, all 3 dimensions must have periodic
|
||||
boundaries unless you use the kspace_modify command to define a 2d
|
||||
slab with a non-periodic z dimension. :dd
|
||||
|
||||
{Cannot use nonperiodic boundaries with PPPM} :dt
|
||||
{Cannot use non-periodic boundaries with PPPM} :dt
|
||||
|
||||
For kspace style pppm, all 3 dimensions must have periodic boundaries
|
||||
unless you use the kspace_modify command to define a 2d slab with a
|
||||
non-periodic z dimension. :dd
|
||||
|
||||
{Cannot use nonperiodic boundaries with PPPMDisp} :dt
|
||||
{Cannot use non-periodic boundaries with PPPMDisp} :dt
|
||||
|
||||
For kspace style pppm/disp, all 3 dimensions must have periodic
|
||||
boundaries unless you use the kspace_modify command to define a 2d
|
||||
|
@ -3351,21 +3351,21 @@ probably due to errors in the Python code. :dd
|
|||
The default minimum order is 2. This can be reset by the
|
||||
kspace_modify minorder command. :dd
|
||||
|
||||
{Coulomb cut not supported in pair_style buck/long/coul/coul} :dt
|
||||
{Coulombic cutoff not supported in pair_style buck/long/coul/coul} :dt
|
||||
|
||||
Must use long-range Coulombic interactions. :dd
|
||||
|
||||
{Coulomb cut not supported in pair_style lj/long/coul/long} :dt
|
||||
{Coulombic cutoff not supported in pair_style lj/long/coul/long} :dt
|
||||
|
||||
Must use long-range Coulombic interactions. :dd
|
||||
|
||||
{Coulomb cut not supported in pair_style lj/long/tip4p/long} :dt
|
||||
{Coulombic cutoff not supported in pair_style lj/long/tip4p/long} :dt
|
||||
|
||||
Must use long-range Coulombic interactions. :dd
|
||||
|
||||
{Coulomb cutoffs of pair hybrid sub-styles do not match} :dt
|
||||
{Coulombic cutoffs of pair hybrid sub-styles do not match} :dt
|
||||
|
||||
If using a Kspace solver, all Coulomb cutoffs of long pair styles must
|
||||
If using a Kspace solver, all Coulombic cutoffs of long pair styles must
|
||||
be the same. :dd
|
||||
|
||||
{Coulombic cut not supported in pair_style lj/long/dipole/long} :dt
|
||||
|
@ -5938,9 +5938,9 @@ map command will force an atom map to be created. :dd
|
|||
|
||||
Self-explanatory. :dd
|
||||
|
||||
{Input line quote not followed by whitespace} :dt
|
||||
{Input line quote not followed by white-space} :dt
|
||||
|
||||
An end quote must be followed by whitespace. :dd
|
||||
An end quote must be followed by white-space. :dd
|
||||
|
||||
{Insertion region extends outside simulation box} :dt
|
||||
|
||||
|
@ -7014,7 +7014,7 @@ The kspace accuracy designated in the input must be greater than zero. :dd
|
|||
|
||||
{KSpace accuracy too large to estimate G vector} :dt
|
||||
|
||||
Reduce the accuracy request or specify gwald explicitly
|
||||
Reduce the accuracy request or specify gewald explicitly
|
||||
via the kspace_modify command. :dd
|
||||
|
||||
{KSpace accuracy too low} :dt
|
||||
|
@ -8014,7 +8014,7 @@ Self-explanatory. :dd
|
|||
|
||||
{Package command after simulation box is defined} :dt
|
||||
|
||||
The package command cannot be used afer a read_data, read_restart, or
|
||||
The package command cannot be used after a read_data, read_restart, or
|
||||
create_box command. :dd
|
||||
|
||||
{Package gpu command without GPU package installed} :dt
|
||||
|
@ -9198,7 +9198,7 @@ creates one large file for all processors. :dd
|
|||
{Restart file byte ordering is not recognized} :dt
|
||||
|
||||
The file does not appear to be a LAMMPS restart file since it doesn't
|
||||
contain a recognized byte-orderomg flag at the beginning. :dd
|
||||
contain a recognized byte-ordering flag at the beginning. :dd
|
||||
|
||||
{Restart file byte ordering is swapped} :dt
|
||||
|
||||
|
@ -9410,7 +9410,7 @@ You may also want to boost the page size. :dd
|
|||
|
||||
{Small to big integers are not sized correctly} :dt
|
||||
|
||||
This error occurs whenthe sizes of smallint, imageint, tagint, bigint,
|
||||
This error occurs when the sizes of smallint, imageint, tagint, bigint,
|
||||
as defined in src/lmptype.h are not what is expected. Contact
|
||||
the developers if this occurs. :dd
|
||||
|
||||
|
|
|
@ -757,7 +757,7 @@ Self-explanatory. :dd
|
|||
|
||||
This may indicate the shell command did not operate as expected. :dd
|
||||
|
||||
{Should not allow rigid bodies to bounce off relecting walls} :dt
|
||||
{Should not allow rigid bodies to bounce off reflecting walls} :dt
|
||||
|
||||
LAMMPS allows this, but their dynamics are not computed correctly. :dd
|
||||
|
||||
|
@ -850,10 +850,10 @@ Most FENE models need this setting for the special_bonds command. :dd
|
|||
|
||||
Most FENE models need this setting for the special_bonds command. :dd
|
||||
|
||||
{Using a manybody potential with bonds/angles/dihedrals and special_bond exclusions} :dt
|
||||
{Using a many-body potential with bonds/angles/dihedrals and special_bond exclusions} :dt
|
||||
|
||||
This is likely not what you want to do. The exclusion settings will
|
||||
eliminate neighbors in the neighbor list, which the manybody potential
|
||||
eliminate neighbors in the neighbor list, which the many-body potential
|
||||
needs to calculated its terms correctly. :dd
|
||||
|
||||
{Using compute temp/deform with inconsistent fix deform remap option} :dt
|
||||
|
|
|
@ -78,7 +78,7 @@ micelle: self-assembly of small lipid-like molecules into 2d bilayers
|
|||
min: energy minimization of 2d LJ melt
|
||||
mscg: parameterize a multi-scale coarse-graining (MSCG) model
|
||||
msst: MSST shock dynamics
|
||||
nb3b: use of nonbonded 3-body harmonic pair style
|
||||
nb3b: use of non-bonded 3-body harmonic pair style
|
||||
neb: nudged elastic band (NEB) calculation for barrier finding
|
||||
nemd: non-equilibrium MD of 2d sheared system
|
||||
obstacle: flow around two voids in a 2d channel
|
||||
|
|
|
@ -45,7 +45,7 @@ General howto :h3
|
|||
<!-- RST
|
||||
|
||||
.. toctree::
|
||||
:name: general
|
||||
:name: general_howto
|
||||
:maxdepth: 1
|
||||
|
||||
Howto_restart
|
||||
|
|
|
@ -19,7 +19,7 @@ barostat attempts to equilibrate the system to the requested T and/or
|
|||
P.
|
||||
|
||||
Barostatting in LAMMPS is performed by "fixes"_fix.html. Two
|
||||
barosttating methods are currently available: Nose-Hoover (npt and
|
||||
barostatting methods are currently available: Nose-Hoover (npt and
|
||||
nph) and Berendsen:
|
||||
|
||||
"fix npt"_fix_nh.html
|
||||
|
|
|
@ -22,8 +22,8 @@ commands, to calculate various properties of a system:
|
|||
"fix ave/chunk"_fix_ave_chunk.html
|
||||
any of the "compute */chunk"_compute.html commands :ul
|
||||
|
||||
Here, each of the 4 kinds of chunk-related commands is briefly
|
||||
overviewed. Then some examples are given of how to compute different
|
||||
Here a brief overview for each of the 4 kinds of chunk-related commands
|
||||
is provided. Then some examples are given of how to compute different
|
||||
properties with chunk commands.
|
||||
|
||||
Compute chunk/atom command: :h4
|
||||
|
|
|
@ -64,7 +64,7 @@ client or server.
|
|||
"server mc"_server_mc.html = LAMMPS is a server for computing a Monte Carlo energy :ul
|
||||
|
||||
The server doc files give details of the message protocols
|
||||
for data that is exchanged bewteen the client and server.
|
||||
for data that is exchanged between the client and server.
|
||||
|
||||
These example directories illustrate how to use LAMMPS as either a
|
||||
client or server code:
|
||||
|
@ -87,7 +87,7 @@ DFT forces, thru a Python wrapper script on VASP.
|
|||
Here is how to launch a client and server code together for any of the
|
||||
4 modes of message exchange that the "message"_message.html command
|
||||
and the CSlib support. Here LAMMPS is used as both the client and
|
||||
server code. Another code could be subsitituted for either.
|
||||
server code. Another code could be substituted for either.
|
||||
|
||||
The examples below show launching both codes from the same window (or
|
||||
batch script), using the "&" character to launch the first code in the
|
||||
|
|
|
@ -19,7 +19,7 @@ polarizable"_Howto_polarizable.html doc page for a discussion of all
|
|||
the polarizable models available in LAMMPS.
|
||||
|
||||
Technically, shells are attached to the cores by a spring force f =
|
||||
k*r where k is a parametrized spring constant and r is the distance
|
||||
k*r where k is a parameterized spring constant and r is the distance
|
||||
between the core and the shell. The charges of the core and the shell
|
||||
add up to the ion charge, thus q(ion) = q(core) + q(shell). This
|
||||
setup introduces the ion polarizability (alpha) given by
|
||||
|
@ -111,7 +111,7 @@ the core and shell particles corresponds to the polarization,
|
|||
hereby an instantaneous relaxation of the shells is approximated
|
||||
and a fast core/shell spring frequency ensures a nearly constant
|
||||
internal kinetic energy during the simulation.
|
||||
Thermostats can alter this polarization behaviour, by scaling the
|
||||
Thermostats can alter this polarization behavior, by scaling the
|
||||
internal kinetic energy, meaning the shell will not react freely to
|
||||
its electrostatic environment.
|
||||
Therefore it is typically desirable to decouple the relative motion of
|
||||
|
@ -165,7 +165,7 @@ fix_modify press_bar temp CSequ press thermo_press_lmp # pressure modification
|
|||
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.
|
||||
momentum to the system, which is noticeable over long trajectories.
|
||||
Therefore it is recommendable to use the "fix
|
||||
momentum"_fix_momentum.html command in combination with "compute
|
||||
temp/cs"_compute_temp_cs.html when equilibrating the system to
|
||||
|
|
|
@ -74,7 +74,7 @@ command.
|
|||
A reasonable approach that combines the upsides of both methods is to
|
||||
make the first run using the {kspace_modify force/disp/real} and
|
||||
{kspace_modify force/disp/kspace} commands, write down the PPPM
|
||||
parameters from the outut, and specify these parameters using the
|
||||
parameters from the output, and specify these parameters using the
|
||||
second approach in subsequent runs (which have the same composition,
|
||||
force field, and approximately the same volume).
|
||||
|
||||
|
|
|
@ -17,7 +17,7 @@ for a discussion of all the polarizable models available in LAMMPS.
|
|||
The Drude model has a number of features aimed at its use in
|
||||
molecular systems ("Lamoureux and Roux"_#howto-Lamoureux):
|
||||
|
||||
Thermostating of the additional degrees of freedom associated with the
|
||||
Thermostatting of the additional degrees of freedom associated with the
|
||||
induced dipoles at very low temperature, in terms of the reduced
|
||||
coordinates of the Drude particles with respect to their cores. This
|
||||
makes the trajectory close to that of relaxed induced dipoles. :ulb,l
|
||||
|
|
|
@ -82,7 +82,7 @@ decouple the degrees of freedom associated with the Drude oscillators
|
|||
from those of the normal atoms. Thermalizing the Drude dipoles at
|
||||
temperatures comparable to the rest of the simulation leads to several
|
||||
problems (kinetic energy transfer, very short timestep, etc.), which
|
||||
can be remediate by the "cold Drude" technique ("Lamoureux and
|
||||
can be remedied by the "cold Drude" technique ("Lamoureux and
|
||||
Roux"_#Lamoureux2).
|
||||
|
||||
Two closely related models are used to represent polarization through
|
||||
|
@ -213,7 +213,7 @@ of mass of the DC-DP pairs, with relaxation time 100 and with random
|
|||
seed 12345. This fix applies also a Langevin thermostat at temperature
|
||||
1. to the relative motion of the DPs around their DCs, with relaxation
|
||||
time 20 and random seed 13977. Only the DCs and non-polarizable
|
||||
atoms need to be in this fix's group. LAMMPS will thermostate the DPs
|
||||
atoms need to be in this fix's group. LAMMPS will thermostat the DPs
|
||||
together with their DC. For this, ghost atoms need to know their
|
||||
velocities. Thus you need to add the following command:
|
||||
|
||||
|
@ -360,7 +360,7 @@ fix NPH all nph iso 1. 1. 500 :pre
|
|||
It is also possible to use a Nose-Hoover instead of a Langevin
|
||||
thermostat. This requires to use "{fix
|
||||
drude/transform}"_fix_drude_transform.html just before and after the
|
||||
time intergation fixes. The {fix drude/transform/direct} converts the
|
||||
time integration fixes. The {fix drude/transform/direct} converts the
|
||||
atomic masses, positions, velocities and forces into a reduced
|
||||
representation, where the DCs transform into the centers of mass of
|
||||
the DC-DP pairs and the DPs transform into their relative position
|
||||
|
@ -396,7 +396,7 @@ global pressure and thus a global temperature whatever the fix group.
|
|||
We do want the pressure to correspond to the whole system, but we want
|
||||
the temperature to correspond to the fix group only. We must then use
|
||||
the {fix_modify} command for this. In the end, the block of
|
||||
instructions for thermostating and barostating will look like
|
||||
instructions for thermostatting and barostatting will look like
|
||||
|
||||
compute TATOMS ATOMS temp
|
||||
fix DIRECT all drude/transform/direct
|
||||
|
|
|
@ -30,7 +30,7 @@ examples/elastic directory described on the "Examples"_Examples.html
|
|||
doc page.
|
||||
|
||||
Calculating elastic constants at finite temperature is more
|
||||
challenging, because it is necessary to run a simulation that perfoms
|
||||
challenging, because it is necessary to run a simulation that performs
|
||||
time averages of differential properties. One way to do this is to
|
||||
measure the change in average stress tensor in an NVT simulations when
|
||||
the cell volume undergoes a finite deformation. In order to balance
|
||||
|
|
|
@ -96,7 +96,7 @@ machine to a directory with the name you chose. If none is given, it will
|
|||
default to "lammps". Typical names are "mylammps" or something similar.
|
||||
|
||||
You can use this local clone to make changes and
|
||||
test them without interfering with the repository on Github.
|
||||
test them without interfering with the repository on GitHub.
|
||||
|
||||
To pull changes from upstream into this copy, you can go to the directory
|
||||
and use git pull:
|
||||
|
@ -150,7 +150,7 @@ After the commit, the changes can be pushed to the same branch on GitHub:
|
|||
$ git push :pre
|
||||
|
||||
Git will ask you for your user name and password on GitHub if you have
|
||||
not configured anything. If your local branch is not present on Github yet,
|
||||
not configured anything. If your local branch is not present on GitHub yet,
|
||||
it will ask you to add it by running
|
||||
|
||||
$ git push --set-upstream origin github-tutorial-update :pre
|
||||
|
@ -254,20 +254,53 @@ them, or if a developer has requested that something needs to be changed
|
|||
before the feature can be accepted into the official LAMMPS version.
|
||||
After each push, the automated checks are run again.
|
||||
|
||||
[Labels]
|
||||
|
||||
LAMMPS developers may add labels to your pull request to assign it to
|
||||
categories (mostly for bookkeeping purposes), but a few of them are
|
||||
important: needs_work, work_in_progress, test-for-regression, and
|
||||
full-regression-test. The first two indicate, that your pull request
|
||||
is not considered to be complete. With "needs_work" the burden is on
|
||||
exclusively on you; while "work_in_progress" can also mean, that a
|
||||
LAMMPS developer may want to add changes. Please watch the comments
|
||||
to the pull requests. The two "test" labels are used to trigger
|
||||
extended tests before the code is merged. This is sometimes done by
|
||||
LAMMPS developers, if they suspect that there may be some subtle
|
||||
side effects from your changes. It is not done by default, because
|
||||
those tests are very time consuming.
|
||||
|
||||
[Reviews]
|
||||
|
||||
As of Summer 2018, a pull request needs at least 1 approving review
|
||||
from a LAMMPS developer with write access to the repository.
|
||||
In case your changes touch code that certain developers are associated
|
||||
with, they are auto-requested by the GitHub software. Those associations
|
||||
are set in the file
|
||||
".github/CODEOWNERS"_https://github.com/lammps/lammps/blob/master/.github/CODEOWNERS
|
||||
Thus if you want to be automatically notified to review when anybody
|
||||
changes files or packages, that you have contributed to LAMMPS, you can
|
||||
add suitable patterns to that file, or a LAMMPS developer may add you.
|
||||
|
||||
Otherwise, you can also manually request reviews from specific developers,
|
||||
or LAMMPS developers - in their assessment of your pull request - may
|
||||
determine who else should be reviewing your contribution and add that person.
|
||||
Through reviews, LAMMPS developers also may request specific changes from you.
|
||||
If those are not addressed, your pull requests cannot be merged.
|
||||
|
||||
[Assignees]
|
||||
|
||||
There is an assignee label for pull requests. If the request has not
|
||||
There is an assignee property for pull requests. If the request has not
|
||||
been reviewed by any developer yet, it is not assigned to anyone. After
|
||||
revision, a developer can choose to assign it to either a) you, b) a
|
||||
LAMMPS developer (including him/herself) or c) Steve Plimpton (sjplimp).
|
||||
LAMMPS developer (including him/herself) or c) Axel Kohlmeyer (akohlmey).
|
||||
|
||||
Case a) happens if changes are required on your part :ulb,l
|
||||
Case b) means that at the moment, it is being tested and reviewed by a
|
||||
LAMMPS developer with the expectation that some changes would be required.
|
||||
After the review, the developer can choose to implement changes directly
|
||||
or suggest them to you. :l
|
||||
Case c) means that the pull request has been assigned to the lead
|
||||
developer Steve Plimpton and means it is considered ready for merging. :ule,l
|
||||
Case c) means that the pull request has been assigned to the developer
|
||||
overseeing the merging of pull requests into the master branch. :ule,l
|
||||
|
||||
In this case, Axel assigned the tutorial to Steve:
|
||||
|
||||
|
@ -336,7 +369,7 @@ commit and push again:
|
|||
$ git commit -m "Merged Axel's suggestions and updated text"
|
||||
$ git push git@github.com:Pakketeretet2/lammps :pre
|
||||
|
||||
This merge also shows up on the lammps Github page:
|
||||
This merge also shows up on the lammps GitHub page:
|
||||
|
||||
:c,image(JPG/tutorial_reverse_pull_request7.png)
|
||||
|
||||
|
@ -381,3 +414,6 @@ Furthermore, the naming of the patches now follow the pattern
|
|||
"patch_<Day><Month><Year>" to simplify comparisons between releases.
|
||||
Finally, all patches and submissions are subject to automatic testing
|
||||
and code checks to make sure they at the very least compile.
|
||||
|
||||
A discussion of the LAMMPS developer GitHub workflow can be found in the file
|
||||
"doc/github-development-workflow.md"_https://github.com/lammps/lammps/blob/master/doc/github-development-workflow.md
|
||||
|
|
|
@ -31,8 +31,8 @@ plane @ a b c x0 y0 z0 @ a*(x-x0) + b*(y-y0) + c*(z-z0) = 0 @ A plane with norma
|
|||
plane_wiggle @ a w @ z - a*sin(w*x) = 0 @ A plane with a sinusoidal modulation on z along x.
|
||||
sphere @ R @ x^2 + y^2 + z^2 - R^2 = 0 @ A sphere of radius R
|
||||
supersphere @ R q @ | x |^q + | y |^q + | z |^q - R^q = 0 @ A supersphere of hyperradius R
|
||||
spine @ a, A, B, B2, c @ -(x^2 + y^2) + (a^2 - z^2/f(z)^2)*(1 + (A*sin(g(z)*z^2))^4), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise @ An approximation to a dendtritic spine
|
||||
spine_two @ a, A, B, B2, c @ -(x^2 + y^2) + (a^2 - z^2/f(z)^2)*(1 + (A*sin(g(z)*z^2))^2), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise @ Another approximation to a dendtritic spine
|
||||
spine @ a, A, B, B2, c @ -(x^2 + y^2) + (a^2 - z^2/f(z)^2)*(1 + (A*sin(g(z)*z^2))^4), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise @ An approximation to a dendritic spine
|
||||
spine_two @ a, A, B, B2, c @ -(x^2 + y^2) + (a^2 - z^2/f(z)^2)*(1 + (A*sin(g(z)*z^2))^2), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise @ Another approximation to a dendritic spine
|
||||
thylakoid @ wB LB lB @ Various, see "(Paquay)"_#Paquay1 @ A model grana thylakoid consisting of two block-like compartments connected by a bridge of width wB, length LB and taper length lB
|
||||
torus @ R r @ (R - sqrt( x^2 + y^2 ) )^2 + z^2 - r^2 @ A torus with large radius R and small radius r, centered on (0,0,0) :tb(s=@)
|
||||
|
||||
|
|
|
@ -55,5 +55,5 @@ using the "fix flow/gauss"_fix_flow_gauss.html command.
|
|||
:line
|
||||
|
||||
:link(Daivis-nemd)
|
||||
[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dyanmics (book),
|
||||
[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dynamics (book),
|
||||
Cambridge University Press, https://doi.org/10.1017/9781139017848, (2017).
|
||||
|
|
|
@ -45,8 +45,8 @@ high symmetry around each site leads to stable trajectories of the
|
|||
core-shell pairs. However, bonded atoms in molecules can be so close
|
||||
that a core would interact too strongly or even capture the Drude
|
||||
particle of a neighbor. The Drude dipole model is relatively more
|
||||
complex in order to remediate this and other issues. Specifically, the
|
||||
Drude model includes specific thermostating of the core-Drude pairs
|
||||
complex in order to remedy this and other issues. Specifically, the
|
||||
Drude model includes specific thermostatting of the core-Drude pairs
|
||||
and short-range damping of the induced dipoles.
|
||||
|
||||
The three polarization methods can be implemented through a
|
||||
|
@ -77,5 +77,5 @@ motion of the Drude particles with respect to their cores is kept
|
|||
approaching the self-consistent regime. In both models the
|
||||
temperature is regulated using the velocities of the center of mass of
|
||||
core+shell (or Drude) pairs, but in the Drude model the actual
|
||||
relative core-Drude particle motion is thermostated separately as
|
||||
relative core-Drude particle motion is thermostatted separately as
|
||||
well.
|
||||
|
|
|
@ -141,16 +141,16 @@ Python code if {L} was a lammps instance:
|
|||
L.command("region box block 0 10 0 5 -0.5 0.5") :pre
|
||||
|
||||
With the PyLammps interface, any command can be split up into arbitrary parts
|
||||
separated by whitespace, passed as individual arguments to a region method.
|
||||
separated by white-space, passed as individual arguments to a region method.
|
||||
|
||||
L.region("box block", 0, 10, 0, 5, -0.5, 0.5) :pre
|
||||
|
||||
Note that each parameter is set as Python literal floating-point number. In the
|
||||
PyLammps interface, each command takes an arbitrary parameter list and transparently
|
||||
merges it to a single command string, separating individual parameters by whitespace.
|
||||
merges it to a single command string, separating individual parameters by white-space.
|
||||
|
||||
The benefit of this approach is avoiding redundant command calls and easier
|
||||
parameterization. In the original interface parametrization needed to be done
|
||||
parameterization. In the original interface parameterization needed to be done
|
||||
manually by creating formatted strings.
|
||||
|
||||
L.command("region box block %f %f %f %f %f %f" % (xlo, xhi, ylo, yhi, zlo, zhi)) :pre
|
||||
|
@ -328,7 +328,7 @@ jupyter notebook :pre
|
|||
IPyLammps Examples :h4
|
||||
|
||||
Examples of IPython notebooks can be found in the python/examples/pylammps
|
||||
subdirectory. To open these notebooks launch {jupyter notebook} inside this
|
||||
sub-directory. To open these notebooks launch {jupyter notebook} inside this
|
||||
directory and navigate to one of them. If you compiled and installed
|
||||
a LAMMPS shared library with exceptions, PNG, JPEG and FFMPEG support
|
||||
you should be able to rerun all of these notebooks.
|
||||
|
|
|
@ -9,7 +9,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
|
|||
|
||||
Multi-replica simulations :h3
|
||||
|
||||
Several commands in LAMMPS run mutli-replica simulations, meaning
|
||||
Several commands in LAMMPS run multi-replica simulations, meaning
|
||||
that multiple instances (replicas) of your simulation are run
|
||||
simultaneously, with small amounts of data exchanged between replicas
|
||||
periodically.
|
||||
|
|
|
@ -30,7 +30,7 @@ r0 of OH bond = 1.0
|
|||
theta of HOH angle = 109.47 :all(b),p
|
||||
|
||||
Note that as originally proposed, the SPC model was run with a 9
|
||||
Angstrom cutoff for both LJ and Coulommbic terms. It can also be used
|
||||
Angstrom cutoff for both LJ and Coulombic terms. It can also be used
|
||||
with long-range Coulombics (Ewald or PPPM in LAMMPS), without changing
|
||||
any of the parameters above, though it becomes a different model in
|
||||
that mode of usage.
|
||||
|
|
|
@ -35,7 +35,7 @@ There are several "atom styles"_atom_style.html that allow for
|
|||
definition of finite-size particles: sphere, dipole, ellipsoid, line,
|
||||
tri, peri, and body.
|
||||
|
||||
The sphere style defines particles that are spheriods and each
|
||||
The sphere style defines particles that are spheroids and each
|
||||
particle can have a unique diameter and mass (or density). These
|
||||
particles store an angular velocity (omega) and can be acted upon by
|
||||
torque. The "set" command can be used to modify the diameter and mass
|
||||
|
@ -236,7 +236,7 @@ particles are point masses.
|
|||
Also note that body particles cannot be modeled with the "fix
|
||||
rigid"_fix_rigid.html command. Body particles are treated by LAMMPS
|
||||
as single particles, though they can store internal state, such as a
|
||||
list of sub-particles. Individual body partices are typically treated
|
||||
list of sub-particles. Individual body particles are typically treated
|
||||
as rigid bodies, and their motion integrated with a command like "fix
|
||||
nve/body"_fix_nve_body.html. Interactions between pairs of body
|
||||
particles are computed via a command like "pair_style
|
||||
|
|
|
@ -36,7 +36,7 @@ A Langevin thermostat can be applied to those magnetic spins using
|
|||
"fix langevin/spin"_fix_langevin_spin.html. Typically, this thermostat
|
||||
can be coupled to another Langevin thermostat applied to the atoms
|
||||
using "fix langevin"_fix_langevin.html in order to simulate
|
||||
thermostated spin-lattice system.
|
||||
thermostatted spin-lattice system.
|
||||
|
||||
The magnetic Gilbert damping can also be applied using "fix
|
||||
langevin/spin"_fix_langevin_spin.html. It allows to either dissipate
|
||||
|
|
|
@ -96,5 +96,5 @@ temperature compute is used for default thermodynamic output.
|
|||
:line
|
||||
|
||||
:link(Daivis-thermostat)
|
||||
[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dyanmics (book),
|
||||
[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dynamics (book),
|
||||
Cambridge University Press, https://doi.org/10.1017/9781139017848, (2017).
|
||||
|
|
|
@ -200,7 +200,7 @@ used with non-orthogonal basis vectors to define a lattice that will
|
|||
tile a triclinic simulation box via the
|
||||
"create_atoms"_create_atoms.html command.
|
||||
|
||||
A second use is to run Parinello-Rahman dynamics via the "fix
|
||||
A second use is to run Parrinello-Rahman dynamics via the "fix
|
||||
npt"_fix_nh.html command, which will adjust the xy, xz, yz tilt
|
||||
factors to compensate for off-diagonal components of the pressure
|
||||
tensor. The analog for an "energy minimization"_minimize.html is
|
||||
|
|
|
@ -140,5 +140,5 @@ with time at sufficiently long times.
|
|||
:line
|
||||
|
||||
:link(Daivis-viscosity)
|
||||
[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dyanmics (book),
|
||||
[(Daivis and Todd)] Daivis and Todd, Nonequilibrium Molecular Dynamics (book),
|
||||
Cambridge University Press, https://doi.org/10.1017/9781139017848, (2017).
|
||||
|
|
|
@ -45,7 +45,7 @@ git clone -b unstable https://github.com/lammps/lammps.git mylammps :pre
|
|||
where "mylammps" is the name of the directory you wish to create on
|
||||
your machine and "unstable" is one of the 3 branches listed above.
|
||||
(Note that you actually download all 3 branches; you can switch
|
||||
between them at any time using "git checkout <branchname>".)
|
||||
between them at any time using "git checkout <branch name>".)
|
||||
|
||||
Once the command completes, your directory will contain the same files
|
||||
as if you unpacked a current LAMMPS tarball, with two exceptions:
|
||||
|
|
|
@ -48,7 +48,7 @@ Trung Ngyuen (Northwestern U), GPU and RIGID and BODY packages
|
|||
Mike Parks (Sandia), PERI package for Peridynamics
|
||||
Roy Pollock (LLNL), Ewald and PPPM solvers
|
||||
Christian Trott (Sandia), USER-CUDA and KOKKOS packages
|
||||
Ilya Valuev (JIHT), USER-AWPMD package for wave-packet MD
|
||||
Ilya Valuev (JIHT), USER-AWPMD package for wave packet MD
|
||||
Greg Wagner (Northwestern U), MEAM package for MEAM potential :ul
|
||||
|
||||
:line
|
||||
|
|
|
@ -68,7 +68,7 @@ commands)
|
|||
pairwise potentials: Lennard-Jones, Buckingham, Morse, Born-Mayer-Huggins, \
|
||||
Yukawa, soft, class 2 (COMPASS), hydrogen bond, tabulated
|
||||
charged pairwise potentials: Coulombic, point-dipole
|
||||
manybody potentials: EAM, Finnis/Sinclair EAM, modified EAM (MEAM), \
|
||||
many-body potentials: EAM, Finnis/Sinclair EAM, modified EAM (MEAM), \
|
||||
embedded ion method (EIM), EDIP, ADP, Stillinger-Weber, Tersoff, \
|
||||
REBO, AIREBO, ReaxFF, COMB, SNAP, Streitz-Mintmire, 3-body polymorphic
|
||||
long-range interactions for charge, point-dipoles, and LJ dispersion: \
|
||||
|
@ -114,7 +114,7 @@ Ensembles, constraints, and boundary conditions :h4,link(ensemble)
|
|||
|
||||
2d or 3d systems
|
||||
orthogonal or non-orthogonal (triclinic symmetry) simulation domains
|
||||
constant NVE, NVT, NPT, NPH, Parinello/Rahman integrators
|
||||
constant NVE, NVT, NPT, NPH, Parrinello/Rahman integrators
|
||||
thermostatting options for groups and geometric regions of atoms
|
||||
pressure control via Nose/Hoover or Berendsen barostatting in 1 to 3 dimensions
|
||||
simulation box deformation (tensile and shear)
|
||||
|
|
|
@ -13,15 +13,19 @@ LAMMPS is designed to be a fast, parallel engine for molecular
|
|||
dynamics (MD) simulations. It provides only a modest amount of
|
||||
functionality for setting up simulations and analyzing their output.
|
||||
|
||||
Specifically, LAMMPS does not:
|
||||
Specifically, LAMMPS was not conceived and designed for:
|
||||
|
||||
run thru a GUI
|
||||
build molecular systems
|
||||
being run thru a GUI
|
||||
build molecular systems, or building molecular topologies
|
||||
assign force-field coefficients automagically
|
||||
perform sophisticated analyses of your MD simulation
|
||||
perform sophisticated analysis of your MD simulation
|
||||
visualize your MD simulation interactively
|
||||
plot your output data :ul
|
||||
|
||||
Although over the years these limitations have been somewhat
|
||||
reduced through features added to LAMMPS or external tools
|
||||
that either interface with LAMMPS or extend LAMMPS.
|
||||
|
||||
Here are suggestions on how to perform these tasks:
|
||||
|
||||
GUI: LAMMPS can be built as a library and a Python wrapper that wraps
|
||||
|
@ -29,7 +33,7 @@ the library interface is provided. Thus, GUI interfaces can be
|
|||
written in Python (or C or C++ if desired) that run LAMMPS and
|
||||
visualize or plot its output. Examples of this are provided in the
|
||||
python directory and described on the "Python"_Python_head.html doc
|
||||
page. :ulb,l
|
||||
page. Also, there are several external wrappers or GUI front ends.:ulb,l
|
||||
|
||||
Builder: Several pre-processing tools are packaged with LAMMPS. Some
|
||||
of them convert input files in formats produced by other MD codes such
|
||||
|
@ -40,28 +44,36 @@ molecular builder that will generate complex molecular models. See
|
|||
the "Tools"_Tools.html doc page for details on tools packaged with
|
||||
LAMMPS. The "Pre/post processing
|
||||
page"_http:/lammps.sandia.gov/prepost.html of the LAMMPS website
|
||||
describes a variety of 3rd party tools for this task. :l
|
||||
describes a variety of 3rd party tools for this task. Furthermore,
|
||||
some LAMMPS internal commands to reconstruct topology, as well as
|
||||
the option to insert molecule templates instead of atoms.:l
|
||||
|
||||
Force-field assignment: The conversion tools described in the previous
|
||||
bullet for CHARMM, AMBER, and Insight will also assign force field
|
||||
coefficients in the LAMMPS format, assuming you provide CHARMM, AMBER,
|
||||
or Accelerys force field files. :l
|
||||
or BIOVIA (formerly Accelrys) force field files. :l
|
||||
|
||||
Simulation analyses: If you want to perform analyses on-the-fly as
|
||||
Simulation analysis: If you want to perform analysis on-the-fly as
|
||||
your simulation runs, see the "compute"_compute.html and
|
||||
"fix"_fix.html doc pages, which list commands that can be used in a
|
||||
LAMMPS input script. Also see the "Modify"_Modify.html doc page for
|
||||
info on how to add your own analysis code or algorithms to LAMMPS.
|
||||
For post-processing, LAMMPS output such as "dump file
|
||||
snapshots"_dump.html can be converted into formats used by other MD or
|
||||
post-processing codes. Some post-processing tools packaged with
|
||||
post-processing codes. To some degree, that conversion can be done
|
||||
directly inside of LAMMPS by interfacing to the VMD molfile plugins.
|
||||
The "rerun"_rerun.html command also allows to do some post-processing
|
||||
of existing trajectories, and through being able to read a variety
|
||||
of file formats, this can also be used for analyzing trajectories
|
||||
from other MD codes. Some post-processing tools packaged with
|
||||
LAMMPS will do these conversions. Scripts provided in the
|
||||
tools/python directory can extract and massage data in dump files to
|
||||
make it easier to import into other programs. See the
|
||||
"Tools"_Tools.html doc page for details on these various options. :l
|
||||
|
||||
Visualization: LAMMPS can produce JPG or PNG snapshot images
|
||||
on-the-fly via its "dump image"_dump_image.html command. For
|
||||
on-the-fly via its "dump image"_dump_image.html command and pass
|
||||
them to an external program FFmpeg to generate movies from them. For
|
||||
high-quality, interactive visualization there are many excellent and
|
||||
free tools available. See the "Other Codes
|
||||
page"_http://lammps.sandia.gov/viz.html page of the LAMMPS website for
|
||||
|
|
|
@ -33,11 +33,11 @@ how much effort it will cause to integrate and test it, how much it
|
|||
requires changes to the core codebase, and of how much interest it is
|
||||
to the larger LAMMPS community. Please see below for a checklist of
|
||||
typical requirements. Once you have prepared everything, see the
|
||||
"Howto github"_Howto_github.html doc page for instructions on how to
|
||||
"Using GitHub with LAMMPS Howto"_Howto_github.html doc page for instructions on how to
|
||||
submit your changes or new files through a GitHub pull request. If you
|
||||
prefer to submit patches or full files, you should first make certain,
|
||||
that your code works correctly with the latest patch-level version of
|
||||
LAMMPS and contains all bugfixes from it. Then create a gzipped tar
|
||||
LAMMPS and contains all bug fixes from it. Then create a gzipped tar
|
||||
file of all changed or added files or a corresponding patch file using
|
||||
'diff -u' or 'diff -c' and compress it with gzip. Please only use gzip
|
||||
compression, as this works well on all platforms.
|
||||
|
|
|
@ -10,7 +10,7 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
|
|||
Pair styles :h3
|
||||
|
||||
Classes that compute pairwise interactions are derived from the Pair
|
||||
class. In LAMMPS, pairwise calculation include manybody potentials
|
||||
class. In LAMMPS, pairwise calculation include many-body potentials
|
||||
such as EAM or Tersoff where particles interact without a static bond
|
||||
topology. New styles can be created to add new pair potentials to
|
||||
LAMMPS.
|
||||
|
|
|
@ -20,6 +20,6 @@ Here is a brief description of methods you define in your new derived
|
|||
class. See region.h for details.
|
||||
|
||||
inside: determine whether a point is in the region
|
||||
surface_interior: determine if a point is within a cutoff distance inside of surc
|
||||
surface_exterior: determine if a point is within a cutoff distance outside of surf
|
||||
surface_interior: determine if a point is within a cutoff distance inside of surface
|
||||
surface_exterior: determine if a point is within a cutoff distance outside of surface
|
||||
shape_update : change region shape if set by time-dependent variable :tb(s=:)
|
||||
|
|
|
@ -494,7 +494,7 @@ MANYBODY package :link(PKG-MANYBODY),h4
|
|||
|
||||
[Contents:]
|
||||
|
||||
A variety of manybody and bond-order potentials. These include
|
||||
A variety of many-body and bond-order potentials. These include
|
||||
(AI)REBO, BOP, EAM, EIM, Stillinger-Weber, and Tersoff potentials.
|
||||
|
||||
[Supporting info:]
|
||||
|
@ -518,7 +518,7 @@ MC package :link(PKG-MC),h4
|
|||
Several fixes and a pair style that have Monte Carlo (MC) or MC-like
|
||||
attributes. These include fixes for creating, breaking, and swapping
|
||||
bonds, for performing atomic swaps, and performing grand-canonical MC
|
||||
(GCMC) in conjuction with dynamics.
|
||||
(GCMC) in conjunction with dynamics.
|
||||
|
||||
[Supporting info:]
|
||||
|
||||
|
@ -1207,7 +1207,7 @@ USER-PLUMED package :link(PKG-USER-PLUMED),h4
|
|||
[Contents:]
|
||||
|
||||
The fix plumed command allows you to use the PLUMED free energy plugin
|
||||
for molecular dynamics to analyse and bias your LAMMPS trajectory on
|
||||
for molecular dynamics to analyze and bias your LAMMPS trajectory on
|
||||
the fly. The PLUMED library is called from within the LAMMPS input
|
||||
script by using the "fix plumed _fix_plumed.html command.
|
||||
|
||||
|
|
|
@ -38,8 +38,8 @@ int = internal library: provided with LAMMPS, but you may need to build it
|
|||
ext = external library: you will need to download and install it on your machine :ul
|
||||
|
||||
Package, Description, Doc page, Example, Library
|
||||
"USER-ATC"_Packages_details.html#PKG-USER-ATC, atom-to-continuum coupling, "fix atc"_fix_atc.html, USER/atc, int
|
||||
"USER-AWPMD"_Packages_details.html#PKG-USER-AWPMD, wave-packet MD, "pair_style awpmd/cut"_pair_awpmd.html, USER/awpmd, int
|
||||
"USER-ATC"_Packages_details.html#PKG-USER-ATC, Atom-to-Continuum coupling, "fix atc"_fix_atc.html, USER/atc, int
|
||||
"USER-AWPMD"_Packages_details.html#PKG-USER-AWPMD, wave packet MD, "pair_style awpmd/cut"_pair_awpmd.html, USER/awpmd, int
|
||||
"USER-BOCS"_Packages_details.html#PKG-USER-BOCS, BOCS bottom up coarse graining, "fix bocs"_fix_bocs.html, USER/bocs, no
|
||||
"USER-CGDNA"_Packages_details.html#PKG-USER-CGDNA, coarse-grained DNA force fields, src/USER-CGDNA/README, USER/cgdna, no
|
||||
"USER-CGSDK"_Packages_details.html#PKG-USER-CGSDK, SDK coarse-graining model, "pair_style lj/sdk"_pair_sdk.html, USER/cgsdk, no
|
||||
|
|
|
@ -79,7 +79,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 "Python
|
||||
must also follow the steps summarized in the "Python
|
||||
run"_Python_run.html doc page. 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.
|
||||
|
|
|
@ -46,7 +46,7 @@ http://mt.seas.upenn.edu/Archive/Graphics/A3/A3.html :pre
|
|||
:link(atomeye,http://mt.seas.upenn.edu/Archive/Graphics/A)
|
||||
:link(atomeye3,http://mt.seas.upenn.edu/Archive/Graphics/A3/A3.html)
|
||||
|
||||
The latter link is to AtomEye 3 which has the scriping
|
||||
The latter link is to AtomEye 3 which has the scripting
|
||||
capability needed by these Python scripts.
|
||||
|
||||
Note that for PyMol, you need to have built and installed the
|
||||
|
|
|
@ -41,7 +41,7 @@ path for the default location of this MPI package. After the
|
|||
installation of the MPICH2 software, it needs to be integrated into
|
||||
the system. For this you need to start a Command Prompt in
|
||||
{Administrator Mode} (right click on the icon and select it). Change
|
||||
into the MPICH2 installation directory, then into the subdirectory
|
||||
into the MPICH2 installation directory, then into the sub-directory
|
||||
[bin] and execute [smpd.exe -install]. Exit the command window.
|
||||
|
||||
Get a new, regular command prompt by going to Start->Run... ,
|
||||
|
|
|
@ -19,7 +19,7 @@ using code options that implement alternate algorithms that can
|
|||
speed-up a simulation. The second is to use one of the several
|
||||
accelerator packages provided with LAMMPS that contain code optimized
|
||||
for certain kinds of hardware, including multi-core CPUs, GPUs, and
|
||||
Intel Xeon Phi coprocessors.
|
||||
Intel Xeon Phi co-processors.
|
||||
|
||||
The "Benchmark page"_http://lammps.sandia.gov/bench.html of the LAMMPS
|
||||
web site gives performance results for the various accelerator
|
||||
|
|
|
@ -14,11 +14,11 @@ Corporation. It provides two methods for accelerating simulations,
|
|||
depending on the hardware you have. The first is acceleration on
|
||||
Intel CPUs by running in single, mixed, or double precision with
|
||||
vectorization. The second is acceleration on Intel Xeon Phi
|
||||
coprocessors via offloading neighbor list and non-bonded force
|
||||
co-processors 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
|
||||
When offloading to a co-processor from a CPU, the same routine is run
|
||||
twice, once on the CPU and once with an offload flag. This allows
|
||||
LAMMPS to run on the CPU cores and coprocessor cores simultaneously.
|
||||
LAMMPS to run on the CPU cores and co-processor cores simultaneously.
|
||||
|
||||
[Currently Available USER-INTEL Styles:]
|
||||
|
||||
|
@ -47,7 +47,7 @@ These are scalable in size; the results given are with 512K
|
|||
particles (524K for Liquid Crystal). Most of the simulations are
|
||||
standard LAMMPS benchmarks (indicated by the filename extension in
|
||||
parenthesis) with modifications to the run length and to add a
|
||||
warmup run (for use with offload benchmarks).
|
||||
warm-up run (for use with offload benchmarks).
|
||||
|
||||
:c,image(JPG/user_intel.png)
|
||||
|
||||
|
@ -134,19 +134,19 @@ Do not use thread affinity (set KMP_AFFINITY=none) :l
|
|||
The "newton off" setting may provide better scalability :l
|
||||
:ule
|
||||
|
||||
For Intel Xeon Phi coprocessors (Offload):
|
||||
For Intel Xeon Phi co-processors (Offload):
|
||||
|
||||
Edit src/MAKE/OPTIONS/Makefile.intel_coprocessor as necessary :ulb,l
|
||||
Edit src/MAKE/OPTIONS/Makefile.intel_co-processor as necessary :ulb,l
|
||||
"-pk intel N omp 1" added to command-line where N is the number of
|
||||
coprocessors per node. :l
|
||||
co-processors per node. :l
|
||||
:ule
|
||||
|
||||
:line
|
||||
|
||||
[Required hardware/software:]
|
||||
|
||||
In order to use offload to coprocessors, an Intel Xeon Phi
|
||||
coprocessor and an Intel compiler are required. For this, the
|
||||
In order to use offload to co-processors, an Intel Xeon Phi
|
||||
co-processor 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.
|
||||
|
||||
|
@ -214,7 +214,7 @@ Makefile.intel_cpu_intelmpi # Intel Compiler, Intel MPI, No Offload
|
|||
Makefile.knl # Intel Compiler, Intel MPI, No Offload
|
||||
Makefile.intel_cpu_mpich # Intel Compiler, MPICH, No Offload
|
||||
Makefile.intel_cpu_openpmi # Intel Compiler, OpenMPI, No Offload
|
||||
Makefile.intel_coprocessor # Intel Compiler, Intel MPI, Offload :pre
|
||||
Makefile.intel_co-processor # Intel Compiler, Intel MPI, Offload :pre
|
||||
|
||||
Makefile.knl is identical to Makefile.intel_cpu_intelmpi except that
|
||||
it explicitly specifies that vectorization should be for Intel Xeon
|
||||
|
@ -227,9 +227,9 @@ source /opt/intel/parallel_studio_xe_2016.3.067/psxevars.sh
|
|||
# or psxevars.csh for C-shell
|
||||
make intel_cpu_intelmpi :pre
|
||||
|
||||
Note that if you build with support for a Phi coprocessor, the same
|
||||
binary can be used on nodes with or without coprocessors installed.
|
||||
However, if you do not have coprocessors on your system, building
|
||||
Note that if you build with support for a Phi co-processor, the same
|
||||
binary can be used on nodes with or without co-processors installed.
|
||||
However, if you do not have co-processors on your system, building
|
||||
without offload support will produce a smaller binary.
|
||||
|
||||
The general requirements for Makefiles with the USER-INTEL package
|
||||
|
@ -272,7 +272,7 @@ Advanced performance tuning options are also described below to get
|
|||
the best performance.
|
||||
|
||||
When running on a single node (including runs using offload to a
|
||||
coprocessor), best performance is normally obtained by using 1 MPI
|
||||
co-processor), best performance is normally obtained by using 1 MPI
|
||||
task per physical core and additional OpenMP threads with SMT. For
|
||||
Intel Xeon processors, 2 OpenMP threads should be used for SMT.
|
||||
For Intel Xeon Phi CPUs, 2 or 4 OpenMP threads should be used
|
||||
|
@ -290,7 +290,7 @@ NOTE: Setting core affinity is often used to pin MPI tasks and OpenMP
|
|||
threads to a core or group of cores so that memory access can be
|
||||
uniform. Unless disabled at build time, affinity for MPI tasks and
|
||||
OpenMP threads on the host (CPU) will be set by default on the host
|
||||
{when using offload to a coprocessor}. In this case, it is unnecessary
|
||||
{when using offload to a co-processor}. In this case, it is unnecessary
|
||||
to use other methods to control affinity (e.g. taskset, numactl,
|
||||
I_MPI_PIN_DOMAIN, etc.). This can be disabled with the {no_affinity}
|
||||
option to the "package intel"_package.html command or by disabling the
|
||||
|
@ -310,15 +310,15 @@ editing the input script. This switch will automatically append
|
|||
options for the USER-INTEL package. The default package command will
|
||||
specify that USER-INTEL calculations are performed in mixed precision,
|
||||
that the number of OpenMP threads is specified by the OMP_NUM_THREADS
|
||||
environment variable, and that if coprocessors are present and the
|
||||
binary was built with offload support, that 1 coprocessor per node
|
||||
environment variable, and that if co-processors are present and the
|
||||
binary was built with offload support, that 1 co-processor per node
|
||||
will be used with automatic balancing of work between the CPU and the
|
||||
coprocessor.
|
||||
co-processor.
|
||||
|
||||
You can specify different options for the USER-INTEL package by using
|
||||
the "-pk intel Nphi" "command-line switch"_Run_options.html with
|
||||
keyword/value pairs as specified in the documentation. Here, Nphi = #
|
||||
of Xeon Phi coprocessors/node (ignored without offload
|
||||
of Xeon Phi co-processors/node (ignored without offload
|
||||
support). Common options to the USER-INTEL package include {omp} to
|
||||
override any OMP_NUM_THREADS setting and specify the number of OpenMP
|
||||
threads, {mode} to set the floating-point precision mode, and {lrt} to
|
||||
|
@ -332,7 +332,7 @@ Examples (see documentation for your MPI/Machine for differences in
|
|||
launching MPI applications):
|
||||
|
||||
mpirun -np 72 -ppn 36 lmp_machine -sf intel -in in.script # 2 nodes, 36 MPI tasks/node, $OMP_NUM_THREADS OpenMP Threads
|
||||
mpirun -np 72 -ppn 36 lmp_machine -sf intel -in in.script -pk intel 0 omp 2 mode double # Don't use any coprocessors that might be available, use 2 OpenMP threads for each task, use double precision :pre
|
||||
mpirun -np 72 -ppn 36 lmp_machine -sf intel -in in.script -pk intel 0 omp 2 mode double # Don't use any co-processors that might be available, use 2 OpenMP threads for each task, use double precision :pre
|
||||
|
||||
[Or run with the USER-INTEL package by editing an input script:]
|
||||
|
||||
|
@ -364,7 +364,7 @@ intel"_package.html command that can improve performance when using
|
|||
"PPPM"_kspace_style.html for long-range electrostatics on processors
|
||||
with SMT. It generates an extra pthread for each MPI task. The thread
|
||||
is dedicated to performing some of the PPPM calculations and MPI
|
||||
communications. This feature requires setting the preprocessor flag
|
||||
communications. This feature requires setting the pre-processor flag
|
||||
-DLMP_INTEL_USELRT in the makefile when compiling LAMMPS. It is unset
|
||||
in the default makefiles ({Makefile.mpi} and {Makefile.serial}) but
|
||||
it is set in all makefiles tuned for the USER-INTEL package. On Intel
|
||||
|
@ -422,29 +422,29 @@ that MPI runs are performed in MCDRAM.
|
|||
|
||||
The default settings for offload should give good performance.
|
||||
|
||||
When using LAMMPS with offload to Intel coprocessors, best performance
|
||||
When using LAMMPS with offload to Intel co-processors, best performance
|
||||
will typically be achieved with concurrent calculations performed on
|
||||
both the CPU and the coprocessor. This is achieved by offloading only
|
||||
a fraction of the neighbor and pair computations to the coprocessor or
|
||||
both the CPU and the co-processor. This is achieved by offloading only
|
||||
a fraction of the neighbor and pair computations to the co-processor or
|
||||
using "hybrid"_pair_hybrid.html pair styles where only one style uses
|
||||
the "intel" suffix. For simulations with long-range electrostatics or
|
||||
bond, angle, dihedral, improper calculations, computation and data
|
||||
transfer to the coprocessor will run concurrently with computations
|
||||
transfer to the co-processor will run concurrently with computations
|
||||
and MPI communications for these calculations on the host CPU. This
|
||||
is illustrated in the figure below for the rhodopsin protein benchmark
|
||||
running on E5-2697v2 processors with a Intel Xeon Phi 7120p
|
||||
coprocessor. In this plot, the vertical access is time and routines
|
||||
co-processor. In this plot, the vertical access is time and routines
|
||||
running at the same time are running concurrently on both the host and
|
||||
the coprocessor.
|
||||
the co-processor.
|
||||
|
||||
:c,image(JPG/offload_knc.png)
|
||||
|
||||
The fraction of the offloaded work is controlled by the {balance}
|
||||
keyword in the "package intel"_package.html command. A balance of 0
|
||||
runs all calculations on the CPU. A balance of 1 runs all
|
||||
supported calculations on the coprocessor. A balance of 0.5 runs half
|
||||
of the calculations on the coprocessor. Setting the balance to -1
|
||||
(the default) will enable dynamic load balancing that continously
|
||||
supported calculations on the co-processor. A balance of 0.5 runs half
|
||||
of the calculations on the co-processor. Setting the balance to -1
|
||||
(the default) will enable dynamic load balancing that continuously
|
||||
adjusts the fraction of offloaded work throughout the simulation.
|
||||
Because data transfer cannot be timed, this option typically produces
|
||||
results within 5 to 10 percent of the optimal fixed balance.
|
||||
|
@ -455,23 +455,23 @@ near-optimal setting that will carry over to additional runs.
|
|||
|
||||
The default for the "package intel"_package.html command is to have
|
||||
all the MPI tasks on a given compute node use a single Xeon Phi
|
||||
coprocessor. In general, running with a large number of MPI tasks on
|
||||
co-processor. In general, running with a large number of MPI tasks on
|
||||
each node will perform best with offload. Each MPI task will
|
||||
automatically get affinity to a subset of the hardware threads
|
||||
available on the coprocessor. For example, if your card has 61 cores,
|
||||
available on the co-processor. For example, if your card has 61 cores,
|
||||
with 60 cores available for offload and 4 hardware threads per core
|
||||
(240 total threads), running with 24 MPI tasks per node will cause
|
||||
each MPI task to use a subset of 10 threads on the coprocessor. Fine
|
||||
each MPI task to use a subset of 10 threads on the co-processor. Fine
|
||||
tuning of the number of threads to use per MPI task or the number of
|
||||
threads to use per core can be accomplished with keyword settings of
|
||||
the "package intel"_package.html command.
|
||||
|
||||
The USER-INTEL package has two modes for deciding which atoms will be
|
||||
handled by the coprocessor. This choice is controlled with the {ghost}
|
||||
handled by the co-processor. This choice is controlled with the {ghost}
|
||||
keyword of the "package intel"_package.html command. When set to 0,
|
||||
ghost atoms (atoms at the borders between MPI tasks) are not offloaded
|
||||
to the card. This allows for overlap of MPI communication of forces
|
||||
with computation on the coprocessor when the "newton"_newton.html
|
||||
with computation on the co-processor when the "newton"_newton.html
|
||||
setting is "on". The default is dependent on the style being used,
|
||||
however, better performance may be achieved by setting this option
|
||||
explicitly.
|
||||
|
@ -482,21 +482,21 @@ cores. This is due to the fact that additional threads are generated
|
|||
internally to handle the asynchronous offload tasks.
|
||||
|
||||
If pair computations are being offloaded to an Intel Xeon Phi
|
||||
coprocessor, a diagnostic line is printed to the screen (not to the
|
||||
co-processor, a diagnostic line is printed to the screen (not to the
|
||||
log file), during the setup phase of a run, indicating that offload
|
||||
mode is being used and indicating the number of coprocessor threads
|
||||
mode is being used and indicating the number of co-processor threads
|
||||
per MPI task. Additionally, an offload timing summary is printed at
|
||||
the end of each run. When offloading, the frequency for "atom
|
||||
sorting"_atom_modify.html is changed to 1 so that the per-atom data is
|
||||
effectively sorted at every rebuild of the neighbor lists. All the
|
||||
available coprocessor threads on each Phi will be divided among MPI
|
||||
available co-processor threads on each Phi will be divided among MPI
|
||||
tasks, unless the {tptask} option of the "-pk intel" "command-line
|
||||
switch"_Run_options.html is used to limit the coprocessor threads per
|
||||
switch"_Run_options.html is used to limit the co-processor threads per
|
||||
MPI task.
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
When offloading to a coprocessor, "hybrid"_pair_hybrid.html styles
|
||||
When offloading to a co-processor, "hybrid"_pair_hybrid.html styles
|
||||
that require skip lists for neighbor builds cannot be offloaded.
|
||||
Using "hybrid/overlay"_pair_hybrid.html is allowed. Only one intel
|
||||
accelerated style may be used with hybrid styles when offloading.
|
||||
|
@ -510,7 +510,7 @@ supported.
|
|||
|
||||
[References:]
|
||||
|
||||
Brown, W.M., Carrillo, J.-M.Y., Mishra, B., Gavhane, N., Thakker, F.M., De Kraker, A.R., Yamada, M., Ang, J.A., Plimpton, S.J., "Optimizing Classical Molecular Dynamics in LAMMPS," in Intel Xeon Phi Processor High Performance Programming: Knights Landing Edition, J. Jeffers, J. Reinders, A. Sodani, Eds. Morgan Kaufmann. :ulb,l
|
||||
Brown, W.M., Carrillo, J.-M.Y., Mishra, B., Gavhane, N., Thakkar, F.M., De Kraker, A.R., Yamada, M., Ang, J.A., Plimpton, S.J., "Optimizing Classical Molecular Dynamics in LAMMPS," in Intel Xeon Phi Processor High Performance Programming: Knights Landing Edition, J. Jeffers, J. Reinders, A. Sodani, Eds. Morgan Kaufmann. :ulb,l
|
||||
|
||||
Brown, W. M., Semin, A., Hebenstreit, M., Khvostov, S., Raman, K., Plimpton, S.J. "Increasing Molecular Dynamics Simulation Rates with an 8-Fold Increase in Electrical Power Efficiency."_http://dl.acm.org/citation.cfm?id=3014915 2016 High Performance Computing, Networking, Storage and Analysis, SC16: International Conference (pp. 82-95). :l
|
||||
|
||||
|
|
|
@ -13,11 +13,11 @@ Kokkos is a templated C++ library that provides abstractions to allow
|
|||
a single implementation of an application kernel (e.g. a pair style)
|
||||
to run efficiently on different kinds of hardware, such as GPUs, Intel
|
||||
Xeon Phis, or many-core CPUs. Kokkos maps the C++ kernel onto
|
||||
different backend languages such as CUDA, OpenMP, or Pthreads. The
|
||||
different back end languages such as CUDA, OpenMP, or Pthreads. The
|
||||
Kokkos library also provides data abstractions to adjust (at compile
|
||||
time) the memory layout of data structures like 2d and 3d arrays to
|
||||
optimize performance on different hardware. For more information on
|
||||
Kokkos, see "Github"_https://github.com/kokkos/kokkos. Kokkos is part
|
||||
Kokkos, see "GitHub"_https://github.com/kokkos/kokkos. Kokkos is part
|
||||
of "Trilinos"_http://trilinos.sandia.gov/packages/kokkos. The Kokkos
|
||||
library was written primarily by Carter Edwards, Christian Trott, and
|
||||
Dan Sunderland (all Sandia).
|
||||
|
@ -106,9 +106,9 @@ modification to the input script is needed. Alternatively, one can run
|
|||
with the KOKKOS package by editing the input script as described
|
||||
below.
|
||||
|
||||
NOTE: When using a single OpenMP thread, the Kokkos Serial backend (i.e.
|
||||
NOTE: When using a single OpenMP thread, the Kokkos Serial back end (i.e.
|
||||
Makefile.kokkos_mpi_only) will give better performance than the OpenMP
|
||||
backend (i.e. Makefile.kokkos_omp) because some of the overhead to make
|
||||
back end (i.e. Makefile.kokkos_omp) because some of the overhead to make
|
||||
the code thread-safe is removed.
|
||||
|
||||
NOTE: The default for the "package kokkos"_package.html command is to
|
||||
|
@ -127,21 +127,21 @@ mpirun -np 16 lmp_kokkos_mpi_only -k on -sf kk -pk kokkos newton on neigh half c
|
|||
If the "newton"_newton.html command is used in the input
|
||||
script, it can also override the Newton flag defaults.
|
||||
|
||||
For half neighbor lists and OpenMP, the KOKKOS package uses data
|
||||
duplication (i.e. thread-private arrays) by default to avoid
|
||||
thread-level write conflicts in the force arrays (and other data
|
||||
structures as necessary). Data duplication is typically fastest for
|
||||
small numbers of threads (i.e. 8 or less) but does increase memory
|
||||
footprint and is not scalable to large numbers of threads. An
|
||||
alternative to data duplication is to use thread-level atomics, which
|
||||
don't require duplication. The use of atomics can be forced by compiling
|
||||
with the "-DLMP_KOKKOS_USE_ATOMICS" compile switch. Most but not all
|
||||
Kokkos-enabled pair_styles support data duplication. Alternatively, full
|
||||
neighbor lists avoid the need for duplication or atomics but require
|
||||
more compute operations per atom. When using the Kokkos Serial backend
|
||||
or the OpenMP backend with a single thread, no duplication or atomics are
|
||||
used. For CUDA and half neighbor lists, the KOKKOS package always uses
|
||||
atomics.
|
||||
For half neighbor lists and OpenMP, the KOKKOS package uses data
|
||||
duplication (i.e. thread-private arrays) by default to avoid
|
||||
thread-level write conflicts in the force arrays (and other data
|
||||
structures as necessary). Data duplication is typically fastest for
|
||||
small numbers of threads (i.e. 8 or less) but does increase memory
|
||||
footprint and is not scalable to large numbers of threads. An
|
||||
alternative to data duplication is to use thread-level atomic operations
|
||||
which do not require data duplication. The use of atomic operations can
|
||||
be enforced by compiling LAMMPS with the "-DLMP_KOKKOS_USE_ATOMICS"
|
||||
pre-processor flag. Most but not all Kokkos-enabled pair_styles support
|
||||
data duplication. Alternatively, full neighbor lists avoid the need for
|
||||
duplication or atomic operations but require more compute operations per
|
||||
atom. When using the Kokkos Serial back end or the OpenMP back end with
|
||||
a single thread, no duplication or atomic operations are used. For CUDA
|
||||
and half neighbor lists, the KOKKOS package always uses atomic operations.
|
||||
|
||||
[Core and Thread Affinity:]
|
||||
|
||||
|
@ -193,7 +193,7 @@ threads/task as Nt. The product of these two values should be N, i.e.
|
|||
NOTE: The default for the "package kokkos"_package.html command is to
|
||||
use "full" neighbor lists and set the Newton flag to "off" for both
|
||||
pairwise and bonded interactions. When running on KNL, this will
|
||||
typically be best for pair-wise potentials. For manybody potentials,
|
||||
typically be best for pair-wise potentials. For many-body potentials,
|
||||
using "half" neighbor lists and setting the Newton flag to "on" may be
|
||||
faster. It can also be faster to use non-threaded communication. Use
|
||||
the "-pk kokkos" "command-line switch"_Run_options.html to change the
|
||||
|
@ -207,7 +207,7 @@ mpirun -np 64 lmp_kokkos_phi -k on t 4 -sf kk -pk kokkos newton on neigh half co
|
|||
NOTE: MPI tasks and threads should be bound to cores as described
|
||||
above for CPUs.
|
||||
|
||||
NOTE: To build with Kokkos support for Intel Xeon Phi coprocessors
|
||||
NOTE: To build with Kokkos support for Intel Xeon Phi co-processors
|
||||
such as Knight's Corner (KNC), your system must be configured to use
|
||||
them in "native" mode, not "offload" mode like the USER-INTEL package
|
||||
supports.
|
||||
|
|
|
@ -131,7 +131,7 @@ effect worsens when using an increasing number of nodes. :l
|
|||
The system has a spatially inhomogeneous particle density which does
|
||||
not map well to the "domain decomposition scheme"_processors.html or
|
||||
"load-balancing"_balance.html options that LAMMPS provides. This is
|
||||
because multi-threading achives parallelism over the number of
|
||||
because multi-threading achieves parallelism over the number of
|
||||
particles, not via their distribution in space. :l
|
||||
|
||||
A machine is being used in "capability mode", i.e. near the point
|
||||
|
@ -143,7 +143,7 @@ the performance-limiting factor. Using multi-threading allows less
|
|||
MPI tasks to be invoked and can speed-up the long-range solver, while
|
||||
increasing overall performance by parallelizing the pairwise and
|
||||
bonded calculations via OpenMP. Likewise additional speedup can be
|
||||
sometimes be achived by increasing the length of the Coulombic cutoff
|
||||
sometimes be achieved by increasing the length of the Coulombic cutoff
|
||||
and thus reducing the work done by the long-range solver. Using the
|
||||
"run_style verlet/split"_run_style.html command, which is compatible
|
||||
with the USER-OMP package, is an alternative way to reduce the number
|
||||
|
|
|
@ -14,7 +14,7 @@ Accelerated versions of various "pair_style"_pair_style.html,
|
|||
been added to LAMMPS, which will typically run faster than the
|
||||
standard non-accelerated versions. Some require appropriate hardware
|
||||
to be present on your system, e.g. GPUs or Intel Xeon Phi
|
||||
coprocessors.
|
||||
co-processors.
|
||||
|
||||
All of these commands are in packages provided with LAMMPS. An
|
||||
overview of packages is give on the "Packages"_Packages.html doc
|
||||
|
@ -161,7 +161,7 @@ package. These styles support vectorized single and mixed precision
|
|||
calculations, in addition to full double precision. In extreme cases,
|
||||
this can provide speedups over 3.5x on CPUs. The package also
|
||||
supports acceleration in "offload" mode to Intel(R) Xeon Phi(TM)
|
||||
coprocessors. This can result in additional speedup over 2x depending
|
||||
co-processors. This can result in additional speedup over 2x depending
|
||||
on the hardware configuration. :l
|
||||
|
||||
Styles with a "kk" suffix are part of the KOKKOS package, and can be
|
||||
|
|
|
@ -163,7 +163,7 @@ for the "chain benchmark"_Speed_bench.html.
|
|||
|
||||
colvars tools :h4,link(colvars)
|
||||
|
||||
The colvars directory contains a collection of tools for postprocessing
|
||||
The colvars directory contains a collection of tools for post-processing
|
||||
data produced by the colvars collective variable library.
|
||||
To compile the tools, edit the makefile for your system and run "make".
|
||||
|
||||
|
@ -406,15 +406,15 @@ supports it. It has its own WWW page at
|
|||
msi2lmp tool :h4,link(msi)
|
||||
|
||||
The msi2lmp sub-directory contains a tool for creating LAMMPS template
|
||||
input and data files from BIOVIA's Materias Studio files (formerly Accelrys'
|
||||
Insight MD code, formerly MSI/Biosym and its Discover MD code).
|
||||
input and data files from BIOVIA's Materias Studio files (formerly
|
||||
Accelrys' Insight MD code, formerly MSI/Biosym and its Discover MD code).
|
||||
|
||||
This tool was written by John Carpenter (Cray), Michael Peachey
|
||||
(Cray), and Steve Lustig (Dupont). Several people contributed changes
|
||||
to remove bugs and adapt its output to changes in LAMMPS.
|
||||
|
||||
This tool has several known limitations and is no longer under active
|
||||
development, so there are no changes except for the occasional bugfix.
|
||||
development, so there are no changes except for the occasional bug fix.
|
||||
|
||||
See the README file in the tools/msi2lmp folder for more information.
|
||||
|
||||
|
|
|
@ -28,7 +28,7 @@ The {sdk} angle style is a combination of the harmonic angle potential,
|
|||
where theta0 is the equilibrium value of the angle and K a prefactor,
|
||||
with the {repulsive} part of the non-bonded {lj/sdk} pair style
|
||||
between the atoms 1 and 3. This angle potential is intended for
|
||||
coarse grained MD simulations with the CMM parametrization using the
|
||||
coarse grained MD simulations with the CMM parameterization using the
|
||||
"pair_style lj/sdk"_pair_sdk.html. Relative to the pair_style
|
||||
{lj/sdk}, however, the energy is shifted by {epsilon}, to avoid sudden
|
||||
jumps. Note that the usual 1/2 factor is included in K.
|
||||
|
|
|
@ -87,7 +87,7 @@ quantities.
|
|||
{line} | end points, angular velocity | rigid bodies |
|
||||
{meso} | rho, e, cv | SPH particles |
|
||||
{molecular} | bonds, angles, dihedrals, impropers | uncharged molecules |
|
||||
{peri} | mass, volume | mesocopic Peridynamic models |
|
||||
{peri} | mass, volume | mesoscopic Peridynamic models |
|
||||
{smd} | volume, kernel diameter, contact radius, mass | solid and fluid SPH particles |
|
||||
{sphere} | diameter, mass, angular velocity | granular models |
|
||||
{spin} | magnetic moment | system with magnetic particles |
|
||||
|
|
|
@ -247,7 +247,7 @@ to {Niter} times. After each dimension finishes, the imbalance factor
|
|||
is re-computed, and the balancing operation halts if the {stopthresh}
|
||||
criterion is met.
|
||||
|
||||
A rebalance operation in a single dimension is performed using a
|
||||
A re-balance operation in a single dimension is performed using a
|
||||
recursive multisectioning algorithm, where the position of each
|
||||
cutting plane (line in 2d) in the dimension is adjusted independently.
|
||||
This is similar to a recursive bisectioning for a single value, except
|
||||
|
@ -261,11 +261,11 @@ information, so that they become closer together over time. Thus as
|
|||
the recursion progresses, the count of particles on either side of the
|
||||
plane gets closer to the target value.
|
||||
|
||||
Once the rebalancing is complete and final processor sub-domains
|
||||
Once the re-balancing is complete and final processor sub-domains
|
||||
assigned, particles are migrated to their new owning processor, and
|
||||
the balance procedure ends.
|
||||
|
||||
NOTE: At each rebalance operation, the bisectioning for each cutting
|
||||
NOTE: At each re-balance operation, the bisectioning for each cutting
|
||||
plane (line in 2d) typically starts with low and high bounds separated
|
||||
by the extent of a processor's sub-domain in one dimension. The size
|
||||
of this bracketing region shrinks by 1/2 every iteration. Thus if
|
||||
|
@ -348,7 +348,7 @@ specified groups, its weight is not changed. If it belongs to
|
|||
multiple groups, its weight is the product of the weight factors.
|
||||
|
||||
This weight style is useful in combination with pair style
|
||||
"hybrid"_pair_hybrid.html, e.g. when combining a more costly manybody
|
||||
"hybrid"_pair_hybrid.html, e.g. when combining a more costly many-body
|
||||
potential with a fast pair-wise potential. It is also useful when
|
||||
using "run_style respa"_run_style.html where some portions of the
|
||||
system have many bonded interactions and others none. It assumes that
|
||||
|
|
|
@ -52,7 +52,7 @@ hydrogen-bonding interaction {oxdna/hbond} (see also documentation of
|
|||
"(Snodin)"_#oxdna2 bond style the analogous pair styles and an
|
||||
additional Debye-Hueckel pair style {oxdna2/dh} have to be defined.
|
||||
The coefficients in the above example have to be kept fixed and cannot
|
||||
be changed without reparametrizing the entire model.
|
||||
be changed without reparameterizing the entire model.
|
||||
|
||||
Example input and data files for DNA duplexes can be found in
|
||||
examples/USER/cgdna/examples/oxDNA/ and /oxDNA2/. A simple python
|
||||
|
|
|
@ -154,6 +154,6 @@ Communication mode {multi} is currently only available for
|
|||
|
||||
[Default:]
|
||||
|
||||
The option defauls are mode = single, group = all, cutoff = 0.0, vel =
|
||||
The option defaults are mode = single, group = all, cutoff = 0.0, vel =
|
||||
no. The cutoff default of 0.0 means that ghost cutoff = neighbor
|
||||
cutoff = pairwise force cutoff + neighbor skin.
|
||||
|
|
|
@ -309,7 +309,7 @@ compute"_Commands_compute.html doc page are followed by one or more of
|
|||
"temp/uef"_compute_temp_uef.html -
|
||||
"ti"_compute_ti.html - thermodynamic integration free energy values
|
||||
"torque/chunk"_compute_torque_chunk.html - torque applied on each chunk
|
||||
"vacf"_compute_vacf.html - velocity-autocorrelation function of group of atoms
|
||||
"vacf"_compute_vacf.html - velocity auto-correlation function of group of atoms
|
||||
"vcm/chunk"_compute_vcm_chunk.html - velocity of center-of-mass for each chunk
|
||||
"voronoi/atom"_compute_voronoi_atom.html - Voronoi volume and neighbors for each atom
|
||||
"xrd"_compute_xrd.html - :ul
|
||||
|
|
|
@ -33,22 +33,22 @@ keyword = {ordinate} :l
|
|||
|
||||
compute 1 fluid adf 32 1 1 1 0.0 1.2 0.0 1.2 &
|
||||
1 1 2 0.0 1.2 0.0 1.5 &
|
||||
1 2 2 0.0 1.5 0.0 1.5 &
|
||||
1 2 2 0.0 1.5 0.0 1.5 &
|
||||
2 1 1 0.0 1.2 0.0 1.2 &
|
||||
2 1 2 0.0 1.5 2.0 3.5 &
|
||||
2 2 2 2.0 3.5 2.0 3.5
|
||||
2 2 2 2.0 3.5 2.0 3.5
|
||||
compute 1 fluid adf 32 1*2 1*2 1*2 0.5 3.5
|
||||
compute 1 fluid adf 32 :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
Define a computation that calculates one or more angular distribution functions
|
||||
(ADF) for a group of particles. Each ADF is calculated in histogram form
|
||||
(ADF) for a group of particles. Each ADF is calculated in histogram form
|
||||
by measuring the angle formed by a central atom and two neighbor atoms and
|
||||
binning these angles into {Nbin} bins.
|
||||
Only neighbors for which {Rinner} < {R} < {Router} are counted, where
|
||||
{Rinner} and {Router} are specified separately for the first and second
|
||||
neighbor atom in each requested ADF.
|
||||
neighbor atom in each requested ADF.
|
||||
|
||||
NOTE: If you have a bonded system, then the settings of
|
||||
"special_bonds"_special_bonds.html command can remove pairwise
|
||||
|
@ -66,18 +66,18 @@ the dump file. The rerun script can use a
|
|||
"special_bonds"_special_bonds.html command that includes all pairs in
|
||||
the neighbor list.
|
||||
|
||||
NOTE: If you request any outer cutoff {Router} > force cutoff, or if no
|
||||
NOTE: If you request any outer cutoff {Router} > force cutoff, or if no
|
||||
pair style is defined, e.g. the "rerun"_rerun.html command is being used to
|
||||
post-process a dump file of snapshots you must insure ghost atom information
|
||||
out to the largest value of {Router} + {skin} is communicated, via the
|
||||
"comm_modify cutoff"_comm_modify.html command, else the ADF computation
|
||||
cannot be performed, and LAMMPS will give an error message. The {skin} value
|
||||
is what is specified with the "neighbor"_neighbor.html command.
|
||||
post-process a dump file of snapshots you must insure ghost atom information
|
||||
out to the largest value of {Router} + {skin} is communicated, via the
|
||||
"comm_modify cutoff"_comm_modify.html command, else the ADF computation
|
||||
cannot be performed, and LAMMPS will give an error message. The {skin} value
|
||||
is what is specified with the "neighbor"_neighbor.html command.
|
||||
|
||||
The {itypeN},{jtypeN},{ktypeN} settings can be specified in one of two
|
||||
ways. An explicit numeric value can be used, as in the 1st example
|
||||
above. Or a wild-card asterisk can be used to specify a range of atom
|
||||
types as in the 2nd example above.
|
||||
types as in the 2nd example above.
|
||||
This takes the form "*" or "*n" or "n*" or "m*n". If N = the
|
||||
number of atom types, then an asterisk with no numeric values means
|
||||
all types from 1 to N. A leading asterisk means all types from 1 to n
|
||||
|
@ -88,13 +88,13 @@ all types from 1 to N. A leading asterisk means all types from 1 to n
|
|||
If {itypeN}, {jtypeN}, and {ktypeN} are single values, as in the 1st example
|
||||
above, this means that the ADF is computed where atoms of type {itypeN}
|
||||
are the central atom, and neighbor atoms of type {jtypeN} and {ktypeN}
|
||||
are forming the angle. If any of {itypeN}, {jtypeN}, or {ktypeN}
|
||||
are forming the angle. If any of {itypeN}, {jtypeN}, or {ktypeN}
|
||||
represent a range of values via
|
||||
the wild-card asterisk, as in the 2nd example above, this means that the
|
||||
ADF is computed where atoms of any of the range of types represented
|
||||
by {itypeN} are the central atom, and the angle is formed by two neighbors,
|
||||
one neighbor in the range of types represented by {jtypeN} and another neighbor
|
||||
in the range of types represented by {ktypeN}.
|
||||
one neighbor in the range of types represented by {jtypeN} and another neighbor
|
||||
in the range of types represented by {ktypeN}.
|
||||
|
||||
If no {itypeN}, {jtypeN}, {ktypeN} settings are specified, then
|
||||
LAMMPS will generate a single ADF for all atoms in the group.
|
||||
|
@ -106,13 +106,13 @@ Such an ADF is both uninformative and
|
|||
extremely expensive to compute. For example, with liquid water
|
||||
with a 10 A force cutoff, there are 80,000 angles per atom.
|
||||
In addition, most of the interesting angular structure occurs for
|
||||
neighbors that are the closest to the central atom, involving
|
||||
neighbors that are the closest to the central atom, involving
|
||||
just a few dozen angles.
|
||||
|
||||
Angles for each ADF are generated by double-looping over the list of
|
||||
neighbors of each central atom I,
|
||||
just as they would be in the force calculation for
|
||||
a threebody potential such as "Stillinger-Weber"_pair_sw.html.
|
||||
Angles for each ADF are generated by double-looping over the list of
|
||||
neighbors of each central atom I,
|
||||
just as they would be in the force calculation for
|
||||
a three-body potential such as "Stillinger-Weber"_pair_sw.html.
|
||||
The angle formed by central atom I and neighbor atoms J and K is included in an
|
||||
ADF if the following criteria are met:
|
||||
|
||||
|
@ -121,12 +121,12 @@ the distance between atoms I,J is between Rjinner and Rjouter
|
|||
the distance between atoms I,K is between Rkinner and Rkouter
|
||||
the type of the I atom matches itypeN (one or a range of types)
|
||||
atoms I,J,K are distinct
|
||||
the type of the J atom matches jtypeN (one or a range of types)
|
||||
the type of the J atom matches jtypeN (one or a range of types)
|
||||
the type of the K atom matches ktypeN (one or a range of types) :ul
|
||||
|
||||
Each unique angle satisfying the above criteria is counted only once, regardless
|
||||
of whether either or both of the neighbor atoms making up the
|
||||
angle appear in both the J and K lists.
|
||||
angle appear in both the J and K lists.
|
||||
It is OK if a particular angle is included in more than
|
||||
one individual histogram, due to the way the {itypeN}, {jtypeN}, {ktypeN}
|
||||
arguments are specified.
|
||||
|
@ -146,15 +146,15 @@ number radial distribution function.
|
|||
|
||||
The {ordinate} optional keyword determines
|
||||
whether the bins are of uniform angular size from zero
|
||||
to 180 ({degree}), zero to Pi ({radian}), or the
|
||||
to 180 ({degree}), zero to Pi ({radian}), or the
|
||||
cosine of the angle uniform in the range \[-1,1\] ({cosine}).
|
||||
{cosine} has the advantage of eliminating the {acos()} function
|
||||
call, which speeds up the compute by 2-3x, and it is also preferred
|
||||
on physical grounds, because the for uniformly distributed particles
|
||||
on physical grounds, because the for uniformly distributed particles
|
||||
in 3D, the angular probability density w.r.t dtheta is
|
||||
sin(theta)/2, while for d(cos(theta)), it is 1/2,
|
||||
Regardless of which ordinate is chosen, the first column of ADF
|
||||
values is normalized w.r.t. the range of that ordinate, so that
|
||||
sin(theta)/2, while for d(cos(theta)), it is 1/2,
|
||||
Regardless of which ordinate is chosen, the first column of ADF
|
||||
values is normalized w.r.t. the range of that ordinate, so that
|
||||
the integral is 1.
|
||||
|
||||
The simplest way to output the results of the compute adf calculation
|
||||
|
@ -170,7 +170,7 @@ This compute calculates a global array with the number of rows =
|
|||
{Nbins}, and the number of columns = 1 + 2*Ntriples, where Ntriples is the
|
||||
number of I,J,K triples specified. The first column has the bin
|
||||
coordinate (angle-related ordinate at midpoint of bin). Each subsequent column has
|
||||
the two ADF values for a specific set of ({itypeN},{jtypeN},{ktypeN})
|
||||
the two ADF values for a specific set of ({itypeN},{jtypeN},{ktypeN})
|
||||
interactions, as described above. These values can be used
|
||||
by any command that uses a global values from a compute as input. See
|
||||
the "Howto output"_Howto_output.html doc page for an overview of
|
||||
|
@ -181,15 +181,15 @@ The array values calculated by this compute are all "intensive".
|
|||
The first column of array values is the angle-related ordinate, either
|
||||
the angle in degrees or radians, or the cosine of the angle. Each
|
||||
subsequent pair of columns gives the first and second kinds of ADF
|
||||
for a specific set of ({itypeN},{jtypeN},{ktypeN}). The values
|
||||
for a specific set of ({itypeN},{jtypeN},{ktypeN}). The values
|
||||
in the first ADF column are normalized numbers >= 0.0,
|
||||
whose integral w.r.t. the ordinate is 1,
|
||||
i.e. the first ADF is a normalized probability distribution.
|
||||
i.e. the first ADF is a normalized probability distribution.
|
||||
The values in the second ADF column are also numbers >= 0.0.
|
||||
They are the cumulative density distribution of angles per atom.
|
||||
By definition, this ADF is monotonically increasing from zero to
|
||||
a maximum value equal to the average total number of
|
||||
angles per atom satisfying the ADF criteria.
|
||||
angles per atom satisfying the ADF criteria.
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
|
@ -200,7 +200,7 @@ distances, you can use the "rerun"_rerun.html command to post-process
|
|||
a dump file and set the cutoff for the potential to be longer in the
|
||||
rerun script. Note that in the rerun context, the force cutoff is
|
||||
arbitrary, since you aren't running dynamics and thus are not changing
|
||||
your model.
|
||||
your model.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
|
|
|
@ -28,7 +28,7 @@ The results enable efficient identification and characterization of
|
|||
twins and grains in hexagonal close-packed structures.
|
||||
|
||||
The output of the compute is thus the 3 components of a unit vector
|
||||
associdate with each atom. The components are set to 0.0 for
|
||||
associated with each atom. The components are set to 0.0 for
|
||||
atoms not in the group.
|
||||
|
||||
Details of the calculation are given in "(Barrett)"_#Barrett.
|
||||
|
|
|
@ -68,7 +68,7 @@ in the bond, which is simply 1/2 m1 v1^2 + 1/2 m2 v2^2, where v1 and
|
|||
v2 are the magnitude of the velocity of the 2 atoms along the bond
|
||||
direction, after the COM velocity has been subtracted from each.
|
||||
|
||||
The value {engrot} is the rotationsl kinetic energy of the two atoms
|
||||
The value {engrot} is the rotational kinetic energy of the two atoms
|
||||
in the bond, which is simply 1/2 m1 v1^2 + 1/2 m2 v2^2, where v1 and
|
||||
v2 are the magnitude of the velocity of the 2 atoms perpendicular to
|
||||
the bond direction, after the COM velocity has been subtracted from
|
||||
|
|
|
@ -210,7 +210,7 @@ between {crmin} and {crmax}. For example, if {crmin} = 1.0 and
|
|||
{crmax} = 10.0 and {ncbin} = 9, then the first bin spans 1.0 < r <
|
||||
2.0, and the last bin spans 9.0 < r 10.0. The geometry of the bins in
|
||||
the radial dimensions is the same whether the simulation box is
|
||||
orthogonal or triclinic; i.e. the concetric circles are not tilted or
|
||||
orthogonal or triclinic; i.e. the concentric circles are not tilted or
|
||||
scaled differently in the two different dimensions to transform them
|
||||
into ellipses.
|
||||
|
||||
|
|
|
@ -33,7 +33,7 @@ Currently, there are five kinds of CNA patterns LAMMPS recognizes:
|
|||
fcc = 1
|
||||
hcp = 2
|
||||
bcc = 3
|
||||
icosohedral = 4
|
||||
icosahedral = 4
|
||||
unknown = 5 :ul
|
||||
|
||||
The value of the CNA pattern will be 0 for atoms not in the specified
|
||||
|
|
|
@ -26,7 +26,7 @@ in a group. This is a quantity relevant for "Peridynamics
|
|||
models"_pair_peri.html. See "this document"_PDF/PDLammps_overview.pdf
|
||||
for an overview of LAMMPS commands for Peridynamics modeling.
|
||||
|
||||
The "damage" of a Peridymaics particles is based on the bond breakage
|
||||
The "damage" of a Peridynamics particles is based on the bond breakage
|
||||
between the particle and its neighbors. If all the bonds are broken
|
||||
the particle is considered to be fully damaged.
|
||||
|
||||
|
|
|
@ -57,7 +57,7 @@ correctly with time=0 atom coordinates from the restart file.
|
|||
|
||||
:line
|
||||
|
||||
The {refresh} option can be used in conjuction with the "dump_modify
|
||||
The {refresh} option can be used in conjunction with the "dump_modify
|
||||
refresh" command to generate incremental dump files.
|
||||
|
||||
The definition and motivation of an incremental dump file is as
|
||||
|
|
|
@ -82,11 +82,11 @@ first term in the equation for J above.
|
|||
|
||||
The heat flux can be output every so many timesteps (e.g. via the
|
||||
"thermo_style custom"_thermo_style.html command). Then as a
|
||||
post-processing operation, an autocorrelation can be performed, its
|
||||
post-processing operation, an auto-correlation can be performed, its
|
||||
integral estimated, and the Green-Kubo formula above evaluated.
|
||||
|
||||
The "fix ave/correlate"_fix_ave_correlate.html command can calculate
|
||||
the autocorrelation. The trap() function in the
|
||||
the auto-correlation. The trap() function in the
|
||||
"variable"_variable.html command can calculate the integral.
|
||||
|
||||
An example LAMMPS input script for solid Ar is appended below. The
|
||||
|
|
|
@ -50,7 +50,7 @@ The value of the displacement will be
|
|||
|
||||
If the {com} option is set to {yes} then the effect of any drift in
|
||||
the center-of-mass of the group of atoms is subtracted out before the
|
||||
displacment of each atom is calculated.
|
||||
displacement of each atom is calculated.
|
||||
|
||||
If the {average} option is set to {yes} then the reference position of
|
||||
an atom is based on the average position of that atom, corrected for
|
||||
|
|
|
@ -48,7 +48,7 @@ others.
|
|||
|
||||
If the {com} option is set to {yes} then the effect of any drift in
|
||||
the center-of-mass of the group of atoms is subtracted out before the
|
||||
displacment of each atom is calculated.
|
||||
displacement of each atom is calculated.
|
||||
|
||||
See the "compute msd"_compute_msd.html doc page for further important
|
||||
NOTEs, which also apply to this compute.
|
||||
|
|
|
@ -15,7 +15,7 @@ compute ID group-ID pair pstyle \[nstyle\] \[evalue\] :pre
|
|||
ID, group-ID are documented in "compute"_compute.html command :ulb,l
|
||||
pair = style name of this compute command :l
|
||||
pstyle = style name of a pair style that calculates additional values :l
|
||||
nsub = {n}-instance of a substyle, if a pair style is used multiple times in a hybrid style :l
|
||||
nsub = {n}-instance of a sub-style, if a pair style is used multiple times in a hybrid style :l
|
||||
{evalue} = {epair} or {evdwl} or {ecoul} or blank (optional) :l
|
||||
:ule
|
||||
|
||||
|
|
|
@ -30,7 +30,7 @@ The plasticity for a Peridynamic particle is the so-called consistency
|
|||
parameter (lambda). For elastic deformation lambda = 0, otherwise
|
||||
lambda > 0 for plastic deformation. For details, see
|
||||
"(Mitchell)"_#Mitchell and the PDF doc included in the LAMMPS
|
||||
distro in "doc/PDF/PDLammps_EPS.pdf"_PDF/PDLammps_EPS.pdf.
|
||||
distribution in "doc/PDF/PDLammps_EPS.pdf"_PDF/PDLammps_EPS.pdf.
|
||||
|
||||
This command can be invoked for one of the Peridynamic "pair
|
||||
styles"_pair_peri.html: peri/eps.
|
||||
|
|
|
@ -40,7 +40,7 @@ below), Kb is the Boltzmann constant, T is the temperature, d is the
|
|||
dimensionality of the system (2 or 3 for 2d/3d), and V is the system
|
||||
volume (or area in 2d). The second term is the virial, equal to
|
||||
-dU/dV, computed for all pairwise as well as 2-body, 3-body, 4-body,
|
||||
manybody, and long-range interactions, where r_i and f_i are the
|
||||
many-body, and long-range interactions, where r_i and f_i are the
|
||||
position and force vector of atom i, and the black dot indicates a dot
|
||||
product. When periodic boundary conditions are used, N' necessarily
|
||||
includes periodic image (ghost) atoms outside the central box, and the
|
||||
|
@ -68,7 +68,7 @@ compute temperature or ke and/or the virial. The {virial} keyword
|
|||
means include all terms except the kinetic energy {ke}.
|
||||
|
||||
Details of how LAMMPS computes the virial efficiently for the entire
|
||||
system, including for manybody potentials and accounting for the
|
||||
system, including for many-body potentials and accounting for the
|
||||
effects of periodic boundary conditions are discussed in
|
||||
"(Thompson)"_#Thompson1.
|
||||
|
||||
|
|
|
@ -58,7 +58,7 @@ This compute currently calculates the pressure tensor contributions
|
|||
for pair styles only (i.e. no bond, angle, dihedral, etc. contributions
|
||||
and in the presence of bonded interactions, the result will be incorrect
|
||||
due to exclusions for special bonds) and requires pair-wise force
|
||||
calculations not available for most manybody pair styles. K-space
|
||||
calculations not available for most many-body pair styles. K-space
|
||||
calculations are also excluded. Note that this pressure compute outputs
|
||||
the configurational terms only; the kinetic contribution is not included
|
||||
and may be calculated from the number density output by P_kin=density*k*T.
|
||||
|
|
|
@ -19,7 +19,7 @@ input = one or more atom attributes :l
|
|||
x, y, z, xs, ys, zs, xu, yu, zu, ix, iy, iz,
|
||||
vx, vy, vz, fx, fy, fz,
|
||||
q, mux, muy, muz, mu,
|
||||
sp, spx, spy, spz, fmx, fmy, fmz,
|
||||
sp, spx, spy, spz, fmx, fmy, fmz,
|
||||
radius, diameter, omegax, omegay, omegaz,
|
||||
angmomx, angmomy, angmomz,
|
||||
shapex,shapey, shapez,
|
||||
|
@ -158,8 +158,8 @@ corresponding attribute is in, e.g. velocity units for vx, charge
|
|||
units for q, etc.
|
||||
|
||||
For the spin quantities, sp is in the units of the Bohr magneton, spx,
|
||||
spy, and spz are adimensional quantities, and fmx, fmy and fmz are
|
||||
given in rad.THz.
|
||||
spy, and spz are unitless quantities, and fmx, fmy and fmz are given
|
||||
in rad/THz.
|
||||
|
||||
[Restrictions:] none
|
||||
|
||||
|
|
|
@ -80,7 +80,7 @@ too frequently or to have multiple compute/dump commands, each with a
|
|||
|
||||
[Output info:]
|
||||
|
||||
This compute calculates a per-atom arry, which can be accessed by
|
||||
This compute calculates a per-atom array, which can be accessed by
|
||||
any command that uses per-atom values from a compute as input. See
|
||||
the "Howto output"_Howto_output.html doc page for an overview of
|
||||
LAMMPS output options.
|
||||
|
|
|
@ -61,7 +61,7 @@ or {max} options find the minimum or maximum value across all vector
|
|||
values. The {ave} setting adds the vector values into a global total,
|
||||
then divides by the number of values in the vector. The {sumsq}
|
||||
option sums the square of the values in the vector into a global
|
||||
total. The {avesq} setting does the same as {sumsq}, then divdes the
|
||||
total. The {avesq} setting does the same as {sumsq}, then divides the
|
||||
sum of squares by the number of values. The last two options can be
|
||||
useful for calculating the variance of some quantity, e.g. variance =
|
||||
sumsq - ave^2.
|
||||
|
|
|
@ -137,7 +137,7 @@ compute micelle all chunk/atom c_spread compress yes :pre
|
|||
Further analysis on a per-micelle basis can now be performed using any
|
||||
of the per-chunk computes listed on the "Howto chunk"_Howto_chunk.html
|
||||
doc page. E.g. count the number of atoms in each micelle, calculate
|
||||
its center or mass, shape (moments of intertia), radius of gyration,
|
||||
its center or mass, shape (moments of inertia), radius of gyration,
|
||||
etc.
|
||||
|
||||
compute prop all property/chunk micelle count
|
||||
|
|
|
@ -106,7 +106,7 @@ There are two options for outputting the coordinates of the center of
|
|||
mass (COM) of the body. The {x}, {y}, {z} attributes write the COM
|
||||
"unscaled", in the appropriate distance "units"_units.html (Angstroms,
|
||||
sigma, etc). Use {xu}, {yu}, {zu} if you want the COM "unwrapped" by
|
||||
the image flags for each atobody. Unwrapped means that if the body
|
||||
the image flags for each body. Unwrapped means that if the body
|
||||
COM has passed thru a periodic boundary one or more times, the value
|
||||
is generated what the COM coordinate would be if it had not been
|
||||
wrapped back into the periodic box.
|
||||
|
|
|
@ -29,7 +29,7 @@ within the neighborhood of the central node and the deformation
|
|||
gradient, the approximated relative separation will coincide with the
|
||||
actual relative separation of the particles i and j in the deformed
|
||||
configuration. This compute is only really useful for debugging the
|
||||
hourglass control mechanim which is part of the Total-Lagrangian SPH
|
||||
hourglass control mechanism which is part of the Total-Lagrangian SPH
|
||||
pair style.
|
||||
|
||||
See "this PDF guide"_PDF/SMD_LAMMPS_userguide.pdf to use Smooth
|
||||
|
|
|
@ -30,7 +30,7 @@ Mach Dynamics in LAMMPS.
|
|||
|
||||
[Output info:]
|
||||
|
||||
This compute outputss a per-particle vector of vectors (tensors),
|
||||
This compute outputs a per-particle vector of vectors (tensors),
|
||||
which can be accessed by any command that uses per-particle values
|
||||
from a compute as input. See the "Howto output"_Howto_output.html doc
|
||||
page for an overview of LAMMPS output options.
|
||||
|
|
|
@ -38,7 +38,7 @@ overview of LAMMPS output options.
|
|||
|
||||
The per-particle vector has 7 entries. The first three entries
|
||||
correspond to the lengths of the ellipsoid's axes and have units of
|
||||
length. These axis valus are computed as the contact radius times the
|
||||
length. These axis values are computed as the contact radius times the
|
||||
xx, yy, or zz components of the Green-Lagrange strain tensor
|
||||
associated with the particle. The next 4 values are quaternions
|
||||
(order: q, x, y, z) which describe the spatial rotation of the
|
||||
|
|
|
@ -73,9 +73,9 @@ Note that the stress for each atom is due to its interaction with all
|
|||
other atoms in the simulation, not just with other atoms in the group.
|
||||
|
||||
Details of how LAMMPS computes the virial for individual atoms for
|
||||
either pairwise or manybody potentials, and including the effects of
|
||||
either pairwise or many-body potentials, and including the effects of
|
||||
periodic boundary conditions is discussed in "(Thompson)"_#Thompson2.
|
||||
The basic idea for manybody potentials is to treat each component of
|
||||
The basic idea for many-body potentials is to treat each component of
|
||||
the force computation between a small cluster of atoms in the same
|
||||
manner as in the formula above for bond, angle, dihedral, etc
|
||||
interactions. Namely the quantity R dot F is summed over the atoms in
|
||||
|
|
|
@ -47,7 +47,7 @@ the based classes of LAMMPS.
|
|||
The pairwise contributions are computing via a callback that the
|
||||
compute registers with the non-bonded pairwise force computation.
|
||||
This limits the use to systems that have no bonds, no Kspace, and no
|
||||
manybody interactions. On the other hand, the computation does not
|
||||
many-body interactions. On the other hand, the computation does not
|
||||
have to compute forces or energies a second time and thus can be much
|
||||
more efficient. The callback mechanism allows to write more complex
|
||||
pairwise property computations.
|
||||
|
|
|
@ -60,7 +60,7 @@ same. If it does not rotate around the axis perpendicular to its
|
|||
circular cross section, then it should have 5 dof instead of 6 in 3d.
|
||||
The latter is the case for uniaxial ellipsoids in a "GayBerne
|
||||
model"_pair_gayberne.html since there is no induced torque around the
|
||||
optical axis. It will also be the case for biaxial ellipsoids when
|
||||
optical axis. It will also be the case for bi-axial ellipsoids when
|
||||
exactly two of the semiaxes have the same length and the corresponding
|
||||
relative well depths are equal.
|
||||
|
||||
|
|
|
@ -118,7 +118,7 @@ or "fix rigid"_fix_rigid.html. This is because those degrees of
|
|||
freedom (e.g. a constrained bond) could apply to sets of atoms that
|
||||
are both included and excluded from a specific chunk, and hence the
|
||||
concept is somewhat ill-defined. In some cases, you can use the
|
||||
{adof} and {cdof} keywords to adjust the calculated degress of freedom
|
||||
{adof} and {cdof} keywords to adjust the calculated degrees of freedom
|
||||
appropriately, as explained below.
|
||||
|
||||
Note that the per-chunk temperature calculated by this compute and the
|
||||
|
|
|
@ -74,7 +74,7 @@ relative to the COM velocity of the core/shell pair. If this compute
|
|||
is used with a fix command that performs thermostatting then this bias
|
||||
will be subtracted from each atom, thermostatting of the remaining COM
|
||||
velocity will be performed, and the bias will be added back in. This
|
||||
means the thermostating will effectively be performed on the
|
||||
means the thermostatting will effectively be performed on the
|
||||
core/shell pairs, instead of on the individual core and shell atoms.
|
||||
Thermostatting fixes that work in this way include "fix
|
||||
nvt"_fix_nh.html, "fix temp/rescale"_fix_temp_rescale.html, "fix
|
||||
|
|
|
@ -45,7 +45,7 @@ described in "Eike"_#Eike.
|
|||
|
||||
Typically this compute will be used in conjunction with the "fix
|
||||
adapt"_fix_adapt.html command which can perform alchemical
|
||||
transformations by adusting the strength of an interaction potential
|
||||
transformations by adjusting the strength of an interaction potential
|
||||
as a simulation runs, as defined by one or more
|
||||
"pair_style"_pair_style.html or "kspace_style"_kspace_style.html
|
||||
commands. This scaling is done via a prefactor on the energy, forces,
|
||||
|
|
|
@ -58,7 +58,7 @@ edge vectors starting from the origin given by A = (xhi-xlo,0,0); B =
|
|||
(xy,yhi-ylo,0); C = (xz,yz,zhi-zlo). {Xy,xz,yz} can be 0.0 or
|
||||
positive or negative values and are called "tilt factors" because they
|
||||
are the amount of displacement applied to faces of an originally
|
||||
orthogonal box to transform it into the parallelipiped.
|
||||
orthogonal box to transform it into the parallelepiped.
|
||||
|
||||
By default, a {prism} region used with the create_box command must
|
||||
have tilt factors (xy,xz,yz) that do not skew the box more than half
|
||||
|
|
|
@ -41,7 +41,7 @@ field.
|
|||
NOTE: The newer {charmmfsw} style was released in March 2017. We
|
||||
recommend it be used instead of the older {charmm} style when running
|
||||
a simulation with the CHARMM force field, either with long-range
|
||||
Coulombics or a Coulomb cutoff, via the "pair_style
|
||||
Coulombics or a Coulombic cutoff, via the "pair_style
|
||||
lj/charmmfsw/coul/long"_pair_charmm.html and "pair_style
|
||||
lj/charmmfsw/coul/charmmfsh"_pair_charmm.html commands respectively.
|
||||
Otherwise the older {charmm} style is fine to use. See the discussion
|
||||
|
@ -87,7 +87,7 @@ special_bonds 1-4 scaling factor to 0.0 (which is the
|
|||
default). Otherwise 1-4 non-bonded interactions in dihedrals will be
|
||||
computed twice.
|
||||
|
||||
For simulations using the CHARMM force field with a Coulomb cutoff,
|
||||
For simulations using the CHARMM force field with a Coulombic cutoff,
|
||||
the difference between the {charmm} and {charmmfsw} styles is in the
|
||||
computation of the 1-4 non-bond interactions, though only if the
|
||||
distance between the two atoms is within the switching region of the
|
||||
|
|
|
@ -17,7 +17,7 @@ group-ID = ID of the group of atoms to be imaged :l
|
|||
h5md = style of dump command (other styles {atom} or {cfg} or {dcd} or {xtc} or {xyz} or {local} or {custom} are discussed on the "dump"_dump.html doc page) :l
|
||||
N = dump every this many timesteps :l
|
||||
file.h5 = name of file to write to :l
|
||||
args = list of data elements to dump, with their dump "subintervals"
|
||||
args = list of data elements to dump, with their dump "sub-intervals"
|
||||
position options
|
||||
image
|
||||
velocity options
|
||||
|
@ -63,7 +63,7 @@ another particle group must specify {create_group yes}.
|
|||
:link(h5md,http://nongnu.org/h5md/)
|
||||
|
||||
Each data element is written every N*N_element steps. For {image}, no
|
||||
subinterval is needed as it must be present at the same interval as
|
||||
sub-interval is needed as it must be present at the same interval as
|
||||
{position}. {image} must be given after {position} in any case. The
|
||||
box information (edges in each dimension) is stored at the same
|
||||
interval than the {position} element, if present. Else it is stored
|
||||
|
@ -76,7 +76,7 @@ written to a dump file may be slightly outside the simulation box.
|
|||
[Use from write_dump:]
|
||||
|
||||
It is possible to use this dump style with the
|
||||
"write_dump"_write_dump.html command. In this case, the subintervals
|
||||
"write_dump"_write_dump.html command. In this case, the sub-intervals
|
||||
must not be set at all. The write_dump command can be used either to
|
||||
create a new file or to add current data to an existing dump file by
|
||||
using the {file_from} keyword.
|
||||
|
|
|
@ -541,10 +541,11 @@ a) Use the ImageMagick convert program. :ulb,l
|
|||
% convert *.jpg foo.gif
|
||||
% convert -loop 1 *.ppm foo.mpg :pre
|
||||
|
||||
Animated GIF files from ImageMagick are unoptimized. You can use a
|
||||
program like gifsicle to optimize and massively shrink them.
|
||||
MPEG files created by ImageMagick are in MPEG-1 format with rather
|
||||
inefficient compression and low quality.
|
||||
Animated GIF files from ImageMagick are not optimized. You can use
|
||||
a program like gifsicle to optimize and thus massively shrink them.
|
||||
MPEG files created by ImageMagick are in MPEG-1 format with a rather
|
||||
inefficient compression and low quality compared to more modern
|
||||
compression styles like MPEG-4, H.264, VP8, VP9, H.265 and so on.
|
||||
|
||||
b) Use QuickTime. :l
|
||||
|
||||
|
@ -564,7 +565,7 @@ allows extremely flexible encoding and decoding of movies.
|
|||
cat snap.*.jpg | ffmpeg -y -f image2pipe -c:v mjpeg -i - -b:v 2000k movie.m4v
|
||||
cat snap.*.ppm | ffmpeg -y -f image2pipe -c:v ppm -i - -b:v 2400k movie.avi :pre
|
||||
|
||||
Frontends for FFmpeg exist for multiple platforms. For more
|
||||
Front ends for FFmpeg exist for multiple platforms. For more
|
||||
information see the "FFmpeg homepage"_http://www.ffmpeg.org/
|
||||
|
||||
:ule
|
||||
|
|
|
@ -201,7 +201,7 @@ atom type (1 to Ntype) in the simulation. The same element name can
|
|||
be given to multiple atom types.
|
||||
|
||||
In the case of {xyz} format dumps, there are no restrictions to what
|
||||
label can be used as an element name. Any whitespace separated text
|
||||
label can be used as an element name. Any white-space separated text
|
||||
will be accepted.
|
||||
|
||||
:link(atomeye,http://mt.seas.upenn.edu/Archive/Graphics/A)
|
||||
|
@ -667,7 +667,7 @@ command, when its atom diameter setting is {type}, to set the size
|
|||
that atoms of each type will be drawn in the image. The specified
|
||||
{type} should be an integer from 1 to Ntypes. As with the {acolor}
|
||||
keyword, a wildcard asterisk can be used as part of the {type}
|
||||
argument to specify a range of atomt types. The specified {diam} is
|
||||
argument to specify a range of atom types. The specified {diam} is
|
||||
the size in whatever distance "units"_units.html the input script is
|
||||
using, e.g. Angstroms.
|
||||
|
||||
|
|
|
@ -202,7 +202,7 @@ accelerated styles exist.
|
|||
"dt/reset"_fix_dt_reset.html - reset the timestep based on velocity, forces
|
||||
"edpd/source"_fix_dpd_source.html -
|
||||
"efield"_fix_efield.html - impose electric field on system
|
||||
"ehex"_fix_ehex.html - ehanced heat exchange algorithm
|
||||
"ehex"_fix_ehex.html - enhanced heat exchange algorithm
|
||||
"enforce2d"_fix_enforce2d.html - zero out z-dimension velocity and force
|
||||
"eos/cv"_fix_eos_cv.html -
|
||||
"eos/table"_fix_eos_table.html -
|
||||
|
|
|
@ -28,7 +28,7 @@ keyword = {basis} or {size} or {freq} or {temp} or {random} or {units} :l
|
|||
target = target temperature for the region between zhi-extent and zhi (temperature units)
|
||||
damp = damping parameter (time units)
|
||||
seed = random number seed for langevin kicks
|
||||
extent = extent of thermostated region (distance units)
|
||||
extent = extent of thermostatted region (distance units)
|
||||
{random} args = xmax ymax zmax seed
|
||||
{xmax}, {ymax}, {zmax} = maximum displacement in particular direction (distance units)
|
||||
{seed} = random number seed for random displacement
|
||||
|
@ -68,7 +68,7 @@ be added.
|
|||
The {random} keyword will give the atoms random displacements around
|
||||
their lattice points to simulate some initial temperature.
|
||||
|
||||
The {temp} keyword will cause a region to be thermostated with a
|
||||
The {temp} keyword will cause a region to be thermostatted with a
|
||||
Langevin thermostat on the zhi boundary. The size of the region is
|
||||
measured from zhi and is set with the {extent} argument.
|
||||
|
||||
|
|
|
@ -240,7 +240,7 @@ shake"_fix_shake.html or "fix rigid"_fix_rigid.html. This is because
|
|||
those degrees of freedom (e.g. a constrained bond) could apply to sets
|
||||
of atoms that are both included and excluded from a specific chunk,
|
||||
and hence the concept is somewhat ill-defined. In some cases, you can
|
||||
use the {adof} and {cdof} keywords to adjust the calculated degress of
|
||||
use the {adof} and {cdof} keywords to adjust the calculated degrees of
|
||||
freedom appropriately, as explained below.
|
||||
|
||||
Also note that a bias can be subtracted from atom velocities before
|
||||
|
|
|
@ -133,7 +133,7 @@ fix 2 all ave/time 100 1 100 c_myRDF\[1\] c_myRDF\[2\] c_myRDF\[3\] file tmp2.rd
|
|||
The {Nevery}, {Nrepeat}, and {Nfreq} arguments specify on what
|
||||
timesteps the input values will be used in order to contribute to the
|
||||
average. The final averaged quantities are generated on timesteps
|
||||
that are a mlutiple of {Nfreq}. The average is over {Nrepeat}
|
||||
that are a multiple of {Nfreq}. The average is over {Nrepeat}
|
||||
quantities, computed in the preceding portion of the simulation every
|
||||
{Nevery} timesteps. {Nfreq} must be a multiple of {Nevery} and
|
||||
{Nevery} must be non-zero even if {Nrepeat} is 1. Also, the timesteps
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue