forked from lijiext/lammps
1007 lines
42 KiB
Plaintext
1007 lines
42 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 "Aspherical particles"_#4_14
|
|
4.15 "Output from LAMMPS"_#4_15 :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.
|
|
|
|
: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
|
|
cd $d
|
|
read_data data.polymer
|
|
run 10000
|
|
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 proc 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
|
|
|
|
To run a simulation of a granular model, you will want to use
|
|
the following commands:
|
|
|
|
"atom_style"_atom_style.html granular
|
|
"fix nve/gran"_fix_nve_gran.html
|
|
"fix gravity"_fix_gravity.html
|
|
"thermo_style"_thermo_style.html gran :ul
|
|
|
|
Use one of these 3 pair potentials:
|
|
|
|
"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 gran/diag"_fix_gran_diag.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.188
|
|
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.1507
|
|
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. We plan to add a cutoff
|
|
version in 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
|
|
|
|
: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 Aspherical particles :link(4_14),h4
|
|
|
|
LAMMPS supports ellipsoidal particles via the "atom_style
|
|
ellipsoid"_atom_style.html and "shape"_shape.html commands. The
|
|
latter command defines the 3 axes (diameters) of a general ellipsoid.
|
|
The "pair_style gayberne"_pair_gayberne.html command can be used to
|
|
define a Gay-Berne (GB) potential for how ellipsoidal particles
|
|
interact with each other and with spherical particles. The GB
|
|
potential is like a Lennard-Jones (LJ) potential, generalized for
|
|
orientation-dependent interactions.
|
|
|
|
The orientation of ellipsoidal particles is stored as a quaternion.
|
|
See the "set"_set.html command for a brief explanation of quaternions
|
|
and how the orientation of such particles can be initialized. The
|
|
data file read by the "read_data"_read_data.html command contains
|
|
quaternions for each atom in the Atoms section if "atom_style
|
|
ellipsoid"_atom_style.html is being used. The "compute
|
|
temp/asphere"_compute_temp_asphere.html command can be used to
|
|
calculate the temperature of a group of ellipsoidal particles, taking
|
|
account of rotational degrees of freedom. The motion of the particles
|
|
can be integrated via the "fix nve/asphere"_fix_nve_asphere.html, "fix
|
|
nvt/asphere"_fix_nvt_asphere.html, or "fix
|
|
npt/asphere"_fix_npt_asphere.html commands. All of these commands are
|
|
part of the ASPHERE package in LAMMPS.
|
|
|
|
Computationally, the cost for two ellipsoidal particles to interact is
|
|
30 times (or more) expensive than for 2 spherical LJ particles. Thus
|
|
if you are modeling a system with many spherical particles (e.g. as
|
|
the solvent), then you should insure sphere-sphere interactions are
|
|
computed with a cheaper potential than GB. This can be done by
|
|
setting the particle's 3 shape parameters to all be equal (a sphere).
|
|
Additionally, the corresponding GB potential coefficients can be set
|
|
so the GB potential will treat the pair of particles as LJ spheres.
|
|
Details are given in the doc page for the "pair_style
|
|
gayberne"_pair_gayberne.html. Alternatively, the "pair_style
|
|
hybrid"_pair_hybrid.html potential can be used, with the sphere-sphere
|
|
interactions computed by another pair potential, such as "pair_style
|
|
lj/cut"_pair_lj.html.
|
|
|
|
:line
|
|
|
|
4.15 Output from LAMMPS :link(4_15),h4
|
|
|
|
Aside from "restart files"_restart.html, there are two basic kinds of
|
|
LAMMPS output. The first is "thermodynamic output"_thermo_style.html,
|
|
which is a list of quantities printed every few timesteps to the
|
|
screen and logfile. The second is "dump files"_dump.html, which
|
|
contain snapshots of atoms and various per-atom values and are written
|
|
at a specified frequency. A simulation prints one set of
|
|
thermodynamic output; it may generate any number of dump files. As
|
|
discussed below, LAMMPS gives you a variety of ways to determine what
|
|
quantities are computed and printed when thermodynamic info or dump
|
|
files are output. There are also three fixes which can do their own
|
|
output of user-chosen quantities: "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. These are also described
|
|
below. Throughout this discussion, note that users can "add their own
|
|
computes and fixes to LAMMPS"_Section_modify.html which can then
|
|
generate values that can be output with these commands.
|
|
|
|
Thermodynamic output :h5
|
|
|
|
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. Each of these are described in turn.
|
|
|
|
In LAMMPS, a "compute"_compute.html comes in two flavors: ones that
|
|
compute global values (e.g. temperature, pressure tensor) and ones
|
|
that compute per-atom values. Only global quantities from a compute
|
|
can be used for thermodynamic output. The user-defined ID of the
|
|
compute is used along with an optional subscript as part of the
|
|
"thermo_style"_thermo_style.html command. E.g. c_myTemp outputs the
|
|
single scalar value generated by the compute; c_myTemp\[2\] outputs
|
|
the 2nd vector value. Note that there is a "compute
|
|
reduce"_compute_reduce.html command which can sum per-atom quantities
|
|
into a global scalar or vector.
|
|
|
|
"Fixes"_fix.html can generate global scalar or vector values which can
|
|
be output with thermodynamic output, e.g. the energy of an indenter's
|
|
interaction with the simulation atoms. These values are accessed via
|
|
the same format as a compute's values, as f_ID or f_ID\[N\]. See the
|
|
doc pages for individual fix commands to see which ones generate
|
|
global values that can be output with thermodynamic info. The "fix
|
|
ave/time"_fix_ave_time.html command generates time-averaged global
|
|
quantities which can be accessed for thermodynamic output, e.g. a
|
|
time-averaged pressure.
|
|
|
|
"Variables"_variable.html can be defined in the input script. All
|
|
styles except the atom-style variable can be used for thermodynamic
|
|
output, since it generates per-atom values. A variable with the name
|
|
"abc" is referenced in a thermo_style command as v_abc.
|
|
|
|
The formula associated with equal-style variables can contain math
|
|
operations and functions (x+y,x*y,(),sqrt,exp,etc), atom values
|
|
(x\[N\],fx\[N\],etc), group functions (mass(),vcm(),etc), references
|
|
to thermodynamic quantities (temp,press,vol,etc), references to
|
|
"computes"_compute.html that generate global values, references to
|
|
"fixes"_fix.html that generate global values, or references to other
|
|
"variables"_variable.html. Thus an equal-style variable is the most
|
|
general way to define some quantity to calculate and include with
|
|
thermodynamic output.
|
|
|
|
Dump file output :h5
|
|
|
|
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 keywords can be specified (tag, 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 value to be output. Each of
|
|
these are described in turn.
|
|
|
|
"Computes"_compute.html that generate one or more per-atom values can
|
|
be accessed by the dump custom command. These are computes that have
|
|
the word "atom" in their style name, e.g. ke/atom, stress/atom, etc.
|
|
The values are accessed as c_myKE for a scalar per-atom quantity or as
|
|
c_myStress\[2\] for a component of a vector per-atom quantity.
|
|
|
|
"Fixes"_fix.html can generate per-atom values to output to dump files.
|
|
For example, the "fix ave/atom"_fix_ave_atom.html command calculates
|
|
time-averages of per-atom quantities, such as per-atom
|
|
"computes"_compute.html and atom-style "variables"_variable.html.
|
|
These per-atom fix values are accessed by the "dump custom"_dump.html
|
|
command via the same format as a compute's values, as f_myKE or
|
|
f_myStress\[2\].
|
|
|
|
"Variables"_variable.html can be defined in the input script. Only
|
|
atom-style variables can be used for dump custom output, since only
|
|
they produce per-atom values. A variable with the name "abc" is
|
|
referenced in a dump custom command as v_abc.
|
|
|
|
Just like equal-style variables, the formula associated with
|
|
atom-style variables can contain math operations and functions
|
|
(x+y,x*y,(),sqrt,exp,etc), atom values (x\[N\],fx\[N\],etc), group
|
|
functions (mass(),vcm(),etc), references to thermodynamic quantities
|
|
(temp,press,vol,etc), references to "computes"_compute.html that
|
|
generate global values, references to "fixes"_fix.html that generate
|
|
global values, or references to non atom-style variables that generate
|
|
global values. In addition, an atom-style variable can reference
|
|
vectors of atom values (x\[\],fx\[\],etc), "computes"_compute.html
|
|
that generate per-atom values, "fixes"_fix.html that generate per-atom
|
|
values, or other atom-style variables. Thus an atom-style variable is
|
|
the most general way to define some quantity to calculate and output
|
|
to a dump file.
|
|
|
|
Fix output :h5
|
|
|
|
Three other fixes are of particular note for output: "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 time-averaging of
|
|
any global quantity, like those output with thermodynamic info. The
|
|
user specifies one or more quantities to time average. 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), any thermodynamic quantity can be time averaged in this way.
|
|
|
|
The "fix ave/time"_fix_ave_time.html command offers several options
|
|
for how it performs time averaging. The results it produces can be
|
|
used in two ways. First, they can be written directly to a file, one
|
|
line per timestamp. Note that the averaging parameters can be
|
|
specified in such a way that averaging is not done at all, in which
|
|
case this is simply a convenient means of outputting desired
|
|
quantities directly to a separate file. Like other fixes that produce
|
|
global quantities, the results of this fix can also be used as input
|
|
to any command that accesses global quantities, e.g. by the
|
|
"thermo_style custom"_thermo_style.html command, by a variable, etc.
|
|
|
|
The "fix ave/spatial"_fix_ave_spatial.html command enables
|
|
spatial-averaging of 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 "fix ave/spatial"_fix_ave_spatial.html command offers several
|
|
options for how it performs time averaging. The per-layer values it
|
|
produces can be used in two ways. First, they can be written directly
|
|
to a file. Note that the averaging parameters can be specified in
|
|
such a way that time averaging is not done, in which case this is a
|
|
convenient means of simply outputting desired quantities (summed over
|
|
atoms within a 1d layer) directly to a separate file. Like other
|
|
fixes that produce global quantities, the results of this fix can also
|
|
be used as input by any command that accesses global quantities,
|
|
e.g. by the "thermo_style custom"_thermo_style.html command, by a
|
|
variable, etc. See the doc page for "fix
|
|
ave/spatial"_fix_ave_spatial.html for a description of how these
|
|
values are indexed.
|
|
|
|
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), and 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. Thus the "fix
|
|
print"_fix_print.html command is a means to output any desired
|
|
calculated quantity separate from normal thermodynamic or dump file
|
|
output.
|
|
|
|
This table summarizes the various output options, specifying what
|
|
their inputs and outputs are. The frequency with which they are
|
|
invoked and produce output is also listed. Basically, any two
|
|
commands can be hooked together so long as one produces output that
|
|
matches the input needs of the other. A "match" means that the
|
|
frequencies and global vs per-atom attributes are the same.
|
|
|
|
Command: Input: Input Freq: Output: Output Freq
|
|
thermo_style custom: thermo keyword, global scalar/vector compute, global scalar/vector fix, equal variable: nthermo: screen, log: nthermo
|
|
dump custom: keyword, peratom scalar/vector compute, peratom scalar/vector fix, atom variable: dump freq: file: dump freq
|
|
global fixes: N/A: N/A: global scalar/vector: 1 or nevery
|
|
peratom fixes: N/A: N/A: peratom scalar/vector: 1 or nevery
|
|
fix ave/time: global scalar/vector fix, global scalar/vector compute, equal variable: nevery: global scalar/vector, file: nfreq
|
|
fix ave/spatial: peratom scalar/vector fix, peratom scalar/vector compute, atom vector, atom variable, density mass/number: nevery: global vector: nfreq, file
|
|
fix ave/atom: peratom scalar/vector compute, peratom scalar/vector fix, atom variable, atom vector: nevery: peratom scalar/vector: nfreq
|
|
fix print: any variable: nevery: screen, file: nevery
|
|
global computes: N/A: N/A: global scalar/vector: N/A
|
|
peratom computes: N/A: N/A: peratom scalar/vector: N/A
|
|
compute sum: peratom scalar/vector compute, peratom scalar/vector fix, atom variable: N/A: global scalar/vector: N/A
|
|
variable equal: thermo keywords, atom value vx\[123\], global scalar/vector compute, global scalar/vector fix, non-atom variable: N/A: global scalar: N/A
|
|
variable atom: thermo keywords, atom value vx\[123\], atom vector vx\[\], global scalar/vector compute, peratom scalar/vector compute, global scalar/vector fix, peratom scalar/vector fix, any variable: N/A: peratom scalar: N/A
|
|
print: any variable: N/A: screen, log: between runs
|
|
run every: any variable: nevery: screen, log: nevery :tb(s=:)
|
|
|
|
: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).
|