forked from lijiext/lammps
1444 lines
61 KiB
Plaintext
1444 lines
61 KiB
Plaintext
"Previous Section"_Section_commands.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_example.html :c
|
|
|
|
:link(lws,http://lammps.sandia.gov)
|
|
:link(ld,Manual.html)
|
|
:link(lc,Section_commands.html#comm)
|
|
|
|
:line
|
|
|
|
4. How-to discussions :h3
|
|
|
|
The following sections describe what commands can be used to perform
|
|
certain kinds of LAMMPS simulations.
|
|
|
|
4.1 "Restarting a simulation"_#4_1
|
|
4.2 "2d simulations"_#4_2
|
|
4.3 "CHARMM and AMBER force fields"_#4_3
|
|
4.4 "Running multiple simulations from one input script"_#4_4
|
|
4.5 "Parallel tempering"_#4_5
|
|
4.6 "Granular models"_#4_6
|
|
4.7 "TIP3P water model"_#4_7
|
|
4.8 "TIP4P water model"_#4_8
|
|
4.9 "SPC water model"_#4_9
|
|
4.10 "Coupling LAMMPS to other codes"_#4_10
|
|
4.11 "Visualizing LAMMPS snapshots"_#4_11
|
|
4.12 "Non-orthogonal simulation boxes"_#4_12
|
|
4.13 "NEMD simulations"_#4_13
|
|
4.14 "Extended spherical and aspherical particles"_#4_14
|
|
4.15 "Output from LAMMPS (thermo, dumps, computes, fixes, variables)"_#4_15
|
|
4.16 "Thermostatting, barostatting and computing temperature"_#4_16
|
|
4.17 "Walls"_#4_17 :all(b)
|
|
|
|
The example input scripts included in the LAMMPS distribution and
|
|
highlighted in "this section"_Section_example.html also show how to
|
|
setup and run various kinds of problems.
|
|
|
|
:line
|
|
|
|
4.1 Restarting a simulation :link(4_1),h4
|
|
|
|
There are 3 ways to continue a long LAMMPS simulation. Multiple
|
|
"run"_run.html commands can be used in the same input script. Each
|
|
run will continue from where the previous run left off. Or binary
|
|
restart files can be saved to disk using the "restart"_restart.html
|
|
command. At a later time, these binary files can be read via a
|
|
"read_restart"_read_restart.html command in a new script. Or they can
|
|
be converted to text data files and read by a
|
|
"read_data"_read_data.html command in a new script. "This
|
|
section"_Section_tools.html discusses the {restart2data} tool that is
|
|
used to perform the conversion.
|
|
|
|
Here we give examples of 2 scripts that read either a binary restart
|
|
file or a converted data file and then issue a new run command to
|
|
continue where the previous run left off. They illustrate what
|
|
settings must be made in the new script. Details are discussed in the
|
|
documentation for the "read_restart"_read_restart.html and
|
|
"read_data"_read_data.html commands.
|
|
|
|
Look at the {in.chain} input script provided in the {bench} directory
|
|
of the LAMMPS distribution to see the original script that these 2
|
|
scripts are based on. If that script had the line
|
|
|
|
restart 50 tmp.restart :pre
|
|
|
|
added to it, it would produce 2 binary restart files (tmp.restart.50
|
|
and tmp.restart.100) as it ran.
|
|
|
|
This script could be used to read the 1st restart file and re-run the
|
|
last 50 timesteps:
|
|
|
|
read_restart tmp.restart.50 :pre
|
|
|
|
neighbor 0.4 bin
|
|
neigh_modify every 1 delay 1 :pre
|
|
|
|
fix 1 all nve
|
|
fix 2 all langevin 1.0 1.0 10.0 904297 :pre
|
|
|
|
timestep 0.012 :pre
|
|
|
|
run 50 :pre
|
|
|
|
Note that the following commands do not need to be repeated because
|
|
their settings are included in the restart file: {units, atom_style,
|
|
special_bonds, pair_style, bond_style}. However these commands do
|
|
need to be used, since their settings are not in the restart file:
|
|
{neighbor, fix, timestep}.
|
|
|
|
If you actually use this script to perform a restarted run, you will
|
|
notice that the thermodynamic data match at step 50 (if you also put a
|
|
"thermo 50" command in the original script), but do not match at step
|
|
100. This is because the "fix langevin"_fix_langevin.html command
|
|
uses random numbers in a way that does not allow for perfect restarts.
|
|
|
|
As an alternate approach, the restart file could be converted to a data
|
|
file using this tool:
|
|
|
|
restart2data tmp.restart.50 tmp.restart.data :pre
|
|
|
|
Then, this script could be used to re-run the last 50 steps:
|
|
|
|
units lj
|
|
atom_style bond
|
|
pair_style lj/cut 1.12
|
|
pair_modify shift yes
|
|
bond_style fene
|
|
special_bonds 0.0 1.0 1.0 :pre
|
|
|
|
read_data tmp.restart.data :pre
|
|
|
|
neighbor 0.4 bin
|
|
neigh_modify every 1 delay 1 :pre
|
|
|
|
fix 1 all nve
|
|
fix 2 all langevin 1.0 1.0 10.0 904297 :pre
|
|
|
|
timestep 0.012 :pre
|
|
|
|
reset_timestep 50
|
|
run 50 :pre
|
|
|
|
Note that nearly all the settings specified in the original {in.chain}
|
|
script must be repeated, except the {pair_coeff} and {bond_coeff}
|
|
commands since the new data file lists the force field coefficients.
|
|
Also, the "reset_timestep"_reset_timestep.html command is used to tell
|
|
LAMMPS the current timestep. This value is stored in restart files,
|
|
but not in data files.
|
|
|
|
:line
|
|
|
|
4.2 2d simulations :link(4_2),h4
|
|
|
|
Use the "dimension"_dimension.html command to specify a 2d simulation.
|
|
|
|
Make the simulation box periodic in z via the "boundary"_boundary.html
|
|
command. This is the default.
|
|
|
|
If using the "create box"_create_box.html command to define a
|
|
simulation box, set the z dimensions narrow, but finite, so that the
|
|
create_atoms command will tile the 3d simulation box with a single z
|
|
plane of atoms - e.g.
|
|
|
|
"create box"_create_box.html 1 -10 10 -10 10 -0.25 0.25 :pre
|
|
|
|
If using the "read data"_read_data.html command to read in a file of
|
|
atom coordinates, set the "zlo zhi" values to be finite but narrow,
|
|
similar to the create_box command settings just described. For each
|
|
atom in the file, assign a z coordinate so it falls inside the
|
|
z-boundaries of the box - e.g. 0.0.
|
|
|
|
Use the "fix enforce2d"_fix_enforce2d.html command as the last
|
|
defined fix to insure that the z-components of velocities and forces
|
|
are zeroed out every timestep. The reason to make it the last fix is
|
|
so that any forces induced by other fixes will be zeroed out.
|
|
|
|
Many of the example input scripts included in the LAMMPS distribution
|
|
are for 2d models.
|
|
|
|
IMPORTANT NOTE: Some models in LAMMPS treat particles as extended
|
|
spheres, as opposed to point particles. In 2d, the particles will
|
|
still be spheres, not disks, meaning their moment of inertia will be
|
|
the same as in 3d.
|
|
|
|
:line
|
|
|
|
4.3 CHARMM and AMBER force fields :link(4_3),h4
|
|
|
|
There are many different ways to compute forces in the "CHARMM"_charmm
|
|
and "AMBER"_amber molecular dynamics codes, only some of which are
|
|
available as options in LAMMPS. A force field has 2 parts: the
|
|
formulas that define it and the coefficients used for a particular
|
|
system. Here we only discuss formulas implemented in LAMMPS. Setting
|
|
coefficients is done in the input data file via the
|
|
"read_data"_read_data.html command or in the input script with
|
|
commands like "pair_coeff"_pair_coeff.html or
|
|
"bond_coeff"_bond_coeff.html. See "this section"_Section_tools.html for
|
|
additional tools that can use CHARMM or AMBER to assign force field
|
|
coefficients and convert their output into LAMMPS input.
|
|
|
|
See "(MacKerell)"_#MacKerell for a description of the CHARMM force
|
|
field. See "(Cornell)"_#Cornell for a description of the AMBER force
|
|
field.
|
|
|
|
:link(charmm,http://www.scripps.edu/brooks)
|
|
:link(amber,http://amber.scripps.edu)
|
|
|
|
These style choices compute force field formulas that are consistent
|
|
with common options in CHARMM or AMBER. See each command's
|
|
documentation for the formula it computes.
|
|
|
|
"bond_style"_bond_style.html harmonic
|
|
"angle_style"_angle_style.html charmm
|
|
"dihedral_style"_dihedral_style.html charmm
|
|
"pair_style"_pair_style.html lj/charmm/coul/charmm
|
|
"pair_style"_pair_style.html lj/charmm/coul/charmm/implicit
|
|
"pair_style"_pair_style.html lj/charmm/coul/long :ul
|
|
|
|
"special_bonds"_special_bonds.html charmm
|
|
"special_bonds"_special_bonds.html amber :ul
|
|
|
|
:line
|
|
|
|
4.4 Running multiple simulations from one input script :link(4_4),h4
|
|
|
|
This can be done in several ways. See the documentation for
|
|
individual commands for more details on how these examples work.
|
|
|
|
If "multiple simulations" means continue a previous simulation for
|
|
more timesteps, then you simply use the "run"_run.html command
|
|
multiple times. For example, this script
|
|
|
|
units lj
|
|
atom_style atomic
|
|
read_data data.lj
|
|
run 10000
|
|
run 10000
|
|
run 10000
|
|
run 10000
|
|
run 10000 :pre
|
|
|
|
would run 5 successive simulations of the same system for a total of
|
|
50,000 timesteps.
|
|
|
|
If you wish to run totally different simulations, one after the other,
|
|
the "clear"_clear.html command can be used in between them to
|
|
re-initialize LAMMPS. For example, this script
|
|
|
|
units lj
|
|
atom_style atomic
|
|
read_data data.lj
|
|
run 10000
|
|
clear
|
|
units lj
|
|
atom_style atomic
|
|
read_data data.lj.new
|
|
run 10000 :pre
|
|
|
|
would run 2 independent simulations, one after the other.
|
|
|
|
For large numbers of independent simulations, you can use
|
|
"variables"_variable.html and the "next"_next.html and
|
|
"jump"_jump.html commands to loop over the same input script
|
|
multiple times with different settings. For example, this
|
|
script, named in.polymer
|
|
|
|
variable d index run1 run2 run3 run4 run5 run6 run7 run8
|
|
shell cd $d
|
|
read_data data.polymer
|
|
run 10000
|
|
shell cd ..
|
|
clear
|
|
next d
|
|
jump in.polymer :pre
|
|
|
|
would run 8 simulations in different directories, using a data.polymer
|
|
file in each directory. The same concept could be used to run the
|
|
same system at 8 different temperatures, using a temperature variable
|
|
and storing the output in different log and dump files, for example
|
|
|
|
variable a loop 8
|
|
variable t index 0.8 0.85 0.9 0.95 1.0 1.05 1.1 1.15
|
|
log log.$a
|
|
read data.polymer
|
|
velocity all create $t 352839
|
|
fix 1 all nvt $t $t 100.0
|
|
dump 1 all atom 1000 dump.$a
|
|
run 100000
|
|
next t
|
|
next a
|
|
jump in.polymer :pre
|
|
|
|
All of the above examples work whether you are running on 1 or
|
|
multiple processors, but assumed you are running LAMMPS on a single
|
|
partition of processors. LAMMPS can be run on multiple partitions via
|
|
the "-partition" command-line switch as described in "this
|
|
section"_Section_start.html#2_6 of the manual.
|
|
|
|
In the last 2 examples, if LAMMPS were run on 3 partitions, the same
|
|
scripts could be used if the "index" and "loop" variables were
|
|
replaced with {universe}-style variables, as described in the
|
|
"variable"_variable.html command. Also, the "next t" and "next a"
|
|
commands would need to be replaced with a single "next a t" command.
|
|
With these modifications, the 8 simulations of each script would run
|
|
on the 3 partitions one after the other until all were finished.
|
|
Initially, 3 simulations would be started simultaneously, one on each
|
|
partition. When one finished, that partition would then start
|
|
the 4th simulation, and so forth, until all 8 were completed.
|
|
|
|
:line
|
|
|
|
4.5 Parallel tempering :link(4_5),h4
|
|
|
|
The "temper"_temper.html command can be used to perform a parallel
|
|
tempering or replica-exchange simulation where multiple copies of a
|
|
simulation are run at different temperatures on different sets of
|
|
processors, and Monte Carlo temperature swaps are performed between
|
|
pairs of copies.
|
|
|
|
Use the -procs and -in "command-line switches"_Section_start.html#2_6
|
|
to launch LAMMPS on multiple partitions.
|
|
|
|
In your input script, define a set of temperatures, one for each
|
|
processor partition, using the "variable"_variable.html command:
|
|
|
|
variable t world 300.0 310.0 320.0 330.0 :pre
|
|
|
|
Define a fix of style "nvt"_fix_nvt.html or "langevin"_fix_langevin.html
|
|
to control the temperature of each simulation:
|
|
|
|
fix myfix all nvt $t $t 100.0 :pre
|
|
|
|
Use the "temper"_temper.html command in place of a "run"_run.html
|
|
command to perform a simulation where tempering exchanges will take
|
|
place:
|
|
|
|
temper 100000 100 $t myfix 3847 58382 :pre
|
|
|
|
:line
|
|
|
|
4.6 Granular models :link(4_6),h4
|
|
|
|
Granular system are composed of spherical particles with a diameter,
|
|
as opposed to point particles. This means they have an angular
|
|
velocity and torque can be imparted to them to cause them to rotate.
|
|
|
|
To run a simulation of a granular model, you will want to use
|
|
the following commands:
|
|
|
|
"atom_style"_atom_style.html granular
|
|
"fix nve/sphere"_fix_nve_sphere.html
|
|
"fix gravity"_fix_gravity.html :ul
|
|
|
|
This compute
|
|
|
|
"compute erotate/sphere"_compute_erotate_sphere.html :ul
|
|
|
|
calculates rotational kinetic energy which can be "output with
|
|
thermodynamic info"_Section_howto.html#4_15.
|
|
|
|
Use one of these 3 pair potentials, which compute forces and torques
|
|
between interacting pairs of particles:
|
|
|
|
"pair_style"_pair_style.html gran/history
|
|
"pair_style"_pair_style.html gran/no_history
|
|
"pair_style"_pair_style.html gran/hertzian :ul
|
|
|
|
These commands implement fix options specific to granular systems:
|
|
|
|
"fix freeze"_fix_freeze.html
|
|
"fix pour"_fix_pour.html
|
|
"fix viscous"_fix_viscous.html
|
|
"fix wall/gran"_fix_wall_gran.html :ul
|
|
|
|
The fix style {freeze} zeroes both the force and torque of frozen
|
|
atoms, and should be used for granular system instead of the fix style
|
|
{setforce}.
|
|
|
|
For computational efficiency, you can eliminate needless pairwise
|
|
computations between frozen atoms by using this command:
|
|
|
|
"neigh_modify"_neigh_modify.html exclude :ul
|
|
|
|
:line
|
|
|
|
4.7 TIP3P water model :link(4_7),h4
|
|
|
|
The TIP3P water model as implemented in CHARMM
|
|
"(MacKerell)"_#MacKerell specifies a 3-site rigid water molecule with
|
|
charges and Lennard-Jones parameters assigned to each of the 3 atoms.
|
|
In LAMMPS the "fix shake"_fix_shake.html command can be used to hold
|
|
the two O-H bonds and the H-O-H angle rigid. A bond style of
|
|
{harmonic} and an angle style of {harmonic} or {charmm} should also be
|
|
used.
|
|
|
|
These are the additional parameters (in real units) to set for O and H
|
|
atoms and the water molecule to run a rigid TIP3P-CHARMM model with a
|
|
cutoff. The K values can be used if a flexible TIP3P model (without
|
|
fix shake) is desired. If the LJ epsilon and sigma for HH and OH are
|
|
set to 0.0, it corresponds to the original 1983 TIP3P model
|
|
"(Jorgensen)"_#Jorgensen.
|
|
|
|
O mass = 15.9994
|
|
H mass = 1.008 :all(b),p
|
|
|
|
O charge = -0.834
|
|
H charge = 0.417 :all(b),p
|
|
|
|
LJ epsilon of OO = 0.1521
|
|
LJ sigma of OO = 3.1507
|
|
LJ epsilon of HH = 0.0460
|
|
LJ sigma of HH = 0.4000
|
|
LJ epsilon of OH = 0.0836
|
|
LJ sigma of OH = 1.7753 :all(b),p
|
|
|
|
K of OH bond = 450
|
|
r0 of OH bond = 0.9572 :all(b),p
|
|
|
|
K of HOH angle = 55
|
|
theta of HOH angle = 104.52 :all(b),p
|
|
|
|
These are the parameters to use for TIP3P with a long-range Coulombic
|
|
solver (Ewald or PPPM in LAMMPS):
|
|
|
|
O mass = 15.9994
|
|
H mass = 1.008 :all(b),p
|
|
|
|
O charge = -0.830
|
|
H charge = 0.415 :all(b),p
|
|
|
|
LJ epsilon of OO = 0.102
|
|
LJ sigma of OO = 3.188
|
|
LJ epsilon, sigma of OH, HH = 0.0 :all(b),p
|
|
|
|
K of OH bond = 450
|
|
r0 of OH bond = 0.9572 :all(b),p
|
|
|
|
K of HOH angle = 55
|
|
theta of HOH angle = 104.52 :all(b),p
|
|
|
|
:line
|
|
|
|
4.8 TIP4P water model :link(4_8),h4
|
|
|
|
The four-point TIP4P rigid water model extends the traditional
|
|
three-point TIP3P model by adding an additional site, usually
|
|
massless, where the charge associated with the oxygen atom is placed.
|
|
This site M is located at a fixed distance away from the oxygen along
|
|
the bisector of the HOH bond angle. A bond style of {harmonic} and an
|
|
angle style of {harmonic} or {charmm} should also be used.
|
|
|
|
Currently, only a four-point model for long-range Coulombics is
|
|
implemented via the LAMMPS "pair style
|
|
lj/cut/coul/long/tip4p"_pair_lj.html. A cutoff version may be added
|
|
the future. For both models, the bond lengths and bond angles should
|
|
be held fixed using the "fix shake"_fix_shake.html command.
|
|
|
|
These are the additional parameters (in real units) to set for O and H
|
|
atoms and the water molecule to run a rigid TIP4P model with a cutoff
|
|
"(Jorgensen)"_#Jorgensen. Note that the OM distance is specified in
|
|
the "pair_style"_pair_style.html command, not as part of the pair
|
|
coefficients.
|
|
|
|
O mass = 15.9994
|
|
H mass = 1.008 :all(b),p
|
|
|
|
O charge = -1.040
|
|
H charge = 0.520 :all(b),p
|
|
|
|
r0 of OH bond = 0.9572
|
|
theta of HOH angle = 104.52 :all(b),p
|
|
|
|
OM distance = 0.15 :all(b),p
|
|
|
|
LJ epsilon of O-O = 0.1550
|
|
LJ sigma of O-O = 3.1536
|
|
LJ epsilon, sigma of OH, HH = 0.0 :all(b),p
|
|
|
|
These are the parameters to use for TIP4P with a long-range Coulombic
|
|
solver (Ewald or PPPM in LAMMPS):
|
|
|
|
O mass = 15.9994
|
|
H mass = 1.008 :all(b),p
|
|
|
|
O charge = -1.0484
|
|
H charge = 0.5242 :all(b),p
|
|
|
|
r0 of OH bond = 0.9572
|
|
theta of HOH angle = 104.52 :all(b),p
|
|
|
|
OM distance = 0.1250 :all(b),p
|
|
|
|
LJ epsilon of O-O = 0.16275
|
|
LJ sigma of O-O = 3.16435
|
|
LJ epsilon, sigma of OH, HH = 0.0 :all(b),p
|
|
|
|
:line
|
|
|
|
4.9 SPC water model :link(4_9),h4
|
|
|
|
The SPC water model specifies a 3-site rigid water molecule with
|
|
charges and Lennard-Jones parameters assigned to each of the 3 atoms.
|
|
In LAMMPS the "fix shake"_fix_shake.html command can be used to hold
|
|
the two O-H bonds and the H-O-H angle rigid. A bond style of
|
|
{harmonic} and an angle style of {harmonic} or {charmm} should also be
|
|
used.
|
|
|
|
These are the additional parameters (in real units) to set for O and H
|
|
atoms and the water molecule to run a rigid SPC model with long-range
|
|
Coulombics (Ewald or PPPM in LAMMPS).
|
|
|
|
O mass = 15.9994
|
|
H mass = 1.008 :all(b),p
|
|
|
|
O charge = -0.820
|
|
H charge = 0.410 :all(b),p
|
|
|
|
LJ epsilon of OO = 0.1553
|
|
LJ sigma of OO = 3.166
|
|
LJ epsilon, sigma of OH, HH = 0.0 :all(b),p
|
|
|
|
r0 of OH bond = 1.0
|
|
theta of HOH angle = 109.47 :all(b),p
|
|
|
|
To use SPC with a long-range Coulombic solver (Ewald or PPPM in
|
|
LAMMPS), the only parameters that change are the partial charge
|
|
assignments:
|
|
|
|
O charge = -0.8476
|
|
H charge = 0.4238 :all(b),p
|
|
|
|
:line
|
|
|
|
4.10 Coupling LAMMPS to other codes :link(4_10),h4
|
|
|
|
LAMMPS is designed to allow it to be coupled to other codes. For
|
|
example, a quantum mechanics code might compute forces on a subset of
|
|
atoms and pass those forces to LAMMPS. Or a continuum finite element
|
|
(FE) simulation might use atom positions as boundary conditions on FE
|
|
nodal points, compute a FE solution, and return interpolated forces on
|
|
MD atoms.
|
|
|
|
LAMMPS can be coupled to other codes in at least 3 ways. Each has
|
|
advantages and disadvantages, which you'll have to think about in the
|
|
context of your application.
|
|
|
|
(1) Define a new "fix"_fix.html command that calls the other code. In
|
|
this scenario, LAMMPS is the driver code. During its timestepping,
|
|
the fix is invoked, and can make library calls to the other code,
|
|
which has been linked to LAMMPS as a library. This is the way the
|
|
"POEMS"_poems package that performs constrained rigid-body motion on
|
|
groups of atoms is hooked to LAMMPS. See the
|
|
"fix_poems"_fix_poems.html command for more details. See "this
|
|
section"_Section_modify.html of the documentation for info on how to add
|
|
a new fix to LAMMPS.
|
|
|
|
:link(poems,http://www.rpi.edu/~anderk5/lab)
|
|
|
|
(2) Define a new LAMMPS command that calls the other code. This is
|
|
conceptually similar to method (1), but in this case LAMMPS and the
|
|
other code are on a more equal footing. Note that now the other code
|
|
is not called during the timestepping of a LAMMPS run, but between
|
|
runs. The LAMMPS input script can be used to alternate LAMMPS runs
|
|
with calls to the other code, invoked via the new command. The
|
|
"run"_run.html command facilitates this with its {every} option, which
|
|
makes it easy to run a few steps, invoke the command, run a few steps,
|
|
invoke the command, etc.
|
|
|
|
In this scenario, the other code can be called as a library, as in
|
|
(1), or it could be a stand-alone code, invoked by a system() call
|
|
made by the command (assuming your parallel machine allows one or more
|
|
processors to start up another program). In the latter case the
|
|
stand-alone code could communicate with LAMMPS thru files that the
|
|
command writes and reads.
|
|
|
|
See "this section"_Section_modify.html of the documentation for how to
|
|
add a new command to LAMMPS.
|
|
|
|
(3) Use LAMMPS as a library called by another code. In this case the
|
|
other code is the driver and calls LAMMPS as needed. Or a wrapper
|
|
code could link and call both LAMMPS and another code as libraries.
|
|
Again, the "run"_run.html command has options that allow it to be
|
|
invoked with minimal overhead (no setup or clean-up) if you wish to do
|
|
multiple short runs, driven by another program.
|
|
|
|
"This section"_Section_start.html#2_4 of the documentation describes
|
|
how to build LAMMPS as a library. Once this is done, you can
|
|
interface with LAMMPS either via C++, C, or Fortran (or any other
|
|
language that supports a vanilla C-like interface, e.g. a scripting
|
|
language). For example, from C++ you could create one (or more)
|
|
"instances" of LAMMPS, pass it an input script to process, or execute
|
|
individual commands, all by invoking the correct class methods in
|
|
LAMMPS. From C or Fortran you can make function calls to do the same
|
|
things. Library.cpp and library.h contain such a C interface with the
|
|
functions:
|
|
|
|
void lammps_open(int, char **, MPI_Comm, void **);
|
|
void lammps_close(void *);
|
|
void lammps_file(void *, char *);
|
|
char *lammps_command(void *, char *); :pre
|
|
|
|
The functions contain C++ code you could write in a C++ application
|
|
that was invoking LAMMPS directly. Note that LAMMPS classes are
|
|
defined within a LAMMPS namespace (LAMMPS_NS) if you use them
|
|
from another C++ application.
|
|
|
|
Two of the routines in library.cpp are of particular note. The
|
|
lammps_open() function initiates LAMMPS and takes an MPI communicator
|
|
as an argument. It returns a pointer to a LAMMPS "object". As with
|
|
C++, the lammps_open() function can be called multiple times, to
|
|
create multiple instances of LAMMPS.
|
|
|
|
LAMMPS will run on the set of processors in the communicator. This
|
|
means the calling code can run LAMMPS on all or a subset of
|
|
processors. For example, a wrapper script might decide to alternate
|
|
between LAMMPS and another code, allowing them both to run on all the
|
|
processors. Or it might allocate half the processors to LAMMPS and
|
|
half to the other code and run both codes simultaneously before
|
|
syncing them up periodically.
|
|
|
|
Library.cpp contains a lammps_command() function to which the caller
|
|
passes a single LAMMPS command (a string). Thus the calling code can
|
|
read or generate a series of LAMMPS commands (e.g. an input script)
|
|
one line at a time and pass it thru the library interface to setup a
|
|
problem and then run it.
|
|
|
|
A few other sample functions are included in library.cpp, but the key
|
|
idea is that you can write any functions you wish to define an
|
|
interface for how your code talks to LAMMPS and add them to
|
|
library.cpp and library.h. The routines you add can access any LAMMPS
|
|
data. The examples/couple directory has example C++ and C codes which
|
|
show how a stand-alone code can link LAMMPS as a library, run LAMMPS
|
|
on a subset of processors, grab data from LAMMPS, change it, and put
|
|
it back into LAMMPS.
|
|
|
|
:line
|
|
|
|
4.11 Visualizing LAMMPS snapshots :link(4_11),h4
|
|
|
|
LAMMPS itself does not do visualization, but snapshots from LAMMPS
|
|
simulations can be visualized (and analyzed) in a variety of ways.
|
|
|
|
LAMMPS snapshots are created by the "dump"_dump.html command which can
|
|
create files in several formats. The native LAMMPS dump format is a
|
|
text file (see "dump atom" or "dump custom") which can be visualized
|
|
by the "xmovie"_Section_tools.html#xmovie program, included with the
|
|
LAMMPS package. This produces simple, fast 2d projections of 3d
|
|
systems, and can be useful for rapid debugging of simulation geometry
|
|
and atom trajectories.
|
|
|
|
Several programs included with LAMMPS as auxiliary tools can convert
|
|
native LAMMPS dump files to other formats. See the
|
|
"Section_tools"_Section_tools.html doc page for details. The first is
|
|
the "ch2lmp tool"_Section_tools.html#charmm, which contains a
|
|
lammps2pdb Perl script which converts LAMMPS dump files into PDB
|
|
files. The second is the "lmp2arc tool"_Section_tools.html#arc which
|
|
converts LAMMPS dump files into Accelrys' Insight MD program files.
|
|
The third is the "lmp2cfg tool"_Section_tools.html#cfg which converts
|
|
LAMMPS dump files into CFG files which can be read into the
|
|
"AtomEye"_atomeye visualizer.
|
|
|
|
A Python-based toolkit distributed by our group can read native LAMMPS
|
|
dump files, including custom dump files with additional columns of
|
|
user-specified atom information, and convert them to various formats
|
|
or pipe them into visualization software directly. See the "Pizza.py
|
|
WWW site"_pizza for details. Specifically, Pizza.py can convert
|
|
LAMMPS dump files into PDB, XYZ, "Ensight"_ensight, and VTK formats.
|
|
Pizza.py can pipe LAMMPS dump files directly into the Raster3d and
|
|
RasMol visualization programs. Pizza.py has tools that do interactive
|
|
3d OpenGL visualization and one that creates SVG images of dump file
|
|
snapshots.
|
|
|
|
LAMMPS can create XYZ files directly (via "dump xyz") which is a
|
|
simple text-based file format used by many visualization programs
|
|
including "VMD"_vmd.
|
|
|
|
LAMMPS can create DCD files directly (via "dump dcd") which can be
|
|
read by "VMD"_vmd in conjunction with a CHARMM PSF file. Using this
|
|
form of output avoids the need to convert LAMMPS snapshots to PDB
|
|
files. See the "dump"_dump.html command for more information on DCD
|
|
files.
|
|
|
|
LAMMPS can create XTC files directly (via "dump xtc") which is GROMACS
|
|
file format which can also be read by "VMD"_vmd for visualization.
|
|
See the "dump"_dump.html command for more information on XTC files.
|
|
|
|
:link(pizza,http://www.cs.sandia.gov/~sjplimp/pizza.html)
|
|
:link(vmd,http://www.ks.uiuc.edu/Research/vmd)
|
|
:link(ensight,http://www.ensight.com)
|
|
:link(atomeye,http://164.107.79.177/Archive/Graphics/A)
|
|
|
|
:line
|
|
|
|
4.12 Non-orthogonal simulation boxes :link(4_12),h4
|
|
|
|
By default, LAMMPS uses an orthogonal simulation box to encompass the
|
|
particles. The "boundary"_boundary.html command sets the boundary
|
|
conditions of the box (periodic, non-periodic, etc). If the box size
|
|
is xprd by yprd by zprd then the 3 mutually orthogonal edge vectors of
|
|
an orthogonal simulation box are a = (xprd,0,0), b = (0,yprd,0), and c
|
|
= (0,0,zprd).
|
|
|
|
LAMMPS also allows non-orthogonal simulation boxes (triclinic
|
|
symmetry) to be defined with 3 additional "tilt" parameters which
|
|
change the edge vectors of the simulation box to be a = (xprd,0,0), b
|
|
= (xy,yprd,0), and c = (xz,yz,zprd). The xy, xz, and yz parameters
|
|
can be positive or negative. The simulation box must be periodic in
|
|
both dimensions associated with a tilt factor. For example, if xz !=
|
|
0.0, then the x and z dimensions must be periodic.
|
|
|
|
To avoid extremely tilted boxes (which would be computationally
|
|
inefficient), no tilt factor can skew the box more than half the
|
|
distance of the parallel box length, which is the 1st dimension in the
|
|
tilt factor (x for xz). For example, if xlo = 2 and xhi = 12, then
|
|
the x box length is 10 and the xy tilt factor must be between -5 and
|
|
5. Similarly, both xz and yz must be between -(xhi-xlo)/2 and
|
|
+(yhi-ylo)/2. Note that this is not a limitation, since if the
|
|
maximum tilt factor is 5 (as in this example), then configurations
|
|
with tilt = ..., -15, -5, 5, 15, 25, ... are all equivalent.
|
|
|
|
You tell LAMMPS to use a non-orthogonal box when the simulation box is
|
|
defined. This happens in one of 3 ways. If the
|
|
"create_box"_create_box.html command is used with a region of style
|
|
{prism}, then a non-orthogonal domain is setup. See the
|
|
"region"_region.html command for details. If the
|
|
"read_data"_read_data.html command is used to define the simulation
|
|
box, and the header of the data file contains a line with the "xy xz
|
|
yz" keyword, then a non-orthogonal domain is setup. See the
|
|
"read_data"_read_data.html command for details. Finally, if the
|
|
"read_restart"_read_restart.html command reads a restart file which
|
|
was written from a simulation using a triclinic box, then a
|
|
non-orthogonal box will be enabled for the restarted simulation.
|
|
|
|
Note that you can define a non-orthogonal box with all 3 tilt factors
|
|
= 0.0, so that it is initially orthogonal. This is necessary if the
|
|
box will become non-orthogonal. Alternatively, you can use the
|
|
"change_box"_change_box.html command to convert a simulation box from
|
|
orthogonal to non-orthogonal and vice versa.
|
|
|
|
One use of non-orthogonal boxes is to model solid-state crystals with
|
|
triclinic symmetry. The "lattice"_lattice.html command can be used
|
|
with non-orthogonal basis vectors to define a lattice that will tile a
|
|
non-orthogonal simulation box via the "create_atoms"_create_atoms.html
|
|
command. Note that while the box edge vectors a,b,c cannot be
|
|
arbitrary vectors (e.g. a must be aligned with the x axis), it is
|
|
possible to rotate any crystal's basis vectors so that they meet these
|
|
restrictions.
|
|
|
|
A second use of non-orthogonal boxes is to shear a bulk solid to study
|
|
the response of the material. The "fix deform"_fix_deform.html
|
|
command can be used for this purpose. It allows dynamic control of
|
|
the xy, xz, and yz tilt factors as a simulation runs.
|
|
|
|
Another use of non-orthogonal boxes is to perform non-equilibrium MD
|
|
(NEMD) simulations, as discussed in the next section.
|
|
|
|
:line
|
|
|
|
4.13 NEMD simulations :link(4_13),h4
|
|
|
|
Non-equilibrium molecular dynamics or NEMD simulations are typically
|
|
used to measure a fluid's rheological properties such as viscosity.
|
|
In LAMMPS, such simulations can be performed by first setting up a
|
|
non-orthogonal simulation box (see the preceding Howto section).
|
|
|
|
A shear strain can be applied to the simulation box at a desired
|
|
strain rate by using the "fix deform"_fix_deform.html command. The
|
|
"fix nvt/sllod"_fix_nvt_sllod.html command can be used to thermostat
|
|
the sheared fluid and integrate the SLLOD equations of motion for the
|
|
system. Fix nvt/sllod uses "compute
|
|
temp/deform"_compute_temp_deform.html to compute a thermal temperature
|
|
by subtracting out the streaming velocity of the shearing atoms. The
|
|
velocity profile or other properties of the fluid can be monitored via
|
|
the "fix ave/spatial"_fix_ave_spatial.html command.
|
|
|
|
As discussed in the previous section on non-orthogonal simulation
|
|
boxes, the amount of tilt or skew that can be applied is limited by
|
|
LAMMPS for computational efficiency to be 1/2 of the parallel box
|
|
length. However, "fix deform"_fix_deform.html can continuously strain
|
|
a box by an arbitrary amount. As discussed in the "fix
|
|
deform"_fix_deform.html command, when the tilt value reaches a limit,
|
|
the box is re-shaped to the opposite limit which is an equivalent
|
|
tiling of periodic space. The strain rate can then continue to change
|
|
as before. In a long NEMD simulation these box re-shaping events may
|
|
occur many times.
|
|
|
|
In a NEMD simulation, the "remap" option of "fix
|
|
deform"_fix_deform.html should be set to "remap v", since that is what
|
|
"fix nvt/sllod"_fix_nvt_sllod.html assumes to generate a velocity
|
|
profile consistent with the applied shear strain rate.
|
|
|
|
An alternative method for calculating viscosities is provided via the
|
|
"fix viscosity"_fix_viscosity.html command.
|
|
|
|
:line
|
|
|
|
4.14 Extended spherical and aspherical particles :link(4_14),h4
|
|
|
|
Typical MD models treat atoms or particles as point masses.
|
|
Sometimes, however, it is desirable to have a model with finite-size
|
|
particles such as spherioids or aspherical ellipsoids. The difference
|
|
is that such particles have a moment of inertia, rotational energy,
|
|
and angular momentum. Rotation is induced by torque from interactions
|
|
with other particles.
|
|
|
|
LAMMPS has several options for running simulations with these kinds of
|
|
particles. The following aspects are discussed in turn:
|
|
|
|
atom styles
|
|
pair potentials
|
|
time integration
|
|
computes, thermodynamics, and dump output
|
|
rigid bodies composed of extended particles :ul
|
|
|
|
Atom styles :h5
|
|
|
|
There are 3 "atom styles"_atom_style.html that allow for definition of
|
|
finite-size particles: granular, dipole, ellipsoid.
|
|
|
|
Granular particles are spheriods and each particle can have a unique
|
|
diameter and mass (or density). These particles store an angular
|
|
velocity (omega) and can be acted upon by torque.
|
|
|
|
Dipolar particles are typically spheriods with a point dipole and each
|
|
particle type has a diamater and mass, set by the "shape"_shape.html
|
|
and "mass"_mass.html commands. These particles store an angular
|
|
velocity (omega) and can be acted upon by torque. They also store an
|
|
orientation for the point dipole (mu) which has a length set by the
|
|
"dipole"_dipole.html command. The "set"_set.html command can be used
|
|
to initialize the orientation of dipole moments.
|
|
|
|
Ellipsoid particles are aspherical. Each particle type has an
|
|
ellipsoidal shape and mass, defined by the "shape"_shape.html and
|
|
"mass"_mass.html commands. These particles store an angular momentum
|
|
and their orientation (quaternion), and can be acted upon by torque.
|
|
They do not store an angular velocity (omega), which can be in a
|
|
different direction than angular momentum, rather they compute it as
|
|
needed. Ellipsoidal particles can also store a dipole moment if an
|
|
"atom_style hybrid ellipsoid dipole"_atom_style.html is used. The
|
|
"set"_set.html command can be used to initialize the orientation of
|
|
ellipsoidal particles and has a brief explanation of quaternions.
|
|
|
|
Note that if one of these atom styles is used (or multiple styles via
|
|
the "atom_style hybrid"_atom_style.html command), not all particles in
|
|
the system are required to be finite-size or aspherical. For example,
|
|
if the 3 shape parameters are set to the same value, the particle will
|
|
be a spheroid rather than an ellipsoid. If the 3 shape parameters are
|
|
all set to 0.0 or if the diameter is set to 0.0, it will be a point
|
|
particle. If the dipole moment is set to zero, the particle will not
|
|
have a point dipole associated with it. The pair styles used to
|
|
compute pairwise interactions will typically compute the correct
|
|
interaction in these simplified (cheaper) cases. "Pair_style
|
|
hybrid"_pair_hybrid.html can be used to insure the correct
|
|
interactions are computed for the appropriate style of interactions.
|
|
Likewise, using groups to partition particles (ellipsoid versus
|
|
spheroid versus point particles) will allow you to use the appropriate
|
|
time integrators and temperature computations for each class of
|
|
particles. See the doc pages for various commands for details.
|
|
|
|
Also note that for "2d simulations"_dimension.html, finite-size
|
|
spheroids and ellipsoids are still treated as 3d particles, rather
|
|
than as disks or ellipses. This means they have the same moment of
|
|
inertia for a 3d extended object. When their temperature is
|
|
coomputed, the correct degrees of freedom are used for rotation in a
|
|
2d versus 3d system.
|
|
|
|
Pair potentials :h5
|
|
|
|
When a system with extended particles is defined, the particles will
|
|
only rotate and experience torque if the force field computes such
|
|
interactions. These are the various "pair styles"_pair_style.html
|
|
that generate torque:
|
|
|
|
"pair_style gran/history"_pair_gran.html
|
|
"pair_style gran/hertzian"_pair_gran.html
|
|
"pair_style gran/no_history"_pair_gran.html
|
|
"pair_style dipole/cut"_pair_dipole.html
|
|
"pair_style gayberne"_pair_gayberne.html
|
|
"pair_style resquared"_pair_resuared.html
|
|
"pair_style lubricate"_pair_lubricate.html :ul
|
|
|
|
The "granular pair styles"_pair_gran.html are used with "atom_style
|
|
granular"_atom_style.html. The "dipole pair style"_pair_dipole.html
|
|
is used with "atom_style dipole"_atom_style.html. The
|
|
"GayBerne"_pair_gayberne.html and "REsquared"_pair_resquared.html
|
|
potentials require particles have a "shape"_shape.html and are
|
|
designed for "ellipsoidal particles"_atom_style.html. The
|
|
"lubrication potential"_pair_lubricate.html requires that particles
|
|
have a "shape"_shape.html. It can currently only be used with
|
|
extended spherical particles.
|
|
|
|
Time integration :h5
|
|
|
|
There are 3 fixes that perform time integration on extended spherical
|
|
particles, meaning the integrators update the rotational orientation
|
|
and angular velocity or angular momentum of the particles:
|
|
|
|
"fix nve/sphere"_fix_nve_sphere.html
|
|
"fix nvt/sphere"_fix_nvt_sphere.html
|
|
"fix npt/sphere"_fix_npt_sphere.html :ul
|
|
|
|
Likewise, there are 3 fixes that perform time integration on extended
|
|
aspherical particles:
|
|
|
|
"fix nve/asphere"_fix_nve_asphere.html
|
|
"fix nvt/asphere"_fix_nvt_asphere.html
|
|
"fix npt/asphere"_fix_npt_asphere.html :ul
|
|
|
|
The advantage of these fixes is that those which thermostat the
|
|
particles include the rotational degrees of freedom in the temperature
|
|
calculation and thermostatting. Other thermostats can be used with
|
|
fix nve/sphere or fix nve/asphere, such as fix langevin or fix
|
|
temp/berendsen, but those thermostats only operate on the
|
|
translational kinetic energy of the extended particles.
|
|
|
|
Note that for mixtures of point and extended particles, you should
|
|
only use these integration fixes on "groups"_group.html which contain
|
|
extended particles.
|
|
|
|
Computes, thermodynamics, and dump output :h5
|
|
|
|
There are 4 computes that calculate the temperature or rotational energy
|
|
of extended spherical or aspherical particles:
|
|
|
|
"compute temp/sphere"_compute_temp_sphere.html
|
|
"compute temp/asphere"_compute_temp_asphere.html
|
|
"compute erotate/sphere"_compute_erotate_sphere.html
|
|
"compute erotate/asphere"_compute_erotate_asphere.html :ul
|
|
|
|
These include rotational degrees of freedom in their computation. If
|
|
you wish the thermodynamic output of temperature or pressure to use
|
|
one of these computes (e.g. for a system entirely composed of extended
|
|
particles), then the compute can be defined and the
|
|
"thermo_modify"_thermo_modify.html command used. Note that by
|
|
default thermodynamic quantities will be calculated with a temperature
|
|
that only includes translational degrees of freedom. See the
|
|
"thermo_style"_thermo_style.html command for details.
|
|
|
|
The "dump custom"_dump.html command can output various attributes of
|
|
extended particles, including the dipole moment (mu), the angular
|
|
velocity (omega), the angular momentum (angmom), the quaternion
|
|
(quat), and the torque (tq) on the particle.
|
|
|
|
Rigid bodies composed of extended particles :h5
|
|
|
|
The "fix rigid"_fix_rigid.html command treats a collection of
|
|
particles as a rigid body, computes its inertia tensor, sums the total
|
|
force and torque on the rigid body each timestep due to forces on its
|
|
constituent particles, and integrates the motion of the rigid body.
|
|
|
|
(NOTE: the feature described in the following paragraph has not yet
|
|
been released. It will be soon.)
|
|
|
|
If any of the constituent particles of a rigid body are extended
|
|
particles (spheroids or ellipsoids), then their contribution to the
|
|
inertia tensor of the body is different than if they were point
|
|
particles. This means the rotational dynamics of the rigid body will
|
|
be different. Thus a model of a dimer is different if the dimer
|
|
consists of two point masses versus two extended sphereoids, even if
|
|
the two particles have the same mass. Extended particles that
|
|
experience torque due to their interaction with other particles will
|
|
also impart that torque to a rigid body they are part of.
|
|
|
|
See the "fix rigid" command for example of complex rigid-body models
|
|
it is possible to define in LAMMPS.
|
|
|
|
Note that the "fix shake"_fix_shake.html command can also be used to
|
|
treat 2, 3, or 4 particles as a rigid body, but it always assumes the
|
|
particles are point masses.
|
|
|
|
:line
|
|
|
|
4.15 Output from LAMMPS (thermo, dumps, computes, fixes, variables) :link(4_15),h4
|
|
|
|
There are four basic kinds of LAMMPS output:
|
|
|
|
"Thermodynamic output"_thermo_style.html, which is a list
|
|
of quantities printed every few timesteps to the screen and logfile. :ulb,l
|
|
|
|
"Dump files"_dump.html, which contain snapshots of atoms and various
|
|
per-atom values and are written at a specified frequency. :l
|
|
|
|
Certain fixes can output user-specified quantities to files: "fix
|
|
ave/time"_fix_ave_time.html for time averaging, "fix
|
|
ave/spatial"_fix_ave_spatial.html for spatial averaging, and "fix
|
|
print"_fix_print.html for single-line output of
|
|
"variables"_variable.html. Fix print can also output to the
|
|
screen. :l
|
|
|
|
"Restart files"_restart.html. :l,ule
|
|
|
|
A simulation prints one set of thermodynamic output and (optionally)
|
|
restart files. It can generate any number of dump files and fix
|
|
output files, depending on what "dump"_dump.html and "fix"_fix.html
|
|
commands you specify.
|
|
|
|
As discussed below, LAMMPS gives you a variety of ways to determine
|
|
what quantities are computed and printed when the thermodynamics,
|
|
dump, or fix commands listed above perform output. Throughout this
|
|
discussion, note that users can also "add their own computes and fixes
|
|
to LAMMPS"_Section_modify.html which can then generate values that can
|
|
then be output with these commands.
|
|
|
|
The following sub-sections discuss different LAMMPS command related
|
|
to output and the kind of data they operate on and produce:
|
|
|
|
"Global/per-atom/local data"_#global
|
|
"Scalar/vector/array data"_#scalar
|
|
"Thermodynamic output"_#thermo
|
|
"Dump file output"_#dump
|
|
"Fixes that write output files"_#fixoutput
|
|
"Computes that process output quantities"_#computeoutput
|
|
"Fixes that process output quantities"_#fixoutput
|
|
"Computes that generate values to output"_#compute
|
|
"Fixes that generate values to output"_#fix
|
|
"Variables that generate values to output"_#variable
|
|
"Summary table of output options and data flow between commands"_#table :ul
|
|
|
|
Global/per-atom/local data :h5,link(global)
|
|
|
|
Various output-related commands work with three different styles of
|
|
data: global, per-atom, or local. A global datum is one or more
|
|
system-wide values, e.g. the temperature of the system. A per-atom
|
|
datum is one or more values per atom, e.g. the kinetic energy of each
|
|
atom. Local datums are calculated by each processor based on the
|
|
atoms it owns, but there may be zero or more per atom, e.g. a list of
|
|
bond distances.
|
|
|
|
Scalar/vector/array data :h5,link(scalar)
|
|
|
|
Global, per-atom, and local datums can each come in three kinds: a
|
|
single scalar value, a vector of values, or a 2d array of values. The
|
|
doc page for a "compute" or "fix" or "variable" that generates data
|
|
will specify both the style and kind of data it produces, e.g. a
|
|
per-atom vector.
|
|
|
|
When a quantity is accessed, as in many of the output commands
|
|
discussed below, it can be referenced via the following bracket
|
|
notation, where ID in this case is the ID of a compute. The leading
|
|
"c_" would be replaced by "f_" for a fix, or "v_" for a variable:
|
|
|
|
c_ID | entire scalar, vector, or array
|
|
c_ID\[I\] | one element of vector, one column of array
|
|
c_ID\[I\]\[J\] | one element of array :tb(s=|)
|
|
|
|
In other words, using one bracket reduces the dimension of the data
|
|
once (vector -> scalar, array -> vector). Using two brackets reduces
|
|
the dimension twice (array -> scalar). Thus a command that uses
|
|
scalar values as input can typically also process elements of a vector
|
|
or array.
|
|
|
|
Thermodynamic output :h5,link(thermo)
|
|
|
|
The frequency and format of thermodynamic output is set by the
|
|
"thermo"_thermo.html, "thermo_style"_thermo_style.html, and
|
|
"thermo_modify"_thermo_modify.html commands. The
|
|
"thermo_style"_thermo_style.html command also specifies what values
|
|
are calculated and written out. Pre-defined keywords can be specified
|
|
(e.g. press, etotal, etc). Three additional kinds of keywords can
|
|
also be specified (c_ID, f_ID, v_name), where a "compute"_compute.html
|
|
or "fix"_fix.html or "variable"_variable.html provides the value to be
|
|
output. In each case, the compute, fix, or variable must generate
|
|
global values for input to the "thermo_style custom"_dump.html
|
|
command.
|
|
|
|
Dump file output :h5,link(dump)
|
|
|
|
Dump file output is specified by the "dump"_dump.html and
|
|
"dump_modify"_dump_modify.html commands. There are several
|
|
pre-defined formats (dump atom, dump xtc, etc).
|
|
|
|
There is also a "dump custom"_dump.html format where the user
|
|
specifies what values are output with each atom. Pre-defined atom
|
|
attributes can be specified (id, x, fx, etc). Three additional kinds
|
|
of keywords can also be specified (c_ID, f_ID, v_name), where a
|
|
"compute"_compute.html or "fix"_fix.html or "variable"_variable.html
|
|
provides the values to be output. In each case, the compute, fix, or
|
|
variable must generate per-atom values for input to the "dump
|
|
custom"_dump.html command.
|
|
|
|
There is also a "dump local"_dump.html format where the user specifies
|
|
what local values to output. A pre-defined index keyword can be
|
|
specified to enumuerate the local values. Two additional kinds of
|
|
keywords can also be specified (c_ID, f_ID), where a
|
|
"compute"_compute.html or "fix"_fix.html or "variable"_variable.html
|
|
provides the values to be output. In each case, the compute or fix
|
|
must generate local values for input to the "dump local"_dump.html
|
|
command.
|
|
|
|
Fixes that write output files :h5,link(fixoutput)
|
|
|
|
Three fixes take various quantities as input and can write output
|
|
files: "fix ave/time"_fix_ave_time.html, "fix
|
|
ave/spatial"_fix_ave_spatial.html, and "fix print"_fix_print.html.
|
|
|
|
The "fix ave/time"_fix_ave_time.html command enables direct output to
|
|
a file and/or time-averaging of global scalars or vectors. The user
|
|
specifies one or more quantities as input. These can be global
|
|
"compute"_compute.html values, global "fix"_fix.html values, or
|
|
"variables"_variable.html of any style except the atom style which
|
|
produces per-atom values. Since a variable can refer to keywords used
|
|
by the "thermo_style custom"_thermo_style.html command (like temp or
|
|
press) and individual per-atom values, a wide variety of quantities
|
|
can be time averaged and/or output in this way. If the inputs are one
|
|
or more scalar values, then the fix generate a global scalar or vector
|
|
of output. If the inputs are one or more vector values, then the fix
|
|
generates a global vector or array of output. The time-averaged
|
|
output of this fix can also be used as input to other output commands.
|
|
|
|
The "fix ave/spatial"_fix_ave_spatial.html command enables direct
|
|
output to a file of spatial-averaged per-atom quantities like those
|
|
output in dump files, within 1d layers of the simulation box. The
|
|
per-atom quantities can be atom density (mass or number) or atom
|
|
attributes such as position, velocity, force. They can also be
|
|
per-atom quantities calculated by a "compute"_compute.html, by a
|
|
"fix"_fix.html, or by an atom-style "variable"_variable.html. The
|
|
spatial-averaged output of this fix can also be used as input to other
|
|
output commands.
|
|
|
|
The "fix ave/histo"_fix_ave_histo.html command enables direct output
|
|
to a file of histogrammed quantities, which can be global or per-atom
|
|
or local quantities. The histogram output of this fix can also be
|
|
used as input to other output commands.
|
|
|
|
The "fix print"_fix_print.html command can generate a line of output
|
|
written to the screen and log file or to a separate file, periodically
|
|
during a running simulation. The line can contain one or more
|
|
"variable"_variable.html values for any style variable except the atom
|
|
style). As explained above, variables themselves can contain
|
|
references to global values generated by "thermodynamic
|
|
keywords"_thermo_style.html, "computes"_compute.html,
|
|
"fixes"_fix.html, or other "variables"_variable.html, or to per-atom
|
|
values for a specific atom. Thus the "fix print"_fix_print.html
|
|
command is a means to output a wide variety of quantities separate
|
|
from normal thermodynamic or dump file output.
|
|
|
|
Computes that process output quantities :h5,link(computeoutput)
|
|
|
|
The "compute reduce"_compute_reduce.html and "compute
|
|
reduce/region"_compute_reduce.html commands take one or more vector
|
|
quantities as inputs and "reduce" them (sum, min, max, ave) to scalar
|
|
quantities. These are produced as output values which can be used as
|
|
input to other output commands.
|
|
|
|
The "compute property/atom"_compute_property_atom.html command takes a
|
|
list of one or more pre-defined atom attributes (id, x, fx, etc) and
|
|
stores the values in a per-atom vector or array. These are produced
|
|
as output values which can be used as input to other output commands.
|
|
The list of atom attributes is the same as for the "dump
|
|
custom"_dump.html command.
|
|
|
|
The "compute property/local"_compute_property_local.html command takes
|
|
a list of one or more pre-defined local attributes (bond info, angle
|
|
info, etc) and stores the values in a local vector or array. These
|
|
are produced as output values which can be used as input to other
|
|
output commands.
|
|
|
|
Fixes that process output quantities :h5,link(fixoutput)
|
|
|
|
The "fix ave/atom"_fix_ave_atom.html command performs time-averaging
|
|
of per-atom vectors. The per-atom quantities can be atom attributes
|
|
such as position, velocity, force. They can also be per-atom
|
|
quantities calculated by a "compute"_compute.html, by a
|
|
"fix"_fix.html, or by an atom-style "variable"_variable.html. The
|
|
time-averaged per-atom output of this fix can be used as input to
|
|
other output commands.
|
|
|
|
Computes that generate values to output :h5,link(compute)
|
|
|
|
Every "compute"_compute.html in LAMMPS produces either global or
|
|
per-atom or local values. The values can be scalars or vectors or
|
|
arrays of data. These values can be output using the other commands
|
|
described in this section. The doc page for each compute command
|
|
describes what it produces. Computes that produce per-atom or local
|
|
values have the word "atom" or "local" in their style name. Computes
|
|
without the word "atom" or "local" produce global values.
|
|
|
|
Fixes that generate values to output :h5,link(fix)
|
|
|
|
Some "fixes"_fix.html in LAMMPS produces either global or per-atom or
|
|
local values which can be accessed by other commands. The values can
|
|
be scalars or vectors or arrays of data. These values can be output
|
|
using the other commands described in this section. The doc page for
|
|
each fix command tells whether it produces any output quantities and
|
|
describes them.
|
|
|
|
Variables that generate values to output :h5,link(variable)
|
|
|
|
Every "variables"_variable.html defined in an input script generates
|
|
either a global scalar value or a per-atom vector (only atom-style
|
|
variables) when it is accessed. The formulas used to define equal-
|
|
and atom-style variables can contain references to the thermodynamic
|
|
keywords and to global and per-atom data generated by computes, fixes,
|
|
and other variables. The values generated by variables can be output
|
|
using the other commands described in this section.
|
|
|
|
Summary table of output options and data flow between commands :h5,link(table)
|
|
|
|
This table summarizes the various commands that can be used for
|
|
generating output from LAMMPS. Each command produces output data of
|
|
some kind and/or writes data to a file. Most of the commands can take
|
|
data from other commands as input. Thus you can link many of these
|
|
commands together in pipeline form, where data produced by one command
|
|
is used as input to another command and eventually written to the
|
|
screen or to a file. Note that to hook two commands together the
|
|
output and input data types must match, e.g. global/per-atom/local
|
|
data and scalar/vector/array data.
|
|
|
|
Also note that, as described above, when a command takes a scalar as
|
|
input, that could be an element of a vector or array. Likewise a
|
|
vector input could be a column of an array.
|
|
|
|
Command: Input: Output:
|
|
"thermo_style custom"_thermo_style.html: global scalars: screen, log file:
|
|
"dump custom"_dump.html: per-atom vectors: dump file:
|
|
"dump local"_dump.html: local vectors: dump file:
|
|
"fix print"_fix_print.html: global scalar from variable: screen, file:
|
|
"print"_print.html: global scalar from variable: screen:
|
|
"computes"_compute.html: N/A: global/per-atom/local scalar/vector/array:
|
|
"fixes"_fix.html: N/A: global/per-atom/local scalar/vector/array:
|
|
"variables"_variable.html: global scalars, per-atom vectors: global scalar, per-atom vector:
|
|
"compute reduce"_compute_reduce.html: global/per-atom/local vectors: global scalar/vector:
|
|
"compute property/atom"_compute_property_atom.html: per-atom vectors: per-atom vector/array:
|
|
"compute property/local"_compute_property_local.html: local vectors: local vector/array:
|
|
"fix ave/atom"_fix_ave_atom.html: per-atom vectors: per-atom vector/array:
|
|
"fix ave/time"_fix_ave_time.html: global scalars/vectors: global scalar/vector/array, file:
|
|
"fix ave/spatial"_fix_ave_spatial.html: per-atom vectors: global array, file:
|
|
"fix ave/histo"_fix_ave_histo.html: global/per-atom/local scalars and vectors: global array, file:
|
|
:tb(s=:)
|
|
|
|
:line
|
|
|
|
4.16 Thermostatting, barostatting, and computing temperature :link(4_16),h4
|
|
|
|
Thermostatting means controlling the temperature of particles in an MD
|
|
simulation. Barostatting means controlling the pressure. Since the
|
|
pressure includes a kinetic component due to particle velocities, both
|
|
these operations require calculation of the temperature. Typically a
|
|
target temperature (T) and/or pressure (P) is specified by the user,
|
|
and the thermostat or barostat attempts to equilibrate the system to
|
|
the requested T and/or P.
|
|
|
|
Temperature is computed as kinetic energy divided by some number of
|
|
degrees of freedom (and the Boltzmann constant). Since kinetic energy
|
|
is a function of particle velocity, there is often a need to
|
|
distinguish between a particle's advection velocity (due to some
|
|
aggregate motiion of particles) and its thermal velocity. The sum of
|
|
the two is the particle's total velocity, but the latter is often what
|
|
is wanted to compute a temperature.
|
|
|
|
LAMMPS has several options for computing temperatures, any of which
|
|
can be used in thermostatting and barostatting. These "compute
|
|
commands"_compute.html calculate temperature, and the "compute
|
|
pressure"_compute_pressure.html command calculates pressure.
|
|
|
|
"compute temp"_compute_temp.html
|
|
"compute temp/sphere"_compute_temp_sphere.html
|
|
"compute temp/asphere"_compute_temp_asphere.html
|
|
"compute temp/com"_compute_temp_com.html
|
|
"compute temp/deform"_compute_temp_deform.html
|
|
"compute temp/partial"_compute_temp_partial.html
|
|
"compute temp/profile"_compute_temp_profile.html
|
|
"compute temp/ramp"_compute_temp_ramp.html
|
|
"compute temp/region"_compute_temp_region.html :ul
|
|
|
|
All but the first 3 calculate velocity biases (i.e. advection
|
|
velocities) that are removed when computing the thermal temperature.
|
|
"Fix temp/sphere"_fix_temp_sphere.html and "fix
|
|
temp/asphere"_fix_temp_asphere.html compute kinetic energy for
|
|
extended particles that includes rotational degrees of freedom. They
|
|
both allow, as an extra argument, which is another temperature compute
|
|
that subtracts a velocity bias. This allows the translational
|
|
velocity of extended spherical or aspherical particles to be adjusted
|
|
in prescribed ways.
|
|
|
|
Thermostatting in LAMMPS is performed by "fixes"_fix.html. Four
|
|
thermostatting fixes are currently available: Nose-Hoover (nvt),
|
|
Berendsen, Langevin, and direct rescaling (temp/rescale):
|
|
|
|
"fix nvt"_fix_nvt.html
|
|
"fix nvt/sphere"_fix_nvt_sphere.html
|
|
"fix nvt/asphere"_fix_nvt_asphere.html
|
|
"fix nvt/sllod"_fix_nvt_sllod.html
|
|
"fix temp/berendsen"_fix_temp_berendsen.html
|
|
"fix langevin"_fix_langevin.html
|
|
"fix temp/rescale"_fix_temp_rescale.html :ul
|
|
|
|
"Fix nvt"_fix_nvt.html only thermostats the translational velocity of
|
|
particles. "Fix nvt/sllod"_fix_nvt_sllod.html also does this, except
|
|
that it subtracts out a velocity bias due to a deforming box and
|
|
integrates the SLLOD equations of motion. See the "NEMD
|
|
simulations"_#4_13 section of this page for further details. "Fix
|
|
nvt/sphere"_fix_nvt_sphere.html and "fix
|
|
nvt/asphere"_fix_nvt_asphere.html thermostat not only translation
|
|
velocities but also rotational velocities for spherical and aspherical
|
|
particles.
|
|
|
|
Any of these fixes can use temperature computes that remove bias for
|
|
two purposes: (a) computing the current temperature to compare to the
|
|
requested target temperature, and (b) adjusting only the thermal
|
|
temperature component of the particle's velocities. See the doc pages
|
|
for the individual fixes and for the "fix_modify"_fix_modify.html
|
|
command for instructions on how to assign a temperature compute to a
|
|
thermostatting fix. For example, you can apply a thermostat to only
|
|
the x and z components of velocity by using it in conjunction with
|
|
"compute temp/partial"_compute_temp_partial.html.
|
|
|
|
IMPORTANT NOTE: Only the nvt fixes perform time integration, meaning
|
|
they update the velocities and positions of particles due to forces
|
|
and velocities respectively. The other thermostat fixes only adjust
|
|
velocities; they do NOT perform time integration updates. Thus they
|
|
should be used in conjunction with a constant NVE integration fix such
|
|
as these:
|
|
|
|
"fix nve"_fix_nve.html
|
|
"fix nve/sphere"_fix_nve_sphere.html
|
|
"fix nve/asphere"_fix_nve_asphere.html :ul
|
|
|
|
Barostatting in LAMMPS is also performed by "fixes"_fix.html. Two
|
|
barosttating methods are currently available: Nose-Hoover (npt and
|
|
nph) and Berendsen:
|
|
|
|
"fix npt"_fix_npt.html
|
|
"fix npt/sphere"_fix_npt_sphere.html
|
|
"fix npt/asphere"_fix_npt_asphere.html
|
|
"fix nph"_fix_nph.html
|
|
"fix press/berendsen"_fix_press_berendsen.html :ul
|
|
|
|
The "fix npt"_fix_npt.html commands include a Nose-Hoover thermostat
|
|
and barostat. "Fix nph"_fix_nph.html is just a Nose/Hoover barostat;
|
|
it does no thermostatting. Both "fix nph"_fix_nph.html and "fix
|
|
press/bernendsen"_fix_press_berendsen.html can be used in conjunction
|
|
with any of the thermostatting fixes.
|
|
|
|
As with the thermostats, "fix npt"_fix_npt.html and "fix
|
|
nph"_fix_nph.html only use translational motion of the particles in
|
|
computing T and P and performing thermo/barostatting. "Fix
|
|
npt/sphere"_fix_npt_sphere.html and "fix
|
|
npt/asphere"_fix_npt_asphere.html thermo/barostat using not only
|
|
translation velocities but also rotational velocities for spherical
|
|
and aspherical particles.
|
|
|
|
All of the barostatting fixes use the "compute
|
|
pressure"_compute_pressure.html compute to calculate a current
|
|
pressure. By default, this compute is created with a simple "compute
|
|
temp"_compute_temp.html (see the last argument of the "compute
|
|
pressure"_compute_pressure.html command), which is used to calculated
|
|
the kinetic componenet of the pressure. The barostatting fixes can
|
|
also use temperature computes that remove bias for the purpose of
|
|
computing the kinetic componenet which contributes to the current
|
|
pressure. See the doc pages for the individual fixes and for the
|
|
"fix_modify"_fix_modify.html command for instructions on how to assign
|
|
a temperature or pressure compute to a barostatting fix.
|
|
|
|
IMPORTANT NOTE: As with the thermostats, the Nose/Hoover methods ("fix
|
|
npt"_fix_npt.html and "fix nph"_fix_nph.html) perform time
|
|
integration. "Fix press/berendsen"_fix_press_berendsen.html does NOT,
|
|
so it should be used with one of the constant NVE fixes or with one of
|
|
the NVT fixes.
|
|
|
|
Finally, thermodynamic output, which can be setup via the
|
|
"thermo_style"_thermo_style.html command, often includes temperature
|
|
and pressure values. As explained on the doc page for the
|
|
"thermo_style"_thermo_style.html command, the default T and P are
|
|
setup by the thermo command itself. They are NOT the ones associated
|
|
with any thermostatting or barostatting fix you have defined or with
|
|
any compute that calculates a temperature or pressure. Thus if you
|
|
want to view these values of T and P, you need to specify them
|
|
explicitly via a "thermo_style custom"_thermo_style.html command. Or
|
|
you can use the "thermo_modify"_thermo_modify.html command to
|
|
re-define what temperature or pressure compute is used for default
|
|
thermodynamic output.
|
|
|
|
:line
|
|
|
|
4.16 Walls :link(4_17),h4
|
|
|
|
Walls in an MD simulation are typically used to bound particle motion,
|
|
i.e. to serve as a boundary condition.
|
|
|
|
Walls in LAMMPS can be of rough (made of particles) or idealized
|
|
surfaces. Ideal walls can be smooth, generating forces only in the
|
|
normal direction, or frictional, generating forces also in the
|
|
tangential direction.
|
|
|
|
Rough walls, built of particles, can be created in various ways. The
|
|
particles themselves can be generated like any other particle, via the
|
|
"lattice"_lattice.html and "create_atoms"_create_atoms.html commands,
|
|
or read in via the "read_data"_read_data.html command.
|
|
|
|
Their motion can be constrained by many different commands, so that
|
|
they do not move at all, move together as a group at constant velocity
|
|
or in response to a net force acting on them, move in a prescribed
|
|
fashion (e.g. rotate around a point), etc. Note that if a time
|
|
integration fix like "fix nve"_fix_nve.html or "fix nvt"_fix_nvt.html
|
|
is not used with the group that contains wall particles, their
|
|
positions and velocities will not be updated.
|
|
|
|
"fix aveforce"_fix_aveforce.html - set force on particles to average value, so they move together
|
|
"fix setforce"_fix_setforce.html - set force on particles to a value, e.g. 0.0
|
|
"fix freeze"_fix_freeze.html - freeze particles for use as granular walls
|
|
"fix nve/noforce"_fix_nve_noforce.html - advect particles by their velocity, but without force
|
|
"fix move"_fix_move.html - prescribe motion of particles by a linear velocity, oscillation, rotation, variable :ul
|
|
|
|
The "fix move"_fix_move.html command offers the most generality, since
|
|
the motion of individual particles can be specified with
|
|
"variable"_variable.html formula which depends on time and/or the
|
|
particle position.
|
|
|
|
For rough walls, it may be useful to turn off pairwise interactions
|
|
between wall particles via the "neigh_modify
|
|
exclude"_neigh_modify.html command.
|
|
|
|
Rough walls can also be created by specifying frozen particles that do
|
|
not move and do not interact with mobile particles, and then tethering
|
|
other particles to the fixed particles, via a "bond"_bond_style.html.
|
|
The bonded particles do interact with other mobile particles.
|
|
|
|
Idealized walls can be specified via several fix commands. "Fix
|
|
wall/gran"_fix_wall_gran.html creates frictional walls for use with
|
|
granular particles; all the other commands create smooth walls.
|
|
|
|
"fix wall/reflect"_fix_wall_reflect.html - reflective flat walls
|
|
"fix wall/lj93"_fix_wall.html - flat walls, with Lennard-Jones 9/3 potential
|
|
"fix wall/lj126"_fix_wall.html - flat walls, with Lennard-Jones 12/6 potential
|
|
"fix wall/colloid"_fix_wall.html - flat walls, with "pair_style colloid"_pair_colloid.html potential
|
|
"fix wall/harmonic"_fix_wall.html - flat walls, with repulsive harmonic spring potential
|
|
"fix wall/region"_fix_wall_region.html - use region surface as wall
|
|
"fix wall/gran"_fix_wall_gran.html - flat or curved walls with "pair_style granular"_pair_gran.html potential :ul
|
|
|
|
The {lj93}, {lj126}, {colloid}, and {harmonic} styles all allow the
|
|
flat walls to move with a constant velocity, or oscillate in time.
|
|
The "fix wall/region"_fix_wall_region.html command offers the most
|
|
generality, since the region surface is treated as a wall, and the
|
|
geometry of the region can be a simple primitive volume (e.g. a
|
|
sphere, or cube, or plane), or a complex volume made from the union
|
|
and intersection of primitive volumes. "Regions"_region.html can also
|
|
specify a volume "interior" or "exterior" to the specified primitive
|
|
shape or {union} or {intersection}. "Regions"_region.html can also be
|
|
"dynamic" meaning they move with constant velocity, oscillate, or
|
|
rotate.
|
|
|
|
The only frictional idealized walls currently in LAMMPS are flat or
|
|
curved surfaces specified by the "fix wall/gran"_fix_wall_gran.html
|
|
command. At some point we plan to allow regoin surfaces to be used as
|
|
frictional walls, as well as triangulated surfaces.
|
|
|
|
:line
|
|
:line
|
|
|
|
:link(Cornell)
|
|
[(Cornell)] Cornell, Cieplak, Bayly, Gould, Merz, Ferguson,
|
|
Spellmeyer, Fox, Caldwell, Kollman, JACS 117, 5179-5197 (1995).
|
|
|
|
:link(Horn)
|
|
[(Horn)] Horn, Swope, Pitera, Madura, Dick, Hura, and Head-Gordon,
|
|
J Chem Phys, 120, 9665 (2004).
|
|
|
|
:link(MacKerell)
|
|
[(MacKerell)] MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field,
|
|
Fischer, Gao, Guo, Ha, et al, J Phys Chem, 102, 3586 (1998).
|
|
|
|
:link(Jorgensen)
|
|
[(Jorgensen)] Jorgensen, Chandrasekhar, Madura, Impey, Klein, J Chem
|
|
Phys, 79, 926 (1983).
|