forked from lijiext/lammps
more spelling fixes and occational re-edits
This commit is contained in:
parent
c6c00ee7ee
commit
0bcb1bd301
|
@ -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)
|
||||
|
|
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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 barostatting 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
|
||||
|
@ -369,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)
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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).
|
||||
|
|
|
@ -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)
|
||||
|
|
|
@ -51,7 +51,7 @@ 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 analysis: If you want to perform analysis on-the-fly as
|
||||
your simulation runs, see the "compute"_compute.html and
|
||||
|
|
|
@ -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:]
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -17,7 +17,7 @@ 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).
|
||||
|
@ -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.
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -112,7 +112,7 @@ 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.
|
||||
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:
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -57,7 +57,7 @@ This command adjusts the size and shape of processor sub-domains
|
|||
within the simulation box, to attempt to balance the number of
|
||||
particles and thus the computational cost (load) evenly across
|
||||
processors. The load balancing is "dynamic" in the sense that
|
||||
rebalancing is performed periodically during the simulation. To
|
||||
re-balancing is performed periodically during the simulation. To
|
||||
perform "static" balancing, before or between runs, see the
|
||||
"balance"_balance.html command.
|
||||
|
||||
|
@ -178,15 +178,15 @@ The {group-ID} is ignored. However the impact of balancing on
|
|||
different groups of atoms can be affected by using the {group} weight
|
||||
style as described below.
|
||||
|
||||
The {Nfreq} setting determines how often a rebalance is performed. If
|
||||
{Nfreq} > 0, then rebalancing will occur every {Nfreq} steps. Each
|
||||
time a rebalance occurs, a reneighboring is triggered, so {Nfreq}
|
||||
should not be too small. If {Nfreq} = 0, then rebalancing will be
|
||||
The {Nfreq} setting determines how often a re-balance is performed. If
|
||||
{Nfreq} > 0, then re-balancing will occur every {Nfreq} steps. Each
|
||||
time a re-balance occurs, a reneighboring is triggered, so {Nfreq}
|
||||
should not be too small. If {Nfreq} = 0, then re-balancing will be
|
||||
done every time reneighboring normally occurs, as determined by the
|
||||
the "neighbor"_neighbor.html and "neigh_modify"_neigh_modify.html
|
||||
command settings.
|
||||
|
||||
On rebalance steps, rebalancing will only be attempted if the current
|
||||
On re-balance steps, re-balancing will only be attempted if the current
|
||||
imbalance factor, as defined above, exceeds the {thresh} setting.
|
||||
|
||||
:line
|
||||
|
@ -208,7 +208,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
|
||||
density-dependent 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
|
||||
|
@ -226,19 +226,19 @@ the recursion progresses, the count of particles on either side of the
|
|||
plane gets closer to the target value.
|
||||
|
||||
The density-dependent part of this algorithm is often an advantage
|
||||
when you rebalance a system that is already nearly balanced. It
|
||||
when you re-balance a system that is already nearly balanced. It
|
||||
typically converges more quickly than the geometric bisectioning
|
||||
algorithm used by the "balance"_balance.html command. However, if can
|
||||
be a disadvantage if you attempt to rebalance a system that is far
|
||||
be a disadvantage if you attempt to re-balance a system that is far
|
||||
from balanced, and converge more slowly. In this case you probably
|
||||
want to use the "balance"_balance.html command before starting a run,
|
||||
so that you begin the run with a balanced system.
|
||||
|
||||
Once the rebalancing is complete and final processor sub-domains
|
||||
Once the re-balancing is complete and final processor sub-domains
|
||||
assigned, particles migrate to their new owning processor as part of
|
||||
the normal reneighboring procedure.
|
||||
|
||||
NOTE: At each rebalance operation, the bisectioning for each cutting
|
||||
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 based on the local density, as
|
||||
|
@ -248,7 +248,7 @@ typically be positioned to better than 1 part in 1000 accuracy
|
|||
(relative to the perfect target position). For {Niter} = 20, it will
|
||||
be accurate to better than 1 part in a million. Thus there is no need
|
||||
to set {Niter} to a large value. This is especially true if you are
|
||||
rebalancing often enough that each time you expect only an incremental
|
||||
re-balancing often enough that each time you expect only an incremental
|
||||
adjustment in the cutting planes is necessary. LAMMPS will check if
|
||||
the threshold accuracy is reached (in a dimension) is less iterations
|
||||
than {Niter} and exit early.
|
||||
|
@ -283,7 +283,7 @@ in that sub-box.
|
|||
:line
|
||||
|
||||
The {out} keyword writes text to the specified {filename} with the
|
||||
results of each rebalancing operation. The file contains the bounds
|
||||
results of each re-balancing operation. The file contains the bounds
|
||||
of the sub-domain for each processor after the balancing operation
|
||||
completes. The format of the file is compatible with the
|
||||
"Pizza.py"_pizza {mdump} tool which has support for manipulating and
|
||||
|
@ -344,13 +344,13 @@ files"_restart.html. None of the "fix_modify"_fix_modify.html options
|
|||
are relevant to this fix.
|
||||
|
||||
This fix computes a global scalar which is the imbalance factor
|
||||
after the most recent rebalance and a global vector of length 3 with
|
||||
additional information about the most recent rebalancing. The 3
|
||||
after the most recent re-balance and a global vector of length 3 with
|
||||
additional information about the most recent re-balancing. The 3
|
||||
values in the vector are as follows:
|
||||
|
||||
1 = max # of particles per processor
|
||||
2 = total # iterations performed in last rebalance
|
||||
3 = imbalance factor right before the last rebalance was performed :ul
|
||||
2 = total # iterations performed in last re-balance
|
||||
3 = imbalance factor right before the last re-balance was performed :ul
|
||||
|
||||
As explained above, the imbalance factor is the ratio of the maximum
|
||||
number of particles (or total weight) on any processor to the average
|
||||
|
|
|
@ -91,7 +91,7 @@ package"_Build_package.html doc page for more info.
|
|||
[Related:]
|
||||
|
||||
For more details about the pressure correction and the entire BOCS software
|
||||
package, visit the "BOCS package on github"_bocsgithub and read the release
|
||||
package, visit the "BOCS package on GitHub"_bocsgithub and read the release
|
||||
paper by Dunn et. al. "(Dunn2)"_#bocs-Dunn2 .
|
||||
|
||||
|
||||
|
|
|
@ -101,7 +101,7 @@ NOTE: Breaking a bond typically alters the energy of a system. You
|
|||
should be careful not to choose bond breaking criteria that induce a
|
||||
dramatic change in energy. For example, if you define a very stiff
|
||||
harmonic bond and break it when 2 atoms are separated by a distance
|
||||
far from the equilibribum bond length, then the 2 atoms will be
|
||||
far from the equilibrium bond length, then the 2 atoms will be
|
||||
dramatically released when the bond is broken. More generally, you
|
||||
may need to thermostat your system to compensate for energy changes
|
||||
resulting from broken bonds (and angles, dihedrals, impropers).
|
||||
|
|
|
@ -139,8 +139,8 @@ for "extra angle per atom", "extra dihedral per atom", and "extra
|
|||
improper per atom" if angles, dihedrals, or impropers are being added
|
||||
when bonds are created. See the "read_data"_read_data.html or
|
||||
"create_box"_create_box.html command for more details. Note that a
|
||||
data file with no atoms can be used if you wish to add unbonded atoms
|
||||
via the "create atoms"_create_atoms.html command, e.g. for a
|
||||
data file with no atoms can be used if you wish to add non-bonded
|
||||
atoms via the "create atoms"_create_atoms.html command, e.g. for a
|
||||
percolation simulation.
|
||||
|
||||
NOTE: LAMMPS stores and maintains a data structure with a list of the
|
||||
|
@ -196,7 +196,7 @@ NOTE: Creating a bond typically alters the energy of a system. You
|
|||
should be careful not to choose bond creation criteria that induce a
|
||||
dramatic change in energy. For example, if you define a very stiff
|
||||
harmonic bond and create it when 2 atoms are separated by a distance
|
||||
far from the equilibribum bond length, then the 2 atoms will oscillate
|
||||
far from the equilibrium bond length, then the 2 atoms will oscillate
|
||||
dramatically when the bond is formed. More generally, you may need to
|
||||
thermostat your system to compensate for energy changes resulting from
|
||||
created bonds (and angles, dihedrals, impropers).
|
||||
|
|
|
@ -79,7 +79,7 @@ probabilistic criteria to effect predetermined topology changes in
|
|||
simulations using standard force fields.
|
||||
|
||||
This fix was created to facilitate the dynamic creation of polymeric,
|
||||
amorphous or highly-crosslinked systems. A suggested workflow for
|
||||
amorphous or highly cross-linked systems. A suggested workflow for
|
||||
using this fix is: 1) identify a reaction to be simulated 2) build a
|
||||
molecule template of the reaction site before the reaction has
|
||||
occurred 3) build a molecule template of the reaction site after the
|
||||
|
|
|
@ -84,7 +84,7 @@ the molecule IDs for your polymer chains in a certain way, typically
|
|||
in the data file, read by the "read_data"_read_data.html command.
|
||||
Consider a system of 6-mer chains. You have 2 choices. If the
|
||||
molecule IDs for monomers on each chain are set to 1,2,3,4,5,6 then
|
||||
swaps will conserve chain length. For a particular momoner there will
|
||||
swaps will conserve chain length. For a particular monomer there will
|
||||
be only one other monomer on another chain which is a potential swap
|
||||
partner. If the molecule IDs for monomers on each chain are set to
|
||||
1,2,3,3,2,1 then swaps will conserve chain length but swaps will be
|
||||
|
|
|
@ -51,7 +51,7 @@ md"_server_md.html doc page.
|
|||
Note that when using LAMMPS as an MD client, your LAMMPS input script
|
||||
should not normally contain force field commands, like a
|
||||
"pair_style"_pair_style.html, "bond_style"_bond_style.html, or
|
||||
"kspace_style"_kspace_style.html commmand. However it is possible for
|
||||
"kspace_style"_kspace_style.html command. However it is possible for
|
||||
a server code to only compute a portion of the full force-field, while
|
||||
LAMMPS computes the remaining part. Your LAMMPS script can also
|
||||
specify boundary conditions or force constraints in the usual way,
|
||||
|
|
|
@ -24,12 +24,12 @@ fix_modify myCMAP energy yes :pre
|
|||
|
||||
[Description:]
|
||||
|
||||
This command enables CMAP crossterms to be added to simulations which
|
||||
This command enables CMAP cross-terms to be added to simulations which
|
||||
use the CHARMM force field. These are relevant for any CHARMM model
|
||||
of a peptide or protein sequences that is 3 or more amino-acid
|
||||
residues long; see "(Buck)"_#Buck and "(Brooks)"_#Brooks2 for details,
|
||||
including the analytic energy expressions for CMAP interactions. The
|
||||
CMAP crossterms add additional potential energy contributions to pairs
|
||||
CMAP cross-terms add additional potential energy contributions to pairs
|
||||
of overlapping phi-psi dihedrals of amino-acids, which are important
|
||||
to properly represent their conformational behavior.
|
||||
|
||||
|
@ -49,7 +49,7 @@ in its header section:
|
|||
|
||||
N crossterms :pre
|
||||
|
||||
where N is the number of CMAP crossterms. It should also have a section
|
||||
where N is the number of CMAP cross-terms. It should also have a section
|
||||
in the body of the data file like this with N lines:
|
||||
|
||||
CMAP :pre
|
||||
|
@ -69,7 +69,7 @@ sections match those specified in the read_data command following the
|
|||
data file name; see the "read_data"_read_data.html doc page for
|
||||
more details.
|
||||
|
||||
A data file containing CMAP crossterms can be generated from a PDB
|
||||
A data file containing CMAP cross-terms can be generated from a PDB
|
||||
file using the charmm2lammps.pl script in the tools/ch2lmp directory
|
||||
of the LAMMPS distribution. The script must be invoked with the
|
||||
optional "-cmap" flag to do this; see the tools/ch2lmp/README file for
|
||||
|
@ -87,7 +87,7 @@ the note below about how to include the CMAP energy when performing an
|
|||
|
||||
[Restart, fix_modify, output, run start/stop, minimize info:]
|
||||
|
||||
This fix writes the list of CMAP crossterms to "binary restart
|
||||
This fix writes the list of CMAP cross-terms to "binary restart
|
||||
files"_restart.html. See the "read_restart"_read_restart.html command
|
||||
for info on how to re-specify a fix in an input script that reads a
|
||||
restart file, so that the operation of the fix continues in an
|
||||
|
|
|
@ -81,7 +81,7 @@ the image flags to reconstruct the absolute atom positions.
|
|||
Setting this to {no} will use the current local coordinates that are
|
||||
wrapped back into the simulation cell at each re-neighboring instead.
|
||||
|
||||
The {tstat} keyword can be either NULL or the label of a thermostating
|
||||
The {tstat} keyword can be either NULL or the label of a thermostatting
|
||||
fix that thermostats all atoms in the fix colvars group. This will be
|
||||
used to provide the colvars module with the current thermostat target
|
||||
temperature.
|
||||
|
|
|
@ -255,7 +255,7 @@ temperature compute you are using.
|
|||
|
||||
This fix writes the state of the deposition to "binary restart
|
||||
files"_restart.html. This includes information about how many
|
||||
particles have been depositied, the random number generator seed, the
|
||||
particles have been deposited, the random number generator seed, the
|
||||
next timestep for deposition, etc. See the
|
||||
"read_restart"_read_restart.html command for info on how to re-specify
|
||||
a fix in an input script that reads a restart file, so that the
|
||||
|
|
|
@ -91,8 +91,8 @@ different temperatures, two Nose-Hoover thermostats must be defined,
|
|||
acting on two distinct groups.
|
||||
|
||||
NOTE: The {fix drude/transform/direct} command must appear before any
|
||||
Nose-Hoover thermostating fixes. The {fix drude/transform/inverse}
|
||||
command must appear after any Nose-Hoover thermostating fixes.
|
||||
Nose-Hoover thermostatting fixes. The {fix drude/transform/inverse}
|
||||
command must appear after any Nose-Hoover thermostatting fixes.
|
||||
|
||||
Example:
|
||||
|
||||
|
@ -106,8 +106,8 @@ thermo_style custom step cpu etotal ke pe ebond ecoul elong press vol temp c_TDR
|
|||
|
||||
In this example, {gCORES} is the group of the atom cores and {gDRUDES}
|
||||
is the group of the Drude particles (electrons). The centers of mass
|
||||
of the Drude oscillators will be thermostated at 300.0 and the
|
||||
internal degrees of freedom will be thermostated at 1.0. The
|
||||
of the Drude oscillators will be thermostatted at 300.0 and the
|
||||
internal degrees of freedom will be thermostatted at 1.0. The
|
||||
temperatures of cores and Drude particles, in center-of-mass and
|
||||
relative coordinates, are calculated using "compute
|
||||
temp/drude"_compute_temp_drude.html
|
||||
|
@ -130,8 +130,8 @@ fix fINVERSE all drude/transform/inverse :pre
|
|||
|
||||
In this example, {gCORES} is the group of the atom cores and {gDRUDES}
|
||||
is the group of the Drude particles. The centers of mass of the Drude
|
||||
oscillators will be thermostated at 298.0 and the internal degrees of
|
||||
freedom will be thermostated at 5.0. The whole system will be
|
||||
oscillators will be thermostatted at 298.0 and the internal degrees of
|
||||
freedom will be thermostatted at 5.0. The whole system will be
|
||||
barostatted at 1.0.
|
||||
|
||||
In order to avoid the flying ice cube problem (irreversible transfer
|
||||
|
|
|
@ -80,9 +80,9 @@ position to the respective reservoir. The quantity
|
|||
\(F_\{\Gamma_\{k(\mathbf r_i)\}\}\) corresponds to the input parameter
|
||||
{F}, which is the energy flux into the reservoir. Furthermore,
|
||||
\(K_\{\Gamma_\{k(\mathbf r_i)\}\}\) and \(v_\{\Gamma_\{k(\mathbf r_i)\}\}\)
|
||||
denote the non-translational kinetic energy and the centre of mass
|
||||
denote the non-translational kinetic energy and the center of mass
|
||||
velocity of that reservoir. The thermostatting force does not affect
|
||||
the centre of mass velocities of the individual reservoirs and the
|
||||
the center of mass velocities of the individual reservoirs and the
|
||||
entire simulation box. A derivation of the equations and details on
|
||||
the numerical implementation with velocity Verlet in LAMMPS can be
|
||||
found in reference "(Wirnsberger)"#_Wirnsberger.
|
||||
|
@ -116,10 +116,10 @@ specified in the input script and the keyword {constrain} is set, the
|
|||
bond distances will be corrected a second time at the end of the
|
||||
integration step. It is recommended to specify the keyword {com} in
|
||||
addition to the keyword {constrain}. With this option all sites of a
|
||||
constrained cluster are rescaled, if its centre of mass is located
|
||||
constrained cluster are rescaled, if its center of mass is located
|
||||
inside the region. Rescaling all sites of a cluster by the same factor
|
||||
does not introduce any velocity components along fixed bonds. No
|
||||
rescaling takes place if the centre of mass lies outside the region.
|
||||
rescaling takes place if the center of mass lies outside the region.
|
||||
|
||||
NOTE: You can only use the keyword {com} along with {constrain}.
|
||||
|
||||
|
|
|
@ -35,13 +35,13 @@ temperature.
|
|||
|
||||
The interpolation tables are created by fitting cubic splines to the
|
||||
file values and interpolating energy values at each of {N} internal
|
||||
temperatures, and vice-versa. During a simulation, these tables are
|
||||
temperatures, and vice versa. During a simulation, these tables are
|
||||
used to interpolate internal energy or temperature values as needed.
|
||||
The interpolation is done with the {linear} style.
|
||||
|
||||
For the {linear} style, the internal temperature is used to find 2
|
||||
surrounding table values from which an internal energy is computed by
|
||||
linear interpolation, and vice-versa.
|
||||
linear interpolation, and vice versa.
|
||||
|
||||
The filename specifies a file containing tabulated internal
|
||||
temperature and internal energy values. The keyword specifies a
|
||||
|
|
|
@ -54,8 +54,8 @@ just the single atom is deleted.
|
|||
As an example, if you wish to delete 10 water molecules every {N}
|
||||
steps, you should set {M} to 30. If only the water's oxygen atoms
|
||||
were in the fix group, then two hydrogen atoms would be deleted when
|
||||
an oxygen atom is selected for deletion, whether the hydrogens are
|
||||
inside the evaporation region or not.
|
||||
an oxygen atom is selected for deletion, whether the hydrogen atoms
|
||||
are inside the evaporation region or not.
|
||||
|
||||
Note that neighbor lists are re-built on timesteps that atoms are
|
||||
removed. Thus you should not remove atoms too frequently or you will
|
||||
|
|
|
@ -53,7 +53,7 @@ particles as usual. Either constant volume or constant pressure
|
|||
algorithms can be used.
|
||||
|
||||
The fix enforces a generalized ensemble in a single replica
|
||||
only. Typically, this ideaology is combined with replica exchange with
|
||||
only. Typically, this ideology is combined with replica exchange with
|
||||
replicas differing by {lambda} only for simplicity, but this is not
|
||||
required. A multi-replica simulation can be run within the LAMMPS
|
||||
environment using the "temper/grem"_temper_grem.html command. This
|
||||
|
|
|
@ -109,7 +109,7 @@ are relevant to this fix.
|
|||
|
||||
This fix computes a global scalar which can be accessed by various
|
||||
"output commands"_Howto_output.html. This scalar is the most recent
|
||||
value by which velocites were scaled. The scalar value calculated by
|
||||
value by which velocities were scaled. The scalar value calculated by
|
||||
this fix is "intensive". If {eflux} is specified as an atom-style
|
||||
variable, this fix computes the average value by which the velocities
|
||||
were scaled for all of the atoms that had their velocities scaled.
|
||||
|
|
|
@ -205,12 +205,12 @@ the current timestep. The vector stores the following quantities:
|
|||
7 = max drift distance of any atom during this run (distance units)
|
||||
8 = max bond length during this run (distance units) :ul
|
||||
|
||||
9 = cummulative hyper time since fix was defined (time units)
|
||||
10 = cummulative count of event timesteps since fix was defined
|
||||
11 = cummulative count of atoms in events since fix was defined :ul
|
||||
9 = cumulative hyper time since fix was defined (time units)
|
||||
10 = cumulative count of event timesteps since fix was defined
|
||||
11 = cumulative count of atoms in events since fix was defined :ul
|
||||
|
||||
The first 5 quantities are for the current timestep. Quantities 6-8
|
||||
are for the current hyper run. Quantities 9-11 are cummulative across
|
||||
are for the current hyper run. Quantities 9-11 are cumulative across
|
||||
multiple runs (since the fix was defined in the input script).
|
||||
|
||||
For value 7, drift is the distance an atom moves between timesteps
|
||||
|
@ -228,7 +228,7 @@ For value 11, each time the "hyper"_hyper.html command checks for an
|
|||
event, it invokes a compute to flag zero or more atoms as
|
||||
participating in one or more events. E.g. atoms that have displaced
|
||||
more than some distance from the previous quench state. Value 11 is
|
||||
the cummulative count of the number of atoms participating in any of
|
||||
the cumulative count of the number of atoms participating in any of
|
||||
the events that were found.
|
||||
|
||||
The scalar and vector values calculated by this fix are all
|
||||
|
|
|
@ -310,14 +310,14 @@ quantities:
|
|||
18 = count of bias overlaps found during this run
|
||||
19 = count of non-matching bias coefficients found during this run :ul
|
||||
|
||||
20 = cummulative hyper time since fix created (time units)
|
||||
21 = cummulative count of event timesteps since fix created
|
||||
22 = cummulative count of atoms in events since fix created
|
||||
23 = cummulative # of new bonds since fix created :ul
|
||||
20 = cumulative hyper time since fix created (time units)
|
||||
21 = cumulative count of event timesteps since fix created
|
||||
22 = cumulative count of atoms in events since fix created
|
||||
23 = cumulative # of new bonds since fix created :ul
|
||||
|
||||
The first quantities (1-5) are for the current timestep. Quantities
|
||||
6-19 are for the current hyper run. They are reset each time a new
|
||||
hyper run is performed. Quantities 20-23 are cummulative across
|
||||
hyper run is performed. Quantities 20-23 are cumulative across
|
||||
multiple runs (since the fix was defined in the input script).
|
||||
|
||||
For value 6, the numerator is a count of all biased bonds on every
|
||||
|
@ -333,7 +333,7 @@ For values 13 and 14, the maxstrain of a ghost atom is the maxstrain
|
|||
of any bond it is part of, and it is checked for ghost atoms within
|
||||
the bond neighbor cutoff.
|
||||
|
||||
Values 15-19 are mostly useful for debugging and diagnositc purposes.
|
||||
Values 15-19 are mostly useful for debugging and diagnostic purposes.
|
||||
|
||||
For values 15-17, it is possible that a ghost atom owned by another
|
||||
processor will move far enough (e.g. as part of an event-in-progress)
|
||||
|
@ -367,7 +367,7 @@ For value 22, each time the "hyper"_hyper.html command checks for an
|
|||
event, it invokes a compute to flag zero or more atoms as
|
||||
participating in one or more events. E.g. atoms that have displaced
|
||||
more than some distance from the previous quench state. Value 22 is
|
||||
the cummulative count of the number of atoms participating in any of
|
||||
the cumulative count of the number of atoms participating in any of
|
||||
the events that were found.
|
||||
|
||||
Value 23 tallies the number of new bonds created by the bond reset
|
||||
|
|
|
@ -41,7 +41,7 @@ it allows LAMMPS to connect an IMD client, for example the "VMD
|
|||
visualization program"_VMD, so that it can monitor the progress of the
|
||||
simulation and interactively apply forces to selected atoms.
|
||||
|
||||
If LAMMPS is compiled with the preprocessor flag -DLAMMPS_ASYNC_IMD
|
||||
If LAMMPS is compiled with the pre-processor flag -DLAMMPS_ASYNC_IMD
|
||||
then fix imd will use POSIX threads to spawn a IMD communication
|
||||
thread on MPI rank 0 in order to offload data reading and writing
|
||||
from the main execution thread and potentially lower the inferred
|
||||
|
|
|
@ -129,7 +129,7 @@ variable rate equal 1.0
|
|||
variable r equal "v_r0 + step*dt*v_rate" :pre
|
||||
|
||||
If the {side} keyword is specified as {out}, which is the default,
|
||||
then particles outside the indenter are pushded away from its outer
|
||||
then particles outside the indenter are pushed away from its outer
|
||||
surface, as described above. This only applies to spherical or
|
||||
cylindrical indenters. If the {side} keyword is specified as {in},
|
||||
the action of the indenter is reversed. Particles inside the indenter
|
||||
|
|
|
@ -179,7 +179,7 @@ options.
|
|||
For the {omega} keyword there is also a scale factor of 10.0/3.0 that
|
||||
is applied as a multiplier on the Ff (damping) term in the equation
|
||||
above and of sqrt(10.0/3.0) as a multiplier on the Fr term. This does
|
||||
not affect the thermostatting behaviour of the Langevin formalism but
|
||||
not affect the thermostatting behavior of the Langevin formalism but
|
||||
insures that the randomized rotational diffusivity of spherical
|
||||
particles is correct.
|
||||
|
||||
|
|
|
@ -78,22 +78,22 @@ transform:
|
|||
\begin\{equation\} F = \frac M \{M'\}\, F' - f' \end\{equation\}
|
||||
\begin\{equation\} f = \frac m \{M'\}\, F' + f' \end\{equation\}
|
||||
|
||||
This fix also thermostates non-polarizable atoms in the group at
|
||||
This fix also thermostats non-polarizable atoms in the group at
|
||||
temperature {Tcom}, as if they had a massless Drude partner. The
|
||||
Drude particles themselves need not be in the group. The center of
|
||||
mass and the dipole are thermostated iff the core atom is in the
|
||||
mass and the dipole are thermostatted iff the core atom is in the
|
||||
group.
|
||||
|
||||
Note that the thermostat effect of this fix is applied to only the
|
||||
translational degrees of freedom of the particles, which is an
|
||||
important consideration if finite-size particles, which have
|
||||
rotational degrees of freedom, are being thermostated. The
|
||||
rotational degrees of freedom, are being thermostatted. The
|
||||
translational degrees of freedom can also have a bias velocity removed
|
||||
from them before thermostating takes place; see the description below.
|
||||
from them before thermostatting takes place; see the description below.
|
||||
|
||||
NOTE: Like the "fix langevin"_fix_langevin.html command, this fix does
|
||||
NOT perform time integration. It only modifies forces to effect
|
||||
thermostating. Thus you must use a separate time integration fix, like
|
||||
thermostatting. Thus you must use a separate time integration fix, like
|
||||
"fix nve"_fix_nve.html or "fix nph"_fix_nh.html to actually update the
|
||||
velocities and positions of atoms using the modified forces.
|
||||
Likewise, this fix should not normally be used on atoms that also have
|
||||
|
@ -102,7 +102,7 @@ nvt"_fix_nh.html or "fix temp/rescale"_fix_temp_rescale.html commands.
|
|||
|
||||
See the "Howto thermostat"_Howto_thermostat.html doc page for a
|
||||
discussion of different ways to compute temperature and perform
|
||||
thermostating.
|
||||
thermostatting.
|
||||
|
||||
:line
|
||||
|
||||
|
@ -126,7 +126,7 @@ comm_modify vel yes :pre
|
|||
:line
|
||||
|
||||
{Tcom} is the target temperature of the centers of mass, which would
|
||||
be used to thermostate the non-polarizable atoms. {Tdrude} is the
|
||||
be used to thermostat the non-polarizable atoms. {Tdrude} is the
|
||||
(normally low) target temperature of the core-Drude particle pairs
|
||||
(dipoles). {Tcom} and {Tdrude} can be specified as an equal-style
|
||||
"variable"_variable.html. If the value is a variable, it should be
|
||||
|
@ -139,7 +139,7 @@ functions, and include "thermo_style"_thermo_style.html command
|
|||
keywords for the simulation box parameters and timestep and elapsed
|
||||
time. Thus it is easy to specify a time-dependent temperature.
|
||||
|
||||
Like other fixes that perform thermostating, this fix can be used with
|
||||
Like other fixes that perform thermostatting, this fix can be used with
|
||||
"compute commands"_compute.html that remove a "bias" from the atom
|
||||
velocities. E.g. removing the center-of-mass velocity from a group of
|
||||
atoms. This is not done by default, but only if the
|
||||
|
@ -147,11 +147,11 @@ atoms. This is not done by default, but only if the
|
|||
compute to this fix that includes such a bias term. See the doc pages
|
||||
for individual "compute commands"_compute.html to determine which ones
|
||||
include a bias. In this case, the thermostat works in the following
|
||||
manner: bias is removed from each atom, thermostating is performed on
|
||||
manner: bias is removed from each atom, thermostatting is performed on
|
||||
the remaining thermal degrees of freedom, and the bias is added back
|
||||
in. NOTE: this feature has not been tested.
|
||||
|
||||
Note: The temperature thermostating the core-Drude particle pairs
|
||||
Note: The temperature thermostatting the core-Drude particle pairs
|
||||
should be chosen low enough, so as to mimic as closely as possible the
|
||||
self-consistent minimization. It must however be high enough, so that
|
||||
the dipoles can follow the local electric field exerted by the
|
||||
|
@ -213,7 +213,7 @@ the system, but is a bit slower. :l
|
|||
Use two different random seeds to avoid unphysical correlations. :l
|
||||
|
||||
Temperature is controlled by the fix {langevin/drude}, so the
|
||||
time-integration fixes do not thermostate. Don't forget to
|
||||
time-integration fixes do not thermostat. Don't forget to
|
||||
time-integrate both cores and Drude particles. :l
|
||||
|
||||
Pressure is time-integrated only once by using {nve} for Drude
|
||||
|
@ -223,11 +223,11 @@ for both. :l
|
|||
The temperatures of cores and Drude particles are calculated by
|
||||
"compute temp/drude"_compute_temp_drude.html :l
|
||||
|
||||
Contrary to the alternative thermostating using Nose-Hoover thermostat
|
||||
Contrary to the alternative thermostatting using Nose-Hoover thermostat
|
||||
fix {npt} and "fix drude/transform"_fix_drude_transform.html, the
|
||||
{fix_modify} command is not required here, because the fix {nph}
|
||||
computes the global pressure even if its group is {ATOMS}. This is
|
||||
what we want. If we thermostated {ATOMS} using {npt}, the pressure
|
||||
what we want. If we thermostatted {ATOMS} using {npt}, the pressure
|
||||
should be the global one, but the temperature should be only that of
|
||||
the cores. That's why the command {fix_modify} should be called in
|
||||
that case. :l
|
||||
|
@ -247,7 +247,7 @@ restarted simulation should produce the same behavior.
|
|||
|
||||
The "fix_modify"_fix_modify.html {temp} option is supported by this
|
||||
fix. You can use it to assign a temperature "compute"_compute.html
|
||||
you have defined to this fix which will be used in its thermostating
|
||||
you have defined to this fix which will be used in its thermostatting
|
||||
procedure, as described above. For consistency, the group used by the
|
||||
compute should include the group of this fix and the Drude particles.
|
||||
|
||||
|
|
|
@ -63,7 +63,7 @@ meso"_fix_meso.html command). It is up to you to decide whether periodic
|
|||
boundaries are appropriate with the kind of particle motion you are
|
||||
prescribing with this fix.
|
||||
|
||||
NOTE: As dicsussed below, particles are moved relative to their initial
|
||||
NOTE: As discussed below, particles are moved relative to their initial
|
||||
position at the time the fix is specified. These initial coordinates
|
||||
are stored by the fix in "unwrapped" form, by using the image flags
|
||||
associated with each particle. See the "dump custom"_dump.html command
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue