forked from lijiext/lammps
changes for Intro and Howto doc pages
This commit is contained in:
Steven J. Plimpton
parent
8c0955aaff
commit
90897f570e
|
|
@ -1,6 +1,6 @@
|
|||
"Previous Section"_Python.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
|
||||
Section"_Section_history.html :c
|
||||
Section"_Manual.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
"Previous Section"_Section_howto.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
|
||||
Section"_Section_perf.html :c
|
||||
"Previous Section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc - "Next
|
||||
Section"_Tools.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,128 @@
|
|||
"Previous Section"_Performance.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
|
||||
Section"_Examples.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
How to discussions :h2
|
||||
|
||||
These doc pages describe how to perform various tasks with LAMMPS,
|
||||
both for users and developers. The
|
||||
"glossary"_http://lammps.sandia.gov website page also lists MD
|
||||
terminology with links to corresponding LAMMPS manual pages.
|
||||
|
||||
The example input scripts included in the examples dir of the LAMMPS
|
||||
distribution and highlighted on the "Examples"_Examples.html doc page
|
||||
also show how to setup and run various kinds of simulations.
|
||||
|
||||
<!-- RST
|
||||
|
||||
.. toctree::
|
||||
|
||||
Howto_github
|
||||
Howto_pylammps
|
||||
Howto_bash
|
||||
|
||||
.. toctree::
|
||||
|
||||
Howto_restart
|
||||
Howto_viz
|
||||
Howto_multiple
|
||||
Howto_replica
|
||||
Howto_library
|
||||
Howto_couple
|
||||
|
||||
.. toctree::
|
||||
|
||||
Howto_output
|
||||
Howto_chunk
|
||||
|
||||
.. toctree::
|
||||
|
||||
Howto_2d
|
||||
Howto_triclinic
|
||||
Howto_walls
|
||||
Howto_nemd
|
||||
Howto_granular
|
||||
Howto_spherical
|
||||
Howto_dispersion
|
||||
|
||||
.. toctree::
|
||||
|
||||
Howto_temperature
|
||||
Howto_thermostat
|
||||
Howto_barostat
|
||||
Howto_elastic
|
||||
Howto_kappa
|
||||
Howto_viscosity
|
||||
Howto_diffusion
|
||||
|
||||
.. toctree::
|
||||
|
||||
Howto_bioFF
|
||||
Howto_tip3p
|
||||
Howto_tip4p
|
||||
Howto_spc
|
||||
|
||||
.. toctree::
|
||||
|
||||
Howto_body
|
||||
Howto_polarizable
|
||||
Howto_coreshell
|
||||
Howto_drude
|
||||
Howto_drude2
|
||||
Howto_manifold
|
||||
Howto_spins
|
||||
|
||||
END_RST -->
|
||||
|
||||
<!-- HTML_ONLY -->
|
||||
|
||||
"Using GitHub with LAMMPS"_Howto_github.html
|
||||
"PyLAMMPS interface to LAMMPS"_Howto_pylammps.html
|
||||
"Using LAMMPS with bash on Windows"_Howto_bash.html
|
||||
|
||||
"Restart a simulation"_Howto_restart.html
|
||||
"Visualize LAMMPS snapshots"_Howto_viz.html
|
||||
"Run multiple simulations from one input script"_Howto_multiple.html
|
||||
"Multi-replica simulations"_Howto_replica.html
|
||||
"Library interface to LAMMPS"_Howto_library.html
|
||||
"Couple LAMMPS to other codes"_Howto_couple.html :all(b)
|
||||
|
||||
"Output from LAMMPS (thermo, dumps, computes, fixes, variables)"_Howto_output.html
|
||||
"Use chunks to calculate system properties"_Howto_chunk.html :all(b)
|
||||
|
||||
"2d simulations"_Howto_2d.html
|
||||
"Triclinic (non-orthogonal) simulation boxes"_Howto_triclinic.html
|
||||
"Walls"_Howto_walls.html
|
||||
"NEMD simulations"_Howto_nemd.html
|
||||
"Granular models"_Howto_granular.html
|
||||
"Finite-size spherical and aspherical particles"_Howto_spherical.html
|
||||
"Long-range dispersion settings"_Howto_dispersion.html :all(b)
|
||||
|
||||
"Calculate temperature"_Howto_temperature.html
|
||||
"Thermostats"_Howto_thermostat.html
|
||||
"Barostats"_Howto_barostat.html
|
||||
"Calculate elastic constants"_Howto_elastic.html
|
||||
"Calculate thermal conductivity"_Howto_kappa.html
|
||||
"Calculate viscosity"_Howto_viscosity.html
|
||||
"Calculate a diffusion coefficient"_Howto_diffusion.html :all(b)
|
||||
|
||||
"CHARMM, AMBER, and DREIDING force fields"_Howto_bioFF.html
|
||||
"TIP3P water model"_Howto_tip3p.html
|
||||
"TIP4P water model"_Howto_tip4p.html
|
||||
"SPC water model"_Howto_spc.html :all(b)
|
||||
|
||||
"Body style particles"_Howto_body.html
|
||||
"Polarizable models"_Howto_polarizable.html
|
||||
"Adiabatic core/shell model"_Howto_coreshell.html
|
||||
"Drude induced dipoles"_Howto_drude.html
|
||||
"Drude induced dipoles (extended)"_Howto_drude2.html :all(b)
|
||||
"Manifolds (surfaces)"_Howto_manifold.html
|
||||
"Magnetic spins"_Howto_spins.html
|
||||
|
||||
<!-- END_HTML_ONLY -->
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
2d simulations :h3
|
||||
|
||||
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.
|
||||
|
||||
NOTE: Some models in LAMMPS treat particles as finite-size spheres, as
|
||||
opposed to point particles. See the "atom_style
|
||||
sphere"_atom_style.html and "fix nve/sphere"_fix_nve_sphere.html
|
||||
commands for details. By default, for 2d simulations, such particles
|
||||
will still be modeled as 3d spheres, not 2d discs (circles), meaning
|
||||
their moment of inertia will be that of a sphere. If you wish to
|
||||
model them as 2d discs, see the "set density/disc"_set.html command
|
||||
and the {disc} option for the "fix nve/sphere"_fix_nve_sphere.html,
|
||||
"fix nvt/sphere"_fix_nvt_sphere.html, "fix
|
||||
nph/sphere"_fix_nph_sphere.html, "fix npt/sphere"_fix_npt_sphere.html
|
||||
commands.
|
||||
|
|
@ -0,0 +1,75 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Barostats :h3
|
||||
|
||||
Barostatting means controlling the pressure in an MD simulation.
|
||||
"Thermostatting"_Howto_thermostat.html means controlling the
|
||||
temperature of the particles. 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.
|
||||
|
||||
Barostatting in LAMMPS is performed by "fixes"_fix.html. Two
|
||||
barosttating methods are currently available: Nose-Hoover (npt and
|
||||
nph) and Berendsen:
|
||||
|
||||
"fix npt"_fix_nh.html
|
||||
"fix npt/sphere"_fix_npt_sphere.html
|
||||
"fix npt/asphere"_fix_npt_asphere.html
|
||||
"fix nph"_fix_nh.html
|
||||
"fix press/berendsen"_fix_press_berendsen.html :ul
|
||||
|
||||
The "fix npt"_fix_nh.html commands include a Nose-Hoover thermostat
|
||||
and barostat. "Fix nph"_fix_nh.html is just a Nose/Hoover barostat;
|
||||
it does no thermostatting. Both "fix nph"_fix_nh.html and "fix
|
||||
press/berendsen"_fix_press_berendsen.html can be used in conjunction
|
||||
with any of the thermostatting fixes.
|
||||
|
||||
As with the "thermostats"_Howto_thermostat.html, "fix npt"_fix_nh.html
|
||||
and "fix nph"_fix_nh.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 component of the pressure. The barostatting fixes can
|
||||
also use temperature computes that remove bias for the purpose of
|
||||
computing the kinetic component 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.
|
||||
|
||||
NOTE: As with the thermostats, the Nose/Hoover methods ("fix
|
||||
npt"_fix_nh.html and "fix nph"_fix_nh.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.
|
||||
|
||||
Thermodynamic output, which can be setup via the
|
||||
"thermo_style"_thermo_style.html command, often includes pressure
|
||||
values. As explained on the doc page for the
|
||||
"thermo_style"_thermo_style.html command, the default pressure is
|
||||
setup by the thermo command itself. It is NOT the presure associated
|
||||
with any barostatting fix you have defined or with any compute you
|
||||
have defined that calculates a presure. The doc pages for the
|
||||
barostatting fixes explain the ID of the pressure compute they create.
|
||||
Thus if you want to view these pressurse, you need to specify them
|
||||
explicitly via the "thermo_style custom"_thermo_style.html command.
|
||||
Or you can use the "thermo_modify"_thermo_modify.html command to
|
||||
re-define what pressure compute is used for default thermodynamic
|
||||
output.
|
||||
|
|
@ -10,6 +10,7 @@ Using LAMMPS with Bash on Windows :h3
|
|||
[written by Richard Berger]
|
||||
|
||||
:line
|
||||
|
||||
Starting with Windows 10 you can install Linux tools directly in Windows. This
|
||||
allows you to compile LAMMPS following the same procedure as on a real Ubuntu
|
||||
Linux installation. Software can be easily installed using the package manager
|
||||
|
|
@ -0,0 +1,101 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
CHARMM, AMBER, and DREIDING force fields :h3
|
||||
|
||||
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 that correspond to formulas commonly
|
||||
used in the CHARMM, AMBER, and DREIDING force fields. 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 the "Tools"_Tools.html doc page for
|
||||
additional tools that can use CHARMM or AMBER to assign force field
|
||||
coefficients and convert their output into LAMMPS input.
|
||||
|
||||
See "(MacKerell)"_#howto-MacKerell for a description of the CHARMM force
|
||||
field. See "(Cornell)"_#howto-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_harmonic.html harmonic
|
||||
"angle_style"_angle_charmm.html charmm
|
||||
"dihedral_style"_dihedral_charmm.html charmmfsh
|
||||
"dihedral_style"_dihedral_charmm.html charmm
|
||||
"pair_style"_pair_charmm.html lj/charmmfsw/coul/charmmfsh
|
||||
"pair_style"_pair_charmm.html lj/charmmfsw/coul/long
|
||||
"pair_style"_pair_charmm.html lj/charmm/coul/charmm
|
||||
"pair_style"_pair_charmm.html lj/charmm/coul/charmm/implicit
|
||||
"pair_style"_pair_charmm.html lj/charmm/coul/long :ul
|
||||
|
||||
"special_bonds"_special_bonds.html charmm
|
||||
"special_bonds"_special_bonds.html amber :ul
|
||||
|
||||
NOTE: For CHARMM, newer {charmmfsw} or {charmmfsh} styles were
|
||||
released in March 2017. We recommend they be used instead of the
|
||||
older {charmm} styles. See discussion of the differences on the "pair
|
||||
charmm"_pair_charmm.html and "dihedral charmm"_dihedral_charmm.html
|
||||
doc pages.
|
||||
|
||||
DREIDING is a generic force field developed by the "Goddard
|
||||
group"_http://www.wag.caltech.edu at Caltech and is useful for
|
||||
predicting structures and dynamics of organic, biological and
|
||||
main-group inorganic molecules. The philosophy in DREIDING is to use
|
||||
general force constants and geometry parameters based on simple
|
||||
hybridization considerations, rather than individual force constants
|
||||
and geometric parameters that depend on the particular combinations of
|
||||
atoms involved in the bond, angle, or torsion terms. DREIDING has an
|
||||
"explicit hydrogen bond term"_pair_hbond_dreiding.html to describe
|
||||
interactions involving a hydrogen atom on very electronegative atoms
|
||||
(N, O, F).
|
||||
|
||||
See "(Mayo)"_#howto-Mayo for a description of the DREIDING force field
|
||||
|
||||
These style choices compute force field formulas that are consistent
|
||||
with the DREIDING force field. See each command's
|
||||
documentation for the formula it computes.
|
||||
|
||||
"bond_style"_bond_harmonic.html harmonic
|
||||
"bond_style"_bond_morse.html morse :ul
|
||||
|
||||
"angle_style"_angle_harmonic.html harmonic
|
||||
"angle_style"_angle_cosine.html cosine
|
||||
"angle_style"_angle_cosine_periodic.html cosine/periodic :ul
|
||||
|
||||
"dihedral_style"_dihedral_charmm.html charmm
|
||||
"improper_style"_improper_umbrella.html umbrella :ul
|
||||
|
||||
"pair_style"_pair_buck.html buck
|
||||
"pair_style"_pair_buck.html buck/coul/cut
|
||||
"pair_style"_pair_buck.html buck/coul/long
|
||||
"pair_style"_pair_lj.html lj/cut
|
||||
"pair_style"_pair_lj.html lj/cut/coul/cut
|
||||
"pair_style"_pair_lj.html lj/cut/coul/long :ul
|
||||
|
||||
"pair_style"_pair_hbond_dreiding.html hbond/dreiding/lj
|
||||
"pair_style"_pair_hbond_dreiding.html hbond/dreiding/morse :ul
|
||||
|
||||
"special_bonds"_special_bonds.html dreiding :ul
|
||||
|
||||
:line
|
||||
|
||||
:link(howto-MacKerell)
|
||||
[(MacKerell)] MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field,
|
||||
Fischer, Gao, Guo, Ha, et al, J Phys Chem, 102, 3586 (1998).
|
||||
|
||||
:link(howto-Mayo)
|
||||
[(Mayo)] Mayo, Olfason, Goddard III, J Phys Chem, 94, 8897-8909
|
||||
(1990).
|
||||
|
|
@ -0,0 +1,456 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Body particles :h3
|
||||
|
||||
[Overview:]
|
||||
|
||||
In LAMMPS, body particles are generalized finite-size particles.
|
||||
Individual body particles can represent complex entities, such as
|
||||
surface meshes of discrete points, collections of sub-particles,
|
||||
deformable objects, etc. Note that other kinds of finite-size
|
||||
spherical and aspherical particles are also supported by LAMMPS, such
|
||||
as spheres, ellipsoids, line segments, and triangles, but they are
|
||||
simpler entities that body particles. See "Section
|
||||
6.14"_Section_howto.html#howto_14 for a general overview of all these
|
||||
particle types.
|
||||
|
||||
Body particles are used via the "atom_style body"_atom_style.html
|
||||
command. It takes a body style as an argument. The current body
|
||||
styles supported by LAMMPS are as follows. The name in the first
|
||||
column is used as the {bstyle} argument for the "atom_style
|
||||
body"_atom_style.html command.
|
||||
|
||||
{nparticle} : rigid body with N sub-particles
|
||||
{rounded/polygon} : 2d polygons with N vertices
|
||||
{rounded/polyhedron} : 3d polyhedra with N vertices, E edges and F faces :tb(s=:)
|
||||
|
||||
The body style determines what attributes are stored for each body and
|
||||
thus how they can be used to compute pairwise body/body or
|
||||
bond/non-body (point particle) interactions. More details of each
|
||||
style are described below.
|
||||
|
||||
More styles may be added in the future. See the "Modify
|
||||
body"_Modify_body.html doc page for details on how to add a new body
|
||||
style to the code.
|
||||
|
||||
:line
|
||||
|
||||
[When to use body particles:]
|
||||
|
||||
You should not use body particles to model a rigid body made of
|
||||
simpler particles (e.g. point, sphere, ellipsoid, line segment,
|
||||
triangular particles), if the interaction between pairs of rigid
|
||||
bodies is just the summation of pairwise interactions between the
|
||||
simpler particles. LAMMPS already supports this kind of model via the
|
||||
"fix rigid"_fix_rigid.html command. Any of the numerous pair styles
|
||||
that compute interactions between simpler particles can be used. The
|
||||
"fix rigid"_fix_rigid.html command time integrates the motion of the
|
||||
rigid bodies. All of the standard LAMMPS commands for thermostatting,
|
||||
adding constraints, performing output, etc will operate as expected on
|
||||
the simple particles.
|
||||
|
||||
By contrast, when body particles are used, LAMMPS treats an entire
|
||||
body as a single particle for purposes of computing pairwise
|
||||
interactions, building neighbor lists, migrating particles between
|
||||
processors, output of particles to a dump file, etc. This means that
|
||||
interactions between pairs of bodies or between a body and non-body
|
||||
(point) particle need to be encoded in an appropriate pair style. If
|
||||
such a pair style were to mimic the "fix rigid"_fix_rigid.html model,
|
||||
it would need to loop over the entire collection of interactions
|
||||
between pairs of simple particles within the two bodies, each time a
|
||||
single body/body interaction was computed.
|
||||
|
||||
Thus it only makes sense to use body particles and develop such a pair
|
||||
style, when particle/particle interactions are more complex than what
|
||||
the "fix rigid"_fix_rigid.html command can already calculate. For
|
||||
example, consider particles with one or more of the following
|
||||
attributes:
|
||||
|
||||
represented by a surface mesh
|
||||
represented by a collection of geometric entities (e.g. planes + spheres)
|
||||
deformable
|
||||
internal stress that induces fragmentation :ul
|
||||
|
||||
For these models, the interaction between pairs of particles is likely
|
||||
to be more complex than the summation of simple pairwise interactions.
|
||||
An example is contact or frictional forces between particles with
|
||||
planar surfaces that inter-penetrate. Likewise, the body particle may
|
||||
store internal state, such as a stress tensor used to compute a
|
||||
fracture criterion.
|
||||
|
||||
These are additional LAMMPS commands that can be used with body
|
||||
particles of different styles
|
||||
|
||||
"fix nve/body"_fix_nve_body.html : integrate motion of a body particle in NVE ensemble
|
||||
"fix nvt/body"_fix_nvt_body.html : ditto for NVT ensemble
|
||||
"fix npt/body"_fix_npt_body.html : ditto for NPT ensemble
|
||||
"fix nph/body"_fix_nph_body.html : ditto for NPH ensemble
|
||||
"compute body/local"_compute_body_local.html : store sub-particle attributes of a body particle
|
||||
"compute temp/body"_compute_temp_body.html : compute temperature of body particles
|
||||
"dump local"_dump.html : output sub-particle attributes of a body particle
|
||||
"dump image"_dump_image.html : output body particle attributes as an image :tb(s=:)
|
||||
|
||||
The pair styles defined for use with specific body styles are listed
|
||||
in the sections below.
|
||||
|
||||
:line
|
||||
|
||||
[Specifics of body style nparticle:]
|
||||
|
||||
The {nparticle} body style represents body particles as a rigid body
|
||||
with a variable number N of sub-particles. It is provided as a
|
||||
vanilla, prototypical example of a body particle, although as
|
||||
mentioned above, the "fix rigid"_fix_rigid.html command already
|
||||
duplicates its functionality.
|
||||
|
||||
The atom_style body command for this body style takes two additional
|
||||
arguments:
|
||||
|
||||
atom_style body nparticle Nmin Nmax
|
||||
Nmin = minimum # of sub-particles in any body in the system
|
||||
Nmax = maximum # of sub-particles in any body in the system :pre
|
||||
|
||||
The Nmin and Nmax arguments are used to bound the size of data
|
||||
structures used internally by each particle.
|
||||
|
||||
When the "read_data"_read_data.html command reads a data file for this
|
||||
body style, the following information must be provided for each entry
|
||||
in the {Bodies} section of the data file:
|
||||
|
||||
atom-ID 1 M
|
||||
N
|
||||
ixx iyy izz ixy ixz iyz
|
||||
x1 y1 z1
|
||||
...
|
||||
xN yN zN :pre
|
||||
|
||||
where M = 6 + 3*N, and N is the number of sub-particles in the body
|
||||
particle.
|
||||
|
||||
The integer line has a single value N. The floating point line(s)
|
||||
list 6 moments of inertia followed by the coordinates of the N
|
||||
sub-particles (x1 to zN) as 3N values. These values can be listed on
|
||||
as many lines as you wish; see the "read_data"_read_data.html command
|
||||
for more details.
|
||||
|
||||
The 6 moments of inertia (ixx,iyy,izz,ixy,ixz,iyz) should be the
|
||||
values consistent with the current orientation of the rigid body
|
||||
around its center of mass. The values are with respect to the
|
||||
simulation box XYZ axes, not with respect to the principal axes of the
|
||||
rigid body itself. LAMMPS performs the latter calculation internally.
|
||||
The coordinates of each sub-particle are specified as its x,y,z
|
||||
displacement from the center-of-mass of the body particle. The
|
||||
center-of-mass position of the particle is specified by the x,y,z
|
||||
values in the {Atoms} section of the data file, as is the total mass
|
||||
of the body particle.
|
||||
|
||||
The "pair_style body"_pair_body.html command can be used with this
|
||||
body style to compute body/body and body/non-body interactions.
|
||||
|
||||
For output purposes via the "compute
|
||||
body/local"_compute_body_local.html and "dump local"_dump.html
|
||||
commands, this body style produces one datum for each of the N
|
||||
sub-particles in a body particle. The datum has 3 values:
|
||||
|
||||
1 = x position of sub-particle
|
||||
2 = y position of sub-particle
|
||||
3 = z position of sub-particle :pre
|
||||
|
||||
These values are the current position of the sub-particle within the
|
||||
simulation domain, not a displacement from the center-of-mass (COM) of
|
||||
the body particle itself. These values are calculated using the
|
||||
current COM and orientation of the body particle.
|
||||
|
||||
For images created by the "dump image"_dump_image.html command, if the
|
||||
{body} keyword is set, then each body particle is drawn as a
|
||||
collection of spheres, one for each sub-particle. The size of each
|
||||
sphere is determined by the {bflag1} parameter for the {body} keyword.
|
||||
The {bflag2} argument is ignored.
|
||||
|
||||
:line
|
||||
|
||||
[Specifics of body style rounded/polygon:]
|
||||
|
||||
The {rounded/polygon} body style represents body particles as a 2d
|
||||
polygon with a variable number of N vertices. This style can only be
|
||||
used for 2d models; see the "boundary"_boundary.html command. See the
|
||||
"pair_style body/rounded/polygon" doc page for a diagram of two
|
||||
squares with rounded circles at the vertices. Special cases for N = 1
|
||||
(circle) and N = 2 (rod with rounded ends) can also be specified.
|
||||
|
||||
One use of this body style is for 2d discrete element models, as
|
||||
described in "Fraige"_#body-Fraige.
|
||||
|
||||
Similar to body style {nparticle}, the atom_style body command for
|
||||
this body style takes two additional arguments:
|
||||
|
||||
atom_style body rounded/polygon Nmin Nmax
|
||||
Nmin = minimum # of vertices in any body in the system
|
||||
Nmax = maximum # of vertices in any body in the system :pre
|
||||
|
||||
The Nmin and Nmax arguments are used to bound the size of data
|
||||
structures used internally by each particle.
|
||||
|
||||
When the "read_data"_read_data.html command reads a data file for this
|
||||
body style, the following information must be provided for each entry
|
||||
in the {Bodies} section of the data file:
|
||||
|
||||
atom-ID 1 M
|
||||
N
|
||||
ixx iyy izz ixy ixz iyz
|
||||
x1 y1 z1
|
||||
...
|
||||
xN yN zN
|
||||
i j j k k ...
|
||||
diameter :pre
|
||||
|
||||
where M = 6 + 3*N + 2*N + 1, and N is the number of vertices in the
|
||||
body particle.
|
||||
|
||||
The integer line has a single value N. The floating point line(s)
|
||||
list 6 moments of inertia followed by the coordinates of the N
|
||||
vertices (x1 to zN) as 3N values (with z = 0.0 for each), followed by
|
||||
2N vertex indices corresponding to the end points of the N edges,
|
||||
followed by a single diameter value = the rounded diameter of the
|
||||
circle that surrounds each vertex. The diameter value can be different
|
||||
for each body particle. These floating-point values can be listed on
|
||||
as many lines as you wish; see the "read_data"_read_data.html command
|
||||
for more details.
|
||||
|
||||
The 6 moments of inertia (ixx,iyy,izz,ixy,ixz,iyz) should be the
|
||||
values consistent with the current orientation of the rigid body
|
||||
around its center of mass. The values are with respect to the
|
||||
simulation box XYZ axes, not with respect to the principal axes of the
|
||||
rigid body itself. LAMMPS performs the latter calculation internally.
|
||||
The coordinates of each vertex are specified as its x,y,z displacement
|
||||
from the center-of-mass of the body particle. The center-of-mass
|
||||
position of the particle is specified by the x,y,z values in the
|
||||
{Atoms} section of the data file.
|
||||
|
||||
For example, the following information would specify a square particle
|
||||
whose edge length is sqrt(2) and rounded diameter is 1.0. The
|
||||
orientation of the square is aligned with the xy coordinate axes which
|
||||
is consistent with the 6 moments of inertia: ixx iyy izz ixy ixz iyz =
|
||||
1 1 4 0 0 0. Note that only Izz matters in 2D simulations.
|
||||
|
||||
3 1 27
|
||||
4
|
||||
1 1 4 0 0 0
|
||||
-0.7071 -0.7071 0
|
||||
-0.7071 0.7071 0
|
||||
0.7071 0.7071 0
|
||||
0.7071 -0.7071 0
|
||||
0 1
|
||||
1 2
|
||||
2 3
|
||||
3 0
|
||||
1.0 :pre
|
||||
|
||||
A rod in 2D, whose length is 4.0, mass 1.0, rounded at two ends
|
||||
by circles of diameter 0.5, is specified as follows:
|
||||
|
||||
1 1 13
|
||||
2
|
||||
1 1 1.33333 0 0 0
|
||||
-2 0 0
|
||||
2 0 0
|
||||
0.5 :pre
|
||||
|
||||
A disk, whose diameter is 3.0, mass 1.0, is specified as follows:
|
||||
|
||||
1 1 10
|
||||
1
|
||||
1 1 4.5 0 0 0
|
||||
0 0 0
|
||||
3.0 :pre
|
||||
|
||||
The "pair_style body/rounded/polygon"_pair_body_rounded_polygon.html
|
||||
command can be used with this body style to compute body/body
|
||||
interactions. The "fix wall/body/polygon"_fix_wall_body_polygon.html
|
||||
command can be used with this body style to compute the interaction of
|
||||
body particles with a wall.
|
||||
|
||||
:line
|
||||
|
||||
[Specifics of body style rounded/polyhedron:]
|
||||
|
||||
The {rounded/polyhedron} body style represents body particles as a 3d
|
||||
polyhedron with a variable number of N vertices, E edges and F faces.
|
||||
This style can only be used for 3d models; see the
|
||||
"boundary"_boundary.html command. See the "pair_style
|
||||
body/rounded/polygon" doc page for a diagram of a two 2d squares with
|
||||
rounded circles at the vertices. A 3d cube with rounded spheres at
|
||||
the 8 vertices and 12 rounded edges would be similar. Special cases
|
||||
for N = 1 (sphere) and N = 2 (rod with rounded ends) can also be
|
||||
specified.
|
||||
|
||||
This body style is for 3d discrete element models, as described in
|
||||
"Wang"_#body-Wang.
|
||||
|
||||
Similar to body style {rounded/polygon}, the atom_style body command
|
||||
for this body style takes two additional arguments:
|
||||
|
||||
atom_style body rounded/polyhedron Nmin Nmax
|
||||
Nmin = minimum # of vertices in any body in the system
|
||||
Nmax = maximum # of vertices in any body in the system :pre
|
||||
|
||||
The Nmin and Nmax arguments are used to bound the size of data
|
||||
structures used internally by each particle.
|
||||
|
||||
When the "read_data"_read_data.html command reads a data file for this
|
||||
body style, the following information must be provided for each entry
|
||||
in the {Bodies} section of the data file:
|
||||
|
||||
atom-ID 3 M
|
||||
N E F
|
||||
ixx iyy izz ixy ixz iyz
|
||||
x1 y1 z1
|
||||
...
|
||||
xN yN zN
|
||||
0 1
|
||||
1 2
|
||||
2 3
|
||||
...
|
||||
0 1 2 -1
|
||||
0 2 3 -1
|
||||
...
|
||||
1 2 3 4
|
||||
diameter :pre
|
||||
|
||||
where M = 6 + 3*N + 2*E + 4*F + 1, and N is the number of vertices in
|
||||
the body particle, E = number of edges, F = number of faces.
|
||||
|
||||
The integer line has three values: number of vertices (N), number of
|
||||
edges (E) and number of faces (F). The floating point line(s) list 6
|
||||
moments of inertia followed by the coordinates of the N vertices (x1
|
||||
to zN) as 3N values, followed by 2N vertex indices corresponding to
|
||||
the end points of the E edges, then 4*F vertex indices defining F
|
||||
faces. The last value is the diameter value = the rounded diameter of
|
||||
the sphere that surrounds each vertex. The diameter value can be
|
||||
different for each body particle. These floating-point values can be
|
||||
listed on as many lines as you wish; see the
|
||||
"read_data"_read_data.html command for more details. Because the
|
||||
maxmimum vertices per face is hard-coded to be 4
|
||||
(i.e. quadrilaterals), faces with more than 4 vertices need to be
|
||||
split into triangles or quadrilaterals. For triangular faces, the
|
||||
last vertex index should be set to -1.
|
||||
|
||||
The ordering of the 4 vertices within a face should follow
|
||||
the right-hand rule so that the normal vector of the face points
|
||||
outwards from the center of mass.
|
||||
|
||||
The 6 moments of inertia (ixx,iyy,izz,ixy,ixz,iyz) should be the
|
||||
values consistent with the current orientation of the rigid body
|
||||
around its center of mass. The values are with respect to the
|
||||
simulation box XYZ axes, not with respect to the principal axes of the
|
||||
rigid body itself. LAMMPS performs the latter calculation internally.
|
||||
The coordinates of each vertex are specified as its x,y,z displacement
|
||||
from the center-of-mass of the body particle. The center-of-mass
|
||||
position of the particle is specified by the x,y,z values in the
|
||||
{Atoms} section of the data file.
|
||||
|
||||
For example, the following information would specify a cubic particle
|
||||
whose edge length is 2.0 and rounded diameter is 0.5.
|
||||
The orientation of the cube is aligned with the xyz coordinate axes
|
||||
which is consistent with the 6 moments of inertia: ixx iyy izz ixy ixz
|
||||
iyz = 0.667 0.667 0.667 0 0 0.
|
||||
|
||||
1 3 79
|
||||
8 12 6
|
||||
0.667 0.667 0.667 0 0 0
|
||||
1 1 1
|
||||
1 -1 1
|
||||
-1 -1 1
|
||||
-1 1 1
|
||||
1 1 -1
|
||||
1 -1 -1
|
||||
-1 -1 -1
|
||||
-1 1 -1
|
||||
0 1
|
||||
1 2
|
||||
2 3
|
||||
3 0
|
||||
4 5
|
||||
5 6
|
||||
6 7
|
||||
7 4
|
||||
0 4
|
||||
1 5
|
||||
2 6
|
||||
3 7
|
||||
0 1 2 3
|
||||
4 5 6 7
|
||||
0 1 5 4
|
||||
1 2 6 5
|
||||
2 3 7 6
|
||||
3 0 4 7
|
||||
0.5 :pre
|
||||
|
||||
A rod in 3D, whose length is 4.0, mass 1.0 and rounded at two ends
|
||||
by circles of diameter 0.5, is specified as follows:
|
||||
|
||||
1 1 13
|
||||
2
|
||||
0 1.33333 1.33333 0 0 0
|
||||
-2 0 0
|
||||
2 0 0
|
||||
0.5 :pre
|
||||
|
||||
A sphere whose diameter is 3.0 and mass 1.0, is specified as follows:
|
||||
|
||||
1 1 10
|
||||
1
|
||||
0.9 0.9 0.9 0 0 0
|
||||
0 0 0
|
||||
3.0 :pre
|
||||
|
||||
The "pair_style
|
||||
body/rounded/polhedron"_pair_body_rounded_polyhedron.html command can
|
||||
be used with this body style to compute body/body interactions. The
|
||||
"fix wall/body/polyhedron"_fix_wall_body_polygon.html command can be
|
||||
used with this body style to compute the interaction of body particles
|
||||
with a wall.
|
||||
|
||||
:line
|
||||
|
||||
For output purposes via the "compute
|
||||
body/local"_compute_body_local.html and "dump local"_dump.html
|
||||
commands, this body style produces one datum for each of the N
|
||||
sub-particles in a body particle. The datum has 3 values:
|
||||
|
||||
1 = x position of vertex
|
||||
2 = y position of vertex
|
||||
3 = z position of vertex :pre
|
||||
|
||||
These values are the current position of the vertex within the
|
||||
simulation domain, not a displacement from the center-of-mass (COM) of
|
||||
the body particle itself. These values are calculated using the
|
||||
current COM and orientation of the body particle.
|
||||
|
||||
For images created by the "dump image"_dump_image.html command, if the
|
||||
{body} keyword is set, then each body particle is drawn as a polygon
|
||||
consisting of N line segments. Note that the line segments are drawn
|
||||
between the N vertices, which does not correspond exactly to the
|
||||
physical extent of the body (because the "pair_style
|
||||
rounded/polygon"_pair_body_rounded_polygon.html defines finite-size
|
||||
spheres at those point and the line segments between the spheres are
|
||||
tangent to the spheres). The drawn diameter of each line segment is
|
||||
determined by the {bflag1} parameter for the {body} keyword. The
|
||||
{bflag2} argument is ignored.
|
||||
|
||||
:line
|
||||
|
||||
:link(body-Fraige)
|
||||
[(Fraige)] F. Y. Fraige, P. A. Langston, A. J. Matchett, J. Dodds,
|
||||
Particuology, 6, 455 (2008).
|
||||
|
||||
:link(body-Wang)
|
||||
[(Wang)] J. Wang, H. S. Yu, P. A. Langston, F. Y. Fraige, Granular
|
||||
Matter, 13, 1 (2011).
|
||||
|
|
@ -0,0 +1,166 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Use chunks to calculate system properties :h3
|
||||
|
||||
In LAMMS, "chunks" are collections of atoms, as defined by the
|
||||
"compute chunk/atom"_compute_chunk_atom.html command, which assigns
|
||||
each atom to a chunk ID (or to no chunk at all). The number of chunks
|
||||
and the assignment of chunk IDs to atoms can be static or change over
|
||||
time. Examples of "chunks" are molecules or spatial bins or atoms
|
||||
with similar values (e.g. coordination number or potential energy).
|
||||
|
||||
The per-atom chunk IDs can be used as input to two other kinds of
|
||||
commands, to calculate various properties of a system:
|
||||
|
||||
"fix ave/chunk"_fix_ave_chunk.html
|
||||
any of the "compute */chunk"_compute.html commands :ul
|
||||
|
||||
Here, each of the 3 kinds of chunk-related commands is briefly
|
||||
overviewed. Then some examples are given of how to compute different
|
||||
properties with chunk commands.
|
||||
|
||||
Compute chunk/atom command: :h4
|
||||
|
||||
This compute can assign atoms to chunks of various styles. Only atoms
|
||||
in the specified group and optional specified region are assigned to a
|
||||
chunk. Here are some possible chunk definitions:
|
||||
|
||||
atoms in same molecule | chunk ID = molecule ID |
|
||||
atoms of same atom type | chunk ID = atom type |
|
||||
all atoms with same atom property (charge, radius, etc) | chunk ID = output of compute property/atom |
|
||||
atoms in same cluster | chunk ID = output of "compute cluster/atom"_compute_cluster_atom.html command |
|
||||
atoms in same spatial bin | chunk ID = bin ID |
|
||||
atoms in same rigid body | chunk ID = molecule ID used to define rigid bodies |
|
||||
atoms with similar potential energy | chunk ID = output of "compute pe/atom"_compute_pe_atom.html |
|
||||
atoms with same local defect structure | chunk ID = output of "compute centro/atom"_compute_centro_atom.html or "compute coord/atom"_compute_coord_atom.html command :tb(s=|,c=2)
|
||||
|
||||
Note that chunk IDs are integer values, so for atom properties or
|
||||
computes that produce a floating point value, they will be truncated
|
||||
to an integer. You could also use the compute in a variable that
|
||||
scales the floating point value to spread it across multiple integers.
|
||||
|
||||
Spatial bins can be of various kinds, e.g. 1d bins = slabs, 2d bins =
|
||||
pencils, 3d bins = boxes, spherical bins, cylindrical bins.
|
||||
|
||||
This compute also calculates the number of chunks {Nchunk}, which is
|
||||
used by other commands to tally per-chunk data. {Nchunk} can be a
|
||||
static value or change over time (e.g. the number of clusters). The
|
||||
chunk ID for an individual atom can also be static (e.g. a molecule
|
||||
ID), or dynamic (e.g. what spatial bin an atom is in as it moves).
|
||||
|
||||
Note that this compute allows the per-atom output of other
|
||||
"computes"_compute.html, "fixes"_fix.html, and
|
||||
"variables"_variable.html to be used to define chunk IDs for each
|
||||
atom. This means you can write your own compute or fix to output a
|
||||
per-atom quantity to use as chunk ID. See the "Modify"_Modify.html
|
||||
doc pages for info on how to do this. You can also define a "per-atom
|
||||
variable"_variable.html in the input script that uses a formula to
|
||||
generate a chunk ID for each atom.
|
||||
|
||||
Fix ave/chunk command: :h4
|
||||
|
||||
This fix takes the ID of a "compute
|
||||
chunk/atom"_compute_chunk_atom.html command as input. For each chunk,
|
||||
it then sums one or more specified per-atom values over the atoms in
|
||||
each chunk. The per-atom values can be any atom property, such as
|
||||
velocity, force, charge, potential energy, kinetic energy, stress,
|
||||
etc. Additional keywords are defined for per-chunk properties like
|
||||
density and temperature. More generally any per-atom value generated
|
||||
by other "computes"_compute.html, "fixes"_fix.html, and "per-atom
|
||||
variables"_variable.html, can be summed over atoms in each chunk.
|
||||
|
||||
Similar to other averaging fixes, this fix allows the summed per-chunk
|
||||
values to be time-averaged in various ways, and output to a file. The
|
||||
fix produces a global array as output with one row of values per
|
||||
chunk.
|
||||
|
||||
Compute */chunk commands: :h4
|
||||
|
||||
Currently the following computes operate on chunks of atoms to produce
|
||||
per-chunk values.
|
||||
|
||||
"compute com/chunk"_compute_com_chunk.html
|
||||
"compute gyration/chunk"_compute_gyration_chunk.html
|
||||
"compute inertia/chunk"_compute_inertia_chunk.html
|
||||
"compute msd/chunk"_compute_msd_chunk.html
|
||||
"compute property/chunk"_compute_property_chunk.html
|
||||
"compute temp/chunk"_compute_temp_chunk.html
|
||||
"compute torque/chunk"_compute_vcm_chunk.html
|
||||
"compute vcm/chunk"_compute_vcm_chunk.html :ul
|
||||
|
||||
They each take the ID of a "compute
|
||||
chunk/atom"_compute_chunk_atom.html command as input. As their names
|
||||
indicate, they calculate the center-of-mass, radius of gyration,
|
||||
moments of inertia, mean-squared displacement, temperature, torque,
|
||||
and velocity of center-of-mass for each chunk of atoms. The "compute
|
||||
property/chunk"_compute_property_chunk.html command can tally the
|
||||
count of atoms in each chunk and extract other per-chunk properties.
|
||||
|
||||
The reason these various calculations are not part of the "fix
|
||||
ave/chunk command"_fix_ave_chunk.html, is that each requires a more
|
||||
complicated operation than simply summing and averaging over per-atom
|
||||
values in each chunk. For example, many of them require calculation
|
||||
of a center of mass, which requires summing mass*position over the
|
||||
atoms and then dividing by summed mass.
|
||||
|
||||
All of these computes produce a global vector or global array as
|
||||
output, wih one or more values per chunk. They can be used
|
||||
in various ways:
|
||||
|
||||
As input to the "fix ave/time"_fix_ave_time.html command, which can
|
||||
write the values to a file and optionally time average them. :ulb,l
|
||||
|
||||
As input to the "fix ave/histo"_fix_ave_histo.html command to
|
||||
histogram values across chunks. E.g. a histogram of cluster sizes or
|
||||
molecule diffusion rates. :l
|
||||
|
||||
As input to special functions of "equal-style
|
||||
variables"_variable.html, like sum() and max(). E.g. to find the
|
||||
largest cluster or fastest diffusing molecule. :l
|
||||
:ule
|
||||
|
||||
Example calculations with chunks :h4
|
||||
|
||||
Here are examples using chunk commands to calculate various
|
||||
properties:
|
||||
|
||||
(1) Average velocity in each of 1000 2d spatial bins:
|
||||
|
||||
compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.01 units reduced
|
||||
fix 1 all ave/chunk 100 10 1000 cc1 vx vy file tmp.out :pre
|
||||
|
||||
(2) Temperature in each spatial bin, after subtracting a flow
|
||||
velocity:
|
||||
|
||||
compute cc1 all chunk/atom bin/2d x 0.0 0.1 y lower 0.1 units reduced
|
||||
compute vbias all temp/profile 1 0 0 y 10
|
||||
fix 1 all ave/chunk 100 10 1000 cc1 temp bias vbias file tmp.out :pre
|
||||
|
||||
(3) Center of mass of each molecule:
|
||||
|
||||
compute cc1 all chunk/atom molecule
|
||||
compute myChunk all com/chunk cc1
|
||||
fix 1 all ave/time 100 1 100 c_myChunk\[*\] file tmp.out mode vector :pre
|
||||
|
||||
(4) Total force on each molecule and ave/max across all molecules:
|
||||
|
||||
compute cc1 all chunk/atom molecule
|
||||
fix 1 all ave/chunk 1000 1 1000 cc1 fx fy fz file tmp.out
|
||||
variable xave equal ave(f_1\[2\])
|
||||
variable xmax equal max(f_1\[2\])
|
||||
thermo 1000
|
||||
thermo_style custom step temp v_xave v_xmax :pre
|
||||
|
||||
(5) Histogram of cluster sizes:
|
||||
|
||||
compute cluster all cluster/atom 1.0
|
||||
compute cc1 all chunk/atom c_cluster compress yes
|
||||
compute size all property/chunk cc1 count
|
||||
fix 1 all ave/histo 100 1 100 0 20 20 c_size mode vector ave running beyond ignore file tmp.histo :pre
|
||||
|
|
@ -0,0 +1,253 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Adiabatic core/shell model :h3
|
||||
|
||||
The adiabatic core-shell model by "Mitchell and
|
||||
Fincham"_#MitchellFincham is a simple method for adding polarizability
|
||||
to a system. In order to mimic the electron shell of an ion, a
|
||||
satellite particle is attached to it. This way the ions are split into
|
||||
a core and a shell where the latter is meant to react to the
|
||||
electrostatic environment inducing polarizability. See the "Howto
|
||||
polarizable"_Howto_polarizable.html doc page for a discussion of all
|
||||
the polarizable models available in LAMMPS.
|
||||
|
||||
Technically, shells are attached to the cores by a spring force f =
|
||||
k*r where k is a parametrized spring constant and r is the distance
|
||||
between the core and the shell. The charges of the core and the shell
|
||||
add up to the ion charge, thus q(ion) = q(core) + q(shell). This
|
||||
setup introduces the ion polarizability (alpha) given by
|
||||
alpha = q(shell)^2 / k. In a
|
||||
similar fashion the mass of the ion is distributed on the core and the
|
||||
shell with the core having the larger mass.
|
||||
|
||||
To run this model in LAMMPS, "atom_style"_atom_style.html {full} can
|
||||
be used since atom charge and bonds are needed. Each kind of
|
||||
core/shell pair requires two atom types and a bond type. The core and
|
||||
shell of a core/shell pair should be bonded to each other with a
|
||||
harmonic bond that provides the spring force. For example, a data file
|
||||
for NaCl, as found in examples/coreshell, has this format:
|
||||
|
||||
432 atoms # core and shell atoms
|
||||
216 bonds # number of core/shell springs :pre
|
||||
|
||||
4 atom types # 2 cores and 2 shells for Na and Cl
|
||||
2 bond types :pre
|
||||
|
||||
0.0 24.09597 xlo xhi
|
||||
0.0 24.09597 ylo yhi
|
||||
0.0 24.09597 zlo zhi :pre
|
||||
|
||||
Masses # core/shell mass ratio = 0.1 :pre
|
||||
|
||||
1 20.690784 # Na core
|
||||
2 31.90500 # Cl core
|
||||
3 2.298976 # Na shell
|
||||
4 3.54500 # Cl shell :pre
|
||||
|
||||
Atoms :pre
|
||||
|
||||
1 1 2 1.5005 0.00000000 0.00000000 0.00000000 # core of core/shell pair 1
|
||||
2 1 4 -2.5005 0.00000000 0.00000000 0.00000000 # shell of core/shell pair 1
|
||||
3 2 1 1.5056 4.01599500 4.01599500 4.01599500 # core of core/shell pair 2
|
||||
4 2 3 -0.5056 4.01599500 4.01599500 4.01599500 # shell of core/shell pair 2
|
||||
(...) :pre
|
||||
|
||||
Bonds # Bond topology for spring forces :pre
|
||||
|
||||
1 2 1 2 # spring for core/shell pair 1
|
||||
2 2 3 4 # spring for core/shell pair 2
|
||||
(...) :pre
|
||||
|
||||
Non-Coulombic (e.g. Lennard-Jones) pairwise interactions are only
|
||||
defined between the shells. Coulombic interactions are defined
|
||||
between all cores and shells. If desired, additional bonds can be
|
||||
specified between cores.
|
||||
|
||||
The "special_bonds"_special_bonds.html command should be used to
|
||||
turn-off the Coulombic interaction within core/shell pairs, since that
|
||||
interaction is set by the bond spring. This is done using the
|
||||
"special_bonds"_special_bonds.html command with a 1-2 weight = 0.0,
|
||||
which is the default value. It needs to be considered whether one has
|
||||
to adjust the "special_bonds"_special_bonds.html weighting according
|
||||
to the molecular topology since the interactions of the shells are
|
||||
bypassed over an extra bond.
|
||||
|
||||
Note that this core/shell implementation does not require all ions to
|
||||
be polarized. One can mix core/shell pairs and ions without a
|
||||
satellite particle if desired.
|
||||
|
||||
Since the core/shell model permits distances of r = 0.0 between the
|
||||
core and shell, a pair style with a "cs" suffix needs to be used to
|
||||
implement a valid long-range Coulombic correction. Several such pair
|
||||
styles are provided in the CORESHELL package. See "this doc
|
||||
page"_pair_cs.html for details. All of the core/shell enabled pair
|
||||
styles require the use of a long-range Coulombic solver, as specified
|
||||
by the "kspace_style"_kspace_style.html command. Either the PPPM or
|
||||
Ewald solvers can be used.
|
||||
|
||||
For the NaCL example problem, these pair style and bond style settings
|
||||
are used:
|
||||
|
||||
pair_style born/coul/long/cs 20.0 20.0
|
||||
pair_coeff * * 0.0 1.000 0.00 0.00 0.00
|
||||
pair_coeff 3 3 487.0 0.23768 0.00 1.05 0.50 #Na-Na
|
||||
pair_coeff 3 4 145134.0 0.23768 0.00 6.99 8.70 #Na-Cl
|
||||
pair_coeff 4 4 405774.0 0.23768 0.00 72.40 145.40 #Cl-Cl :pre
|
||||
|
||||
bond_style harmonic
|
||||
bond_coeff 1 63.014 0.0
|
||||
bond_coeff 2 25.724 0.0 :pre
|
||||
|
||||
When running dynamics with the adiabatic core/shell model, the
|
||||
following issues should be considered. The relative motion of
|
||||
the core and shell particles corresponds to the polarization,
|
||||
hereby an instantaneous relaxation of the shells is approximated
|
||||
and a fast core/shell spring frequency ensures a nearly constant
|
||||
internal kinetic energy during the simulation.
|
||||
Thermostats can alter this polarization behaviour, by scaling the
|
||||
internal kinetic energy, meaning the shell will not react freely to
|
||||
its electrostatic environment.
|
||||
Therefore it is typically desirable to decouple the relative motion of
|
||||
the core/shell pair, which is an imaginary degree of freedom, from the
|
||||
real physical system. To do that, the "compute
|
||||
temp/cs"_compute_temp_cs.html command can be used, in conjunction with
|
||||
any of the thermostat fixes, such as "fix nvt"_fix_nh.html or "fix
|
||||
langevin"_fix_langevin. This compute uses the center-of-mass velocity
|
||||
of the core/shell pairs to calculate a temperature, and insures that
|
||||
velocity is what is rescaled for thermostatting purposes. This
|
||||
compute also works for a system with both core/shell pairs and
|
||||
non-polarized ions (ions without an attached satellite particle). The
|
||||
"compute temp/cs"_compute_temp_cs.html command requires input of two
|
||||
groups, one for the core atoms, another for the shell atoms.
|
||||
Non-polarized ions which might also be included in the treated system
|
||||
should not be included into either of these groups, they are taken
|
||||
into account by the {group-ID} (2nd argument) of the compute. The
|
||||
groups can be defined using the "group {type}"_group.html command.
|
||||
Note that to perform thermostatting using this definition of
|
||||
temperature, the "fix modify temp"_fix_modify.html command should be
|
||||
used to assign the compute to the thermostat fix. Likewise the
|
||||
"thermo_modify temp"_thermo_modify.html command can be used to make
|
||||
this temperature be output for the overall system.
|
||||
|
||||
For the NaCl example, this can be done as follows:
|
||||
|
||||
group cores type 1 2
|
||||
group shells type 3 4
|
||||
compute CSequ all temp/cs cores shells
|
||||
fix thermoberendsen all temp/berendsen 1427 1427 0.4 # thermostat for the true physical system
|
||||
fix thermostatequ all nve # integrator as needed for the berendsen thermostat
|
||||
fix_modify thermoberendsen temp CSequ
|
||||
thermo_modify temp CSequ # output of center-of-mass derived temperature :pre
|
||||
|
||||
The pressure for the core/shell system is computed via the regular
|
||||
LAMMPS convention by "treating the cores and shells as individual
|
||||
particles"_#MitchellFincham2. For the thermo output of the pressure
|
||||
as well as for the application of a barostat, it is necessary to
|
||||
use an additional "pressure"_compute_pressure compute based on the
|
||||
default "temperature"_compute_temp and specifying it as a second
|
||||
argument in "fix modify"_fix_modify.html and
|
||||
"thermo_modify"_thermo_modify.html resulting in:
|
||||
|
||||
(...)
|
||||
compute CSequ all temp/cs cores shells
|
||||
compute thermo_press_lmp all pressure thermo_temp # pressure for individual particles
|
||||
thermo_modify temp CSequ press thermo_press_lmp # modify thermo to regular pressure
|
||||
fix press_bar all npt temp 300 300 0.04 iso 0 0 0.4
|
||||
fix_modify press_bar temp CSequ press thermo_press_lmp # pressure modification for correct kinetic scalar :pre
|
||||
|
||||
If "compute temp/cs"_compute_temp_cs.html is used, the decoupled
|
||||
relative motion of the core and the shell should in theory be
|
||||
stable. However numerical fluctuation can introduce a small
|
||||
momentum to the system, which is noticable over long trajectories.
|
||||
Therefore it is recommendable to use the "fix
|
||||
momentum"_fix_momentum.html command in combination with "compute
|
||||
temp/cs"_compute_temp_cs.html when equilibrating the system to
|
||||
prevent any drift.
|
||||
|
||||
When initializing the velocities of a system with core/shell pairs, it
|
||||
is also desirable to not introduce energy into the relative motion of
|
||||
the core/shell particles, but only assign a center-of-mass velocity to
|
||||
the pairs. This can be done by using the {bias} keyword of the
|
||||
"velocity create"_velocity.html command and assigning the "compute
|
||||
temp/cs"_compute_temp_cs.html command to the {temp} keyword of the
|
||||
"velocity"_velocity.html command, e.g.
|
||||
|
||||
velocity all create 1427 134 bias yes temp CSequ
|
||||
velocity all scale 1427 temp CSequ :pre
|
||||
|
||||
To maintain the correct polarizability of the core/shell pairs, the
|
||||
kinetic energy of the internal motion shall remain nearly constant.
|
||||
Therefore the choice of spring force and mass ratio need to ensure
|
||||
much faster relative motion of the 2 atoms within the core/shell pair
|
||||
than their center-of-mass velocity. This allows the shells to
|
||||
effectively react instantaneously to the electrostatic environment and
|
||||
limits energy transfer to or from the core/shell oscillators.
|
||||
This fast movement also dictates the timestep that can be used.
|
||||
|
||||
The primary literature of the adiabatic core/shell model suggests that
|
||||
the fast relative motion of the core/shell pairs only allows negligible
|
||||
energy transfer to the environment.
|
||||
The mentioned energy transfer will typically lead to a small drift
|
||||
in total energy over time. This internal energy can be monitored
|
||||
using the "compute chunk/atom"_compute_chunk_atom.html and "compute
|
||||
temp/chunk"_compute_temp_chunk.html commands. The internal kinetic
|
||||
energies of each core/shell pair can then be summed using the sum()
|
||||
special function of the "variable"_variable.html command. Or they can
|
||||
be time/averaged and output using the "fix ave/time"_fix_ave_time.html
|
||||
command. To use these commands, each core/shell pair must be defined
|
||||
as a "chunk". If each core/shell pair is defined as its own molecule,
|
||||
the molecule ID can be used to define the chunks. If cores are bonded
|
||||
to each other to form larger molecules, the chunks can be identified
|
||||
by the "fix property/atom"_fix_property_atom.html via assigning a
|
||||
core/shell ID to each atom using a special field in the data file read
|
||||
by the "read_data"_read_data.html command. This field can then be
|
||||
accessed by the "compute property/atom"_compute_property_atom.html
|
||||
command, to use as input to the "compute
|
||||
chunk/atom"_compute_chunk_atom.html command to define the core/shell
|
||||
pairs as chunks.
|
||||
|
||||
For example if core/shell pairs are the only molecules:
|
||||
|
||||
read_data NaCl_CS_x0.1_prop.data
|
||||
compute prop all property/atom molecule
|
||||
compute cs_chunk all chunk/atom c_prop
|
||||
compute cstherm all temp/chunk cs_chunk temp internal com yes cdof 3.0 # note the chosen degrees of freedom for the core/shell pairs
|
||||
fix ave_chunk all ave/time 10 1 10 c_cstherm file chunk.dump mode vector :pre
|
||||
|
||||
For example if core/shell pairs and other molecules are present:
|
||||
|
||||
fix csinfo all property/atom i_CSID # property/atom command
|
||||
read_data NaCl_CS_x0.1_prop.data fix csinfo NULL CS-Info # atom property added in the data-file
|
||||
compute prop all property/atom i_CSID
|
||||
(...) :pre
|
||||
|
||||
The additional section in the date file would be formatted like this:
|
||||
|
||||
CS-Info # header of additional section :pre
|
||||
|
||||
1 1 # column 1 = atom ID, column 2 = core/shell ID
|
||||
2 1
|
||||
3 2
|
||||
4 2
|
||||
5 3
|
||||
6 3
|
||||
7 4
|
||||
8 4
|
||||
(...) :pre
|
||||
|
||||
:line
|
||||
|
||||
:link(MitchellFincham)
|
||||
[(Mitchell and Fincham)] Mitchell, Fincham, J Phys Condensed Matter,
|
||||
5, 1031-1038 (1993).
|
||||
|
||||
:link(MitchellFincham2)
|
||||
[(Fincham)] Fincham, Mackrodt and Mitchell, J Phys Condensed Matter,
|
||||
6, 393-404 (1994).
|
||||
|
|
@ -0,0 +1,105 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Coupling LAMMPS to other codes :h3
|
||||
|
||||
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 the
|
||||
"Modify"_Modify.html doc pages 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 the "Modify command"_Modify_command.html doc page for info on 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.
|
||||
|
||||
Examples of driver codes that call LAMMPS as a library are included in
|
||||
the examples/COUPLE directory of the LAMMPS distribution; see
|
||||
examples/COUPLE/README for more details:
|
||||
|
||||
simple: simple driver programs in C++ and C which invoke LAMMPS as a
|
||||
library :ulb,l
|
||||
|
||||
lammps_quest: coupling of LAMMPS and "Quest"_quest, to run classical
|
||||
MD with quantum forces calculated by a density functional code :l
|
||||
|
||||
lammps_spparks: coupling of LAMMPS and "SPPARKS"_spparks, to couple
|
||||
a kinetic Monte Carlo model for grain growth using MD to calculate
|
||||
strain induced across grain boundaries :l
|
||||
:ule
|
||||
|
||||
:link(quest,http://dft.sandia.gov/Quest)
|
||||
:link(spparks,http://www.sandia.gov/~sjplimp/spparks.html)
|
||||
|
||||
"This section"_Section_start.html#start_5 of the documentation
|
||||
describes how to build LAMMPS as a library. Once this is done, you
|
||||
can interface with LAMMPS either via C++, C, Fortran, or Python (or
|
||||
any other language that supports a vanilla C-like interface). 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. See the
|
||||
"Python"_Python.html doc pages for a description of the Python wrapper
|
||||
provided with LAMMPS that operates through the LAMMPS library
|
||||
interface.
|
||||
|
||||
The files src/library.cpp and library.h contain the C-style interface
|
||||
to LAMMPS. See the "Howto library"_Howto_library.html doc page for a
|
||||
description of the interface and how to extend it for your needs.
|
||||
|
||||
Note that the lammps_open() function that creates an instance of
|
||||
LAMMPS takes an MPI communicator as an argument. This means that
|
||||
instance of LAMMPS will run on the set of processors in the
|
||||
communicator. Thus 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. Or it might instantiate multiple
|
||||
instances of LAMMPS to perform different calculations.
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Calculate a diffusion coefficient :h3
|
||||
|
||||
The diffusion coefficient D of a material can be measured in at least
|
||||
2 ways using various options in LAMMPS. See the examples/DIFFUSE
|
||||
directory for scripts that implement the 2 methods discussed here for
|
||||
a simple Lennard-Jones fluid model.
|
||||
|
||||
The first method is to measure the mean-squared displacement (MSD) of
|
||||
the system, via the "compute msd"_compute_msd.html command. The slope
|
||||
of the MSD versus time is proportional to the diffusion coefficient.
|
||||
The instantaneous MSD values can be accumulated in a vector via the
|
||||
"fix vector"_fix_vector.html command, and a line fit to the vector to
|
||||
compute its slope via the "variable slope"_variable.html function, and
|
||||
thus extract D.
|
||||
|
||||
The second method is to measure the velocity auto-correlation function
|
||||
(VACF) of the system, via the "compute vacf"_compute_vacf.html
|
||||
command. The time-integral of the VACF is proportional to the
|
||||
diffusion coefficient. The instantaneous VACF values can be
|
||||
accumulated in a vector via the "fix vector"_fix_vector.html command,
|
||||
and time integrated via the "variable trap"_variable.html function,
|
||||
and thus extract D.
|
||||
|
|
@ -0,0 +1,108 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Long-raage dispersion settings :h3
|
||||
|
||||
The PPPM method computes interactions by splitting the pair potential
|
||||
into two parts, one of which is computed in a normal pairwise fashion,
|
||||
the so-called real-space part, and one of which is computed using the
|
||||
Fourier transform, the so called reciprocal-space or kspace part. For
|
||||
both parts, the potential is not computed exactly but is approximated.
|
||||
Thus, there is an error in both parts of the computation, the
|
||||
real-space and the kspace error. The just mentioned facts are true
|
||||
both for the PPPM for Coulomb as well as dispersion interactions. The
|
||||
deciding difference - and also the reason why the parameters for
|
||||
pppm/disp have to be selected with more care - is the impact of the
|
||||
errors on the results: The kspace error of the PPPM for Coulomb and
|
||||
dispersion interaction and the real-space error of the PPPM for
|
||||
Coulomb interaction have the character of noise. In contrast, the
|
||||
real-space error of the PPPM for dispersion has a clear physical
|
||||
interpretation: the underprediction of cohesion. As a consequence, the
|
||||
real-space error has a much stronger effect than the kspace error on
|
||||
simulation results for pppm/disp. Parameters must thus be chosen in a
|
||||
way that this error is much smaller than the kspace error.
|
||||
|
||||
When using pppm/disp and not making any specifications on the PPPM
|
||||
parameters via the kspace modify command, parameters will be tuned
|
||||
such that the real-space error and the kspace error are equal. This
|
||||
will result in simulations that are either inaccurate or slow, both of
|
||||
which is not desirable. For selecting parameters for the pppm/disp
|
||||
that provide fast and accurate simulations, there are two approaches,
|
||||
which both have their up- and downsides.
|
||||
|
||||
The first approach is to set desired real-space an kspace accuracies
|
||||
via the {kspace_modify force/disp/real} and {kspace_modify
|
||||
force/disp/kspace} commands. Note that the accuracies have to be
|
||||
specified in force units and are thus dependent on the chosen unit
|
||||
settings. For real units, 0.0001 and 0.002 seem to provide reasonable
|
||||
accurate and efficient computations for the real-space and kspace
|
||||
accuracies. 0.002 and 0.05 work well for most systems using lj
|
||||
units. PPPM parameters will be generated based on the desired
|
||||
accuracies. The upside of this approach is that it usually provides a
|
||||
good set of parameters and will work for both the {kspace_modify diff
|
||||
ad} and {kspace_modify diff ik} options. The downside of the method
|
||||
is that setting the PPPM parameters will take some time during the
|
||||
initialization of the simulation.
|
||||
|
||||
The second approach is to set the parameters for the pppm/disp
|
||||
explicitly using the {kspace_modify mesh/disp}, {kspace_modify
|
||||
order/disp}, and {kspace_modify gewald/disp} commands. This approach
|
||||
requires a more experienced user who understands well the impact of
|
||||
the choice of parameters on the simulation accuracy and
|
||||
performance. This approach provides a fast initialization of the
|
||||
simulation. However, it is sensitive to errors: A combination of
|
||||
parameters that will perform well for one system might result in
|
||||
far-from-optimal conditions for other simulations. For example,
|
||||
parameters that provide accurate and fast computations for
|
||||
all-atomistic force fields can provide insufficient accuracy or
|
||||
united-atomistic force fields (which is related to that the latter
|
||||
typically have larger dispersion coefficients).
|
||||
|
||||
To avoid inaccurate or inefficient simulations, the pppm/disp stops
|
||||
simulations with an error message if no action is taken to control the
|
||||
PPPM parameters. If the automatic parameter generation is desired and
|
||||
real-space and kspace accuracies are desired to be equal, this error
|
||||
message can be suppressed using the {kspace_modify disp/auto yes}
|
||||
command.
|
||||
|
||||
A reasonable approach that combines the upsides of both methods is to
|
||||
make the first run using the {kspace_modify force/disp/real} and
|
||||
{kspace_modify force/disp/kspace} commands, write down the PPPM
|
||||
parameters from the outut, and specify these parameters using the
|
||||
second approach in subsequent runs (which have the same composition,
|
||||
force field, and approximately the same volume).
|
||||
|
||||
Concerning the performance of the pppm/disp there are two more things
|
||||
to consider. The first is that when using the pppm/disp, the cutoff
|
||||
parameter does no longer affect the accuracy of the simulation
|
||||
(subject to that gewald/disp is adjusted when changing the cutoff).
|
||||
The performance can thus be increased by examining different values
|
||||
for the cutoff parameter. A lower bound for the cutoff is only set by
|
||||
the truncation error of the repulsive term of pair potentials.
|
||||
|
||||
The second is that the mixing rule of the pair style has an impact on
|
||||
the computation time when using the pppm/disp. Fastest computations
|
||||
are achieved when using the geometric mixing rule. Using the
|
||||
arithmetic mixing rule substantially increases the computational cost.
|
||||
The computational overhead can be reduced using the {kspace_modify
|
||||
mix/disp geom} and {kspace_modify splittol} commands. The first
|
||||
command simply enforces geometric mixing of the dispersion
|
||||
coefficients in kspace computations. This introduces some error in
|
||||
the computations but will also significantly speed-up the
|
||||
simulations. The second keyword sets the accuracy with which the
|
||||
dispersion coefficients are approximated using a matrix factorization
|
||||
approach. This may result in better accuracy then using the first
|
||||
command, but will usually also not provide an equally good increase of
|
||||
efficiency.
|
||||
|
||||
Finally, pppm/disp can also be used when no mixing rules apply.
|
||||
This can be achieved using the {kspace_modify mix/disp none} command.
|
||||
Note that the code does not check automatically whether any mixing
|
||||
rule is fulfilled. If mixing rules do not apply, the user will have
|
||||
to specify this command explicitly.
|
||||
|
|
@ -0,0 +1,77 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Drude induced dipoles :h3
|
||||
|
||||
The thermalized Drude model represents induced dipoles by a pair of
|
||||
charges (the core atom and the Drude particle) connected by a harmonic
|
||||
spring. See the "Howto polarizable"_Howto_polarizable.html doc page
|
||||
for a discussion of all the polarizable models available in LAMMPS.
|
||||
|
||||
The Drude model has a number of features aimed at its use in
|
||||
molecular systems ("Lamoureux and Roux"_#howto-Lamoureux):
|
||||
|
||||
Thermostating of the additional degrees of freedom associated with the
|
||||
induced dipoles at very low temperature, in terms of the reduced
|
||||
coordinates of the Drude particles with respect to their cores. This
|
||||
makes the trajectory close to that of relaxed induced dipoles. :ulb,l
|
||||
|
||||
Consistent definition of 1-2 to 1-4 neighbors. A core-Drude particle
|
||||
pair represents a single (polarizable) atom, so the special screening
|
||||
factors in a covalent structure should be the same for the core and
|
||||
the Drude particle. Drude particles have to inherit the 1-2, 1-3, 1-4
|
||||
special neighbor relations from their respective cores. :l
|
||||
|
||||
Stabilization of the interactions between induced dipoles. Drude
|
||||
dipoles on covalently bonded atoms interact too strongly due to the
|
||||
short distances, so an atom may capture the Drude particle of a
|
||||
neighbor, or the induced dipoles within the same molecule may align
|
||||
too much. To avoid this, damping at short range can be done by Thole
|
||||
functions (for which there are physical grounds). This Thole damping
|
||||
is applied to the point charges composing the induced dipole (the
|
||||
charge of the Drude particle and the opposite charge on the core, not
|
||||
to the total charge of the core atom). :l,ule
|
||||
|
||||
A detailed tutorial covering the usage of Drude induced dipoles in
|
||||
LAMMPS is on the "Howto drude2e"_Howto_drude2.html doc page.
|
||||
|
||||
As with the core-shell model, the cores and Drude particles should
|
||||
appear in the data file as standard atoms. The same holds for the
|
||||
springs between them, which are described by standard harmonic bonds.
|
||||
The nature of the atoms (core, Drude particle or non-polarizable) is
|
||||
specified via the "fix drude"_fix_drude.html command. The special
|
||||
list of neighbors is automatically refactored to account for the
|
||||
equivalence of core and Drude particles as regards special 1-2 to 1-4
|
||||
screening. It may be necessary to use the {extra/special/per/atom}
|
||||
keyword of the "read_data"_read_data.html command. If using "fix
|
||||
shake"_fix_shake.html, make sure no Drude particle is in this fix
|
||||
group.
|
||||
|
||||
There are two ways to thermostat the Drude particles at a low
|
||||
temperature: use either "fix langevin/drude"_fix_langevin_drude.html
|
||||
for a Langevin thermostat, or "fix
|
||||
drude/transform/*"_fix_drude_transform.html for a Nose-Hoover
|
||||
thermostat. The former requires use of the command "comm_modify vel
|
||||
yes"_comm_modify.html. The latter requires two separate integration
|
||||
fixes like {nvt} or {npt}. The correct temperatures of the reduced
|
||||
degrees of freedom can be calculated using the "compute
|
||||
temp/drude"_compute_temp_drude.html. This requires also to use the
|
||||
command {comm_modify vel yes}.
|
||||
|
||||
Short-range damping of the induced dipole interactions can be achieved
|
||||
using Thole functions through the "pair style
|
||||
thole"_pair_thole.html in "pair_style hybrid/overlay"_pair_hybrid.html
|
||||
with a Coulomb pair style. It may be useful to use {coul/long/cs} or
|
||||
similar from the CORESHELL package if the core and Drude particle come
|
||||
too close, which can cause numerical issues.
|
||||
|
||||
:line
|
||||
|
||||
:link(howto-Lamoureux)
|
||||
[(Lamoureux and Roux)] G. Lamoureux, B. Roux, J. Chem. Phys 119, 3025 (2003)
|
||||
|
|
@ -0,0 +1,47 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Calculate elastic constants :h3
|
||||
|
||||
Elastic constants characterize the stiffness of a material. The formal
|
||||
definition is provided by the linear relation that holds between the
|
||||
stress and strain tensors in the limit of infinitesimal deformation.
|
||||
In tensor notation, this is expressed as s_ij = C_ijkl * e_kl, where
|
||||
the repeated indices imply summation. s_ij are the elements of the
|
||||
symmetric stress tensor. e_kl are the elements of the symmetric strain
|
||||
tensor. C_ijkl are the elements of the fourth rank tensor of elastic
|
||||
constants. In three dimensions, this tensor has 3^4=81 elements. Using
|
||||
Voigt notation, the tensor can be written as a 6x6 matrix, where C_ij
|
||||
is now the derivative of s_i w.r.t. e_j. Because s_i is itself a
|
||||
derivative w.r.t. e_i, it follows that C_ij is also symmetric, with at
|
||||
most 7*6/2 = 21 distinct elements.
|
||||
|
||||
At zero temperature, it is easy to estimate these derivatives by
|
||||
deforming the simulation box in one of the six directions using the
|
||||
"change_box"_change_box.html command and measuring the change in the
|
||||
stress tensor. A general-purpose script that does this is given in the
|
||||
examples/elastic directory described on the "Examples"_Examples.html
|
||||
doc page.
|
||||
|
||||
Calculating elastic constants at finite temperature is more
|
||||
challenging, because it is necessary to run a simulation that perfoms
|
||||
time averages of differential properties. One way to do this is to
|
||||
measure the change in average stress tensor in an NVT simulations when
|
||||
the cell volume undergoes a finite deformation. In order to balance
|
||||
the systematic and statistical errors in this method, the magnitude of
|
||||
the deformation must be chosen judiciously, and care must be taken to
|
||||
fully equilibrate the deformed cell before sampling the stress
|
||||
tensor. Another approach is to sample the triclinic cell fluctuations
|
||||
that occur in an NPT simulation. This method can also be slow to
|
||||
converge and requires careful post-processing "(Shinoda)"_#Shinoda1
|
||||
|
||||
:line
|
||||
|
||||
:link(Shinoda1)
|
||||
[(Shinoda)] Shinoda, Shiga, and Mikami, Phys Rev B, 69, 134103 (2004).
|
||||
|
|
@ -25,8 +25,8 @@ or improvements to LAMMPS, as it significantly reduces the amount of
|
|||
work required by the LAMMPS developers. Consequently, creating a pull
|
||||
request will increase your chances to have your contribution included
|
||||
and will reduce the time until the integration is complete. For more
|
||||
information on the requirements to have your code included in LAMMPS,
|
||||
see the "Modify contribute"_Modify_contribute.html doc page.
|
||||
information on the requirements to have your code included into LAMMPS
|
||||
please see the "Modify contribute"_Modify_contribute.html doc page.
|
||||
|
||||
:line
|
||||
|
||||
|
|
@ -124,7 +124,7 @@ unrelated feature, you should switch branches!
|
|||
|
||||
After everything is done, add the files to the branch and commit them:
|
||||
|
||||
$ git add doc/src/tutorial_github.txt
|
||||
$ git add doc/src/Howto_github.txt
|
||||
$ git add doc/src/JPG/tutorial*.png :pre
|
||||
|
||||
IMPORTANT NOTE: Do not use {git commit -a} (or {git add -A}). The -a
|
||||
|
|
@ -318,7 +318,7 @@ Because the changes are OK with us, we are going to merge by clicking on
|
|||
Now, since in the meantime our local text for the tutorial also changed,
|
||||
we need to pull Axel's change back into our branch, and merge them:
|
||||
|
||||
$ git add tutorial_github.txt
|
||||
$ git add Howto_github.txt
|
||||
$ git add JPG/tutorial_reverse_pull_request*.png
|
||||
$ git commit -m "Updated text and images on reverse pull requests"
|
||||
$ git pull :pre
|
||||
|
|
@ -331,7 +331,7 @@ With Axel's changes merged in and some final text updates, our feature
|
|||
branch is now perfect as far as we are concerned, so we are going to
|
||||
commit and push again:
|
||||
|
||||
$ git add tutorial_github.txt
|
||||
$ git add Howto_github.txt
|
||||
$ git add JPG/tutorial_reverse_pull_request6.png
|
||||
$ git commit -m "Merged Axel's suggestions and updated text"
|
||||
$ git push git@github.com:Pakketeretet2/lammps :pre
|
||||
|
|
@ -0,0 +1,57 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Granular models :h3
|
||||
|
||||
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 sphere"_atom_style.html
|
||||
"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"_Howto_output.html.
|
||||
|
||||
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
|
||||
|
||||
NOTE: By default, for 2d systems, granular particles are still modeled
|
||||
as 3d spheres, not 2d discs (circles), meaning their moment of inertia
|
||||
will be the same as in 3d. If you wish to model granular particles in
|
||||
2d as 2d discs, see the note on this topic on the "Howto 2d"_Howto_2d
|
||||
doc page, where 2d simulations are discussed.
|
||||
|
|
@ -0,0 +1,90 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Calculate thermal conductivity :h3
|
||||
|
||||
The thermal conductivity kappa of a material can be measured in at
|
||||
least 4 ways using various options in LAMMPS. See the examples/KAPPA
|
||||
directory for scripts that implement the 4 methods discussed here for
|
||||
a simple Lennard-Jones fluid model. Also, see the "Howto
|
||||
viscosity"_Howto_viscosity.html doc page for an analogous discussion
|
||||
for viscosity.
|
||||
|
||||
The thermal conductivity tensor kappa is a measure of the propensity
|
||||
of a material to transmit heat energy in a diffusive manner as given
|
||||
by Fourier's law
|
||||
|
||||
J = -kappa grad(T)
|
||||
|
||||
where J is the heat flux in units of energy per area per time and
|
||||
grad(T) is the spatial gradient of temperature. The thermal
|
||||
conductivity thus has units of energy per distance per time per degree
|
||||
K and is often approximated as an isotropic quantity, i.e. as a
|
||||
scalar.
|
||||
|
||||
The first method is to setup two thermostatted regions at opposite
|
||||
ends of a simulation box, or one in the middle and one at the end of a
|
||||
periodic box. By holding the two regions at different temperatures
|
||||
with a "thermostatting fix"_Howto_thermostat.html, the energy added to
|
||||
the hot region should equal the energy subtracted from the cold region
|
||||
and be proportional to the heat flux moving between the regions. See
|
||||
the papers by "Ikeshoji and Hafskjold"_#howto-Ikeshoji and
|
||||
"Wirnsberger et al"_#howto-Wirnsberger for details of this idea. Note
|
||||
that thermostatting fixes such as "fix nvt"_fix_nh.html, "fix
|
||||
langevin"_fix_langevin.html, and "fix
|
||||
temp/rescale"_fix_temp_rescale.html store the cumulative energy they
|
||||
add/subtract.
|
||||
|
||||
Alternatively, as a second method, the "fix heat"_fix_heat.html or
|
||||
"fix ehex"_fix_ehex.html commands can be used in place of thermostats
|
||||
on each of two regions to add/subtract specified amounts of energy to
|
||||
both regions. In both cases, the resulting temperatures of the two
|
||||
regions can be monitored with the "compute temp/region" command and
|
||||
the temperature profile of the intermediate region can be monitored
|
||||
with the "fix ave/chunk"_fix_ave_chunk.html and "compute
|
||||
ke/atom"_compute_ke_atom.html commands.
|
||||
|
||||
The third method is to perform a reverse non-equilibrium MD simulation
|
||||
using the "fix thermal/conductivity"_fix_thermal_conductivity.html
|
||||
command which implements the rNEMD algorithm of Muller-Plathe.
|
||||
Kinetic energy is swapped between atoms in two different layers of the
|
||||
simulation box. This induces a temperature gradient between the two
|
||||
layers which can be monitored with the "fix
|
||||
ave/chunk"_fix_ave_chunk.html and "compute
|
||||
ke/atom"_compute_ke_atom.html commands. The fix tallies the
|
||||
cumulative energy transfer that it performs. See the "fix
|
||||
thermal/conductivity"_fix_thermal_conductivity.html command for
|
||||
details.
|
||||
|
||||
The fourth method is based on the Green-Kubo (GK) formula which
|
||||
relates the ensemble average of the auto-correlation of the heat flux
|
||||
to kappa. The heat flux can be calculated from the fluctuations of
|
||||
per-atom potential and kinetic energies and per-atom stress tensor in
|
||||
a steady-state equilibrated simulation. This is in contrast to the
|
||||
two preceding non-equilibrium methods, where energy flows continuously
|
||||
between hot and cold regions of the simulation box.
|
||||
|
||||
The "compute heat/flux"_compute_heat_flux.html command can calculate
|
||||
the needed heat flux and describes how to implement the Green_Kubo
|
||||
formalism using additional LAMMPS commands, such as the "fix
|
||||
ave/correlate"_fix_ave_correlate.html command to calculate the needed
|
||||
auto-correlation. See the doc page for the "compute
|
||||
heat/flux"_compute_heat_flux.html command for an example input script
|
||||
that calculates the thermal conductivity of solid Ar via the GK
|
||||
formalism.
|
||||
|
||||
:line
|
||||
|
||||
:link(howto-Ikeshoji)
|
||||
[(Ikeshoji)] Ikeshoji and Hafskjold, Molecular Physics, 81, 251-261
|
||||
(1994).
|
||||
|
||||
:link(howto-Wirnsberger)
|
||||
[(Wirnsberger)] Wirnsberger, Frenkel, and Dellago, J Chem Phys, 143, 124104
|
||||
(2015).
|
||||
|
|
@ -0,0 +1,208 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Library interface to LAMMPS :h3
|
||||
|
||||
As described in "Section 2.5"_Section_start.html#start_5, LAMMPS can
|
||||
be built as a library, so that it can be called by another code, used
|
||||
in a "coupled manner"_Howto_couple.html with other codes, or driven
|
||||
through a "Python interface"_Python.html.
|
||||
|
||||
All of these methodologies use a C-style interface to LAMMPS that is
|
||||
provided in the files src/library.cpp and src/library.h. The
|
||||
functions therein have a C-style argument list, but contain C++ code
|
||||
you could write yourself in a C++ application that was invoking LAMMPS
|
||||
directly. The C++ code in the functions illustrates how to invoke
|
||||
internal LAMMPS operations. Note that LAMMPS classes are defined
|
||||
within a LAMMPS namespace (LAMMPS_NS) if you use them from another C++
|
||||
application.
|
||||
|
||||
The examples/COUPLE and python/examples directories have example C++
|
||||
and C and Python codes which show how a driver code can link to LAMMPS
|
||||
as a library, run LAMMPS on a subset of processors, grab data from
|
||||
LAMMPS, change it, and put it back into LAMMPS.
|
||||
|
||||
The file src/library.cpp contains the following functions for creating
|
||||
and destroying an instance of LAMMPS and sending it commands to
|
||||
execute. See the documentation in the src/library.cpp file for
|
||||
details.
|
||||
|
||||
NOTE: You can write code for additional functions as needed to define
|
||||
how your code talks to LAMMPS and add them to src/library.cpp and
|
||||
src/library.h, as well as to the "Python interface"_Python.html. The
|
||||
added functions can access or change any internal LAMMPS data you
|
||||
wish.
|
||||
|
||||
void lammps_open(int, char **, MPI_Comm, void **)
|
||||
void lammps_open_no_mpi(int, char **, void **)
|
||||
void lammps_close(void *)
|
||||
int lammps_version(void *)
|
||||
void lammps_file(void *, char *)
|
||||
char *lammps_command(void *, char *)
|
||||
void lammps_commands_list(void *, int, char **)
|
||||
void lammps_commands_string(void *, char *)
|
||||
void lammps_free(void *) :pre
|
||||
|
||||
The lammps_open() function is used to initialize LAMMPS, passing in a
|
||||
list of strings as if they were "command-line
|
||||
arguments"_Section_start.html#start_6 when LAMMPS is run in
|
||||
stand-alone mode from the command line, and a MPI communicator for
|
||||
LAMMPS to run under. It returns a ptr to the LAMMPS object that is
|
||||
created, and which is used in subsequent library calls. 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. Or it might instantiate multiple
|
||||
instances of LAMMPS to perform different calculations.
|
||||
|
||||
The lammps_open_no_mpi() function is similar except that no MPI
|
||||
communicator is passed from the caller. Instead, MPI_COMM_WORLD is
|
||||
used to instantiate LAMMPS, and MPI is initialized if necessary.
|
||||
|
||||
The lammps_close() function is used to shut down an instance of LAMMPS
|
||||
and free all its memory.
|
||||
|
||||
The lammps_version() function can be used to determined the specific
|
||||
version of the underlying LAMMPS code. This is particularly useful
|
||||
when loading LAMMPS as a shared library via dlopen(). The code using
|
||||
the library interface can than use this information to adapt to
|
||||
changes to the LAMMPS command syntax between versions. The returned
|
||||
LAMMPS version code is an integer (e.g. 2 Sep 2015 results in
|
||||
20150902) that grows with every new LAMMPS version.
|
||||
|
||||
The lammps_file(), lammps_command(), lammps_commands_list(), and
|
||||
lammps_commands_string() functions are used to pass one or more
|
||||
commands to LAMMPS to execute, the same as if they were coming from an
|
||||
input script.
|
||||
|
||||
Via these functions, the calling code can read or generate a series of
|
||||
LAMMPS commands one or multiple at a time and pass it thru the library
|
||||
interface to setup a problem and then run it in stages. The caller
|
||||
can interleave the command function calls with operations it performs,
|
||||
calls to extract information from or set information within LAMMPS, or
|
||||
calls to another code's library.
|
||||
|
||||
The lammps_file() function passes the filename of an input script.
|
||||
The lammps_command() function passes a single command as a string.
|
||||
The lammps_commands_list() function passes multiple commands in a
|
||||
char** list. In both lammps_command() and lammps_commands_list(),
|
||||
individual commands may or may not have a trailing newline. The
|
||||
lammps_commands_string() function passes multiple commands
|
||||
concatenated into one long string, separated by newline characters.
|
||||
In both lammps_commands_list() and lammps_commands_string(), a single
|
||||
command can be spread across multiple lines, if the last printable
|
||||
character of all but the last line is "&", the same as if the lines
|
||||
appeared in an input script.
|
||||
|
||||
The lammps_free() function is a clean-up function to free memory that
|
||||
the library allocated previously via other function calls. See
|
||||
comments in src/library.cpp file for which other functions need this
|
||||
clean-up.
|
||||
|
||||
The file src/library.cpp also contains these functions for extracting
|
||||
information from LAMMPS and setting value within LAMMPS. Again, see
|
||||
the documentation in the src/library.cpp file for details, including
|
||||
which quantities can be queried by name:
|
||||
|
||||
int lammps_extract_setting(void *, char *)
|
||||
void *lammps_extract_global(void *, char *)
|
||||
void lammps_extract_box(void *, double *, double *,
|
||||
double *, double *, double *, int *, int *)
|
||||
void *lammps_extract_atom(void *, char *)
|
||||
void *lammps_extract_compute(void *, char *, int, int)
|
||||
void *lammps_extract_fix(void *, char *, int, int, int, int)
|
||||
void *lammps_extract_variable(void *, char *, char *) :pre
|
||||
|
||||
The extract_setting() function returns info on the size
|
||||
of data types (e.g. 32-bit or 64-bit atom IDs) used
|
||||
by the LAMMPS executable (a compile-time choice).
|
||||
|
||||
The other extract functions return a pointer to various global or
|
||||
per-atom quantities stored in LAMMPS or to values calculated by a
|
||||
compute, fix, or variable. The pointer returned by the
|
||||
extract_global() function can be used as a permanent reference to a
|
||||
value which may change. For the extract_atom() method, see the
|
||||
extract() method in the src/atom.cpp file for a list of valid per-atom
|
||||
properties. New names could easily be added if the property you want
|
||||
is not listed. For the other extract functions, the underlying
|
||||
storage may be reallocated as LAMMPS runs, so you need to re-call the
|
||||
function to assure a current pointer or returned value(s).
|
||||
|
||||
double lammps_get_thermo(void *, char *)
|
||||
int lammps_get_natoms(void *) :pre
|
||||
|
||||
int lammps_set_variable(void *, char *, char *)
|
||||
void lammps_reset_box(void *, double *, double *, double, double, double) :pre
|
||||
|
||||
The lammps_get_thermo() function returns the current value of a thermo
|
||||
keyword as a double precision value.
|
||||
|
||||
The lammps_get_natoms() function returns the total number of atoms in
|
||||
the system and can be used by the caller to allocate memory for the
|
||||
lammps_gather_atoms() and lammps_scatter_atoms() functions.
|
||||
|
||||
The lammps_set_variable() function can set an existing string-style
|
||||
variable to a new string value, so that subsequent LAMMPS commands can
|
||||
access the variable.
|
||||
|
||||
The lammps_reset_box() function resets the size and shape of the
|
||||
simulation box, e.g. as part of restoring a previously extracted and
|
||||
saved state of a simulation.
|
||||
|
||||
void lammps_gather_atoms(void *, char *, int, int, void *)
|
||||
void lammps_gather_atoms_concat(void *, char *, int, int, void *)
|
||||
void lammps_gather_atoms_subset(void *, char *, int, int, int, int *, void *)
|
||||
void lammps_scatter_atoms(void *, char *, int, int, void *)
|
||||
void lammps_scatter_atoms_subset(void *, char *, int, int, int, int *, void *) :pre
|
||||
|
||||
void lammps_create_atoms(void *, int, tagint *, int *, double *, double *,
|
||||
imageint *, int) :pre
|
||||
|
||||
The gather functions collect peratom info of the requested type (atom
|
||||
coords, atom types, forces, etc) from all processors, and returns the
|
||||
same vector of values to each callling processor. The scatter
|
||||
functions do the inverse. They distribute a vector of peratom values,
|
||||
passed by all calling processors, to invididual atoms, which may be
|
||||
owned by different processos.
|
||||
|
||||
The lammps_gather_atoms() function does this for all N atoms in the
|
||||
system, ordered by atom ID, from 1 to N. The
|
||||
lammps_gather_atoms_concat() function does it for all N atoms, but
|
||||
simply concatenates the subset of atoms owned by each processor. The
|
||||
resulting vector is not ordered by atom ID. Atom IDs can be requetsed
|
||||
by the same function if the caller needs to know the ordering. The
|
||||
lammps_gather_subset() function allows the caller to request values
|
||||
for only a subset of atoms (identified by ID).
|
||||
For all 3 gather function, per-atom image flags can be retrieved in 2 ways.
|
||||
If the count is specified as 1, they are returned
|
||||
in a packed format with all three image flags stored in a single integer.
|
||||
If the count is specified as 3, the values are unpacked into xyz flags
|
||||
by the library before returning them.
|
||||
|
||||
The lammps_scatter_atoms() function takes a list of values for all N
|
||||
atoms in the system, ordered by atom ID, from 1 to N, and assigns
|
||||
those values to each atom in the system. The
|
||||
lammps_scatter_atoms_subset() function takes a subset of IDs as an
|
||||
argument and only scatters those values to the owning atoms.
|
||||
|
||||
The lammps_create_atoms() function takes a list of N atoms as input
|
||||
with atom types and coords (required), an optionally atom IDs and
|
||||
velocities and image flags. It uses the coords of each atom to assign
|
||||
it as a new atom to the processor that owns it. This function is
|
||||
useful to add atoms to a simulation or (in tandem with
|
||||
lammps_reset_box()) to restore a previously extracted and saved state
|
||||
of a simulation. Additional properties for the new atoms can then be
|
||||
assigned via the lammps_scatter_atoms() or lammps_extract_atom()
|
||||
functions.
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Manifolds (surfaces) :h3
|
||||
|
||||
[Overview:]
|
||||
|
||||
This doc page is not about a LAMMPS input script command, but about
|
||||
manifolds, which are generalized surfaces, as defined and used by the
|
||||
USER-MANIFOLD package, to track particle motion on the manifolds. See
|
||||
the src/USER-MANIFOLD/README file for more details about the package
|
||||
and its commands.
|
||||
|
||||
Below is a list of currently supported manifolds by the USER-MANIFOLD
|
||||
package, their parameters and a short description of them. The
|
||||
parameters listed here are in the same order as they should be passed
|
||||
to the relevant fixes.
|
||||
|
||||
{manifold} @ {parameters} @ {equation} @ {description}
|
||||
cylinder @ R @ x^2 + y^2 - R^2 = 0 @ Cylinder along z-axis, axis going through (0,0,0)
|
||||
cylinder_dent @ R l a @ x^2 + y^2 - r(z)^2 = 0, r(x) = R if | z | > l, r(z) = R - a*(1 + cos(z/l))/2 otherwise @ A cylinder with a dent around z = 0
|
||||
dumbbell @ a A B c @ -( x^2 + y^2 ) + (a^2 - z^2/c^2) * ( 1 + (A*sin(B*z^2))^4) = 0 @ A dumbbell
|
||||
ellipsoid @ a b c @ (x/a)^2 + (y/b)^2 + (z/c)^2 = 0 @ An ellipsoid
|
||||
gaussian_bump @ A l rc1 rc2 @ if( x < rc1) -z + A * exp( -x^2 / (2 l^2) ); else if( x < rc2 ) -z + a + b*x + c*x^2 + d*x^3; else z @ A Gaussian bump at x = y = 0, smoothly tapered to a flat plane z = 0.
|
||||
plane @ a b c x0 y0 z0 @ a*(x-x0) + b*(y-y0) + c*(z-z0) = 0 @ A plane with normal (a,b,c) going through point (x0,y0,z0)
|
||||
plane_wiggle @ a w @ z - a*sin(w*x) = 0 @ A plane with a sinusoidal modulation on z along x.
|
||||
sphere @ R @ x^2 + y^2 + z^2 - R^2 = 0 @ A sphere of radius R
|
||||
supersphere @ R q @ | x |^q + | y |^q + | z |^q - R^q = 0 @ A supersphere of hyperradius R
|
||||
spine @ a, A, B, B2, c @ -(x^2 + y^2) + (a^2 - z^2/f(z)^2)*(1 + (A*sin(g(z)*z^2))^4), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise @ An approximation to a dendtritic spine
|
||||
spine_two @ a, A, B, B2, c @ -(x^2 + y^2) + (a^2 - z^2/f(z)^2)*(1 + (A*sin(g(z)*z^2))^2), f(z) = c if z > 0, 1 otherwise; g(z) = B if z > 0, B2 otherwise @ Another approximation to a dendtritic spine
|
||||
thylakoid @ wB LB lB @ Various, see "(Paquay)"_#Paquay1 @ A model grana thylakoid consisting of two block-like compartments connected by a bridge of width wB, length LB and taper length lB
|
||||
torus @ R r @ (R - sqrt( x^2 + y^2 ) )^2 + z^2 - r^2 @ A torus with large radius R and small radius r, centered on (0,0,0) :tb(s=@)
|
||||
|
||||
:link(Paquay1)
|
||||
[(Paquay)] Paquay and Kusters, Biophys. J., 110, 6, (2016).
|
||||
preprint available at "arXiv:1411.3019"_http://arxiv.org/abs/1411.3019/.
|
||||
|
|
@ -0,0 +1,95 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Run multiple simulations from one input script :h3
|
||||
|
||||
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
|
||||
clear
|
||||
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#start_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.
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
NEMD simulations :h3
|
||||
|
||||
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/chunk"_fix_ave_chunk.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 flipped 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.
|
||||
|
||||
NEMD simulations can also be used to measure transport properties of a fluid
|
||||
through a pore or channel. Simulations of steady-state flow can be performed
|
||||
using the "fix flow/gauss"_fix_flow_gauss.html command.
|
||||
|
|
@ -0,0 +1,307 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Output from LAMMPS (thermo, dumps, computes, fixes, variables) :h3
|
||||
|
||||
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/chunk"_fix_ave_chunk.html for spatial or other 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"_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"_#fixprocoutput
|
||||
"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 :h4,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 :h4,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 :h4,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.
|
||||
|
||||
Note that thermodynamic output values can be "extensive" or
|
||||
"intensive". The former scale with the number of atoms in the system
|
||||
(e.g. total energy), the latter do not (e.g. temperature). The
|
||||
setting for "thermo_modify norm"_thermo_modify.html determines whether
|
||||
extensive quantities are normalized or not. Computes and fixes
|
||||
produce either extensive or intensive values; see their individual doc
|
||||
pages for details. "Equal-style variables"_variable.html produce only
|
||||
intensive values; you can include a division by "natoms" in the
|
||||
formula if desired, to make an extensive calculation produce an
|
||||
intensive result.
|
||||
|
||||
Dump file output :h4,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 enumerate 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 :h4,link(fixoutput)
|
||||
|
||||
Several fixes take various quantities as input and can write output
|
||||
files: "fix ave/time"_fix_ave_time.html, "fix
|
||||
ave/chunk"_fix_ave_chunk.html, "fix ave/histo"_fix_ave_histo.html,
|
||||
"fix ave/correlate"_fix_ave_correlate.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/chunk"_fix_ave_chunk.html command enables direct output
|
||||
to a file of chunk-averaged per-atom quantities like those output in
|
||||
dump files. Chunks can represent spatial bins or other collections of
|
||||
atoms, e.g. individual molecules. 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 chunk-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 ave/correlate"_fix_ave_correlate.html command enables direct
|
||||
output to a file of time-correlated quantities, which can be global
|
||||
values. The correlation matrix 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
|
||||
vector or atom styles). 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 :h4,link(computeoutput)
|
||||
|
||||
The "compute reduce"_compute_reduce.html and "compute
|
||||
reduce/region"_compute_reduce.html commands take one or more per-atom
|
||||
or local 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 slice"_compute_slice.html command take one or more global
|
||||
vector or array quantities as inputs and extracts a subset of their
|
||||
values to create a new vector or array. 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 :h4,link(fixprocoutput)
|
||||
|
||||
The "fix vector"_fix_vector.html command can create global vectors as
|
||||
output from global scalars as input, accumulating them one element at
|
||||
a time.
|
||||
|
||||
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.
|
||||
|
||||
The "fix store/state"_fix_store_state.html command can archive one or
|
||||
more per-atom attributes at a particular time, so that the old values
|
||||
can be used in a future calculation or output. The list of atom
|
||||
attributes is the same as for the "dump custom"_dump.html command,
|
||||
including per-atom quantities calculated by a "compute"_compute.html,
|
||||
by a "fix"_fix.html, or by an atom-style "variable"_variable.html.
|
||||
The output of this fix can be used as input to other output commands.
|
||||
|
||||
Computes that generate values to output :h4,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 :h4,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 :h4,link(variable)
|
||||
|
||||
"Variables"_variable.html defined in an input script can store one or
|
||||
more strings. But equal-style, vector-style, and atom-style or
|
||||
atomfile-style variables generate a global scalar value, global vector
|
||||
or values, or a per-atom vector, respectively, when accessed. The
|
||||
formulas used to define these variables can contain references to the
|
||||
thermodynamic keywords and to global and per-atom data generated by
|
||||
computes, fixes, and other variables. The values generated by
|
||||
variables can be used as input to and thus output by the other
|
||||
commands described in this section.
|
||||
|
||||
Summary table of output options and data flow between commands :h4,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 and vectors, per-atom vectors: global scalar and vector, per-atom vector:
|
||||
"compute reduce"_compute_reduce.html: per-atom/local vectors: global scalar/vector:
|
||||
"compute slice"_compute_slice.html: global vectors/arrays: global vector/array:
|
||||
"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 vector"_fix_vector.html: global scalars: global vector:
|
||||
"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/chunk"_fix_ave_chunk.html: per-atom vectors: global array, file:
|
||||
"fix ave/histo"_fix_ave_histo.html: global/per-atom/local scalars and vectors: global array, file:
|
||||
"fix ave/correlate"_fix_ave_correlate.html: global scalars: global array, file:
|
||||
"fix store/state"_fix_store_state.html: per-atom vectors: per-atom vector/array :tb(c=3,s=:)
|
||||
|
|
@ -0,0 +1,81 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Polarizable models :h3
|
||||
|
||||
In polarizable force fields the charge distributions in molecules and
|
||||
materials respond to their electrostatic environments. Polarizable
|
||||
systems can be simulated in LAMMPS using three methods:
|
||||
|
||||
the fluctuating charge method, implemented in the "QEQ"_fix_qeq.html
|
||||
package, :ulb,l
|
||||
the adiabatic core-shell method, implemented in the
|
||||
"CORESHELL"_Howto_coreshell.html package, :l
|
||||
the thermalized Drude dipole method, implemented in the
|
||||
"USER-DRUDE"_Howto_drude.html package. :l,ule
|
||||
|
||||
The fluctuating charge method calculates instantaneous charges on
|
||||
interacting atoms based on the electronegativity equalization
|
||||
principle. It is implemented in the "fix qeq"_fix_qeq.html which is
|
||||
available in several variants. It is a relatively efficient technique
|
||||
since no additional particles are introduced. This method allows for
|
||||
charge transfer between molecules or atom groups. However, because the
|
||||
charges are located at the interaction sites, off-plane components of
|
||||
polarization cannot be represented in planar molecules or atom groups.
|
||||
|
||||
The two other methods share the same basic idea: polarizable atoms are
|
||||
split into one core atom and one satellite particle (called shell or
|
||||
Drude particle) attached to it by a harmonic spring. Both atoms bear
|
||||
a charge and they represent collectively an induced electric dipole.
|
||||
These techniques are computationally more expensive than the QEq
|
||||
method because of additional particles and bonds. These two
|
||||
charge-on-spring methods differ in certain features, with the
|
||||
core-shell model being normally used for ionic/crystalline materials,
|
||||
whereas the so-called Drude model is normally used for molecular
|
||||
systems and fluid states.
|
||||
|
||||
The core-shell model is applicable to crystalline materials where the
|
||||
high symmetry around each site leads to stable trajectories of the
|
||||
core-shell pairs. However, bonded atoms in molecules can be so close
|
||||
that a core would interact too strongly or even capture the Drude
|
||||
particle of a neighbor. The Drude dipole model is relatively more
|
||||
complex in order to remediate this and other issues. Specifically, the
|
||||
Drude model includes specific thermostating of the core-Drude pairs
|
||||
and short-range damping of the induced dipoles.
|
||||
|
||||
The three polarization methods can be implemented through a
|
||||
self-consistent calculation of charges or induced dipoles at each
|
||||
timestep. In the fluctuating charge scheme this is done by the matrix
|
||||
inversion method in "fix qeq/point"_fix_qeq.html, but for core-shell
|
||||
or Drude-dipoles the relaxed-dipoles technique would require an slow
|
||||
iterative procedure. These self-consistent solutions yield accurate
|
||||
trajectories since the additional degrees of freedom representing
|
||||
polarization are massless. An alternative is to attribute a mass to
|
||||
the additional degrees of freedom and perform time integration using
|
||||
an extended Lagrangian technique. For the fluctuating charge scheme
|
||||
this is done by "fix qeq/dynamic"_fix_qeq.html, and for the
|
||||
charge-on-spring models by the methods outlined in the next two
|
||||
sections. The assignment of masses to the additional degrees of
|
||||
freedom can lead to unphysical trajectories if care is not exerted in
|
||||
choosing the parameters of the polarizable models and the simulation
|
||||
conditions.
|
||||
|
||||
In the core-shell model the vibration of the shells is kept faster
|
||||
than the ionic vibrations to mimic the fast response of the
|
||||
polarizable electrons. But in molecular systems thermalizing the
|
||||
core-Drude pairs at temperatures comparable to the rest of the
|
||||
simulation leads to several problems (kinetic energy transfer, too
|
||||
short a timestep, etc.) In order to avoid these problems the relative
|
||||
motion of the Drude particles with respect to their cores is kept
|
||||
"cold" so the vibration of the core-Drude pairs is very slow,
|
||||
approaching the self-consistent regime. In both models the
|
||||
temperature is regulated using the velocities of the center of mass of
|
||||
core+shell (or Drude) pairs, but in the Drude model the actual
|
||||
relative core-Drude particle motion is thermostated separately as
|
||||
well.
|
||||
|
|
@ -15,13 +15,19 @@ END_RST -->
|
|||
|
||||
Overview :h4
|
||||
|
||||
PyLammps is a Python wrapper class which can be created on its own or use an
|
||||
existing lammps Python object. It creates a simpler, Python-like interface to
|
||||
common LAMMPS functionality. Unlike the original flat C-types interface, it
|
||||
exposes a discoverable API. It no longer requires knowledge of the underlying
|
||||
C++ code implementation. Finally, the IPyLammps wrapper builds on top of
|
||||
PyLammps and adds some additional features for IPython integration into IPython
|
||||
notebooks, e.g. for embedded visualization output from dump/image.
|
||||
PyLammps is a Python wrapper class which can be created on its own or
|
||||
use an existing lammps Python object. It creates a simpler,
|
||||
Python-like interface to common LAMMPS functionality, in contrast to
|
||||
the lammps.py wrapper on the C-style LAMMPS library interface which is
|
||||
written using Python ctypes. The lammps.py wrapper is discussed on
|
||||
the "Python library"_Python_library.html doc page.
|
||||
|
||||
Unlike the flat ctypes interface, PyLammps exposes a discoverable API.
|
||||
It no longer requires knowledge of the underlying C++ code
|
||||
implementation. Finally, the IPyLammps wrapper builds on top of
|
||||
PyLammps and adds some additional features for IPython integration
|
||||
into IPython notebooks, e.g. for embedded visualization output from
|
||||
dump/image.
|
||||
|
||||
Comparison of lammps and PyLammps interfaces :h5
|
||||
|
||||
|
|
@ -40,7 +46,6 @@ communication with LAMMPS is hidden from API user
|
|||
shorter, more concise Python
|
||||
better IPython integration, designed for quick prototyping :ul
|
||||
|
||||
|
||||
Quick Start :h4
|
||||
|
||||
System-wide Installation :h5
|
||||
|
|
@ -0,0 +1,61 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Multi-replica simulations :h3
|
||||
|
||||
Several commands in LAMMPS run mutli-replica simulations, meaning
|
||||
that multiple instances (replicas) of your simulation are run
|
||||
simultaneously, with small amounts of data exchanged between replicas
|
||||
periodically.
|
||||
|
||||
These are the relevant commands:
|
||||
|
||||
"neb"_neb.html for nudged elastic band calculations
|
||||
"prd"_prd.html for parallel replica dynamics
|
||||
"tad"_tad.html for temperature accelerated dynamics
|
||||
"temper"_temper.html for parallel tempering
|
||||
"fix pimd"_fix_pimd.html for path-integral molecular dynamics (PIMD) :ul
|
||||
|
||||
NEB is a method for finding transition states and barrier energies.
|
||||
PRD and TAD are methods for performing accelerated dynamics to find
|
||||
and perform infrequent events. Parallel tempering or replica exchange
|
||||
runs different replicas at a series of temperature to facilitate
|
||||
rare-event sampling.
|
||||
|
||||
These commands can only be used if LAMMPS was built with the REPLICA
|
||||
package. See the "Making LAMMPS"_Section_start.html#start_3 section
|
||||
for more info on packages.
|
||||
|
||||
PIMD runs different replicas whose individual particles are coupled
|
||||
together by springs to model a system or ring-polymers.
|
||||
|
||||
This commands can only be used if LAMMPS was built with the USER-MISC
|
||||
package. See the "Making LAMMPS"_Section_start.html#start_3 section
|
||||
for more info on packages.
|
||||
|
||||
In all these cases, you must run with one or more processors per
|
||||
replica. The processors assigned to each replica are determined at
|
||||
run-time by using the "-partition command-line
|
||||
switch"_Section_start.html#start_6 to launch LAMMPS on multiple
|
||||
partitions, which in this context are the same as replicas. E.g.
|
||||
these commands:
|
||||
|
||||
mpirun -np 16 lmp_linux -partition 8x2 -in in.temper
|
||||
mpirun -np 8 lmp_linux -partition 8x1 -in in.neb :pre
|
||||
|
||||
would each run 8 replicas, on either 16 or 8 processors. Note the use
|
||||
of the "-in command-line switch"_Section_start.html#start_6 to specify
|
||||
the input script which is required when running in multi-replica mode.
|
||||
|
||||
Also note that with MPI installed on a machine (e.g. your desktop),
|
||||
you can run on more (virtual) processors than you have physical
|
||||
processors. Thus the above commands could be run on a
|
||||
single-processor (or few-processor) desktop so that you can run
|
||||
a multi-replica simulation on more replicas than you have
|
||||
physical processors.
|
||||
|
|
@ -0,0 +1,97 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Restart a simulation :h3
|
||||
|
||||
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 using the "-r command-line
|
||||
switch"_Section_start.html#start_6 and read by a
|
||||
"read_data"_read_data.html command in a new script.
|
||||
|
||||
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 as follows:
|
||||
|
||||
lmp_g++ -r 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.
|
||||
|
|
@ -0,0 +1,54 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
SPC water model :h3
|
||||
|
||||
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.
|
||||
|
||||
O mass = 15.9994
|
||||
H mass = 1.008
|
||||
O charge = -0.820
|
||||
H charge = 0.410
|
||||
LJ epsilon of OO = 0.1553
|
||||
LJ sigma of OO = 3.166
|
||||
LJ epsilon, sigma of OH, HH = 0.0
|
||||
r0 of OH bond = 1.0
|
||||
theta of HOH angle = 109.47 :all(b),p
|
||||
|
||||
Note that as originally proposed, the SPC model was run with a 9
|
||||
Angstrom cutoff for both LJ and Coulommbic terms. It can also be used
|
||||
with long-range Coulombics (Ewald or PPPM in LAMMPS), without changing
|
||||
any of the parameters above, though it becomes a different model in
|
||||
that mode of usage.
|
||||
|
||||
The SPC/E (extended) water model is the same, except
|
||||
the partial charge assignments change:
|
||||
|
||||
O charge = -0.8476
|
||||
H charge = 0.4238 :all(b),p
|
||||
|
||||
See the "(Berendsen)"_#howto-Berendsen reference for more details on both
|
||||
the SPC and SPC/E models.
|
||||
|
||||
Wikipedia also has a nice article on "water
|
||||
models"_http://en.wikipedia.org/wiki/Water_model.
|
||||
|
||||
:line
|
||||
|
||||
:link(howto-Berendsen)
|
||||
[(Berendsen)] Berendsen, Grigera, Straatsma, J Phys Chem, 91,
|
||||
6269-6271 (1987).
|
||||
|
|
@ -0,0 +1,243 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Finite-size spherical and aspherical particles :h3
|
||||
|
||||
Typical MD models treat atoms or particles as point masses. Sometimes
|
||||
it is desirable to have a model with finite-size particles such as
|
||||
spheroids or ellipsoids or generalized aspherical bodies. The
|
||||
difference is that such particles have a moment of inertia, rotational
|
||||
energy, and angular momentum. Rotation is induced by torque coming
|
||||
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 finite-size particles :ul
|
||||
|
||||
Example input scripts for these kinds of models are in the body,
|
||||
colloid, dipole, ellipse, line, peri, pour, and tri directories of the
|
||||
"examples directory"_Examples.html in the LAMMPS distribution.
|
||||
|
||||
Atom styles :h4
|
||||
|
||||
There are several "atom styles"_atom_style.html that allow for
|
||||
definition of finite-size particles: sphere, dipole, ellipsoid, line,
|
||||
tri, peri, and body.
|
||||
|
||||
The sphere style defines particles that are spheriods and each
|
||||
particle can have a unique diameter and mass (or density). These
|
||||
particles store an angular velocity (omega) and can be acted upon by
|
||||
torque. The "set" command can be used to modify the diameter and mass
|
||||
of individual particles, after then are created.
|
||||
|
||||
The dipole style does not actually define finite-size particles, but
|
||||
is often used in conjunction with spherical particles, via a command
|
||||
like
|
||||
|
||||
atom_style hybrid sphere dipole :pre
|
||||
|
||||
This is because when dipoles interact with each other, they induce
|
||||
torques, and a particle must be finite-size (i.e. have a moment of
|
||||
inertia) in order to respond and rotate. See the "atom_style
|
||||
dipole"_atom_style.html command for details. The "set" command can be
|
||||
used to modify the orientation and length of the dipole moment of
|
||||
individual particles, after then are created.
|
||||
|
||||
The ellipsoid style defines particles that are ellipsoids and thus can
|
||||
be aspherical. Each particle has a shape, specified by 3 diameters,
|
||||
and mass (or density). 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.
|
||||
The "set" command can be used to modify the diameter, orientation, and
|
||||
mass of individual particles, after then are created. It also has a
|
||||
brief explanation of what quaternions are.
|
||||
|
||||
The line style defines line segment particles with two end points and
|
||||
a mass (or density). They can be used in 2d simulations, and they can
|
||||
be joined together to form rigid bodies which represent arbitrary
|
||||
polygons.
|
||||
|
||||
The tri style defines triangular particles with three corner points
|
||||
and a mass (or density). They can be used in 3d simulations, and they
|
||||
can be joined together to form rigid bodies which represent arbitrary
|
||||
particles with a triangulated surface.
|
||||
|
||||
The peri style is used with "Peridynamic models"_pair_peri.html and
|
||||
defines particles as having a volume, that is used internally in the
|
||||
"pair_style peri"_pair_peri.html potentials.
|
||||
|
||||
The body style allows for definition of particles which can represent
|
||||
complex entities, such as surface meshes of discrete points,
|
||||
collections of sub-particles, deformable objects, etc. The body style
|
||||
is discussed in more detail on the "Howto body"_Howto_body.html doc
|
||||
page.
|
||||
|
||||
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, in the ellipsoid style, if the 3 shape parameters are set
|
||||
to the same value, the particle will be a sphere 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. In the line or
|
||||
tri style, if the lineflag or triflag is specified as 0, then it
|
||||
will be a point particle.
|
||||
|
||||
Some of the pair styles used to compute pairwise interactions between
|
||||
finite-size particles also compute the correct interaction with point
|
||||
particles as well, e.g. the interaction between a point particle and a
|
||||
finite-size particle or between two point particles. If necessary,
|
||||
"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 (ellipsoids versus
|
||||
spheres 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, atom styles sphere
|
||||
and ellipsoid still use 3d particles, rather than as circular disks or
|
||||
ellipses. This means they have the same moment of inertia as the 3d
|
||||
object. When temperature is computed, the correct degrees of freedom
|
||||
are used for rotation in a 2d versus 3d system.
|
||||
|
||||
Pair potentials :h4
|
||||
|
||||
When a system with finite-size 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_resquared.html
|
||||
"pair_style brownian"_pair_brownian.html
|
||||
"pair_style lubricate"_pair_lubricate.html
|
||||
"pair_style line/lj"_pair_line_lj.html
|
||||
"pair_style tri/lj"_pair_tri_lj.html
|
||||
"pair_style body"_pair_body.html :ul
|
||||
|
||||
The granular pair styles are used with spherical particles. The
|
||||
dipole pair style is used with the dipole atom style, which could be
|
||||
applied to spherical or ellipsoidal particles. The GayBerne and
|
||||
REsquared potentials require ellipsoidal particles, though they will
|
||||
also work if the 3 shape parameters are the same (a sphere). The
|
||||
Brownian and lubrication potentials are used with spherical particles.
|
||||
The line, tri, and body potentials are used with line segment,
|
||||
triangular, and body particles respectively.
|
||||
|
||||
Time integration :h4
|
||||
|
||||
There are several fixes that perform time integration on finite-size
|
||||
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
|
||||
ellipsoidal 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. The "fix langevin"_fix_langevin
|
||||
command can also be used with its {omgea} or {angmom} options to
|
||||
thermostat the rotational degrees of freedom for spherical or
|
||||
ellipsoidal particles. Other thermostatting fixes only operate on the
|
||||
translational kinetic energy of finite-size particles.
|
||||
|
||||
These fixes perform constant NVE time integration on line segment,
|
||||
triangular, and body particles:
|
||||
|
||||
"fix nve/line"_fix_nve_line.html
|
||||
"fix nve/tri"_fix_nve_tri.html
|
||||
"fix nve/body"_fix_nve_body.html :ul
|
||||
|
||||
Note that for mixtures of point and finite-size particles, these
|
||||
integration fixes can only be used with "groups"_group.html which
|
||||
contain finite-size particles.
|
||||
|
||||
Computes, thermodynamics, and dump output :h4
|
||||
|
||||
There are several computes that calculate the temperature or
|
||||
rotational energy of spherical or ellipsoidal 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
|
||||
finite-size 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.
|
||||
|
||||
These commands can be used to output various attributes of finite-size
|
||||
particles:
|
||||
|
||||
"dump custom"_dump.html
|
||||
"compute property/atom"_compute_property_atom.html
|
||||
"dump local"_dump.html
|
||||
"compute body/local"_compute_body_local.html :ul
|
||||
|
||||
Attributes include the dipole moment, the angular velocity, the
|
||||
angular momentum, the quaternion, the torque, the end-point and
|
||||
corner-point coordinates (for line and tri particles), and
|
||||
sub-particle attributes of body particles.
|
||||
|
||||
Rigid bodies composed of finite-size particles :h4
|
||||
|
||||
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.
|
||||
|
||||
If any of the constituent particles of a rigid body are finite-size
|
||||
particles (spheres or ellipsoids or line segments or triangles), 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
|
||||
spheroids, even if the two particles have the same mass. Finite-size
|
||||
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.
|
||||
|
||||
Also note that body particles cannot be modeled with the "fix
|
||||
rigid"_fix_rigid.html command. Body particles are treated by LAMMPS
|
||||
as single particles, though they can store internal state, such as a
|
||||
list of sub-particles. Individual body partices are typically treated
|
||||
as rigid bodies, and their motion integrated with a command like "fix
|
||||
nve/body"_fix_nve_body.html. Interactions between pairs of body
|
||||
particles are computed via a command like "pair_style
|
||||
body"_pair_body.html.
|
||||
|
|
@ -0,0 +1,59 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Magnetic spins :h3
|
||||
|
||||
The magnetic spin simualtions are enabled by the SPIN package, whose
|
||||
implementation is detailed in "Tranchida"_#Tranchida7.
|
||||
|
||||
The model representents the simulation of atomic magnetic spins coupled
|
||||
to lattice vibrations. The dynamics of those magnetic spins can be used
|
||||
to simulate a broad range a phenomena related to magneto-elasticity, or
|
||||
or to study the influence of defects on the magnetic properties of
|
||||
materials.
|
||||
|
||||
The magnetic spins are interacting with each others and with the
|
||||
lattice via pair interactions. Typically, the magnetic exchange
|
||||
interaction can be defined using the
|
||||
"pair/spin/exchange"_pair_spin_exchange.html command. This exchange
|
||||
applies a magnetic torque to a given spin, considering the orientation
|
||||
of its neighboring spins and their relative distances.
|
||||
It also applies a force on the atoms as a function of the spin
|
||||
orientations and their associated inter-atomic distances.
|
||||
|
||||
The command "fix precession/spin"_fix_precession_spin.html allows to
|
||||
apply a constant magnetic torque on all the spins in the system. This
|
||||
torque can be an external magnetic field (Zeeman interaction), or an
|
||||
uniaxial magnetic anisotropy.
|
||||
|
||||
A Langevin thermostat can be applied to those magnetic spins using
|
||||
"fix langevin/spin"_fix_langevin_spin.html. Typically, this thermostat
|
||||
can be coupled to another Langevin thermostat applied to the atoms
|
||||
using "fix langevin"_fix_langevin.html in order to simulate
|
||||
thermostated spin-lattice system.
|
||||
|
||||
The magnetic Gilbert damping can also be applied using "fix
|
||||
langevin/spin"_fix_langevin_spin.html. It allows to either dissipate
|
||||
the thermal energy of the Langevin thermostat, or to perform a
|
||||
relaxation of the magnetic configuration toward an equilibrium state.
|
||||
|
||||
All the computed magnetic properties can be outputed by two main
|
||||
commands. The first one is "compute spin"_compute_spin.html, that
|
||||
enables to evaluate magnetic averaged quantities, such as the total
|
||||
magnetization of the system along x, y, or z, the spin temperature, or
|
||||
the magnetic energy. The second command is "compute
|
||||
property/atom"_compute_property_atom.html. It enables to output all the
|
||||
per atom magnetic quantities. Typically, the orientation of a given
|
||||
magnetic spin, or the magnetic force acting on this spin.
|
||||
|
||||
:line
|
||||
|
||||
:link(Tranchida7)
|
||||
[(Tranchida)] Tranchida, Plimpton, Thibaudeau and Thompson,
|
||||
arXiv preprint arXiv:1801.10233, (2018).
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Calcalate temperature :h3
|
||||
|
||||
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 motion of particles) and its thermal velocity. The sum of
|
||||
the two is the particle's total velocity, but the latter is often what
|
||||
is wanted to compute a temperature.
|
||||
|
||||
LAMMPS has several options for computing temperatures, any of which can be used in "thermostatting"_Howto_thermostat.html and "barostatting"_Howto_barostat.html. These "compute commands"_compute.html calculate temperature:
|
||||
|
||||
"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 directly (e.g. advection
|
||||
velocities) that are removed when computing the thermal temperature.
|
||||
"Compute temp/sphere"_compute_temp_sphere.html and "compute
|
||||
temp/asphere"_compute_temp_asphere.html compute kinetic energy for
|
||||
finite-size particles that includes rotational degrees of freedom.
|
||||
They both allow for velocity biases indirectly, via an optional extra
|
||||
argument which is another temperature compute that subtracts a velocity bias.
|
||||
This allows the translational velocity of spherical or aspherical
|
||||
particles to be adjusted in prescribed ways.
|
||||
|
|
@ -0,0 +1,89 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Thermostats :h3
|
||||
|
||||
Thermostatting means controlling the temperature of particles in an MD
|
||||
simulation. "Barostatting"_Howto_barostat.html 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.
|
||||
|
||||
Thermostatting in LAMMPS is performed by "fixes"_fix.html, or in one
|
||||
case by a pair style. Several thermostatting fixes are available:
|
||||
Nose-Hoover (nvt), Berendsen, CSVR, Langevin, and direct rescaling
|
||||
(temp/rescale). Dissipative particle dynamics (DPD) thermostatting
|
||||
can be invoked via the {dpd/tstat} pair style:
|
||||
|
||||
"fix nvt"_fix_nh.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 temp/csvr"_fix_temp_csvr.html
|
||||
"fix langevin"_fix_langevin.html
|
||||
"fix temp/rescale"_fix_temp_rescale.html
|
||||
"pair_style dpd/tstat"_pair_dpd.html :ul
|
||||
|
||||
"Fix nvt"_fix_nh.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 "Howto
|
||||
nemd"_Howto_nemd.html doc 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.
|
||||
|
||||
DPD thermostatting alters pairwise interactions in a manner analogous
|
||||
to the per-particle thermostatting of "fix
|
||||
langevin"_fix_langevin.html.
|
||||
|
||||
Any of the thermostatting fixes can use "temperature
|
||||
computes"_Howto_thermostat.html that remove bias which has two
|
||||
effects. First, the current calculated temperature, which is compared
|
||||
to the requested target temperature, is calculated with the velocity
|
||||
bias removed. Second, the thermostat adjusts only the thermal
|
||||
temperature component of the particle's velocities, which are the
|
||||
velocities with the bias removed. The removed bias is then added back
|
||||
to the adjusted 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. Of you could
|
||||
thermostat only the thermal temperature of a streaming flow of
|
||||
particles without affecting the streaming velocity, by using "compute
|
||||
temp/profile"_compute_temp_profile.html.
|
||||
|
||||
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
|
||||
|
||||
Thermodynamic output, which can be setup via the
|
||||
"thermo_style"_thermo_style.html command, often includes temperature
|
||||
values. As explained on the doc page for the
|
||||
"thermo_style"_thermo_style.html command, the default temperature is
|
||||
setup by the thermo command itself. It is NOT the temperature
|
||||
associated with any thermostatting fix you have defined or with any
|
||||
compute you have defined that calculates a temperature. The doc pages
|
||||
for the thermostatting fixes explain the ID of the temperature compute
|
||||
they create. Thus if you want to view these temperatures, you need to
|
||||
specify them explicitly via the "thermo_style
|
||||
custom"_thermo_style.html command. Or you can use the
|
||||
"thermo_modify"_thermo_modify.html command to re-define what
|
||||
temperature compute is used for default thermodynamic output.
|
||||
|
|
@ -0,0 +1,69 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
TIP3P water model :h3
|
||||
|
||||
The TIP3P water model as implemented in CHARMM
|
||||
"(MacKerell)"_#howto-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)"_#Jorgensen1.
|
||||
|
||||
O mass = 15.9994
|
||||
H mass = 1.008
|
||||
O charge = -0.834
|
||||
H charge = 0.417
|
||||
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
|
||||
K of OH bond = 450
|
||||
r0 of OH bond = 0.9572
|
||||
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 (e.g. Ewald or PPPM in LAMMPS), see "(Price)"_#Price1 for
|
||||
details:
|
||||
|
||||
O mass = 15.9994
|
||||
H mass = 1.008
|
||||
O charge = -0.830
|
||||
H charge = 0.415
|
||||
LJ epsilon of OO = 0.102
|
||||
LJ sigma of OO = 3.188
|
||||
LJ epsilon, sigma of OH, HH = 0.0
|
||||
K of OH bond = 450
|
||||
r0 of OH bond = 0.9572
|
||||
K of HOH angle = 55
|
||||
theta of HOH angle = 104.52 :all(b),p
|
||||
|
||||
Wikipedia also has a nice article on "water
|
||||
models"_http://en.wikipedia.org/wiki/Water_model.
|
||||
|
||||
:line
|
||||
|
||||
:link(Jorgensen1)
|
||||
[(Jorgensen)] Jorgensen, Chandrasekhar, Madura, Impey, Klein, J Chem
|
||||
Phys, 79, 926 (1983).
|
||||
|
||||
:link(Price1)
|
||||
[(Price)] Price and Brooks, J Chem Phys, 121, 10096 (2004).
|
||||
|
||||
|
|
@ -0,0 +1,112 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
TIP4P water model :h3
|
||||
|
||||
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.
|
||||
|
||||
A TIP4P model is run with LAMMPS using either this command
|
||||
for a cutoff model:
|
||||
|
||||
"pair_style lj/cut/tip4p/cut"_pair_lj.html
|
||||
|
||||
or these two commands for a long-range model:
|
||||
|
||||
"pair_style lj/cut/tip4p/long"_pair_lj.html
|
||||
"kspace_style pppm/tip4p"_kspace_style.html :ul
|
||||
|
||||
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)"_#Jorgensen1. 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
|
||||
O charge = -1.040
|
||||
H charge = 0.520
|
||||
r0 of OH bond = 0.9572
|
||||
theta of HOH angle = 104.52
|
||||
OM distance = 0.15
|
||||
LJ epsilon of O-O = 0.1550
|
||||
LJ sigma of O-O = 3.1536
|
||||
LJ epsilon, sigma of OH, HH = 0.0
|
||||
Coulombic cutoff = 8.5 :all(b),p
|
||||
|
||||
For the TIP4/Ice model (J Chem Phys, 122, 234511 (2005);
|
||||
http://dx.doi.org/10.1063/1.1931662) these values can be used:
|
||||
|
||||
O mass = 15.9994
|
||||
H mass = 1.008
|
||||
O charge = -1.1794
|
||||
H charge = 0.5897
|
||||
r0 of OH bond = 0.9572
|
||||
theta of HOH angle = 104.52
|
||||
OM distance = 0.1577
|
||||
LJ epsilon of O-O = 0.21084
|
||||
LJ sigma of O-O = 3.1668
|
||||
LJ epsilon, sigma of OH, HH = 0.0
|
||||
Coulombic cutoff = 8.5 :all(b),p
|
||||
|
||||
For the TIP4P/2005 model (J Chem Phys, 123, 234505 (2005);
|
||||
http://dx.doi.org/10.1063/1.2121687), these values can be used:
|
||||
|
||||
O mass = 15.9994
|
||||
H mass = 1.008
|
||||
O charge = -1.1128
|
||||
H charge = 0.5564
|
||||
r0 of OH bond = 0.9572
|
||||
theta of HOH angle = 104.52
|
||||
OM distance = 0.1546
|
||||
LJ epsilon of O-O = 0.1852
|
||||
LJ sigma of O-O = 3.1589
|
||||
LJ epsilon, sigma of OH, HH = 0.0
|
||||
Coulombic cutoff = 8.5 :all(b),p
|
||||
|
||||
These are the parameters to use for TIP4P with a long-range Coulombic
|
||||
solver (e.g. Ewald or PPPM in LAMMPS):
|
||||
|
||||
O mass = 15.9994
|
||||
H mass = 1.008
|
||||
O charge = -1.0484
|
||||
H charge = 0.5242
|
||||
r0 of OH bond = 0.9572
|
||||
theta of HOH angle = 104.52
|
||||
OM distance = 0.1250
|
||||
LJ epsilon of O-O = 0.16275
|
||||
LJ sigma of O-O = 3.16435
|
||||
LJ epsilon, sigma of OH, HH = 0.0 :all(b),p
|
||||
|
||||
Note that the when using the TIP4P pair style, the neighbor list
|
||||
cutoff for Coulomb interactions is effectively extended by a distance
|
||||
2 * (OM distance), to account for the offset distance of the
|
||||
fictitious charges on O atoms in water molecules. Thus it is
|
||||
typically best in an efficiency sense to use a LJ cutoff >= Coulomb
|
||||
cutoff + 2*(OM distance), to shrink the size of the neighbor list.
|
||||
This leads to slightly larger cost for the long-range calculation, so
|
||||
you can test the trade-off for your model. The OM distance and the LJ
|
||||
and Coulombic cutoffs are set in the "pair_style
|
||||
lj/cut/tip4p/long"_pair_lj.html command.
|
||||
|
||||
Wikipedia also has a nice article on "water
|
||||
models"_http://en.wikipedia.org/wiki/Water_model.
|
||||
|
||||
:line
|
||||
|
||||
:link(Jorgensen1)
|
||||
[(Jorgensen)] Jorgensen, Chandrasekhar, Madura, Impey, Klein, J Chem
|
||||
Phys, 79, 926 (1983).
|
||||
|
|
@ -0,0 +1,213 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
Triclinic (non-orthogonal) simulation boxes :h3
|
||||
|
||||
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). The orthogonal
|
||||
box has its "origin" at (xlo,ylo,zlo) and is defined by 3 edge vectors
|
||||
starting from the origin given by [a] = (xhi-xlo,0,0); [b] =
|
||||
(0,yhi-ylo,0); [c] = (0,0,zhi-zlo). The 6 parameters
|
||||
(xlo,xhi,ylo,yhi,zlo,zhi) are defined at the time the simulation box
|
||||
is created, e.g. by the "create_box"_create_box.html or
|
||||
"read_data"_read_data.html or "read_restart"_read_restart.html
|
||||
commands. Additionally, LAMMPS defines box size parameters lx,ly,lz
|
||||
where lx = xhi-xlo, and similarly in the y and z dimensions. The 6
|
||||
parameters, as well as lx,ly,lz, can be output via the "thermo_style
|
||||
custom"_thermo_style.html command.
|
||||
|
||||
LAMMPS also allows simulations to be performed in triclinic
|
||||
(non-orthogonal) simulation boxes shaped as a parallelepiped with
|
||||
triclinic symmetry. The parallelepiped has its "origin" at
|
||||
(xlo,ylo,zlo) and is defined by 3 edge vectors starting from the
|
||||
origin given by [a] = (xhi-xlo,0,0); [b] = (xy,yhi-ylo,0); [c] =
|
||||
(xz,yz,zhi-zlo). {xy,xz,yz} can be 0.0 or positive or negative values
|
||||
and are called "tilt factors" because they are the amount of
|
||||
displacement applied to faces of an originally orthogonal box to
|
||||
transform it into the parallelepiped. In LAMMPS the triclinic
|
||||
simulation box edge vectors [a], [b], and [c] cannot be arbitrary
|
||||
vectors. As indicated, [a] must lie on the positive x axis. [b] must
|
||||
lie in the xy plane, with strictly positive y component. [c] may have
|
||||
any orientation with strictly positive z component. The requirement
|
||||
that [a], [b], and [c] have strictly positive x, y, and z components,
|
||||
respectively, ensures that [a], [b], and [c] form a complete
|
||||
right-handed basis. These restrictions impose no loss of generality,
|
||||
since it is possible to rotate/invert any set of 3 crystal basis
|
||||
vectors so that they conform to the restrictions.
|
||||
|
||||
For example, assume that the 3 vectors [A],[B],[C] are the edge
|
||||
vectors of a general parallelepiped, where there is no restriction on
|
||||
[A],[B],[C] other than they form a complete right-handed basis i.e.
|
||||
[A] x [B] . [C] > 0. The equivalent LAMMPS [a],[b],[c] are a linear
|
||||
rotation of [A], [B], and [C] and can be computed as follows:
|
||||
|
||||
:c,image(Eqs/transform.jpg)
|
||||
|
||||
where A = | [A] | indicates the scalar length of [A]. The hat symbol (^)
|
||||
indicates the corresponding unit vector. {beta} and {gamma} are angles
|
||||
between the vectors described below. Note that by construction,
|
||||
[a], [b], and [c] have strictly positive x, y, and z components, respectively.
|
||||
If it should happen that
|
||||
[A], [B], and [C] form a left-handed basis, then the above equations
|
||||
are not valid for [c]. In this case, it is necessary
|
||||
to first apply an inversion. This can be achieved
|
||||
by interchanging two basis vectors or by changing the sign of one of them.
|
||||
|
||||
For consistency, the same rotation/inversion applied to the basis vectors
|
||||
must also be applied to atom positions, velocities,
|
||||
and any other vector quantities.
|
||||
This can be conveniently achieved by first converting to
|
||||
fractional coordinates in the
|
||||
old basis and then converting to distance coordinates in the new basis.
|
||||
The transformation is given by the following equation:
|
||||
|
||||
:c,image(Eqs/rotate.jpg)
|
||||
|
||||
where {V} is the volume of the box, [X] is the original vector quantity and
|
||||
[x] is the vector in the LAMMPS basis.
|
||||
|
||||
There is no requirement that a triclinic box be periodic in any
|
||||
dimension, though it typically should be in at least the 2nd dimension
|
||||
of the tilt (y in xy) if you want to enforce a shift in periodic
|
||||
boundary conditions across that boundary. Some commands that work
|
||||
with triclinic boxes, e.g. the "fix deform"_fix_deform.html and "fix
|
||||
npt"_fix_nh.html commands, require periodicity or non-shrink-wrap
|
||||
boundary conditions in specific dimensions. See the command doc pages
|
||||
for details.
|
||||
|
||||
The 9 parameters (xlo,xhi,ylo,yhi,zlo,zhi,xy,xz,yz) are defined at the
|
||||
time the simulation box is created. This happens in one of 3 ways.
|
||||
If the "create_box"_create_box.html command is used with a region of
|
||||
style {prism}, then a triclinic box is setup. See the
|
||||
"region"_region.html command for details. If the
|
||||
"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 triclinic box 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 triclinic
|
||||
box will be setup for the restarted simulation.
|
||||
|
||||
Note that you can define a triclinic box with all 3 tilt factors =
|
||||
0.0, so that it is initially orthogonal. This is necessary if the box
|
||||
will become non-orthogonal, e.g. due to the "fix npt"_fix_nh.html or
|
||||
"fix deform"_fix_deform.html commands. Alternatively, you can use the
|
||||
"change_box"_change_box.html command to convert a simulation box from
|
||||
orthogonal to triclinic and vice versa.
|
||||
|
||||
As with orthogonal boxes, LAMMPS defines triclinic box size parameters
|
||||
lx,ly,lz where lx = xhi-xlo, and similarly in the y and z dimensions.
|
||||
The 9 parameters, as well as lx,ly,lz, can be output via the
|
||||
"thermo_style custom"_thermo_style.html command.
|
||||
|
||||
To avoid extremely tilted boxes (which would be computationally
|
||||
inefficient), LAMMPS normally requires that 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). This is required
|
||||
both when the simulation box is created, e.g. via the
|
||||
"create_box"_create_box.html or "read_data"_read_data.html commands,
|
||||
as well as when the box shape changes dynamically during a simulation,
|
||||
e.g. via the "fix deform"_fix_deform.html or "fix npt"_fix_nh.html
|
||||
commands.
|
||||
|
||||
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 geometrically all equivalent. If the box tilt exceeds this
|
||||
limit during a dynamics run (e.g. via the "fix deform"_fix_deform.html
|
||||
command), then the box is "flipped" to an equivalent shape with a tilt
|
||||
factor within the bounds, so the run can continue. See the "fix
|
||||
deform"_fix_deform.html doc page for further details.
|
||||
|
||||
One exception to this rule is if the 1st dimension in the tilt
|
||||
factor (x for xy) is non-periodic. In that case, the limits on the
|
||||
tilt factor are not enforced, since flipping the box in that dimension
|
||||
does not change the atom positions due to non-periodicity. In this
|
||||
mode, if you tilt the system to extreme angles, the simulation will
|
||||
simply become inefficient, due to the highly skewed simulation box.
|
||||
|
||||
The limitation on not creating a simulation box with a tilt factor
|
||||
skewing the box more than half the distance of the parallel box length
|
||||
can be overridden via the "box"_box.html command. Setting the {tilt}
|
||||
keyword to {large} allows any tilt factors to be specified.
|
||||
|
||||
Box flips that may occur using the "fix deform"_fix_deform.html or
|
||||
"fix npt"_fix_nh.html commands can be turned off using the {flip no}
|
||||
option with either of the commands.
|
||||
|
||||
Note that if a simulation box has a large tilt factor, LAMMPS will run
|
||||
less efficiently, due to the large volume of communication needed to
|
||||
acquire ghost atoms around a processor's irregular-shaped sub-domain.
|
||||
For extreme values of tilt, LAMMPS may also lose atoms and generate an
|
||||
error.
|
||||
|
||||
Triclinic crystal structures are often defined using three lattice
|
||||
constants {a}, {b}, and {c}, and three angles {alpha}, {beta} and
|
||||
{gamma}. Note that in this nomenclature, the a, b, and c lattice
|
||||
constants are the scalar lengths of the edge vectors [a], [b], and [c]
|
||||
defined above. The relationship between these 6 quantities
|
||||
(a,b,c,alpha,beta,gamma) and the LAMMPS box sizes (lx,ly,lz) =
|
||||
(xhi-xlo,yhi-ylo,zhi-zlo) and tilt factors (xy,xz,yz) is as follows:
|
||||
|
||||
:c,image(Eqs/box.jpg)
|
||||
|
||||
The inverse relationship can be written as follows:
|
||||
|
||||
:c,image(Eqs/box_inverse.jpg)
|
||||
|
||||
The values of {a}, {b}, {c} , {alpha}, {beta} , and {gamma} can be printed
|
||||
out or accessed by computes using the
|
||||
"thermo_style custom"_thermo_style.html keywords
|
||||
{cella}, {cellb}, {cellc}, {cellalpha}, {cellbeta}, {cellgamma},
|
||||
respectively.
|
||||
|
||||
As discussed on the "dump"_dump.html command doc page, when the BOX
|
||||
BOUNDS for a snapshot is written to a dump file for a triclinic box,
|
||||
an orthogonal bounding box which encloses the triclinic simulation box
|
||||
is output, along with the 3 tilt factors (xy, xz, yz) of the triclinic
|
||||
box, formatted as follows:
|
||||
|
||||
ITEM: BOX BOUNDS xy xz yz
|
||||
xlo_bound xhi_bound xy
|
||||
ylo_bound yhi_bound xz
|
||||
zlo_bound zhi_bound yz :pre
|
||||
|
||||
This bounding box is convenient for many visualization programs and is
|
||||
calculated from the 9 triclinic box parameters
|
||||
(xlo,xhi,ylo,yhi,zlo,zhi,xy,xz,yz) as follows:
|
||||
|
||||
xlo_bound = xlo + MIN(0.0,xy,xz,xy+xz)
|
||||
xhi_bound = xhi + MAX(0.0,xy,xz,xy+xz)
|
||||
ylo_bound = ylo + MIN(0.0,yz)
|
||||
yhi_bound = yhi + MAX(0.0,yz)
|
||||
zlo_bound = zlo
|
||||
zhi_bound = zhi :pre
|
||||
|
||||
These formulas can be inverted if you need to convert the bounding box
|
||||
back into the triclinic box parameters, e.g. xlo = xlo_bound -
|
||||
MIN(0.0,xy,xz,xy+xz).
|
||||
|
||||
One use of triclinic simulation 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 triclinic simulation box via the
|
||||
"create_atoms"_create_atoms.html command.
|
||||
|
||||
A second use is to run Parinello-Rahman dynamics via the "fix
|
||||
npt"_fix_nh.html command, which will adjust the xy, xz, yz tilt
|
||||
factors to compensate for off-diagonal components of the pressure
|
||||
tensor. The analog for an "energy minimization"_minimize.html is
|
||||
the "fix box/relax"_fix_box_relax.html command.
|
||||
|
||||
A third use 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, yz tilt
|
||||
factors as a simulation runs. This is discussed in the next section
|
||||
on non-equilibrium MD (NEMD) simulations.
|
||||
|
|
@ -0,0 +1,133 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Calculate viscosity :h3
|
||||
|
||||
The shear viscosity eta of a fluid can be measured in at least 5 ways
|
||||
using various options in LAMMPS. See the examples/VISCOSITY directory
|
||||
for scripts that implement the 5 methods discussed here for a simple
|
||||
Lennard-Jones fluid model. Also, see the "Howto
|
||||
kappa"_Howto_kappa.html doc page for an analogous discussion for
|
||||
thermal conductivity.
|
||||
|
||||
Eta is a measure of the propensity of a fluid to transmit momentum in
|
||||
a direction perpendicular to the direction of velocity or momentum
|
||||
flow. Alternatively it is the resistance the fluid has to being
|
||||
sheared. It is given by
|
||||
|
||||
J = -eta grad(Vstream)
|
||||
|
||||
where J is the momentum flux in units of momentum per area per time.
|
||||
and grad(Vstream) is the spatial gradient of the velocity of the fluid
|
||||
moving in another direction, normal to the area through which the
|
||||
momentum flows. Viscosity thus has units of pressure-time.
|
||||
|
||||
The first method is to perform a non-equilibrium MD (NEMD) simulation
|
||||
by shearing the simulation box via the "fix deform"_fix_deform.html
|
||||
command, and using the "fix nvt/sllod"_fix_nvt_sllod.html command to
|
||||
thermostat the fluid via the SLLOD equations of motion.
|
||||
Alternatively, as a second method, one or more moving walls can be
|
||||
used to shear the fluid in between them, again with some kind of
|
||||
thermostat that modifies only the thermal (non-shearing) components of
|
||||
velocity to prevent the fluid from heating up.
|
||||
|
||||
In both cases, the velocity profile setup in the fluid by this
|
||||
procedure can be monitored by the "fix ave/chunk"_fix_ave_chunk.html
|
||||
command, which determines grad(Vstream) in the equation above.
|
||||
E.g. the derivative in the y-direction of the Vx component of fluid
|
||||
motion or grad(Vstream) = dVx/dy. The Pxy off-diagonal component of
|
||||
the pressure or stress tensor, as calculated by the "compute
|
||||
pressure"_compute_pressure.html command, can also be monitored, which
|
||||
is the J term in the equation above. See the "Howto
|
||||
nemd"_Howto_nemd.html doc page for details on NEMD simulations.
|
||||
|
||||
The third method is to perform a reverse non-equilibrium MD simulation
|
||||
using the "fix viscosity"_fix_viscosity.html command which implements
|
||||
the rNEMD algorithm of Muller-Plathe. Momentum in one dimension is
|
||||
swapped between atoms in two different layers of the simulation box in
|
||||
a different dimension. This induces a velocity gradient which can be
|
||||
monitored with the "fix ave/chunk"_fix_ave_chunk.html command.
|
||||
The fix tallies the cumulative momentum transfer that it performs.
|
||||
See the "fix viscosity"_fix_viscosity.html command for details.
|
||||
|
||||
The fourth method is based on the Green-Kubo (GK) formula which
|
||||
relates the ensemble average of the auto-correlation of the
|
||||
stress/pressure tensor to eta. This can be done in a fully
|
||||
equilibrated simulation which is in contrast to the two preceding
|
||||
non-equilibrium methods, where momentum flows continuously through the
|
||||
simulation box.
|
||||
|
||||
Here is an example input script that calculates the viscosity of
|
||||
liquid Ar via the GK formalism:
|
||||
|
||||
# Sample LAMMPS input script for viscosity of liquid Ar :pre
|
||||
|
||||
units real
|
||||
variable T equal 86.4956
|
||||
variable V equal vol
|
||||
variable dt equal 4.0
|
||||
variable p equal 400 # correlation length
|
||||
variable s equal 5 # sample interval
|
||||
variable d equal $p*$s # dump interval :pre
|
||||
|
||||
# convert from LAMMPS real units to SI :pre
|
||||
|
||||
variable kB equal 1.3806504e-23 # \[J/K/] Boltzmann
|
||||
variable atm2Pa equal 101325.0
|
||||
variable A2m equal 1.0e-10
|
||||
variable fs2s equal 1.0e-15
|
||||
variable convert equal $\{atm2Pa\}*$\{atm2Pa\}*$\{fs2s\}*$\{A2m\}*$\{A2m\}*$\{A2m\} :pre
|
||||
|
||||
# setup problem :pre
|
||||
|
||||
dimension 3
|
||||
boundary p p p
|
||||
lattice fcc 5.376 orient x 1 0 0 orient y 0 1 0 orient z 0 0 1
|
||||
region box block 0 4 0 4 0 4
|
||||
create_box 1 box
|
||||
create_atoms 1 box
|
||||
mass 1 39.948
|
||||
pair_style lj/cut 13.0
|
||||
pair_coeff * * 0.2381 3.405
|
||||
timestep $\{dt\}
|
||||
thermo $d :pre
|
||||
|
||||
# equilibration and thermalization :pre
|
||||
|
||||
velocity all create $T 102486 mom yes rot yes dist gaussian
|
||||
fix NVT all nvt temp $T $T 10 drag 0.2
|
||||
run 8000 :pre
|
||||
|
||||
# viscosity calculation, switch to NVE if desired :pre
|
||||
|
||||
#unfix NVT
|
||||
#fix NVE all nve :pre
|
||||
|
||||
reset_timestep 0
|
||||
variable pxy equal pxy
|
||||
variable pxz equal pxz
|
||||
variable pyz equal pyz
|
||||
fix SS all ave/correlate $s $p $d &
|
||||
v_pxy v_pxz v_pyz type auto file S0St.dat ave running
|
||||
variable scale equal $\{convert\}/($\{kB\}*$T)*$V*$s*$\{dt\}
|
||||
variable v11 equal trap(f_SS\[3\])*$\{scale\}
|
||||
variable v22 equal trap(f_SS\[4\])*$\{scale\}
|
||||
variable v33 equal trap(f_SS\[5\])*$\{scale\}
|
||||
thermo_style custom step temp press v_pxy v_pxz v_pyz v_v11 v_v22 v_v33
|
||||
run 100000
|
||||
variable v equal (v_v11+v_v22+v_v33)/3.0
|
||||
variable ndens equal count(all)/vol
|
||||
print "average viscosity: $v \[Pa.s\] @ $T K, $\{ndens\} /A^3" :pre
|
||||
|
||||
The fifth method is related to the above Green-Kubo method,
|
||||
but uses the Einstein formulation, analogous to the Einstein
|
||||
mean-square-displacement formulation for self-diffusivity. The
|
||||
time-integrated momentum fluxes play the role of Cartesian
|
||||
coordinates, whose mean-square displacement increases linearly
|
||||
with time at sufficiently long times.
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Visualize LAMMPS snapshots :h3
|
||||
|
||||
LAMMPS itself does not do visualization, but snapshots from LAMMPS
|
||||
simulations can be visualized (and analyzed) in a variety of ways.
|
||||
|
||||
Mention dump image and dump movie.
|
||||
|
||||
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 several popular visualization tools. The "dump
|
||||
image"_dump_image.html and "dump movie"_dump_image.html styles can
|
||||
output internally rendered images and convert a sequence of them to a
|
||||
movie during the MD run. Several programs included with LAMMPS as
|
||||
auxiliary tools can convert between LAMMPS format files and other
|
||||
formats. See the "Tools"_Tools.html doc page for details.
|
||||
|
||||
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.
|
||||
|
||||
:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
|
||||
:link(ensight,http://www.ensight.com)
|
||||
:link(atomeye,http://mt.seas.upenn.edu/Archive/Graphics/A)
|
||||
|
|
@ -0,0 +1,80 @@
|
|||
"Higher level section"_Howto.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Walls :h3
|
||||
|
||||
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_nh.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.
|
||||
|
|
@ -0,0 +1,43 @@
|
|||
"Previous Section"_Manual.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
|
||||
Section"_Section_start.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Introduction :h2
|
||||
|
||||
The "LAMMPS website"_lws is the best introduction to LAMMPS.
|
||||
|
||||
Here is a list of webpages you can browse:
|
||||
|
||||
"Brief intro and significant recent features"_lws
|
||||
"List of features"_http://lammps.sandia.gov/features.html
|
||||
"List of non-features"_http://lammps.sandia.gov/non_features.html
|
||||
"Recent bug fixes and new features"_http://lammps.sandia.gov/bug.html :ul
|
||||
|
||||
"Download info"_http://lammps.sandia.gov/download.html
|
||||
"GitHub site"_https://github.com/lammps/lammps
|
||||
"SourceForge site"_https://sourceforge.net/projects/lammps
|
||||
"Open source and licensing info"_http://lammps.sandia.gov/open_source.html :ul
|
||||
|
||||
"Glossary of MD terms relevant to LAMMPS"_http://lammps.sandia.gov/glossary.html
|
||||
"LAMMPS highlights with images"_http://lammps.sandia.gov/pictures.html
|
||||
"LAMMPS highlights with movies"_http://lammps.sandia.gov/movies.html
|
||||
"Mail list"_http://lammps.sandia.gov/mail.html
|
||||
"Workshops"_http://lammps.sandia.gov/workshops.html
|
||||
"Tutorials"_http://lammps.sandia.gov/tutorials.html
|
||||
"Developer guide"_http://lammps.sandia.gov/Developer.pdf :ul
|
||||
|
||||
"Pre- and post-processing tools for LAMMPS"_http://lammps.sandia.gov/prepost.html
|
||||
"Other software usable with LAMMPS"_http://lammps.sandia.gov/offsite.html
|
||||
"Viz tools usable with LAMMPS"_http://lammps.sandia.gov/viz.html :ul
|
||||
|
||||
"Benchmark performance"_http://lammps.sandia.gov/bench.html
|
||||
"Publications that have cited LAMMPS"_http://lammps.sandia.gov/papers.html
|
||||
"Authors of the LAMMPS code"_http://lammps.sandia.gov/authors.html
|
||||
"History of LAMMPS development"_http://lammps.sandia.gov/history.html
|
||||
"Funding for LAMMPS"_http://lammps.sandia.gov/funding.html :ul
|
||||
|
|
@ -1,5 +1,5 @@
|
|||
<!-- HTML_ONLY -->
|
||||
<
|
||||
<HEAD>
|
||||
<TITLE>LAMMPS Users Manual</TITLE>
|
||||
<META NAME="docnumber" CONTENT="16 Jul 2018 version">
|
||||
<META NAME="author" CONTENT="http://lammps.sandia.gov - Sandia National Laboratories">
|
||||
|
|
@ -18,87 +18,47 @@
|
|||
|
||||
:line
|
||||
|
||||
<H1></H1>
|
||||
|
||||
LAMMPS Documentation :c,h1
|
||||
16 Jul 2018 version :c,h2
|
||||
16 Mar 2018 version :c,h2
|
||||
|
||||
Version info: :h3
|
||||
|
||||
The LAMMPS "version" is the date when it was released, such as 1 May
|
||||
2010. LAMMPS is updated continuously. Whenever we fix a bug or add a
|
||||
feature, we release it immediately, and post a notice on "this page of
|
||||
the WWW site"_bug. Every 2-4 months one of the incremental releases
|
||||
is subjected to more thorough testing and labeled as a {stable} version.
|
||||
|
||||
Each dated copy of LAMMPS contains all the
|
||||
features and bug-fixes up to and including that version date. The
|
||||
version date is printed to the screen and logfile every time you run
|
||||
LAMMPS. It is also in the file src/version.h and in the LAMMPS
|
||||
directory name created when you unpack a tarball, and at the top of
|
||||
the first page of the manual (this page).
|
||||
|
||||
If you browse the HTML doc pages on the LAMMPS WWW site, they always
|
||||
describe the most current [development] version of LAMMPS. :ulb,l
|
||||
|
||||
If you browse the HTML doc pages included in your tarball, they
|
||||
describe the version you have. :l
|
||||
|
||||
The "PDF file"_Manual.pdf on the WWW site or in the tarball is updated
|
||||
about once per month. This is because it is large, and we don't want
|
||||
it to be part of every patch. :l
|
||||
|
||||
There is also a "Developer.pdf"_Developer.pdf file in the doc
|
||||
directory, which describes the internal structure and algorithms of
|
||||
LAMMPS. :l
|
||||
:ule
|
||||
"What is a LAMMPS version?"_Manual_version.html
|
||||
|
||||
LAMMPS stands for Large-scale Atomic/Molecular Massively Parallel
|
||||
Simulator.
|
||||
|
||||
LAMMPS is a classical molecular dynamics simulation code designed to
|
||||
run efficiently on parallel computers. It was developed at Sandia
|
||||
National Laboratories, a US Department of Energy facility, with
|
||||
run efficiently on parallel computers. It was developed originally at
|
||||
Sandia National Laboratories, a US Department of Energy facility, with
|
||||
funding from the DOE. It is an open-source code, distributed freely
|
||||
under the terms of the GNU Public License (GPL).
|
||||
|
||||
The current core group of LAMMPS developers is at Sandia National
|
||||
Labs and Temple University:
|
||||
|
||||
"Steve Plimpton"_sjp, sjplimp at sandia.gov :ulb,l
|
||||
Aidan Thompson, athomps at sandia.gov :l
|
||||
Stan Moore, stamoor at sandia.gov :l
|
||||
"Axel Kohlmeyer"_ako, akohlmey at gmail.com :l
|
||||
:ule
|
||||
|
||||
Past core developers include Paul Crozier, Ray Shan and Mark Stevens,
|
||||
all at Sandia. The [LAMMPS home page] at
|
||||
"http://lammps.sandia.gov"_http://lammps.sandia.gov has more information
|
||||
about the code and its uses. Interaction with external LAMMPS developers,
|
||||
bug reports and feature requests are mainly coordinated through the
|
||||
"LAMMPS project on GitHub."_https://github.com/lammps/lammps
|
||||
The lammps.org domain, currently hosting "public continuous integration
|
||||
testing"_https://ci.lammps.org/job/lammps/ and "precompiled Linux
|
||||
RPM and Windows installer packages"_http://packages.lammps.org is located
|
||||
at Temple University and managed by Richard Berger,
|
||||
richard.berger at temple.edu.
|
||||
|
||||
:link(bug,http://lammps.sandia.gov/bug.html)
|
||||
:link(sjp,http://www.sandia.gov/~sjplimp)
|
||||
:link(ako,http://goo.gl/1wk0)
|
||||
The "LAMMPS website"_lws has information about the code authors, a
|
||||
"mail list"_http://lammps.sandia.gov where users can post questions,
|
||||
and a "GitHub site"https://github.com/lammps/lammps where all LAMMPS
|
||||
development is coordinated.
|
||||
|
||||
:line
|
||||
|
||||
The LAMMPS documentation is organized into the following sections. If
|
||||
you find errors or omissions in this manual or have suggestions for
|
||||
useful information to add, please send an email to the developers so
|
||||
we can improve the LAMMPS documentation.
|
||||
|
||||
Once you are familiar with LAMMPS, you may want to bookmark "this
|
||||
page"_Section_commands.html#comm at Section_commands.html#comm since
|
||||
it gives quick access to documentation for all LAMMPS commands.
|
||||
|
||||
"PDF file"_Manual.pdf of the entire manual, generated by
|
||||
"htmldoc"_http://freecode.com/projects/htmldoc
|
||||
|
||||
The content for this manual is part of the LAMMPS distribution.
|
||||
You can build a local copy of the Manual as HTML pages or a PDF file,
|
||||
by following the steps on the "this page"_Build_manual.html.
|
||||
|
||||
There is also a "Developer.pdf"_Developer.pdf document which gives
|
||||
a brief description of the basic code structure of LAMMPS.
|
||||
|
||||
:line
|
||||
|
||||
This manual is organized into the following sections.
|
||||
|
||||
Once you are familiar with LAMMPS, you may want to bookmark "this
|
||||
page"_Commands.html since it gives quick access to a doc page for
|
||||
every LAMMPS command.
|
||||
|
||||
<!-- RST
|
||||
|
||||
.. toctree::
|
||||
|
|
@ -108,25 +68,23 @@ it gives quick access to documentation for all LAMMPS commands.
|
|||
:name: userdoc
|
||||
:includehidden:
|
||||
|
||||
Section_intro
|
||||
Intro
|
||||
Section_start
|
||||
Section_commands
|
||||
Packages
|
||||
Speed
|
||||
Section_howto
|
||||
Howto
|
||||
Examples
|
||||
Tools
|
||||
Modify
|
||||
Python
|
||||
Errors
|
||||
Section_history
|
||||
|
||||
.. toctree::
|
||||
:caption: Index
|
||||
:name: index
|
||||
:hidden:
|
||||
|
||||
tutorials
|
||||
commands
|
||||
fixes
|
||||
computes
|
||||
|
|
@ -145,12 +103,7 @@ Indices and tables
|
|||
END_RST -->
|
||||
|
||||
<!-- HTML_ONLY -->
|
||||
"Introduction"_Section_intro.html :olb,l
|
||||
1.1 "What is LAMMPS"_intro_1 :ulb,b
|
||||
1.2 "LAMMPS features"_intro_2 :b
|
||||
1.3 "LAMMPS non-features"_intro_3 :b
|
||||
1.4 "Open source distribution"_intro_4 :b
|
||||
1.5 "Acknowledgments and citations"_intro_5 :ule,b
|
||||
"Introduction"_Intro.html :olb,l
|
||||
"Getting started"_Section_start.html :l
|
||||
2.1 "What's in the LAMMPS distribution"_start_1 :ulb,b
|
||||
2.2 "Making LAMMPS"_start_2 :b
|
||||
|
|
@ -168,50 +121,14 @@ END_RST -->
|
|||
3.5 "Commands listed alphabetically"_cmd_5 :ule,b
|
||||
"Optional packages"_Packages.html :l
|
||||
"Accelerate performance"_Speed.html :l
|
||||
"How-to discussions"_Section_howto.html :l
|
||||
6.1 "Restarting a simulation"_howto_1 :ulb,b
|
||||
6.2 "2d simulations"_howto_2 :b
|
||||
6.3 "CHARMM and AMBER force fields"_howto_3 :b
|
||||
6.4 "Running multiple simulations from one input script"_howto_4 :b
|
||||
6.5 "Multi-replica simulations"_howto_5 :b
|
||||
6.6 "Granular models"_howto_6 :b
|
||||
6.7 "TIP3P water model"_howto_7 :b
|
||||
6.8 "TIP4P water model"_howto_8 :b
|
||||
6.9 "SPC water model"_howto_9 :b
|
||||
6.10 "Coupling LAMMPS to other codes"_howto_10 :b
|
||||
6.11 "Visualizing LAMMPS snapshots"_howto_11 :b
|
||||
6.12 "Triclinic (non-orthogonal) simulation boxes"_howto_12 :b
|
||||
6.13 "NEMD simulations"_howto_13 :b
|
||||
6.14 "Finite-size spherical and aspherical particles"_howto_14 :b
|
||||
6.15 "Output from LAMMPS (thermo, dumps, computes, fixes, variables)"_howto_15 :b
|
||||
6.16 "Thermostatting, barostatting, and compute temperature"_howto_16 :b
|
||||
6.17 "Walls"_howto_17 :b
|
||||
6.18 "Elastic constants"_howto_18 :b
|
||||
6.19 "Library interface to LAMMPS"_howto_19 :b
|
||||
6.20 "Calculating thermal conductivity"_howto_20 :b
|
||||
6.21 "Calculating viscosity"_howto_21 :b
|
||||
6.22 "Calculating a diffusion coefficient"_howto_22 :b
|
||||
6.23 "Using chunks to calculate system properties"_howto_23 :b
|
||||
6.24 "Setting parameters for pppm/disp"_howto_24 :b
|
||||
6.25 "Polarizable models"_howto_25 :b
|
||||
6.26 "Adiabatic core/shell model"_howto_26 :b
|
||||
6.27 "Drude induced dipoles"_howto_27 :ule,b
|
||||
"How-to discussions"_Howto.html :l
|
||||
"Example scripts"_Examples.html :l
|
||||
"Auxiliary tools"_Tools.html :l
|
||||
"Modify & extend LAMMPS"_Modify.html :l
|
||||
"Use Python with LAMMPS"_Python.html :l
|
||||
"Errors"_Errors.html :l
|
||||
"Future and history"_Section_history.html :l
|
||||
13.1 "Coming attractions"_hist_1 :ulb,b
|
||||
13.2 "Past versions"_hist_2 :ule,b
|
||||
:ole
|
||||
|
||||
:link(intro_1,Section_intro.html#intro_1)
|
||||
:link(intro_2,Section_intro.html#intro_2)
|
||||
:link(intro_3,Section_intro.html#intro_3)
|
||||
:link(intro_4,Section_intro.html#intro_4)
|
||||
:link(intro_5,Section_intro.html#intro_5)
|
||||
|
||||
:link(start_1,Section_start.html#start_1)
|
||||
:link(start_2,Section_start.html#start_2)
|
||||
:link(start_3,Section_start.html#start_3)
|
||||
|
|
@ -227,36 +144,6 @@ END_RST -->
|
|||
:link(cmd_4,Section_commands.html#cmd_4)
|
||||
:link(cmd_5,Section_commands.html#cmd_5)
|
||||
|
||||
:link(howto_1,Section_howto.html#howto_1)
|
||||
:link(howto_2,Section_howto.html#howto_2)
|
||||
:link(howto_3,Section_howto.html#howto_3)
|
||||
:link(howto_4,Section_howto.html#howto_4)
|
||||
:link(howto_5,Section_howto.html#howto_5)
|
||||
:link(howto_6,Section_howto.html#howto_6)
|
||||
:link(howto_7,Section_howto.html#howto_7)
|
||||
:link(howto_8,Section_howto.html#howto_8)
|
||||
:link(howto_9,Section_howto.html#howto_9)
|
||||
:link(howto_10,Section_howto.html#howto_10)
|
||||
:link(howto_11,Section_howto.html#howto_11)
|
||||
:link(howto_12,Section_howto.html#howto_12)
|
||||
:link(howto_13,Section_howto.html#howto_13)
|
||||
:link(howto_14,Section_howto.html#howto_14)
|
||||
:link(howto_15,Section_howto.html#howto_15)
|
||||
:link(howto_16,Section_howto.html#howto_16)
|
||||
:link(howto_17,Section_howto.html#howto_17)
|
||||
:link(howto_18,Section_howto.html#howto_18)
|
||||
:link(howto_19,Section_howto.html#howto_19)
|
||||
:link(howto_20,Section_howto.html#howto_20)
|
||||
:link(howto_21,Section_howto.html#howto_21)
|
||||
:link(howto_22,Section_howto.html#howto_22)
|
||||
:link(howto_23,Section_howto.html#howto_23)
|
||||
:link(howto_24,Section_howto.html#howto_24)
|
||||
:link(howto_25,Section_howto.html#howto_25)
|
||||
:link(howto_26,Section_howto.html#howto_26)
|
||||
:link(howto_27,Section_howto.html#howto_27)
|
||||
|
||||
:link(hist_1,Section_history.html#hist_1)
|
||||
:link(hist_2,Section_history.html#hist_2)
|
||||
<!-- END_HTML_ONLY -->
|
||||
|
||||
</BODY>
|
||||
|
|
|
|||
|
|
@ -0,0 +1,33 @@
|
|||
"Higher level section"_Manual.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
What does a LAMMPS version mean: :h3
|
||||
|
||||
The LAMMPS "version" is the date when it was released, such as 1 May
|
||||
2014. LAMMPS is updated continuously. Whenever we fix a bug or add a
|
||||
feature, we release it in the next {patch} release, which are
|
||||
typically made every couple of weeks. Info on patch releases are on
|
||||
"this website page"_http://lammps.sandia.gov/bug.html. Every few
|
||||
months, the latest patch release is subjected to more thorough testing
|
||||
and labeled as a {stable} version.
|
||||
|
||||
Each version of LAMMPS contains all the features and bug-fixes up to
|
||||
and including its version date.
|
||||
|
||||
The version date is printed to the screen and logfile every time you
|
||||
run LAMMPS. It is also in the file src/version.h and in the LAMMPS
|
||||
directory name created when you unpack a tarball. And it is on the
|
||||
first page of the "manual"_Manual.html.
|
||||
|
||||
If you browse the HTML doc pages on the LAMMPS WWW site, they always
|
||||
describe the most current patch release of LAMMPS. :ulb,l
|
||||
|
||||
If you browse the HTML doc pages included in your tarball, they
|
||||
describe the version you have, which may be older. :l,ule
|
||||
|
||||
|
|
@ -14,10 +14,9 @@ Body particles can represent complex entities, such as surface meshes
|
|||
of discrete points, collections of sub-particles, deformable objects,
|
||||
etc.
|
||||
|
||||
See "Section 6.14"_Section_howto.html#howto_14 of the manual for
|
||||
an overview of using body particles and the "body"_body.html doc page
|
||||
for details on the various body styles LAMMPS supports. New styles
|
||||
can be created to add new kinds of body particles to LAMMPS.
|
||||
See the "Howto body"_Howto_body.html doc page for an overview of using
|
||||
body particles and the various body styles LAMMPS supports. New
|
||||
styles can be created to add new kinds of body particles to LAMMPS.
|
||||
|
||||
Body_nparticle.cpp is an example of a body particle that is treated as
|
||||
a rigid body containing N sub-particles.
|
||||
|
|
|
|||
|
|
@ -32,14 +32,14 @@ How quickly your contribution will be integrated depends largely on
|
|||
how much effort it will cause to integrate and test it, how much it
|
||||
requires changes to the core codebase, and of how much interest it is
|
||||
to the larger LAMMPS community. Please see below for a checklist of
|
||||
typical requirements. Once you have prepared everything, see "this
|
||||
tutorial"_tutorial_github.html for instructions on how to submit your
|
||||
changes or new files through a GitHub pull request. If you prefer to
|
||||
submit patches or full files, you should first make certain, that your
|
||||
code works correctly with the latest patch-level version of LAMMPS and
|
||||
contains all bugfixes from it. Then create a gzipped tar file of all
|
||||
changed or added files or a corresponding patch file using 'diff -u'
|
||||
or 'diff -c' and compress it with gzip. Please only use gzip
|
||||
typical requirements. Once you have prepared everything, see the
|
||||
"Howto github"_Howto_github.html doc page for instructions on how to
|
||||
submit your changes or new files through a GitHub pull request. If you
|
||||
prefer to submit patches or full files, you should first make certain,
|
||||
that your code works correctly with the latest patch-level version of
|
||||
LAMMPS and contains all bugfixes from it. Then create a gzipped tar
|
||||
file of all changed or added files or a corresponding patch file using
|
||||
'diff -u' or 'diff -c' and compress it with gzip. Please only use gzip
|
||||
compression, as this works well on all platforms.
|
||||
|
||||
If the new features/files are broadly useful we may add them as core
|
||||
|
|
@ -54,8 +54,9 @@ packages by typing "make package" in the LAMMPS src directory.
|
|||
|
||||
Note that by providing us files to release, you are agreeing to make
|
||||
them open-source, i.e. we can release them under the terms of the GPL,
|
||||
used as a license for the rest of LAMMPS. See "Section
|
||||
1.4"_Section_intro.html#intro_4 for details.
|
||||
used as a license for the rest of LAMMPS. See the "Open
|
||||
source"_http://lammps.sandia.gov/open_source.html page on the LAMMPS
|
||||
website for details.
|
||||
|
||||
With user packages and files, all we are really providing (aside from
|
||||
the fame and fortune that accompanies having your name in the source
|
||||
|
|
|
|||
|
|
@ -112,7 +112,7 @@ make machine :pre
|
|||
[Supporting info:]
|
||||
|
||||
src/ASPHERE: filenames -> commands
|
||||
"Section 6.14"_Section_howto.html#howto_14
|
||||
"Howto spherical"_Howto_spherical.html
|
||||
"pair_style gayberne"_pair_gayberne.html
|
||||
"pair_style resquared"_pair_resquared.html
|
||||
"doc/PDF/pair_gayberne_extra.pdf"_PDF/pair_gayberne_extra.pdf
|
||||
|
|
@ -130,7 +130,8 @@ BODY package :link(BODY),h4
|
|||
|
||||
Body-style particles with internal structure. Computes,
|
||||
time-integration fixes, pair styles, as well as the body styles
|
||||
themselves. See the "body"_body.html doc page for an overview.
|
||||
themselves. See the "Howto body"_Howto_body.html doc page for an
|
||||
overview.
|
||||
|
||||
[Install or un-install:]
|
||||
|
||||
|
|
@ -143,7 +144,7 @@ make machine :pre
|
|||
[Supporting info:]
|
||||
|
||||
src/BODY filenames -> commands
|
||||
"body"_body.html
|
||||
"Howto_body"_Howto_body.html
|
||||
"atom_style body"_atom_style.html
|
||||
"fix nve/body"_fix_nve_body.html
|
||||
"pair_style body"_pair_body.html
|
||||
|
|
@ -258,9 +259,9 @@ Compute and pair styles that implement the adiabatic core/shell model
|
|||
for polarizability. The pair styles augment Born, Buckingham, and
|
||||
Lennard-Jones styles with core/shell capabilities. The "compute
|
||||
temp/cs"_compute_temp_cs.html command calculates the temperature of a
|
||||
system with core/shell particles. See "Section
|
||||
6.26"_Section_howto.html#howto_26 for an overview of how to use this
|
||||
package.
|
||||
system with core/shell particles. See the "Howto
|
||||
coreshell"_Howto_coreshell.html doc page for an overview of how to use
|
||||
this package.
|
||||
|
||||
[Author:] Hendrik Heenen (Technical U of Munich).
|
||||
|
||||
|
|
@ -275,8 +276,8 @@ make machine :pre
|
|||
[Supporting info:]
|
||||
|
||||
src/CORESHELL: filenames -> commands
|
||||
"Section 6.26"_Section_howto.html#howto_26
|
||||
"Section 6.25"_Section_howto.html#howto_25
|
||||
"Howto coreshell"_Howto_coreshell.html
|
||||
"Howto polarizable"_Howto_polarizable.html
|
||||
"compute temp/cs"_compute_temp_cs.html
|
||||
"pair_style born/coul/long/cs"_pair_cs.html
|
||||
"pair_style buck/coul/long/cs"_pair_cs.html
|
||||
|
|
@ -418,7 +419,7 @@ make machine :pre
|
|||
[Supporting info:]
|
||||
|
||||
src/GRANULAR: filenames -> commands
|
||||
"Section 6.6"_Section_howto.html#howto_6,
|
||||
"Howto granular"_Howto_granular.html
|
||||
"fix pour"_fix_pour.html
|
||||
"fix wall/gran"_fix_wall_gran.html
|
||||
"pair_style gran/hooke"_pair_gran.html
|
||||
|
|
@ -625,9 +626,9 @@ make machine :pre
|
|||
src/KSPACE: filenames -> commands
|
||||
"kspace_style"_kspace_style.html
|
||||
"doc/PDF/kspace.pdf"_PDF/kspace.pdf
|
||||
"Section 6.7"_Section_howto.html#howto_7
|
||||
"Section 6.8"_Section_howto.html#howto_8
|
||||
"Section 6.9"_Section_howto.html#howto_9
|
||||
"Howto tip3p"_Howto_tip3p.html
|
||||
"Howto tip4p"_Howto_tip4p.html
|
||||
"Howto spc"_Howto_spc.html
|
||||
"pair_style coul"_pair_coul.html
|
||||
Pair Styles section of "Section 3.5"_Section_commands.html#cmd_5 with "long" or "msm" in pair style name
|
||||
examples/peptide
|
||||
|
|
@ -876,7 +877,7 @@ src/MOLECULE: filenames -> commands
|
|||
"improper_style"_improper_style.html
|
||||
"pair_style hbond/dreiding/lj"_pair_hbond_dreiding.html
|
||||
"pair_style lj/charmm/coul/charmm"_pair_charmm.html
|
||||
"Section 6.3"_Section_howto.html#howto_3
|
||||
"Howto bioFF"_Howto_bioFF.html
|
||||
examples/cmap
|
||||
examples/dreiding
|
||||
examples/micelle,
|
||||
|
|
@ -1114,10 +1115,10 @@ PYTHON package :link(PYTHON),h4
|
|||
|
||||
A "python"_python.html command which allow you to execute Python code
|
||||
from a LAMMPS input script. The code can be in a separate file or
|
||||
embedded in the input script itself. See "Section
|
||||
11.2"_Section_python.html#py_2 for an overview of using Python from
|
||||
LAMMPS in this manner and the entire section for other ways to use
|
||||
LAMMPS and Python together.
|
||||
embedded in the input script itself. See the "Python
|
||||
call"_Python_call.html doc page for an overview of using Python from
|
||||
LAMMPS in this manner and all the "Python"_Python.html doc pages for
|
||||
other ways to use LAMMPS and Python together.
|
||||
|
||||
[Install or un-install:]
|
||||
|
||||
|
|
@ -1138,7 +1139,7 @@ to Makefile.lammps) if the LAMMPS build fails.
|
|||
[Supporting info:]
|
||||
|
||||
src/PYTHON: filenames -> commands
|
||||
"Section 11"_Section_python.html
|
||||
"Python call"_Python.html
|
||||
lib/python/README
|
||||
examples/python :ul
|
||||
|
||||
|
|
@ -1228,8 +1229,8 @@ REPLICA package :link(REPLICA),h4
|
|||
[Contents:]
|
||||
|
||||
A collection of multi-replica methods which can be used when running
|
||||
multiple LAMMPS simulations (replicas). See "Section
|
||||
6.5"_Section_howto.html#howto_5 for an overview of how to run
|
||||
multiple LAMMPS simulations (replicas). See the "Howto
|
||||
replica"_Howto_replica.html doc page for an overview of how to run
|
||||
multi-replica simulations in LAMMPS. Methods in the package include
|
||||
nudged elastic band (NEB), parallel replica dynamics (PRD),
|
||||
temperature accelerated dynamics (TAD), parallel tempering, and a
|
||||
|
|
@ -1248,7 +1249,7 @@ make machine :pre
|
|||
[Supporting info:]
|
||||
|
||||
src/REPLICA: filenames -> commands
|
||||
"Section 6.5"_Section_howto.html#howto_5
|
||||
"Howto replica"_Howto_replica.html
|
||||
"neb"_neb.html
|
||||
"prd"_prd.html
|
||||
"tad"_tad.html
|
||||
|
|
@ -1798,10 +1799,10 @@ USER-DRUDE package :link(USER-DRUDE),h4
|
|||
[Contents:]
|
||||
|
||||
Fixes, pair styles, and a compute to simulate thermalized Drude
|
||||
oscillators as a model of polarization. See "Section
|
||||
6.27"_Section_howto.html#howto_27 for an overview of how to use the
|
||||
package. There are auxiliary tools for using this package in
|
||||
tools/drude.
|
||||
oscillators as a model of polarization. See the "Howto
|
||||
drude"_Howto_drude.html and "Howto drude2"_Howto_drude2.html doc pages
|
||||
for an overview of how to use the package. There are auxiliary tools
|
||||
for using this package in tools/drude.
|
||||
|
||||
[Authors:] Alain Dequidt (U Blaise Pascal Clermont-Ferrand), Julien
|
||||
Devemy (CNRS), and Agilio Padua (U Blaise Pascal).
|
||||
|
|
@ -1817,8 +1818,9 @@ make machine :pre
|
|||
[Supporting info:]
|
||||
|
||||
src/USER-DRUDE: filenames -> commands
|
||||
"Section 6.27"_Section_howto.html#howto_27
|
||||
"Section 6.25"_Section_howto.html#howto_25
|
||||
"Howto drude"_Howto_drude.html
|
||||
"Howto drude2"_Howto_drude2.html
|
||||
"Howto polarizable"_Howto_polarizable.html
|
||||
src/USER-DRUDE/README
|
||||
"fix drude"_fix_drude.html
|
||||
"fix drude/transform/*"_fix_drude_transform.html
|
||||
|
|
@ -2158,7 +2160,7 @@ make machine :pre
|
|||
|
||||
src/USER-MANIFOLD: filenames -> commands
|
||||
src/USER-MANIFOLD/README
|
||||
"doc/manifolds"_manifolds.html
|
||||
"Howto manifold"_Howto_manifold.html
|
||||
"fix manifoldforce"_fix_manifoldforce.html
|
||||
"fix nve/manifold/rattle"_fix_nve_manifold_rattle.html
|
||||
"fix nvt/manifold/rattle"_fix_nvt_manifold_rattle.html
|
||||
|
|
|
|||
|
|
@ -31,15 +31,15 @@ int = internal library: provided with LAMMPS, but you may need to build it
|
|||
ext = external library: you will need to download and install it on your machine :ul
|
||||
|
||||
Package, Description, Doc page, Example, Library
|
||||
"ASPHERE"_Packages_details.html#ASPHERE, aspherical particle models, "Section 6.6.14"_Section_howto.html#howto_14, ellipse, -
|
||||
"BODY"_Packages_details.html#BODY, body-style particles, "body"_body.html, body, -
|
||||
"ASPHERE"_Packages_details.html#ASPHERE, aspherical particle models, "Howto spherical"_Howto_spherical.html, ellipse, -
|
||||
"BODY"_Packages_details.html#BODY, body-style particles, "Howto body"_Howto_body.html, body, -
|
||||
"CLASS2"_Packages_details.html#CLASS2, class 2 force fields, "pair_style lj/class2"_pair_class2.html, -, -
|
||||
"COLLOID"_Packages_details.html#COLLOID, colloidal particles, "atom_style colloid"_atom_style.html, colloid, -
|
||||
"COMPRESS"_Packages_details.html#COMPRESS, I/O compression, "dump */gz"_dump.html, -, sys
|
||||
"CORESHELL"_Packages_details.html#CORESHELL, adiabatic core/shell model, "Section 6.6.25"_Section_howto.html#howto_25, coreshell, -
|
||||
"CORESHELL"_Packages_details.html#CORESHELL, adiabatic core/shell model, "Howto coreshell"_Howto_coreshell.html, coreshell, -
|
||||
"DIPOLE"_Packages_details.html#DIPOLE, point dipole particles, "pair_style dipole/cut"_pair_dipole.html, dipole, -
|
||||
"GPU"_Packages_details.html#GPU, GPU-enabled styles, "Section gpu"_Speed_gpu.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, int
|
||||
"GRANULAR"_Packages_details.html#GRANULAR, granular systems, "Section 6.6.6"_Section_howto.html#howto_6, pour, -
|
||||
"GRANULAR"_Packages_details.html#GRANULAR, granular systems, "Howto granular"_Howto_granular.html, pour, -
|
||||
"KIM"_Packages_details.html#KIM, OpenKIM wrapper, "pair_style kim"_pair_kim.html, kim, ext
|
||||
"KOKKOS"_Packages_details.html#KOKKOS, Kokkos-enabled styles, "Speed kokkos"_Speed_kokkos.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
|
||||
"KSPACE"_Packages_details.html#KSPACE, long-range Coulombic solvers, "kspace_style"_kspace_style.html, peptide, -
|
||||
|
|
@ -48,7 +48,7 @@ Package, Description, Doc page, Example, Library
|
|||
"MC"_Packages_details.html#MC, Monte Carlo options, "fix gcmc"_fix_gcmc.html, -, -
|
||||
"MEAM"_Packages_details.html#MEAM, modified EAM potential, "pair_style meam"_pair_meam.html, meam, int
|
||||
"MISC"_Packages_details.html#MISC, miscellanous single-file commands, -, -, -
|
||||
"MOLECULE"_Packages_details.html#MOLECULE, molecular system force fields, "Section 6.6.3"_Section_howto.html#howto_3, peptide, -
|
||||
"MOLECULE"_Packages_details.html#MOLECULE, molecular system force fields, "Howto bioFF"_Howto_bioFF.html, peptide, -
|
||||
"MPIIO"_Packages_details.html#MPIIO, MPI parallel I/O dump and restart, "dump"_dump.html, -, -
|
||||
"MSCG"_Packages_details.html#MSCG, multi-scale coarse-graining wrapper, "fix mscg"_fix_mscg.html, mscg, ext
|
||||
"OPT"_Packages_details.html#OPT, optimized pair styles, "Speed opt"_Speed_opt.html, "Benchmarks"_http://lammps.sandia.gov/bench.html, -
|
||||
|
|
@ -57,7 +57,7 @@ Package, Description, Doc page, Example, Library
|
|||
"PYTHON"_Packages_details.html#PYTHON, embed Python code in an input script, "python"_python.html, python, sys
|
||||
"QEQ"_Packages_details.html#QEQ, QEq charge equilibration, "fix qeq"_fix_qeq.html, qeq, -
|
||||
"REAX"_Packages_details.html#REAX, ReaxFF potential (Fortran), "pair_style reax"_pair_reax.html, reax, int
|
||||
"REPLICA"_Packages_details.html#REPLICA, multi-replica methods, "Section 6.6.5"_Section_howto.html#howto_5, tad, -
|
||||
"REPLICA"_Packages_details.html#REPLICA, multi-replica methods, "Howto replica"_Howto_replica.html, tad, -
|
||||
"RIGID"_Packages_details.html#RIGID, rigid bodies and constraints, "fix rigid"_fix_rigid.html, rigid, -
|
||||
"SHOCK"_Packages_details.html#SHOCK, shock loading methods, "fix msst"_fix_msst.html, -, -
|
||||
"SNAP"_Packages_details.html#SNAP, quantum-fitted potential, "pair_style snap"_pair_snap.html, snap, -
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ Package, Description, Doc page, Example, Library
|
|||
"USER-COLVARS"_Packages_details.html#USER-COLVARS, collective variables library, "fix colvars"_fix_colvars.html, USER/colvars, int
|
||||
"USER-DIFFRACTION"_Packages_details.html#USER-DIFFRACTION, virtual x-ray and electron diffraction,"compute xrd"_compute_xrd.html, USER/diffraction, -
|
||||
"USER-DPD"_Packages_details.html#USER-DPD, reactive dissipative particle dynamics, src/USER-DPD/README, USER/dpd, -
|
||||
"USER-DRUDE"_Packages_details.html#USER-DRUDE, Drude oscillators, "tutorial"_tutorial_drude.html, USER/drude, -
|
||||
"USER-DRUDE"_Packages_details.html#USER-DRUDE, Drude oscillators, "Howto drude"_Howto_drude.html, USER/drude, -
|
||||
"USER-EFF"_Packages_details.html#USER-EFF, electron force field,"pair_style eff/cut"_pair_eff.html, USER/eff, -
|
||||
"USER-FEP"_Packages_details.html#USER-FEP, free energy perturbation,"compute fep"_compute_fep.html, USER/fep, -
|
||||
"USER-H5MD"_Packages_details.html#USER-H5MD, dump output via HDF5,"dump h5md"_dump_h5md.html, -, ext
|
||||
|
|
|
|||
|
|
@ -21,8 +21,8 @@ from lammps import lammps :pre
|
|||
These are the methods defined by the lammps module. If you look at
|
||||
the files src/library.cpp and src/library.h you will see they
|
||||
correspond one-to-one with calls you can make to the LAMMPS library
|
||||
from a C++ or C or Fortran program, and which are described in
|
||||
"Section 6.19"_Section_howto.html#howto_19 of the manual.
|
||||
from a C++ or C or Fortran program, and which are described on the
|
||||
"Howto library"_Howto_library.html doc page.
|
||||
|
||||
The python/examples directory has Python scripts which show how Python
|
||||
can run LAMMPS, grab data, change it, and put it back into LAMMPS.
|
||||
|
|
@ -165,11 +165,11 @@ subscripting. The one exception is that for a fix that calculates a
|
|||
global vector or array, a single double value from the vector or array
|
||||
is returned, indexed by I (vector) or I and J (array). I,J are
|
||||
zero-based indices. The I,J arguments can be left out if not needed.
|
||||
See "Section 6.15"_Section_howto.html#howto_15 of the manual for a
|
||||
discussion of global, per-atom, and local data, and of scalar, vector,
|
||||
and array data types. See the doc pages for individual
|
||||
"computes"_compute.html and "fixes"_fix.html for a description of what
|
||||
they calculate and store.
|
||||
See the "Howto output"_Howto_output.html doc page for a discussion of
|
||||
global, per-atom, and local data, and of scalar, vector, and array
|
||||
data types. See the doc pages for individual "computes"_compute.html
|
||||
and "fixes"_fix.html for a description of what they calculate and
|
||||
store.
|
||||
|
||||
For extract_variable(), an "equal-style or atom-style
|
||||
variable"_variable.html is evaluated and its result returned.
|
||||
|
|
|
|||
|
|
@ -10,5 +10,5 @@ Documentation"_ld - "LAMMPS Commands"_lc :c
|
|||
PyLammps interface :h3
|
||||
|
||||
PyLammps is a Python wrapper class which can be created on its own or
|
||||
use an existing lammps Python object. It has its own "PyLammps
|
||||
Tutorial"_tutorial_pylammps.html doc page.
|
||||
use an existing lammps Python object. It has its own "Howto
|
||||
pylammps"_Howto_pylammps.html doc page.
|
||||
|
|
|
|||
|
|
@ -1,135 +0,0 @@
|
|||
"Previous Section"_Errors.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
|
||||
Section"_Manual.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
13. Future and history :h2
|
||||
|
||||
This section lists features we plan to add to LAMMPS, features of
|
||||
previous versions of LAMMPS, and features of other parallel molecular
|
||||
dynamics codes our group has distributed.
|
||||
|
||||
13.1 "Coming attractions"_#hist_1
|
||||
13.2 "Past versions"_#hist_2 :all(b)
|
||||
|
||||
:line
|
||||
:line
|
||||
|
||||
13.1 Coming attractions :h3,link(hist_1)
|
||||
|
||||
As of summer 2016 we are using the "LAMMPS project issue tracker
|
||||
on GitHub"_https://github.com/lammps/lammps/issues for keeping
|
||||
track of suggested, planned or pending new features. This includes
|
||||
discussions of how to best implement them, or why they would be
|
||||
useful. Especially if a planned or proposed feature is non-trivial
|
||||
to add, e.g. because it requires changes to some of the core
|
||||
classes of LAMMPS, people planning to contribute a new feature to
|
||||
LAMMS are encouraged to submit an issue about their planned
|
||||
implementation this way in order to receive feedback from the
|
||||
LAMMPS core developers. They will provide suggestions about
|
||||
the validity of the proposed approach and possible improvements,
|
||||
pitfalls or alternatives.
|
||||
|
||||
Please see some of the closed issues for examples of how to
|
||||
suggest code enhancements, submit proposed changes, or report
|
||||
possible bugs and how they are resolved.
|
||||
|
||||
As an alternative to using GitHub, you may e-mail the
|
||||
"core developers"_http://lammps.sandia.gov/authors.html or send
|
||||
an e-mail to the "LAMMPS Mail list"_http://lammps.sandia.gov/mail.html
|
||||
if you want to have your suggestion added to the list.
|
||||
|
||||
:line
|
||||
|
||||
13.2 Past versions :h3,link(hist_2)
|
||||
|
||||
LAMMPS development began in the mid 1990s under a cooperative research
|
||||
& development agreement (CRADA) between two DOE labs (Sandia and LLNL)
|
||||
and 3 companies (Cray, Bristol Myers Squibb, and Dupont). The goal was
|
||||
to develop a large-scale parallel classical MD code; the coding effort
|
||||
was led by Steve Plimpton at Sandia.
|
||||
|
||||
After the CRADA ended, a final F77 version, LAMMPS 99, was
|
||||
released. As development of LAMMPS continued at Sandia, its memory
|
||||
management was converted to F90; a final F90 version was released as
|
||||
LAMMPS 2001.
|
||||
|
||||
The current LAMMPS is a rewrite in C++ and was first publicly released
|
||||
as an open source code in 2004. It includes many new features beyond
|
||||
those in LAMMPS 99 or 2001. It also includes features from older
|
||||
parallel MD codes written at Sandia, namely ParaDyn, Warp, and
|
||||
GranFlow (see below).
|
||||
|
||||
In late 2006 we began merging new capabilities into LAMMPS that were
|
||||
developed by Aidan Thompson at Sandia for his MD code GRASP, which has
|
||||
a parallel framework similar to LAMMPS. Most notably, these have
|
||||
included many-body potentials - Stillinger-Weber, Tersoff, ReaxFF -
|
||||
and the associated charge-equilibration routines needed for ReaxFF.
|
||||
|
||||
The "History link"_http://lammps.sandia.gov/history.html on the
|
||||
LAMMPS WWW page gives a timeline of features added to the
|
||||
C++ open-source version of LAMMPS over the last several years.
|
||||
|
||||
These older codes are available for download from the "LAMMPS WWW
|
||||
site"_lws, except for Warp & GranFlow which were primarily used
|
||||
internally. A brief listing of their features is given here.
|
||||
|
||||
LAMMPS 2001
|
||||
|
||||
F90 + MPI
|
||||
dynamic memory
|
||||
spatial-decomposition parallelism
|
||||
NVE, NVT, NPT, NPH, rRESPA integrators
|
||||
LJ and Coulombic pairwise force fields
|
||||
all-atom, united-atom, bead-spring polymer force fields
|
||||
CHARMM-compatible force fields
|
||||
class 2 force fields
|
||||
3d/2d Ewald & PPPM
|
||||
various force and temperature constraints
|
||||
SHAKE
|
||||
Hessian-free truncated-Newton minimizer
|
||||
user-defined diagnostics :ul
|
||||
|
||||
LAMMPS 99
|
||||
|
||||
F77 + MPI
|
||||
static memory allocation
|
||||
spatial-decomposition parallelism
|
||||
most of the LAMMPS 2001 features with a few exceptions
|
||||
no 2d Ewald & PPPM
|
||||
molecular force fields are missing a few CHARMM terms
|
||||
no SHAKE :ul
|
||||
|
||||
Warp
|
||||
|
||||
F90 + MPI
|
||||
spatial-decomposition parallelism
|
||||
embedded atom method (EAM) metal potentials + LJ
|
||||
lattice and grain-boundary atom creation
|
||||
NVE, NVT integrators
|
||||
boundary conditions for applying shear stresses
|
||||
temperature controls for actively sheared systems
|
||||
per-atom energy and centro-symmetry computation and output :ul
|
||||
|
||||
ParaDyn
|
||||
|
||||
F77 + MPI
|
||||
atom- and force-decomposition parallelism
|
||||
embedded atom method (EAM) metal potentials
|
||||
lattice atom creation
|
||||
NVE, NVT, NPT integrators
|
||||
all serial DYNAMO features for controls and constraints :ul
|
||||
|
||||
GranFlow
|
||||
|
||||
F90 + MPI
|
||||
spatial-decomposition parallelism
|
||||
frictional granular potentials
|
||||
NVE integrator
|
||||
boundary conditions for granular flow and packing and walls
|
||||
particle insertion :ul
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -1,550 +0,0 @@
|
|||
"Previous Section"_Manual.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc - "Next
|
||||
Section"_Section_start.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
1. Introduction :h2
|
||||
|
||||
This section provides an overview of what LAMMPS can and can't do,
|
||||
describes what it means for LAMMPS to be an open-source code, and
|
||||
acknowledges the funding and people who have contributed to LAMMPS
|
||||
over the years.
|
||||
|
||||
1.1 "What is LAMMPS"_#intro_1
|
||||
1.2 "LAMMPS features"_#intro_2
|
||||
1.3 "LAMMPS non-features"_#intro_3
|
||||
1.4 "Open source distribution"_#intro_4
|
||||
1.5 "Acknowledgments and citations"_#intro_5 :all(b)
|
||||
|
||||
:line
|
||||
:line
|
||||
|
||||
1.1 What is LAMMPS :link(intro_1),h4
|
||||
|
||||
LAMMPS is a classical molecular dynamics code that models an ensemble
|
||||
of particles in a liquid, solid, or gaseous state. It can model
|
||||
atomic, polymeric, biological, metallic, granular, and coarse-grained
|
||||
systems using a variety of force fields and boundary conditions.
|
||||
|
||||
For examples of LAMMPS simulations, see the Publications page of the
|
||||
"LAMMPS WWW Site"_lws.
|
||||
|
||||
LAMMPS runs efficiently on single-processor desktop or laptop
|
||||
machines, but is designed for parallel computers. It will run on any
|
||||
parallel machine that compiles C++ and supports the "MPI"_mpi
|
||||
message-passing library. This includes distributed- or shared-memory
|
||||
parallel machines and Beowulf-style clusters.
|
||||
|
||||
:link(mpi,http://www-unix.mcs.anl.gov/mpi)
|
||||
|
||||
LAMMPS can model systems with only a few particles up to millions or
|
||||
billions. See "Section 8"_Section_perf.html for information on
|
||||
LAMMPS performance and scalability, or the Benchmarks section of the
|
||||
"LAMMPS WWW Site"_lws.
|
||||
|
||||
LAMMPS is a freely-available open-source code, distributed under the
|
||||
terms of the "GNU Public License"_gnu, which means you can use or
|
||||
modify the code however you wish. See "this section"_#intro_4 for a
|
||||
brief discussion of the open-source philosophy.
|
||||
|
||||
:link(gnu,http://www.gnu.org/copyleft/gpl.html)
|
||||
|
||||
LAMMPS is designed to be easy to modify or extend with new
|
||||
capabilities, such as new force fields, atom types, boundary
|
||||
conditions, or diagnostics. See the "Modify"_Modify.html doc page for
|
||||
more details.
|
||||
|
||||
The current version of LAMMPS is written in C++. Earlier versions
|
||||
were written in F77 and F90. See
|
||||
"Section 13"_Section_history.html for more information on
|
||||
different versions. All versions can be downloaded from the "LAMMPS
|
||||
WWW Site"_lws.
|
||||
|
||||
LAMMPS was originally developed under a US Department of Energy CRADA
|
||||
(Cooperative Research and Development Agreement) between two DOE labs
|
||||
and 3 companies. It is distributed by "Sandia National Labs"_snl.
|
||||
See "this section"_#intro_5 for more information on LAMMPS funding and
|
||||
individuals who have contributed to LAMMPS.
|
||||
|
||||
:link(snl,http://www.sandia.gov)
|
||||
|
||||
In the most general sense, LAMMPS integrates Newton's equations of
|
||||
motion for collections of atoms, molecules, or macroscopic particles
|
||||
that interact via short- or long-range forces with a variety of
|
||||
initial and/or boundary conditions. For computational efficiency
|
||||
LAMMPS uses neighbor lists to keep track of nearby particles. The
|
||||
lists are optimized for systems with particles that are repulsive at
|
||||
short distances, so that the local density of particles never becomes
|
||||
too large. On parallel machines, LAMMPS uses spatial-decomposition
|
||||
techniques to partition the simulation domain into small 3d
|
||||
sub-domains, one of which is assigned to each processor. Processors
|
||||
communicate and store "ghost" atom information for atoms that border
|
||||
their sub-domain. LAMMPS is most efficient (in a parallel sense) for
|
||||
systems whose particles fill a 3d rectangular box with roughly uniform
|
||||
density. Papers with technical details of the algorithms used in
|
||||
LAMMPS are listed in "this section"_#intro_5.
|
||||
|
||||
:line
|
||||
|
||||
1.2 LAMMPS features :link(intro_2),h4
|
||||
|
||||
This section highlights LAMMPS features, with pointers to specific
|
||||
commands which give more details. If LAMMPS doesn't have your
|
||||
favorite interatomic potential, boundary condition, or atom type, see
|
||||
the "Modify"_Modify.html doc page, which describes how you can add it
|
||||
to LAMMPS.
|
||||
|
||||
General features :h4
|
||||
|
||||
runs on a single processor or in parallel
|
||||
distributed-memory message-passing parallelism (MPI)
|
||||
spatial-decomposition of simulation domain for parallelism
|
||||
open-source distribution
|
||||
highly portable C++
|
||||
optional libraries used: MPI and single-processor FFT
|
||||
GPU (CUDA and OpenCL), Intel(R) Xeon Phi(TM) coprocessors, and OpenMP support for many code features
|
||||
easy to extend with new features and functionality
|
||||
runs from an input script
|
||||
syntax for defining and using variables and formulas
|
||||
syntax for looping over runs and breaking out of loops
|
||||
run one or multiple simulations simultaneously (in parallel) from one script
|
||||
build as library, invoke LAMMPS thru library interface or provided Python wrapper
|
||||
couple with other codes: LAMMPS calls other code, other code calls LAMMPS, umbrella code calls both :ul
|
||||
|
||||
Particle and model types :h4
|
||||
("atom style"_atom_style.html command)
|
||||
|
||||
atoms
|
||||
coarse-grained particles (e.g. bead-spring polymers)
|
||||
united-atom polymers or organic molecules
|
||||
all-atom polymers, organic molecules, proteins, DNA
|
||||
metals
|
||||
granular materials
|
||||
coarse-grained mesoscale models
|
||||
finite-size spherical and ellipsoidal particles
|
||||
finite-size line segment (2d) and triangle (3d) particles
|
||||
point dipole particles
|
||||
rigid collections of particles
|
||||
hybrid combinations of these :ul
|
||||
|
||||
Force fields :h4
|
||||
("pair style"_pair_style.html, "bond style"_bond_style.html,
|
||||
"angle style"_angle_style.html, "dihedral style"_dihedral_style.html,
|
||||
"improper style"_improper_style.html, "kspace style"_kspace_style.html
|
||||
commands)
|
||||
|
||||
pairwise potentials: Lennard-Jones, Buckingham, Morse, Born-Mayer-Huggins, \
|
||||
Yukawa, soft, class 2 (COMPASS), hydrogen bond, tabulated
|
||||
charged pairwise potentials: Coulombic, point-dipole
|
||||
manybody potentials: EAM, Finnis/Sinclair EAM, modified EAM (MEAM), \
|
||||
embedded ion method (EIM), EDIP, ADP, Stillinger-Weber, Tersoff, \
|
||||
REBO, AIREBO, ReaxFF, COMB, SNAP, Streitz-Mintmire, 3-body polymorphic
|
||||
long-range interactions for charge, point-dipoles, and LJ dispersion: \
|
||||
Ewald, Wolf, PPPM (similar to particle-mesh Ewald)
|
||||
polarization models: "QEq"_fix_qeq.html, \
|
||||
"core/shell model"_Section_howto.html#howto_26, \
|
||||
"Drude dipole model"_Section_howto.html#howto_27
|
||||
charge equilibration (QEq via dynamic, point, shielded, Slater methods)
|
||||
coarse-grained potentials: DPD, GayBerne, REsquared, colloidal, DLVO
|
||||
mesoscopic potentials: granular, Peridynamics, SPH
|
||||
electron force field (eFF, AWPMD)
|
||||
bond potentials: harmonic, FENE, Morse, nonlinear, class 2, \
|
||||
quartic (breakable)
|
||||
angle potentials: harmonic, CHARMM, cosine, cosine/squared, cosine/periodic, \
|
||||
class 2 (COMPASS)
|
||||
dihedral potentials: harmonic, CHARMM, multi-harmonic, helix, \
|
||||
class 2 (COMPASS), OPLS
|
||||
improper potentials: harmonic, cvff, umbrella, class 2 (COMPASS)
|
||||
polymer potentials: all-atom, united-atom, bead-spring, breakable
|
||||
water potentials: TIP3P, TIP4P, SPC
|
||||
implicit solvent potentials: hydrodynamic lubrication, Debye
|
||||
force-field compatibility with common CHARMM, AMBER, DREIDING, \
|
||||
OPLS, GROMACS, COMPASS options
|
||||
access to "KIM archive"_http://openkim.org of potentials via \
|
||||
"pair kim"_pair_kim.html
|
||||
hybrid potentials: multiple pair, bond, angle, dihedral, improper \
|
||||
potentials can be used in one simulation
|
||||
overlaid potentials: superposition of multiple pair potentials :ul
|
||||
|
||||
Atom creation :h4
|
||||
("read_data"_read_data.html, "lattice"_lattice.html,
|
||||
"create_atoms"_create_atoms.html, "delete_atoms"_delete_atoms.html,
|
||||
"displace_atoms"_displace_atoms.html, "replicate"_replicate.html commands)
|
||||
|
||||
read in atom coords from files
|
||||
create atoms on one or more lattices (e.g. grain boundaries)
|
||||
delete geometric or logical groups of atoms (e.g. voids)
|
||||
replicate existing atoms multiple times
|
||||
displace atoms :ul
|
||||
|
||||
Ensembles, constraints, and boundary conditions :h4
|
||||
("fix"_fix.html command)
|
||||
|
||||
2d or 3d systems
|
||||
orthogonal or non-orthogonal (triclinic symmetry) simulation domains
|
||||
constant NVE, NVT, NPT, NPH, Parinello/Rahman integrators
|
||||
thermostatting options for groups and geometric regions of atoms
|
||||
pressure control via Nose/Hoover or Berendsen barostatting in 1 to 3 dimensions
|
||||
simulation box deformation (tensile and shear)
|
||||
harmonic (umbrella) constraint forces
|
||||
rigid body constraints
|
||||
SHAKE bond and angle constraints
|
||||
Monte Carlo bond breaking, formation, swapping
|
||||
atom/molecule insertion and deletion
|
||||
walls of various kinds
|
||||
non-equilibrium molecular dynamics (NEMD)
|
||||
variety of additional boundary conditions and constraints :ul
|
||||
|
||||
Integrators :h4
|
||||
("run"_run.html, "run_style"_run_style.html, "minimize"_minimize.html commands)
|
||||
|
||||
velocity-Verlet integrator
|
||||
Brownian dynamics
|
||||
rigid body integration
|
||||
energy minimization via conjugate gradient or steepest descent relaxation
|
||||
rRESPA hierarchical timestepping
|
||||
rerun command for post-processing of dump files :ul
|
||||
|
||||
Diagnostics :h4
|
||||
|
||||
see the various flavors of the "fix"_fix.html and "compute"_compute.html commands :ul
|
||||
|
||||
Output :h4
|
||||
("dump"_dump.html, "restart"_restart.html commands)
|
||||
|
||||
log file of thermodynamic info
|
||||
text dump files of atom coords, velocities, other per-atom quantities
|
||||
binary restart files
|
||||
parallel I/O of dump and restart files
|
||||
per-atom quantities (energy, stress, centro-symmetry parameter, CNA, etc)
|
||||
user-defined system-wide (log file) or per-atom (dump file) calculations
|
||||
spatial and time averaging of per-atom quantities
|
||||
time averaging of system-wide quantities
|
||||
atom snapshots in native, XYZ, XTC, DCD, CFG formats :ul
|
||||
|
||||
Multi-replica models :h4
|
||||
|
||||
"nudged elastic band"_neb.html
|
||||
"parallel replica dynamics"_prd.html
|
||||
"temperature accelerated dynamics"_tad.html
|
||||
"parallel tempering"_temper.html
|
||||
|
||||
Pre- and post-processing :h4
|
||||
|
||||
Various pre- and post-processing serial tools are packaged with
|
||||
LAMMPS; see the "Tools"_Tools.html doc page for details. :ulb,l
|
||||
|
||||
Our group has also written and released a separate toolkit called
|
||||
"Pizza.py"_pizza which provides tools for doing setup, analysis,
|
||||
plotting, and visualization for LAMMPS simulations. Pizza.py is
|
||||
written in "Python"_python and is available for download from "the
|
||||
Pizza.py WWW site"_pizza. :l
|
||||
:ule
|
||||
|
||||
:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
|
||||
:link(python,http://www.python.org)
|
||||
|
||||
Specialized features :h4
|
||||
|
||||
LAMMPS can be built with optional packages which implement a variety
|
||||
of additional capabilities. An overview of all the packages is "given
|
||||
here"_Packages.html.
|
||||
|
||||
These are some LAMMPS capabilities which you may not think of as
|
||||
typical classical molecular dynamics options:
|
||||
|
||||
"static"_balance.html and "dynamic load-balancing"_fix_balance.html
|
||||
"generalized aspherical particles"_body.html
|
||||
"stochastic rotation dynamics (SRD)"_fix_srd.html
|
||||
"real-time visualization and interactive MD"_fix_imd.html
|
||||
calculate "virtual diffraction patterns"_compute_xrd.html
|
||||
"atom-to-continuum coupling"_fix_atc.html with finite elements
|
||||
coupled rigid body integration via the "POEMS"_fix_poems.html library
|
||||
"QM/MM coupling"_fix_qmmm.html
|
||||
"path-integral molecular dynamics (PIMD)"_fix_ipi.html and "this as well"_fix_pimd.html
|
||||
Monte Carlo via "GCMC"_fix_gcmc.html and "tfMC"_fix_tfmc.html "atom swapping"_fix_atom_swap.html and "bond swapping"_fix_bond_swap.html
|
||||
"Direct Simulation Monte Carlo"_pair_dsmc.html for low-density fluids
|
||||
"Peridynamics mesoscale modeling"_pair_peri.html
|
||||
"Lattice Boltzmann fluid"_fix_lb_fluid.html
|
||||
"targeted"_fix_tmd.html and "steered"_fix_smd.html molecular dynamics
|
||||
"two-temperature electron model"_fix_ttm.html :ul
|
||||
|
||||
:line
|
||||
|
||||
1.3 LAMMPS non-features :link(intro_3),h4
|
||||
|
||||
LAMMPS is designed to efficiently compute Newton's equations of motion
|
||||
for a system of interacting particles. Many of the tools needed to
|
||||
pre- and post-process the data for such simulations are not included
|
||||
in the LAMMPS kernel for several reasons:
|
||||
|
||||
the desire to keep LAMMPS simple
|
||||
they are not parallel operations
|
||||
other codes already do them
|
||||
limited development resources :ul
|
||||
|
||||
Specifically, LAMMPS itself does not:
|
||||
|
||||
run thru a GUI
|
||||
build molecular systems
|
||||
assign force-field coefficients automagically
|
||||
perform sophisticated analyses of your MD simulation
|
||||
visualize your MD simulation
|
||||
plot your output data :ul
|
||||
|
||||
A few tools for pre- and post-processing tasks are provided as part of
|
||||
the LAMMPS package; they are described on the "Tools"_Tools.html doc
|
||||
page. However, many people use other codes or write their own tools
|
||||
for these tasks.
|
||||
|
||||
As noted above, our group has also written and released a separate
|
||||
toolkit called "Pizza.py"_pizza which addresses some of the listed
|
||||
bullets. It provides tools for doing setup, analysis, plotting, and
|
||||
visualization for LAMMPS simulations. Pizza.py is written in
|
||||
"Python"_python and is available for download from "the Pizza.py WWW
|
||||
site"_pizza.
|
||||
|
||||
LAMMPS requires as input a list of initial atom coordinates and types,
|
||||
molecular topology information, and force-field coefficients assigned
|
||||
to all atoms and bonds. LAMMPS will not build molecular systems and
|
||||
assign force-field parameters for you.
|
||||
|
||||
For atomic systems LAMMPS provides a "create_atoms"_create_atoms.html
|
||||
command which places atoms on solid-state lattices (fcc, bcc,
|
||||
user-defined, etc). Assigning small numbers of force field
|
||||
coefficients can be done via the "pair coeff"_pair_coeff.html, "bond
|
||||
coeff"_bond_coeff.html, "angle coeff"_angle_coeff.html, etc commands.
|
||||
For molecular systems or more complicated simulation geometries, users
|
||||
typically use another code as a builder and convert its output to
|
||||
LAMMPS input format, or write their own code to generate atom
|
||||
coordinate and molecular topology for LAMMPS to read in.
|
||||
|
||||
For complicated molecular systems (e.g. a protein), a multitude of
|
||||
topology information and hundreds of force-field coefficients must
|
||||
typically be specified. We suggest you use a program like
|
||||
"CHARMM"_charmm or "AMBER"_amber or other molecular builders to setup
|
||||
such problems and dump its information to a file. You can then
|
||||
reformat the file as LAMMPS input. Some of the tools described on the
|
||||
"Tools"_Tools.html doc page can assist in this process.
|
||||
|
||||
Similarly, LAMMPS creates output files in a simple format. Most users
|
||||
post-process these files with their own analysis tools or re-format
|
||||
them for input into other programs, including visualization packages.
|
||||
If you are convinced you need to compute something on-the-fly as
|
||||
LAMMPS runs, see the "Modify"_Modify.html doc page for a discussion of
|
||||
how you can use the "dump"_dump.html and "compute"_compute.html and
|
||||
"fix"_fix.html commands to print out data of your choosing. Keep in
|
||||
mind that complicated computations can slow down the molecular
|
||||
dynamics timestepping, particularly if the computations are not
|
||||
parallel, so it is often better to leave such analysis to
|
||||
post-processing codes.
|
||||
|
||||
For high-quality visualization we recommend the
|
||||
following packages:
|
||||
|
||||
"VMD"_http://www.ks.uiuc.edu/Research/vmd
|
||||
"AtomEye"_http://mt.seas.upenn.edu/Archive/Graphics/A
|
||||
"OVITO"_http://www.ovito.org/
|
||||
"ParaView"_http://www.paraview.org/
|
||||
"PyMol"_http://www.pymol.org
|
||||
"Raster3d"_http://www.bmsc.washington.edu/raster3d/raster3d.html
|
||||
"RasMol"_http://www.openrasmol.org :ul
|
||||
|
||||
Other features that LAMMPS does not yet (and may never) support are
|
||||
discussed in "Section 13"_Section_history.html.
|
||||
|
||||
Finally, these are freely-available molecular dynamics codes, most of
|
||||
them parallel, which may be well-suited to the problems you want to
|
||||
model. They can also be used in conjunction with LAMMPS to perform
|
||||
complementary modeling tasks.
|
||||
|
||||
"CHARMM"_charmm
|
||||
"AMBER"_amber
|
||||
"NAMD"_namd
|
||||
"NWCHEM"_nwchem
|
||||
"DL_POLY"_dlpoly
|
||||
"Tinker"_tinker :ul
|
||||
|
||||
:link(charmm,http://www.charmm.org)
|
||||
:link(amber,http://ambermd.org)
|
||||
:link(namd,http://www.ks.uiuc.edu/Research/namd/)
|
||||
:link(nwchem,http://www.emsl.pnl.gov/docs/nwchem/nwchem.html)
|
||||
:link(dlpoly,http://www.ccp5.ac.uk/DL_POLY_CLASSIC)
|
||||
:link(tinker,http://dasher.wustl.edu/tinker)
|
||||
|
||||
CHARMM, AMBER, NAMD, NWCHEM, and Tinker are designed primarily for
|
||||
modeling biological molecules. CHARMM and AMBER use
|
||||
atom-decomposition (replicated-data) strategies for parallelism; NAMD
|
||||
and NWCHEM use spatial-decomposition approaches, similar to LAMMPS.
|
||||
Tinker is a serial code. DL_POLY includes potentials for a variety of
|
||||
biological and non-biological materials; both a replicated-data and
|
||||
spatial-decomposition version exist.
|
||||
|
||||
:line
|
||||
|
||||
1.4 Open source distribution :link(intro_4),h4
|
||||
|
||||
LAMMPS comes with no warranty of any kind. As each source file states
|
||||
in its header, it is a copyrighted code that is distributed free-of-
|
||||
charge, under the terms of the "GNU Public License"_gnu (GPL). This
|
||||
is often referred to as open-source distribution - see
|
||||
"www.gnu.org"_gnuorg or "www.opensource.org"_opensource for more
|
||||
details. The legal text of the GPL is in the LICENSE file that is
|
||||
included in the LAMMPS distribution.
|
||||
|
||||
:link(gnuorg,http://www.gnu.org)
|
||||
:link(opensource,http://www.opensource.org)
|
||||
|
||||
Here is a summary of what the GPL means for LAMMPS users:
|
||||
|
||||
(1) Anyone is free to use, modify, or extend LAMMPS in any way they
|
||||
choose, including for commercial purposes.
|
||||
|
||||
(2) If you distribute a modified version of LAMMPS, it must remain
|
||||
open-source, meaning you distribute it under the terms of the GPL.
|
||||
You should clearly annotate such a code as a derivative version of
|
||||
LAMMPS.
|
||||
|
||||
(3) If you release any code that includes LAMMPS source code, then it
|
||||
must also be open-sourced, meaning you distribute it under the terms
|
||||
of the GPL.
|
||||
|
||||
(4) If you give LAMMPS files to someone else, the GPL LICENSE file and
|
||||
source file headers (including the copyright and GPL notices) should
|
||||
remain part of the code.
|
||||
|
||||
In the spirit of an open-source code, these are various ways you can
|
||||
contribute to making LAMMPS better. You can send email to the
|
||||
"developers"_http://lammps.sandia.gov/authors.html on any of these
|
||||
items.
|
||||
|
||||
Point prospective users to the "LAMMPS WWW Site"_lws. Mention it in
|
||||
talks or link to it from your WWW site. :ulb,l
|
||||
|
||||
If you find an error or omission in this manual or on the "LAMMPS WWW
|
||||
Site"_lws, or have a suggestion for something to clarify or include,
|
||||
send an email to the
|
||||
"developers"_http://lammps.sandia.gov/authors.html. :l
|
||||
|
||||
If you find a bug, the "Errors bugs"_Errors_bugs.html doc page
|
||||
describes how to report it. :l
|
||||
|
||||
If you publish a paper using LAMMPS results, send the citation (and
|
||||
any cool pictures or movies if you like) to add to the Publications,
|
||||
Pictures, and Movies pages of the "LAMMPS WWW Site"_lws, with links
|
||||
and attributions back to you. :l
|
||||
|
||||
Create a new Makefile.machine that can be added to the src/MAKE
|
||||
directory. :l
|
||||
|
||||
The tools sub-directory of the LAMMPS distribution has various
|
||||
stand-alone codes for pre- and post-processing of LAMMPS data. More
|
||||
details are given on the "Tools"_Tools.html doc page. If you write a
|
||||
new tool that users will find useful, it can be added to the LAMMPS
|
||||
distribution. :l
|
||||
|
||||
LAMMPS is designed to be easy to extend with new code for features
|
||||
like potentials, boundary conditions, diagnostic computations, etc.
|
||||
The "Modify"_Modify.html doc page gives details. If you add a feature
|
||||
of general interest, it can be added to the LAMMPS distribution. :l
|
||||
|
||||
The Benchmark page of the "LAMMPS WWW Site"_lws lists LAMMPS
|
||||
performance on various platforms. The files needed to run the
|
||||
benchmarks are part of the LAMMPS distribution. If your machine is
|
||||
sufficiently different from those listed, your timing data can be
|
||||
added to the page. :l
|
||||
|
||||
You can send feedback for the User Comments page of the "LAMMPS WWW
|
||||
Site"_lws. It might be added to the page. No promises. :l
|
||||
|
||||
Cash. Small denominations, unmarked bills preferred. Paper sack OK.
|
||||
Leave on desk. VISA also accepted. Chocolate chip cookies
|
||||
encouraged. :l
|
||||
:ule
|
||||
|
||||
:line
|
||||
|
||||
1.5 Acknowledgments and citations :h3,link(intro_5)
|
||||
|
||||
LAMMPS development has been funded by the "US Department of
|
||||
Energy"_doe (DOE), through its CRADA, LDRD, ASCI, and Genomes-to-Life
|
||||
programs and its "OASCR"_oascr and "OBER"_ober offices.
|
||||
|
||||
Specifically, work on the latest version was funded in part by the US
|
||||
Department of Energy's Genomics:GTL program
|
||||
("www.doegenomestolife.org"_gtl) under the "project"_ourgtl, "Carbon
|
||||
Sequestration in Synechococcus Sp.: From Molecular Machines to
|
||||
Hierarchical Modeling".
|
||||
|
||||
:link(doe,http://www.doe.gov)
|
||||
:link(gtl,http://www.doegenomestolife.org)
|
||||
:link(ourgtl,http://www.genomes2life.org)
|
||||
:link(oascr,http://www.sc.doe.gov/ascr/home.html)
|
||||
:link(ober,http://www.er.doe.gov/production/ober/ober_top.html)
|
||||
|
||||
The following paper describe the basic parallel algorithms used in
|
||||
LAMMPS. If you use LAMMPS results in your published work, please cite
|
||||
this paper and include a pointer to the "LAMMPS WWW Site"_lws
|
||||
(http://lammps.sandia.gov):
|
||||
|
||||
S. Plimpton, [Fast Parallel Algorithms for Short-Range Molecular
|
||||
Dynamics], J Comp Phys, 117, 1-19 (1995).
|
||||
|
||||
Other papers describing specific algorithms used in LAMMPS are listed
|
||||
under the "Citing LAMMPS link"_http://lammps.sandia.gov/cite.html of
|
||||
the LAMMPS WWW page.
|
||||
|
||||
The "Publications link"_http://lammps.sandia.gov/papers.html on the
|
||||
LAMMPS WWW page lists papers that have cited LAMMPS. If your paper is
|
||||
not listed there for some reason, feel free to send us the info. If
|
||||
the simulations in your paper produced cool pictures or animations,
|
||||
we'll be pleased to add them to the
|
||||
"Pictures"_http://lammps.sandia.gov/pictures.html or
|
||||
"Movies"_http://lammps.sandia.gov/movies.html pages of the LAMMPS WWW
|
||||
site.
|
||||
|
||||
The primary LAMMPS developers are at Sandia National Labs and Temple University:
|
||||
|
||||
Steve Plimpton, sjplimp at sandia.gov
|
||||
Aidan Thompson, athomps at sandia.gov
|
||||
Stan Moore, stamoor at sandia.gov
|
||||
Axel Kohlmeyer, akohlmey at gmail.com :ul
|
||||
|
||||
Past primary developers include Paul Crozier and Mark Stevens,
|
||||
both at Sandia, and Ray Shan, now at Materials Design.
|
||||
|
||||
The following folks are responsible for significant contributions to
|
||||
the code, or other aspects of the LAMMPS development effort. Many of
|
||||
the packages they have written are somewhat unique to LAMMPS and the
|
||||
code would not be as general-purpose as it is without their expertise
|
||||
and efforts.
|
||||
|
||||
Axel Kohlmeyer (Temple U), akohlmey at gmail.com, SVN and Git repositories, indefatigable mail list responder, USER-CGSDK, USER-OMP, USER-COLVARS, USER-MOLFILE, USER-QMMM, USER-TALLY, and COMPRESS packages
|
||||
Roy Pollock (LLNL), Ewald and PPPM solvers
|
||||
Mike Brown (ORNL), brownw at ornl.gov, GPU and USER-INTEL package
|
||||
Greg Wagner (Sandia), gjwagne at sandia.gov, MEAM package for MEAM potential (superseded by USER-MEAMC)
|
||||
Mike Parks (Sandia), mlparks at sandia.gov, PERI package for Peridynamics
|
||||
Rudra Mukherjee (JPL), Rudranarayan.M.Mukherjee at jpl.nasa.gov, POEMS package for articulated rigid body motion
|
||||
Reese Jones (Sandia) and collaborators, rjones at sandia.gov, USER-ATC package for atom/continuum coupling
|
||||
Ilya Valuev (JIHT), valuev at physik.hu-berlin.de, USER-AWPMD package for wave-packet MD
|
||||
Christian Trott (U Tech Ilmenau), christian.trott at tu-ilmenau.de, USER-CUDA (obsoleted by KOKKOS) and KOKKOS packages
|
||||
Andres Jaramillo-Botero (Caltech), ajaramil at wag.caltech.edu, USER-EFF package for electron force field
|
||||
Christoph Kloss (JKU), Christoph.Kloss at jku.at, LIGGGHTS fork for granular models and granular/fluid coupling
|
||||
Metin Aktulga (LBL), hmaktulga at lbl.gov, USER-REAXC package for C version of ReaxFF
|
||||
Georg Gunzenmuller (EMI), georg.ganzenmueller at emi.fhg.de, USER-SMD and USER-SPH packages
|
||||
Colin Denniston (U Western Ontario), cdennist at uwo.ca, USER-LB package :ul
|
||||
|
||||
As discussed in "Section 13"_Section_history.html, LAMMPS
|
||||
originated as a cooperative project between DOE labs and industrial
|
||||
partners. Folks involved in the design and testing of the original
|
||||
version of LAMMPS were the following:
|
||||
|
||||
John Carpenter (Mayo Clinic, formerly at Cray Research)
|
||||
Terry Stouch (Lexicon Pharmaceuticals, formerly at Bristol Myers Squibb)
|
||||
Steve Lustig (Dupont)
|
||||
Jim Belak (LLNL) :ul
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
"Previous Section"_Section_intro.html - "LAMMPS WWW Site"_lws -
|
||||
"Previous Section"_Intro.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
|
||||
Section"_Section_commands.html :c
|
||||
|
||||
|
|
@ -934,9 +934,9 @@ Makefile.opt :ul
|
|||
|
||||
LAMMPS can be built as either a static or shared library, which can
|
||||
then be called from another application or a scripting language. See
|
||||
"this section"_Section_howto.html#howto_10 for more info on coupling
|
||||
LAMMPS to other codes. See the "Python"_Python.html doc page for more
|
||||
info on wrapping and running LAMMPS from Python.
|
||||
the "Howto couple"_Howto_couple.html doc page for more info on
|
||||
coupling LAMMPS to other codes. See the "Python"_Python.html doc page
|
||||
for more info on wrapping and running LAMMPS from Python.
|
||||
|
||||
Static library :h4
|
||||
|
||||
|
|
@ -1039,16 +1039,16 @@ src/library.cpp and src/library.h.
|
|||
|
||||
See the sample codes in examples/COUPLE/simple for examples of C++ and
|
||||
C and Fortran codes that invoke LAMMPS thru its library interface.
|
||||
There are other examples as well in the COUPLE directory which are
|
||||
discussed in "Section 6.10"_Section_howto.html#howto_10 of the manual.
|
||||
See the "Python"_Python.html doc page for a description of the Python
|
||||
wrapper provided with LAMMPS that operates through the LAMMPS library
|
||||
interface.
|
||||
There are other examples as well in the COUPLE directory which use
|
||||
coupling ideas discussed on the "Howto couple"_Howto_couple.html doc
|
||||
page. See the "Python"_Python.html doc page for a description of the
|
||||
Python wrapper provided with LAMMPS that operates through the LAMMPS
|
||||
library interface.
|
||||
|
||||
The files src/library.cpp and library.h define the C-style API for
|
||||
using LAMMPS as a library. See "Section
|
||||
6.19"_Section_howto.html#howto_19 of the manual for a description of the
|
||||
interface and how to extend it for your needs.
|
||||
using LAMMPS as a library. See the "Howto library"_Howto_library.html
|
||||
doc page for a description of the interface and how to extend it for
|
||||
your needs.
|
||||
|
||||
:line
|
||||
|
||||
|
|
@ -1391,16 +1391,16 @@ processors in all partitions must equal P. Thus the command
|
|||
"-partition 8x2 4 5" has 10 partitions and runs on a total of 25
|
||||
processors.
|
||||
|
||||
Running with multiple partitions can e useful for running
|
||||
"multi-replica simulations"_Section_howto.html#howto_5, where each
|
||||
replica runs on on one or a few processors. Note that with MPI
|
||||
installed on a machine (e.g. your desktop), you can run on more
|
||||
(virtual) processors than you have physical processors.
|
||||
Running with multiple partitions can be useful for running
|
||||
"multi-replica simulations"_Howto_replica.html, where each replica
|
||||
runs on on one or a few processors. Note that with MPI installed on a
|
||||
machine (e.g. your desktop), you can run on more (virtual) processors
|
||||
than you have physical processors.
|
||||
|
||||
To run multiple independent simulations from one input script, using
|
||||
multiple partitions, see "Section 6.4"_Section_howto.html#howto_4
|
||||
of the manual. World- and universe-style "variables"_variable.html
|
||||
are useful in this context.
|
||||
multiple partitions, see the "Howto multiple"_Howto_multiple.html doc
|
||||
page. World- and universe-style "variables"_variable.html are useful
|
||||
in this context.
|
||||
|
||||
-plog file :pre
|
||||
|
||||
|
|
@ -1787,11 +1787,13 @@ communication, roughly 75% in the example above.
|
|||
|
||||
The current C++ began with a complete rewrite of LAMMPS 2001, which
|
||||
was written in F90. Features of earlier versions of LAMMPS are listed
|
||||
in "Section 13"_Section_history.html. The F90 and F77 versions
|
||||
(2001 and 99) are also freely distributed as open-source codes; check
|
||||
the "LAMMPS WWW Site"_lws for distribution information if you prefer
|
||||
those versions. The 99 and 2001 versions are no longer under active
|
||||
development; they do not have all the features of C++ LAMMPS.
|
||||
on the "History page"_http://lammps.sandia.gov/history.html of the
|
||||
LAMMPS website. The F90 and F77 versions (2001 and 99) are also
|
||||
freely distributed as open-source codes; check the "History
|
||||
page"_http://lammps.sandia.gov/history.html of the LAMMPS website for
|
||||
info about those versions. The 99 and 2001 versions are no longer
|
||||
under active development; they do not have all the features of C++
|
||||
LAMMPS.
|
||||
|
||||
If you are a previous user of LAMMPS 2001, these are the most
|
||||
significant changes you will notice in C++ LAMMPS:
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
"Previous Section"_Package.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
|
||||
Section"_Section_howto.html :c
|
||||
Section"_Howto.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
"Previous Section"_Section_perf.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
"Previous Section"_Examples.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc - "Next
|
||||
Section"_Modify.html :c
|
||||
|
||||
|
|
@ -142,8 +142,8 @@ The syntax for running the tool is
|
|||
chain < def.chain > data.file :pre
|
||||
|
||||
See the def.chain or def.chain.ab files in the tools directory for
|
||||
examples of definition files. This tool was used to create the
|
||||
system for the "chain benchmark"_Section_perf.html.
|
||||
examples of definition files. This tool was used to create the system
|
||||
for the "chain benchmark"_Speed_bench.html.
|
||||
|
||||
:line
|
||||
|
||||
|
|
|
|||
|
|
@ -21,10 +21,10 @@ angle_coeff * 75.0 1 6 :pre
|
|||
[Description:]
|
||||
|
||||
The {cosine/periodic} angle style uses the following potential, which
|
||||
is commonly used in the "DREIDING"_Section_howto.html#howto_4 force
|
||||
field, particularly for organometallic systems where {n} = 4 might be
|
||||
used for an octahedral complex and {n} = 3 might be used for a
|
||||
trigonal center:
|
||||
is commonly used in the "DREIDING"_Howto_bioFF.html force field,
|
||||
particularly for organometallic systems where {n} = 4 might be used
|
||||
for an octahedral complex and {n} = 3 might be used for a trigonal
|
||||
center:
|
||||
|
||||
:c,image(Eqs/angle_cosine_periodic.jpg)
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ style = {angle} or {atomic} or {body} or {bond} or {charge} or {dipole} or \
|
|||
{body} args = bstyle bstyle-args
|
||||
bstyle = style of body particles
|
||||
bstyle-args = additional arguments specific to the bstyle
|
||||
see the "body"_body.html doc page for details
|
||||
see the "Howto body"_Howto_body.html doc page for details
|
||||
{tdpd} arg = Nspecies
|
||||
Nspecies = # of chemical species
|
||||
{template} arg = template-ID
|
||||
|
|
@ -106,9 +106,9 @@ output the custom values.
|
|||
|
||||
All of the above styles define point particles, except the {sphere},
|
||||
{ellipsoid}, {electron}, {peri}, {wavepacket}, {line}, {tri}, and
|
||||
{body} styles, which define finite-size particles. See "Section
|
||||
6.14"_Section_howto.html#howto_14 for an overview of using finite-size
|
||||
particle models with LAMMPS.
|
||||
{body} styles, which define finite-size particles. See the "Howto
|
||||
spherical"_Howto_spherical.html doc page for an overview of using
|
||||
finite-size particle models with LAMMPS.
|
||||
|
||||
All of the point-particle styles assign mass to particles on a
|
||||
per-type basis, using the "mass"_mass.html command, The finite-size
|
||||
|
|
@ -224,15 +224,16 @@ the {bstyle} argument. Body particles can represent complex entities,
|
|||
such as surface meshes of discrete points, collections of
|
||||
sub-particles, deformable objects, etc.
|
||||
|
||||
The "body"_body.html doc page describes the body styles LAMMPS
|
||||
currently supports, and provides more details as to the kind of body
|
||||
particles they represent. For all styles, each body particle stores
|
||||
moments of inertia and a quaternion 4-vector, so that its orientation
|
||||
and position can be time integrated due to forces and torques.
|
||||
The "Howto body"_Howto_body.html doc page describes the body styles
|
||||
LAMMPS currently supports, and provides more details as to the kind of
|
||||
body particles they represent. For all styles, each body particle
|
||||
stores moments of inertia and a quaternion 4-vector, so that its
|
||||
orientation and position can be time integrated due to forces and
|
||||
torques.
|
||||
|
||||
Note that there may be additional arguments required along with the
|
||||
{bstyle} specification, in the atom_style body command. These
|
||||
arguments are described in the "body"_body.html doc page.
|
||||
arguments are described on the "Howto body"_Howto_body.html doc page.
|
||||
|
||||
:line
|
||||
|
||||
|
|
|
|||
|
|
@ -17,8 +17,8 @@ surface meshes of discrete points, collections of sub-particles,
|
|||
deformable objects, etc. Note that other kinds of finite-size
|
||||
spherical and aspherical particles are also supported by LAMMPS, such
|
||||
as spheres, ellipsoids, line segments, and triangles, but they are
|
||||
simpler entities that body particles. See "Section
|
||||
6.14"_Section_howto.html#howto_14 for a general overview of all
|
||||
simpler entities that body particles. See the "Howto
|
||||
body"_Howto_.html doc page for a general overview of all
|
||||
these particle types.
|
||||
|
||||
Body particles are used via the "atom_style body"_atom_style.html
|
||||
|
|
|
|||
|
|
@ -82,9 +82,9 @@ and xhi faces of the box are planes tilting in the +y direction as y
|
|||
increases. These tilted planes are shrink-wrapped around the atoms to
|
||||
determine the x extent of the box.
|
||||
|
||||
See "Section 6.12"_Section_howto.html#howto_12 of the doc pages
|
||||
for a geometric description of triclinic boxes, as defined by LAMMPS,
|
||||
and how to transform these parameters to and from other commonly used
|
||||
See the "Howto triclinic"_Howto_triclinic.html doc page for a
|
||||
geometric description of triclinic boxes, as defined by LAMMPS, and
|
||||
how to transform these parameters to and from other commonly used
|
||||
triclinic representations.
|
||||
|
||||
[Restrictions:]
|
||||
|
|
|
|||
|
|
@ -30,9 +30,9 @@ For triclinic (non-orthogonal) simulation boxes, the {tilt} keyword
|
|||
allows simulation domains to be created with arbitrary tilt factors,
|
||||
e.g. via the "create_box"_create_box.html or
|
||||
"read_data"_read_data.html commands. Tilt factors determine how
|
||||
skewed the triclinic box is; see "this
|
||||
section"_Section_howto.html#howto_12 of the manual for a discussion of
|
||||
triclinic boxes in LAMMPS.
|
||||
skewed the triclinic box is; see the "Howto
|
||||
triclinic"_Howto_triclinic.html doc page for a discussion of triclinic
|
||||
boxes in LAMMPS.
|
||||
|
||||
LAMMPS normally requires that no tilt factor can skew the box more
|
||||
than half the distance of the parallel box length, which is the 1st
|
||||
|
|
|
|||
|
|
@ -75,9 +75,9 @@ The "create_box"_create_box.html, "read data"_read_data.html, and
|
|||
simulation box is orthogonal or triclinic and their doc pages explain
|
||||
the meaning of the xy,xz,yz tilt factors.
|
||||
|
||||
See "Section 6.12"_Section_howto.html#howto_12 of the doc pages
|
||||
for a geometric description of triclinic boxes, as defined by LAMMPS,
|
||||
and how to transform these parameters to and from other commonly used
|
||||
See the "Howto triclinic"_Howto_triclinic.html doc page for a
|
||||
geometric description of triclinic boxes, as defined by LAMMPS, and
|
||||
how to transform these parameters to and from other commonly used
|
||||
triclinic representations.
|
||||
|
||||
The keywords used in this command are applied sequentially to the
|
||||
|
|
@ -140,8 +140,8 @@ transformation in the sequence. If skew is exceeded before the final
|
|||
transformation this can be avoided by changing the order of the
|
||||
sequence, or breaking the transformation into two or more smaller
|
||||
transformations. For more information on the allowed limits for box
|
||||
skew see the discussion on triclinic boxes on "this
|
||||
page"_Section_howto.html#howto_12.
|
||||
skew see the discussion on triclinic boxes on "Howto
|
||||
triclinic"_Howto_triclinic.html doc page.
|
||||
|
||||
:line
|
||||
|
||||
|
|
@ -258,9 +258,7 @@ command.
|
|||
:line
|
||||
|
||||
The {ortho} and {triclinic} keywords convert the simulation box to be
|
||||
orthogonal or triclinic (non-orthogonal). See "this
|
||||
section"_Section_howto#howto_13 for a discussion of how non-orthogonal
|
||||
boxes are represented in LAMMPS.
|
||||
orthogonal or triclinic (non-orthogonal).
|
||||
|
||||
The simulation box is defined as either orthogonal or triclinic when
|
||||
it is created via the "create_box"_create_box.html,
|
||||
|
|
@ -271,8 +269,8 @@ These keywords allow you to toggle the existing simulation box from
|
|||
orthogonal to triclinic and vice versa. For example, an initial
|
||||
equilibration simulation can be run in an orthogonal box, the box can
|
||||
be toggled to triclinic, and then a "non-equilibrium MD (NEMD)
|
||||
simulation"_Section_howto.html#howto_13 can be run with deformation
|
||||
via the "fix deform"_fix_deform.html command.
|
||||
simulation"_Howto_nemd.html can be run with deformation via the "fix
|
||||
deform"_fix_deform.html command.
|
||||
|
||||
If the simulation box is currently triclinic and has non-zero tilt in
|
||||
xy, yz, or xz, then it cannot be converted to an orthogonal box.
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ information about a previous state of the system. Defining a compute
|
|||
does not perform a computation. Instead computes are invoked by other
|
||||
LAMMPS commands as needed, e.g. to calculate a temperature needed for
|
||||
a thermostat fix or to generate thermodynamic or dump file output.
|
||||
See this "howto section"_Section_howto.html#howto_15 for a summary of
|
||||
See the "Howto output"_Howto_output.html doc page for a summary of
|
||||
various LAMMPS output options, many of which involve computes.
|
||||
|
||||
The ID of a compute can only contain alphanumeric characters and
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ which computes this quantity.-
|
|||
|
||||
This compute calculates a per-atom vector, which can be accessed by
|
||||
any command that uses per-atom values from a compute as input. See
|
||||
"Section 6.15"_Section_howto.html#howto_15 for an overview of
|
||||
the "Howto output"_Howto_output.html doc page for an overview of
|
||||
LAMMPS output options.
|
||||
|
||||
[Restrictions:]
|
||||
|
|
|
|||
|
|
@ -37,8 +37,8 @@ This compute calculates a global vector of length N where N is the
|
|||
number of sub_styles defined by the "angle_style
|
||||
hybrid"_angle_style.html command, which can be accessed by indices
|
||||
1-N. These values can be used by any command that uses global scalar
|
||||
or vector values from a compute as input. See "this
|
||||
section"_Section_howto.html#howto_15 for an overview of LAMMPS output
|
||||
or vector values from a compute as input. See the "Howto
|
||||
output"_Howto_output.html doc page for an overview of LAMMPS output
|
||||
options.
|
||||
|
||||
The vector values are "extensive" and will be in energy
|
||||
|
|
|
|||
|
|
@ -70,8 +70,8 @@ array is the number of angles. If a single keyword is specified, a
|
|||
local vector is produced. If two or more keywords are specified, a
|
||||
local array is produced where the number of columns = the number of
|
||||
keywords. The vector or array can be accessed by any command that
|
||||
uses local values from a compute as input. See "this
|
||||
section"_Section_howto.html#howto_15 for an overview of LAMMPS output
|
||||
uses local values from a compute as input. See the "Howto
|
||||
output"_Howto_output.html doc page for an overview of LAMMPS output
|
||||
options.
|
||||
|
||||
The output for {theta} will be in degrees. The output for {eng} will
|
||||
|
|
|
|||
|
|
@ -30,10 +30,9 @@ chunk/atom"_compute_chunk_atom.html command, which assigns each atom
|
|||
to a single chunk (or no chunk). The ID for this command is specified
|
||||
as chunkID. For example, a single chunk could be the atoms in a
|
||||
molecule or atoms in a spatial bin. See the "compute
|
||||
chunk/atom"_compute_chunk_atom.html doc page and "Section
|
||||
6.23"_Section_howto.html#howto_23 for details of how chunks can be
|
||||
defined and examples of how they can be used to measure properties of
|
||||
a system.
|
||||
chunk/atom"_compute_chunk_atom.html and "Howto chunk"_Howto_chunk.html
|
||||
doc pages for details of how chunks can be defined and examples of how
|
||||
they can be used to measure properties of a system.
|
||||
|
||||
This compute calculates the 3 components of the angular momentum
|
||||
vector for each chunk, due to the velocity/momentum of the individual
|
||||
|
|
@ -73,8 +72,8 @@ number of chunks {Nchunk} as calculated by the specified "compute
|
|||
chunk/atom"_compute_chunk_atom.html command. The number of columns =
|
||||
3 for the 3 xyz components of the angular momentum for each chunk.
|
||||
These values can be accessed by any command that uses global array
|
||||
values from a compute as input. See "Section
|
||||
6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
|
||||
values from a compute as input. See the "Howto
|
||||
output"_Howto_output.html doc page for an overview of LAMMPS output
|
||||
options.
|
||||
|
||||
The array values are "intensive". The array values will be in
|
||||
|
|
|
|||
|
|
@ -46,9 +46,8 @@ in examples/USER/misc/basal.
|
|||
|
||||
This compute calculates a per-atom array with 3 columns, which can be
|
||||
accessed by indices 1-3 by any command that uses per-atom values from
|
||||
a compute as input. See "Section
|
||||
6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
|
||||
options.
|
||||
a compute as input. See the "Howto output"_Howto_output.html doc page
|
||||
for an overview of LAMMPS output options.
|
||||
|
||||
The per-atom vector values are unitless since the 3 columns represent
|
||||
components of a unit vector.
|
||||
|
|
|
|||
|
|
@ -32,9 +32,8 @@ Define a computation that calculates properties of individual body
|
|||
sub-particles. The number of datums generated, aggregated across all
|
||||
processors, equals the number of body sub-particles plus the number of
|
||||
non-body particles in the system, modified by the group parameter as
|
||||
explained below. See "Section 6.14"_Section_howto.html#howto_14
|
||||
of the manual and the "body"_body.html doc page for more details on
|
||||
using body particles.
|
||||
explained below. See the "Howto body"_Howto_body.html doc page for
|
||||
more details on using body particles.
|
||||
|
||||
The local data stored by this command is generated by looping over all
|
||||
the atoms. An atom will only be included if it is in the group. If
|
||||
|
|
@ -58,8 +57,8 @@ group.
|
|||
For a body particle, the {integer} keywords refer to fields calculated
|
||||
by the body style for each sub-particle. The body style, as specified
|
||||
by the "atom_style body"_atom_style.html, determines how many fields
|
||||
exist and what they are. See the "body"_body.html doc page for
|
||||
details of the different styles.
|
||||
exist and what they are. See the "Howto_body"_Howto_body.html doc
|
||||
page for details of the different styles.
|
||||
|
||||
Here is an example of how to output body information using the "dump
|
||||
local"_dump.html command with this compute. If fields 1,2,3 for the
|
||||
|
|
@ -78,9 +77,9 @@ array is the number of datums as described above. If a single keyword
|
|||
is specified, a local vector is produced. If two or more keywords are
|
||||
specified, a local array is produced where the number of columns = the
|
||||
number of keywords. The vector or array can be accessed by any
|
||||
command that uses local values from a compute as input. See "this
|
||||
section"_Section_howto.html#howto_15 for an overview of LAMMPS output
|
||||
options.
|
||||
command that uses local values from a compute as input. See the
|
||||
"Howto output"_Howto_output.html doc page for an overview of LAMMPS
|
||||
output options.
|
||||
|
||||
The "units"_units.html for output values depend on the body style.
|
||||
|
||||
|
|
|
|||
|
|
@ -37,8 +37,8 @@ This compute calculates a global vector of length N where N is the
|
|||
number of sub_styles defined by the "bond_style
|
||||
hybrid"_bond_style.html command, which can be accessed by indices 1-N.
|
||||
These values can be used by any command that uses global scalar or
|
||||
vector values from a compute as input. See "this
|
||||
section"_Section_howto.html#howto_15 for an overview of LAMMPS output
|
||||
vector values from a compute as input. See the "Howto
|
||||
output"_Howto_output.html doc page for an overview of LAMMPS output
|
||||
options.
|
||||
|
||||
The vector values are "extensive" and will be in energy
|
||||
|
|
|
|||
|
|
@ -116,8 +116,8 @@ array is the number of bonds. If a single keyword is specified, a
|
|||
local vector is produced. If two or more keywords are specified, a
|
||||
local array is produced where the number of columns = the number of
|
||||
keywords. The vector or array can be accessed by any command that
|
||||
uses local values from a compute as input. See "this
|
||||
section"_Section_howto.html#howto_15 for an overview of LAMMPS output
|
||||
uses local values from a compute as input. See the "Howto
|
||||
output"_Howto_output.html doc page for an overview of LAMMPS output
|
||||
options.
|
||||
|
||||
The output for {dist} will be in distance "units"_units.html. The
|
||||
|
|
|
|||
|
|
@ -97,8 +97,8 @@ too frequently or to have multiple compute/dump commands, each with a
|
|||
|
||||
By default, this compute calculates the centrosymmetry value for each
|
||||
atom as a per-atom vector, which can be accessed by any command that
|
||||
uses per-atom values from a compute as input. See "Section
|
||||
6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
|
||||
uses per-atom values from a compute as input. See the "Howto
|
||||
output"_Howto_output.html doc page for an overview of LAMMPS output
|
||||
options.
|
||||
|
||||
If the {axes} keyword setting is {yes}, then a per-atom array is
|
||||
|
|
|
|||
|
|
@ -101,14 +101,13 @@ msd/chunk"_compute_msd_chunk.html. Or they can be used by the "fix
|
|||
ave/chunk"_fix_ave_chunk.html command to sum and time average a
|
||||
variety of per-atom properties over the atoms in each chunk. Or they
|
||||
can simply be accessed by any command that uses per-atom values from a
|
||||
compute as input, as discussed in "Section
|
||||
6.15"_Section_howto.html#howto_15.
|
||||
compute as input, as discussed on the "Howto output"_Howto_output.html
|
||||
doc page.
|
||||
|
||||
See "Section 6.23"_Section_howto.html#howto_23 for an overview of
|
||||
how this compute can be used with a variety of other commands to
|
||||
tabulate properties of a simulation. The howto section gives several
|
||||
examples of input script commands that can be used to calculate
|
||||
interesting properties.
|
||||
See the "Howto chunk"_Howto_chunk.html doc page for an overview of how
|
||||
this compute can be used with a variety of other commands to tabulate
|
||||
properties of a simulation. The page gives several examples of input
|
||||
script commands that can be used to calculate interesting properties.
|
||||
|
||||
Conceptually it is important to realize that this compute does two
|
||||
simple things. First, it sets the value of {Nchunk} = the number of
|
||||
|
|
@ -167,11 +166,11 @@ or the bounds specified by the optional {bounds} keyword.
|
|||
For orthogonal simulation boxes, the bins are layers, pencils, or
|
||||
boxes aligned with the xyz coordinate axes. For triclinic
|
||||
(non-orthogonal) simulation boxes, the bin faces are parallel to the
|
||||
tilted faces of the simulation box. See "this
|
||||
section"_Section_howto.html#howto_12 of the manual for a discussion of
|
||||
the geometry of triclinic boxes in LAMMPS. As described there, a
|
||||
tilted simulation box has edge vectors a,b,c. In that nomenclature,
|
||||
bins in the x dimension have faces with normals in the "b" cross "c"
|
||||
tilted faces of the simulation box. See the "Howto
|
||||
triclinic"_Howto_triclinic.html doc page for a discussion of the
|
||||
geometry of triclinic boxes in LAMMPS. As described there, a tilted
|
||||
simulation box has edge vectors a,b,c. In that nomenclature, bins in
|
||||
the x dimension have faces with normals in the "b" cross "c"
|
||||
direction. Bins in y have faces normal to the "a" cross "c"
|
||||
direction. And bins in z have faces normal to the "a" cross "b"
|
||||
direction. Note that in order to define the size and position of
|
||||
|
|
@ -626,7 +625,7 @@ cylinder, x for a y-axis cylinder, and x for a z-axis cylinder.
|
|||
|
||||
This compute calculates a per-atom vector, which can be accessed by
|
||||
any command that uses per-atom values from a compute as input. See
|
||||
"Section 6.15"_Section_howto.html#howto_15 for an overview of
|
||||
the "Howto output"_Howto_output.html doc page for an overview of
|
||||
LAMMPS output options.
|
||||
|
||||
The per-atom vector values are unitless chunk IDs, ranging from 1 to
|
||||
|
|
|
|||
|
|
@ -84,7 +84,7 @@ the neighbor list.
|
|||
|
||||
This compute calculates a per-atom vector, which can be accessed by
|
||||
any command that uses per-atom values from a compute as input. See
|
||||
"Section 6.15"_Section_howto.html#howto_15 for an overview of
|
||||
the "Howto output"_Howto_output.html doc page for an overview of
|
||||
LAMMPS output options.
|
||||
|
||||
The per-atom vector values will be an ID > 0, as explained above.
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ too frequently or to have multiple compute/dump commands, each with a
|
|||
|
||||
This compute calculates a per-atom vector, which can be accessed by
|
||||
any command that uses per-atom values from a compute as input. See
|
||||
"Section 6.15"_Section_howto.html#howto_15 for an overview of
|
||||
the "Howto output"_Howto_output.html doc page for an overview of
|
||||
LAMMPS output options.
|
||||
|
||||
The per-atom vector values will be a number from 0 to 5, as explained
|
||||
|
|
|
|||
|
|
@ -78,7 +78,7 @@ too frequently or to have multiple compute/dump commands, each with a
|
|||
|
||||
This compute calculates a per-atom vector, which can be accessed by
|
||||
any command that uses per-atom values from a compute as input. See
|
||||
"Section 6.15"_Section_howto.html#howto_15 for an overview of
|
||||
the "Howto output"_Howto_output.html doc page for an overview of
|
||||
LAMMPS output options.
|
||||
|
||||
The per-atom vector values will be real positive numbers. Some typical CNP
|
||||
|
|
|
|||
|
|
@ -41,9 +41,8 @@ image"_set.html command.
|
|||
|
||||
This compute calculates a global vector of length 3, which can be
|
||||
accessed by indices 1-3 by any command that uses global vector values
|
||||
from a compute as input. See "this
|
||||
section"_Section_howto.html#howto_15 for an overview of LAMMPS output
|
||||
options.
|
||||
from a compute as input. See the "Howto output"_Howto_output.html doc
|
||||
page for an overview of LAMMPS output options.
|
||||
|
||||
The vector values are "intensive". The vector values will be in
|
||||
distance "units"_units.html.
|
||||
|
|
|
|||
|
|
@ -30,10 +30,9 @@ chunk/atom"_compute_chunk_atom.html command, which assigns each atom
|
|||
to a single chunk (or no chunk). The ID for this command is specified
|
||||
as chunkID. For example, a single chunk could be the atoms in a
|
||||
molecule or atoms in a spatial bin. See the "compute
|
||||
chunk/atom"_compute_chunk_atom.html doc page and "Section
|
||||
6.23"_Section_howto.html#howto_23 for details of how chunks can be
|
||||
defined and examples of how they can be used to measure properties of
|
||||
a system.
|
||||
chunk/atom"_compute_chunk_atom.html and "Howto chunk"_Howto_chunk.html
|
||||
doc pages for details of how chunks can be defined and examples of how
|
||||
they can be used to measure properties of a system.
|
||||
|
||||
This compute calculates the x,y,z coordinates of the center-of-mass
|
||||
for each chunk, which includes all effects due to atoms passing thru
|
||||
|
|
@ -71,9 +70,8 @@ number of chunks {Nchunk} as calculated by the specified "compute
|
|||
chunk/atom"_compute_chunk_atom.html command. The number of columns =
|
||||
3 for the x,y,z center-of-mass coordinates of each chunk. These
|
||||
values can be accessed by any command that uses global array values
|
||||
from a compute as input. See "Section
|
||||
6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
|
||||
options.
|
||||
from a compute as input. See the "Howto output"_Howto_output.html doc
|
||||
page for an overview of LAMMPS output options.
|
||||
|
||||
The array values are "intensive". The array values will be in
|
||||
distance "units"_units.html.
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ specified compute group.
|
|||
|
||||
This compute calculates a per-atom vector, whose values can be
|
||||
accessed by any command that uses per-atom values from a compute as
|
||||
input. See "Section 6.15"_Section_howto.html#howto_15 for an
|
||||
input. See the "Howto output"_Howto_output.html doc page for an
|
||||
overview of LAMMPS output options.
|
||||
|
||||
The per-atom vector values will be a number >= 0.0, as explained
|
||||
|
|
|
|||
|
|
@ -109,9 +109,8 @@ array, with N columns.
|
|||
For {cstyle} orientorder, this compute calculates a per-atom vector.
|
||||
|
||||
These values can be accessed by any command that uses per-atom values
|
||||
from a compute as input. See "Section
|
||||
6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
|
||||
options.
|
||||
from a compute as input. See the "Howto output"_Howto_output.html doc
|
||||
page for an overview of LAMMPS output options.
|
||||
|
||||
The per-atom vector or array values will be a number >= 0.0, as
|
||||
explained above.
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ group.
|
|||
|
||||
This compute calculates a per-atom vector, which can be accessed by
|
||||
any command that uses per-atom values from a compute as input. See
|
||||
"Section 6.15"_Section_howto.html#howto_15 for an overview of
|
||||
the "Howto output"_Howto_output.html doc page for an overview of
|
||||
LAMMPS output options.
|
||||
|
||||
The per-atom vector values are unitless numbers (damage) >= 0.0.
|
||||
|
|
|
|||
|
|
@ -37,8 +37,8 @@ This compute calculates a global vector of length N where N is the
|
|||
number of sub_styles defined by the "dihedral_style
|
||||
hybrid"_dihedral_style.html command. which can be accessed by indices
|
||||
1-N. These values can be used by any command that uses global scalar
|
||||
or vector values from a compute as input. See "this
|
||||
section"_Section_howto.html#howto_15 for an overview of LAMMPS output
|
||||
or vector values from a compute as input. See the "Howto
|
||||
output"_Howto_output.html doc page for an overview of LAMMPS output
|
||||
options.
|
||||
|
||||
The vector values are "extensive" and will be in energy
|
||||
|
|
|
|||
|
|
@ -62,8 +62,8 @@ array is the number of dihedrals. If a single keyword is specified, a
|
|||
local vector is produced. If two or more keywords are specified, a
|
||||
local array is produced where the number of columns = the number of
|
||||
keywords. The vector or array can be accessed by any command that
|
||||
uses local values from a compute as input. See "this
|
||||
section"_Section_howto.html#howto_15 for an overview of LAMMPS output
|
||||
uses local values from a compute as input. See the "Howto
|
||||
output"_Howto_output.html doc page for an overview of LAMMPS output
|
||||
options.
|
||||
|
||||
The output for {phi} will be in degrees.
|
||||
|
|
|
|||
|
|
@ -47,8 +47,9 @@ compute group.
|
|||
[Output info:]
|
||||
|
||||
This compute calculates a per-atom vector, which can be accessed by
|
||||
any command that uses per-atom values from a compute as input. See
|
||||
Section_howto 15 for an overview of LAMMPS output options.
|
||||
any command that uses per-atom values from a compute as input. See
|
||||
the "Howto output"_Howto_output.html doc page for an overview of
|
||||
LAMMPS output options.
|
||||
|
||||
The per-atom vector values are unitless numbers (theta) >= 0.0.
|
||||
|
||||
|
|
|
|||
|
|
@ -32,10 +32,9 @@ chunk/atom"_compute_chunk_atom.html command, which assigns each atom
|
|||
to a single chunk (or no chunk). The ID for this command is specified
|
||||
as chunkID. For example, a single chunk could be the atoms in a
|
||||
molecule or atoms in a spatial bin. See the "compute
|
||||
chunk/atom"_compute_chunk_atom.html doc page and "Section
|
||||
6.23"_Section_howto.html#howto_23 for details of how chunks can be
|
||||
defined and examples of how they can be used to measure properties of
|
||||
a system.
|
||||
chunk/atom"_compute_chunk_atom.html and "Howto chunk"_Howto_chunk.html
|
||||
doc pages for details of how chunks can be defined and examples of how
|
||||
they can be used to measure properties of a system.
|
||||
|
||||
This compute calculates the x,y,z coordinates of the dipole vector
|
||||
and the total dipole moment for each chunk, which includes all effects
|
||||
|
|
@ -76,8 +75,8 @@ number of chunks {Nchunk} as calculated by the specified "compute
|
|||
chunk/atom"_compute_chunk_atom.html command. The number of columns =
|
||||
4 for the x,y,z dipole vector components and the total dipole of each
|
||||
chunk. These values can be accessed by any command that uses global
|
||||
array values from a compute as input. See "Section
|
||||
6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
|
||||
array values from a compute as input. See the "Howto
|
||||
output"_Howto_output.html doc page for an overview of LAMMPS output
|
||||
options.
|
||||
|
||||
The array values are "intensive". The array values will be in
|
||||
|
|
|
|||
|
|
@ -118,9 +118,8 @@ would be empty.
|
|||
|
||||
This compute calculates a per-atom array with 4 columns, which can be
|
||||
accessed by indices 1-4 by any command that uses per-atom values from
|
||||
a compute as input. See "Section
|
||||
6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
|
||||
options.
|
||||
a compute as input. See the "Howto output"_Howto_output.html doc page
|
||||
for an overview of LAMMPS output options.
|
||||
|
||||
The per-atom array values will be in distance "units"_units.html.
|
||||
|
||||
|
|
|
|||
|
|
@ -40,9 +40,9 @@ where N is the number of particles in the system
|
|||
[Output info:]
|
||||
|
||||
This compute calculates a global vector of length 5 (U_cond, U_mech,
|
||||
U_chem, dpdTheta, N_particles), which can be accessed by indices 1-5. See
|
||||
"this section"_Section_howto.html#howto_15 for an overview of LAMMPS
|
||||
output options.
|
||||
U_chem, dpdTheta, N_particles), which can be accessed by indices 1-5.
|
||||
See the "Howto output"_Howto_output.html doc page for an overview of
|
||||
LAMMPS output options.
|
||||
|
||||
The vector values will be in energy and temperature "units"_units.html.
|
||||
|
||||
|
|
|
|||
|
|
@ -34,9 +34,9 @@ particles.
|
|||
[Output info:]
|
||||
|
||||
This compute calculates a per-particle array with 4 columns (u_cond,
|
||||
u_mech, u_chem, dpdTheta), which can be accessed by indices 1-4 by any command
|
||||
that uses per-particle values from a compute as input. See
|
||||
"Section 6.15"_Section_howto.html#howto_15 for an overview of
|
||||
u_mech, u_chem, dpdTheta), which can be accessed by indices 1-4 by any
|
||||
command that uses per-particle values from a compute as input. See
|
||||
the "Howto output"_Howto_output.html doc page for an overview of
|
||||
LAMMPS output options.
|
||||
|
||||
The per-particle array values will be in energy (u_cond, u_mech, u_chem)
|
||||
|
|
|
|||
|
|
@ -32,9 +32,9 @@ For more details please see "(Espanol1997)"_#Espanol1997 and
|
|||
[Output info:]
|
||||
|
||||
This compute calculates a per-atom vector, which can be accessed by
|
||||
any command that uses per-atom values from a compute as input. See
|
||||
"Section 6.15"_Section_howto.html#howto_15 for an overview of
|
||||
LAMMPS output options.
|
||||
any command that uses per-atom values from a compute as input. See the
|
||||
"Howto output"_Howto_output.html doc page for an overview of LAMMPS
|
||||
output options.
|
||||
|
||||
The per-atom vector values will be in temperature "units"_units.html.
|
||||
|
||||
|
|
|
|||
|
|
@ -98,8 +98,8 @@ compute 1 all entropy/atom 0.25 7.3 avg yes 5.1 :pre
|
|||
|
||||
By default, this compute calculates the pair entropy value for each
|
||||
atom as a per-atom vector, which can be accessed by any command that
|
||||
uses per-atom values from a compute as input. See "Section
|
||||
6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
|
||||
uses per-atom values from a compute as input. See the "Howto
|
||||
output"_Howto_output.html doc page for an overview of LAMMPS output
|
||||
options.
|
||||
|
||||
The pair entropy values have units of the Boltzmann constant. They are
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ will be the same as in 3d.
|
|||
|
||||
This compute calculates a global scalar (the KE). This value can be
|
||||
used by any command that uses a global scalar value from a compute as
|
||||
input. See "Section 6.15"_Section_howto.html#howto_15 for an
|
||||
input. See the "Howto output"_Howto_output.html doc page for an
|
||||
overview of LAMMPS output options.
|
||||
|
||||
The scalar value calculated by this compute is "extensive". The
|
||||
|
|
|
|||
|
|
@ -41,9 +41,9 @@ calculation.
|
|||
|
||||
This compute calculates a global scalar (the summed rotational energy
|
||||
of all the rigid bodies). This value can be used by any command that
|
||||
uses a global scalar value from a compute as input. See
|
||||
"Section 6.15"_Section_howto.html#howto_15 for an overview of
|
||||
LAMMPS output options.
|
||||
uses a global scalar value from a compute as input. See the "Howto
|
||||
output"_Howto_output.html doc page for an overview of LAMMPS output
|
||||
options.
|
||||
|
||||
The scalar value calculated by this compute is "extensive". The
|
||||
scalar value will be in energy "units"_units.html.
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ as in 3d.
|
|||
|
||||
This compute calculates a global scalar (the KE). This value can be
|
||||
used by any command that uses a global scalar value from a compute as
|
||||
input. See "Section 6.15"_Section_howto.html#howto_15 for an
|
||||
input. See the "Howto output"_Howto_output.html doc page for an
|
||||
overview of LAMMPS output options.
|
||||
|
||||
The scalar value calculated by this compute is "extensive". The
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ in the specified compute group or for point particles with a radius =
|
|||
|
||||
This compute calculates a per-atom vector, which can be accessed by
|
||||
any command that uses per-atom values from a compute as input. See
|
||||
"Section 6.15"_Section_howto.html#howto_15 for an overview of
|
||||
the "Howto output"_Howto_output.html doc page for an overview of
|
||||
LAMMPS output options.
|
||||
|
||||
The per-atom vector values will be in energy "units"_units.html.
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ local atom displacements and may generate "false positives."
|
|||
|
||||
This compute calculates a global scalar (the flag). This value can be
|
||||
used by any command that uses a global scalar value from a compute as
|
||||
input. See "Section 6.15"_Section_howto.html#howto_15 for an
|
||||
input. See the "Howto output"_Howto_output.html doc page for an
|
||||
overview of LAMMPS output options.
|
||||
|
||||
The scalar value calculated by this compute is "intensive". The
|
||||
|
|
|
|||
|
|
@ -219,8 +219,8 @@ unperturbed parameters. The energies include kspace terms if these
|
|||
are used in the simulation.
|
||||
|
||||
These output results can be used by any command that uses a global
|
||||
scalar or vector from a compute as input. See "Section
|
||||
6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
|
||||
scalar or vector from a compute as input. See the "Howto
|
||||
output"_Howto_output.html doc page for an overview of LAMMPS output
|
||||
options. For example, the computed values can be averaged using "fix
|
||||
ave/time"_fix_ave_time.html.
|
||||
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ this command. This command will then assign the global chunk value to
|
|||
each atom in the chunk, producing a per-atom vector or per-atom array
|
||||
as output. The per-atom values can then be output to a dump file or
|
||||
used by any command that uses per-atom values from a compute as input,
|
||||
as discussed in "Section 6.15"_Section_howto.html#howto_15.
|
||||
as discussed on the "Howto output"_Howto_output.html doc page.
|
||||
|
||||
As a concrete example, these commands will calculate the displacement
|
||||
of each atom from the center-of-mass of the molecule it is in, and
|
||||
|
|
@ -203,7 +203,7 @@ vector. If multiple inputs are specified, this compute produces a
|
|||
per-atom array values, where the number of columns is equal to the
|
||||
number of inputs specified. These values can be used by any command
|
||||
that uses per-atom vector or array values from a compute as input.
|
||||
See "Section 6.15"_Section_howto.html#howto_15 for an overview of
|
||||
See the "Howto output"_Howto_output.html doc page for an overview of
|
||||
LAMMPS output options.
|
||||
|
||||
The per-atom vector or array values will be in whatever units the
|
||||
|
|
|
|||
|
|
@ -123,8 +123,8 @@ group-group calculations are performed.
|
|||
This compute calculates a global scalar (the energy) and a global
|
||||
vector of length 3 (force), which can be accessed by indices 1-3.
|
||||
These values can be used by any command that uses global scalar or
|
||||
vector values from a compute as input. See "this
|
||||
section"_Section_howto.html#howto_15 for an overview of LAMMPS output
|
||||
vector values from a compute as input. See the "Howto
|
||||
output"_Howto_output.html doc page for an overview of LAMMPS output
|
||||
options.
|
||||
|
||||
Both the scalar and vector values calculated by this compute are
|
||||
|
|
|
|||
|
|
@ -55,8 +55,8 @@ using the "set image"_set.html command.
|
|||
This compute calculates a global scalar (Rg) and a global vector of
|
||||
length 6 (Rg^2 tensor), which can be accessed by indices 1-6. These
|
||||
values can be used by any command that uses a global scalar value or
|
||||
vector values from a compute as input. See "Section
|
||||
6.15"_Section_howto.html#howto_15 for an overview of LAMMPS output
|
||||
vector values from a compute as input. See the "Howto
|
||||
output"_Howto_output.html doc page for an overview of LAMMPS output
|
||||
options.
|
||||
|
||||
The scalar and vector values calculated by this compute are
|
||||
|
|
|
|||
|
|
@ -35,10 +35,9 @@ chunk/atom"_compute_chunk_atom.html command, which assigns each atom
|
|||
to a single chunk (or no chunk). The ID for this command is specified
|
||||
as chunkID. For example, a single chunk could be the atoms in a
|
||||
molecule or atoms in a spatial bin. See the "compute
|
||||
chunk/atom"_compute_chunk_atom.html doc page and "Section
|
||||
6.23"_Section_howto.html#howto_23 for details of how chunks can be
|
||||
defined and examples of how they can be used to measure properties of
|
||||
a system.
|
||||
chunk/atom"_compute_chunk_atom.html and "Howto chunk"_Howto_chunk.html
|
||||
doc pages for details of how chunks can be defined and examples of how
|
||||
they can be used to measure properties of a system.
|
||||
|
||||
This compute calculates the radius of gyration Rg for each chunk,
|
||||
which includes all effects due to atoms passing thru periodic
|
||||
|
|
@ -93,8 +92,8 @@ calculated by the specified "compute
|
|||
chunk/atom"_compute_chunk_atom.html command. If the {tensor} keyword
|
||||
is specified, the global array has 6 columns. The vector or array can
|
||||
be accessed by any command that uses global values from a compute as
|
||||
input. See "this section"_Section_howto.html#howto_15 for an overview
|
||||
of LAMMPS output options.
|
||||
input. See the "Howto output"_Howto_output.html doc page for an
|
||||
overview of LAMMPS output options.
|
||||
|
||||
All the vector or array values calculated by this compute are
|
||||
"intensive". The vector or array values will be in distance
|
||||
|
|
|
|||
|
|
@ -32,9 +32,9 @@ or to calculate a thermal conductivity using the equilibrium
|
|||
Green-Kubo formalism.
|
||||
|
||||
For other non-equilibrium ways to compute a thermal conductivity, see
|
||||
"this section"_Section_howto.html#howto_20. These include use of the
|
||||
"fix thermal/conductivity"_fix_thermal_conductivity.html command for
|
||||
the Muller-Plathe method. Or the "fix heat"_fix_heat.html command
|
||||
the "Howto kappa"_Howto_kappa.html doc page.. These include use of
|
||||
the "fix thermal/conductivity"_fix_thermal_conductivity.html command
|
||||
for the Muller-Plathe method. Or the "fix heat"_fix_heat.html command
|
||||
which can add or subtract heat from groups of atoms.
|
||||
|
||||
The compute takes three arguments which are IDs of other
|
||||
|
|
@ -99,8 +99,8 @@ result should be: average conductivity ~0.29 in W/mK.
|
|||
This compute calculates a global vector of length 6 (total heat flux
|
||||
vector, followed by convective heat flux vector), which can be
|
||||
accessed by indices 1-6. These values can be used by any command that
|
||||
uses global vector values from a compute as input. See "this
|
||||
section"_Section_howto.html#howto_15 for an overview of LAMMPS output
|
||||
uses global vector values from a compute as input. See the "Howto
|
||||
output"_Howto_output.html doc page for an overview of LAMMPS output
|
||||
options.
|
||||
|
||||
The vector values calculated by this compute are "extensive", meaning
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue