ICODE-ADC/lammps
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

git-svn-id: svn://svn.icms.temple.edu/lammps-ro/trunk@15317 f3b2605a-c512-4ea7-a41b-209d697bcdaa

Browse Source
This commit is contained in:
sjplimp
2016-07-15 22:33:52 +00:00
parent 1587bdf2f1
commit 10bbb28943
34 changed files with 630 additions and 52 deletions
Download Patch File Download Diff File Expand all files Collapse all files

101
doc/html/_sources/dihedral_spherical.txt Normal file
View File

@ -0,0 +1,101 @@
.. index:: dihedral_style spherical
dihedral_style spherical command
================================
Syntax
""""""
.. parsed-literal::
dihedral_style spherical
Examples
""""""""
.. parsed-literal::
dihedral_coeff 1 1 286.1 1 124 1 1 90.0 0 1 90.0 0
dihedral_coeff 1 3 286.1 1 114 1 1 90 0 1 90.0 0 &
17.3 0 0.0 0 1 158 1 0 0.0 0 &
15.1 0 0.0 0 0 0.0 0 1 167.3 1
Description
"""""""""""
The *spherical* dihedral style uses the potential:
.. image:: JPG/dihedral_spherical_angles.jpg
:align: center
.. image:: Eqs/dihedral_spherical.jpg
:align: center
For this dihedral style, the energy can be any function that combines the
4-body dihedral-angle (phi) and the two 3-body bond-angles (theta1, theta2).
For this reason, there is usually no need to define 3-body "angle" forces
separately for the atoms participating in these interactions.
It is probably more efficient to incorporate 3-body angle forces into
the dihedral interaction even if it requires adding additional terms to
the expansion (as was done in the second example). A careful choice of
parameters can prevent singularities that occur with traditional
force-fields whenever theta1 or theta2 approach 0 or 180 degrees.
The last example above corresponds to an interaction with a single energy
minima located at phi=114, theta1=158, theta2=167.3 degrees, and it remains
numerically stable at all angles (phi, theta1, theta2). In this example,
the coefficients 17.3, and 15.1 can be physically interpreted as the
harmonic spring constants for theta1 and theta2 around their minima.
The coefficient 286.1 is the harmonic spring constant for phi after
division by sin(158)*sin(167.3) (the minima positions for theta1 and theta2).
The following coefficients must be defined for each dihedral type via the
:doc:`dihedral_coeff <dihedral_coeff>` command as in the example above, or in
the Dihedral Coeffs section of a data file file read by the
:doc:`read_data <read_data>` command:
* n (integer >= 1)
* C1 (energy)
* K1 (typically an integer)
* a1 (degrees)
* u1 (typically 0.0 or 1.0)
* L1 (typically an integer)
* b1 (degrees, typically 0.0 or 90.0)
* v1 (typically 0.0 or 1.0)
* M1 (typically an integer)
* c1 (degrees, typically 0.0 or 90.0)
* w1 (typically 0.0 or 1.0)
* ....
* Cn (energy)
* Kn (typically an integer)
* an (degrees)
* un (typically 0.0 or 1.0)
* Ln (typically an integer)
* bn (degrees, typically 0.0 or 90.0)
* vn (typically 0.0 or 1.0)
* Mn (typically an integer)
* cn (degrees, typically 0.0 or 90.0)
* wn (typically 0.0 or 1.0)
----------
Restrictions
""""""""""""
This dihedral style can only be used if LAMMPS was built with the
USER_MISC package. See the :ref:`Making LAMMPS <start_3>`
section for more info on packages.
Related commands
""""""""""""""""
:doc:`dihedral_coeff <dihedral_coeff>`
**Default:** none
.. _lws: http://lammps.sandia.gov
.. _ld: Manual.html
.. _lc: Section_commands.html#comm

2
doc/html/_sources/dihedral_style.txt
View File

@ -57,7 +57,7 @@ In the formulas listed for each dihedral style, *phi* is the torsional
angle defined by the quadruplet of atoms. This angle has a sign
convention as shown in this diagram:
.. image:: Eqs/dihedral_sign.jpg
.. image:: JPG/dihedral_sign.jpg
:align: center
where the I,J,K,L ordering of the 4 atoms that define the dihedral

63
doc/html/_sources/dump_image.txt
View File

@ -21,7 +21,7 @@ Syntax
* color = atom attribute that determines color of each atom
* diameter = atom attribute that determines size of each atom
* zero or more keyword/value pairs may be appended
* keyword = *atom* or *adiam* or *bond* or *line* or *tri* or *body* or *size* or *view* or *center* or *up* or *zoom* or *persp* or *box* or *axes* or *subbox* or *shiny* or *ssao*
* keyword = *atom* or *adiam* or *bond* or *line* or *tri* or *body* or *fix* or *size* or *view* or *center* or *up* or *zoom* or *persp* or *box* or *axes* or *subbox* or *shiny* or *ssao*
.. parsed-literal::
*atom* = yes/no = do or do not draw atoms
@ -40,6 +40,10 @@ Syntax
*body* = color bflag1 bflag2
color = *type*
bflag1,bflag2 = 2 numeric flags to affect how bodies are drawn
*fix* = fixID color fflag1 fflag2
fixID = ID of fix that generates objects to dray
color = *type*
fflag1,fflag2 = 2 numeric flags to affect how fix objects are drawn
*size* values = width height = size of images
width = width of image in # of pixels
height = height of image in # of pixels
@ -274,6 +278,10 @@ set a single numeric *size*\ . All atoms will be drawn with that
diameter, e.g. 1.5, which is in whatever distance :doc:`units <units>`
the input script defines, e.g. Angstroms.
----------
The *bond* keyword allows to you to alter how bonds are drawn. A bond
is only drawn if both atoms in the bond are being drawn due to being
in the specified group and due to other selection criteria
@ -316,6 +324,10 @@ If *type* is specified for the *width* value then the diameter of each
bond is determined by its bond type. By default all types have
diameter 0.5. This mapping can be changed by the :doc:`dump_modify bdiam <dump_modify>` command.
----------
The *line* keyword can be used when :doc:`atom_style line <atom_style>`
is used to define particles as line segments, and will draw them as
lines. If this keyword is not used, such particles will be drawn as
@ -339,6 +351,10 @@ lines will be drawn as cylinders with that diameter, e.g. 1.0, which
is in whatever distance :doc:`units <units>` the input script defines,
e.g. Angstroms.
----------
The *tri* keyword can be used when :doc:`atom_style tri <atom_style>` is
used to define particles as triangles, and will draw them as triangles
or edges (3 lines) or both, depending on the setting for *tflag*\ . If
@ -359,6 +375,10 @@ default the mapping of types to colors is as follows:
and repeats itself for types > 6. There is not yet an option to
change this via the :doc:`dump_modify <dump_modify>` command.
----------
The *body* keyword can be used when :doc:`atom_style body <atom_style>`
is used to define body particles with internal state
(e.g. sub-particles), and will drawn them in a manner specific to the
@ -376,6 +396,47 @@ passed to the body style to affect how the drawing of a body particle
is done. See the :doc:`body <body>` doc page for a description of what
these parameters mean for each body style.
The only setting currently allowed for the *color* value is *type*\ ,
which will color the body particles according to the atom type of the
particle. By default the mapping of types to colors is as follows:
* type 1 = red
* type 2 = green
* type 3 = blue
* type 4 = yellow
* type 5 = aqua
* type 6 = cyan
and repeats itself for types > 6. There is not yet an option to
change this via the :doc:`dump_modify <dump_modify>` command.
----------
The *fix* keyword can be used with a :doc:`fix <fix>` that produces
objects to be drawn. An example is the :doc:`fix surface/global <fix_surface_global>` command which can draw lines
or triangles for 2d/3d simulations.
The *fflag1* and *fflag2* settings are numerical values which are
passed to the fix to affect how the drawing of its objects is done.
See the individual fix doc page for a description of what these
parameters mean for a particular fix.
The only setting currently allowed for the *color* value is *type*\ ,
which will color the fix objects according to their type. By default
the mapping of types to colors is as follows:
* type 1 = red
* type 2 = green
* type 3 = blue
* type 4 = yellow
* type 5 = aqua
* type 6 = cyan
and repeats itself for types > 6. There is not yet an option to
change this via the :doc:`dump_modify <dump_modify>` command.
----------

5
doc/html/_sources/fix_addforce.txt
View File

@ -122,8 +122,9 @@ depending on your available hardware, as discussed in
accelerated styles take the same arguments and should produce the same
results, except for round-off and precision issues.
These accelerated styles are part of the ackage. They are only
enabled if LAMMPS was built with that package. See the :ref:`Making LAMMPS <start_3>` section for more info.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the :ref:`Making LAMMPS <start_3>` section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the :ref:`-suffix command-line switch <start_7>` when you invoke LAMMPS, or you can

5
doc/html/_sources/fix_aveforce.txt
View File

@ -80,8 +80,9 @@ depending on your available hardware, as discussed in
accelerated styles take the same arguments and should produce the same
results, except for round-off and precision issues.
These accelerated styles are part of the ackage. They are only
enabled if LAMMPS was built with that package. See the :ref:`Making LAMMPS <start_3>` section for more info.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the :ref:`Making LAMMPS <start_3>` section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the :ref:`-suffix command-line switch <start_7>` when you invoke LAMMPS, or you can

5
doc/html/_sources/fix_enforce2d.txt
View File

@ -38,8 +38,9 @@ depending on your available hardware, as discussed in
accelerated styles take the same arguments and should produce the same
results, except for round-off and precision issues.
These accelerated styles are part of the ackage. They are only
enabled if LAMMPS was built with that package. See the :ref:`Making LAMMPS <start_3>` section for more info.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the :ref:`Making LAMMPS <start_3>` section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the :ref:`-suffix command-line switch <start_7>` when you invoke LAMMPS, or you can

5
doc/html/_sources/fix_freeze.txt
View File

@ -42,8 +42,9 @@ depending on your available hardware, as discussed in
accelerated styles take the same arguments and should produce the same
results, except for round-off and precision issues.
These accelerated styles are part of the ackage. They are only
enabled if LAMMPS was built with that package. See the :ref:`Making LAMMPS <start_3>` section for more info.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the :ref:`Making LAMMPS <start_3>` section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the :ref:`-suffix command-line switch <start_7>` when you invoke LAMMPS, or you can

5
doc/html/_sources/fix_shake.txt
View File

@ -169,8 +169,9 @@ depending on your available hardware, as discussed in
accelerated styles take the same arguments and should produce the same
results, except for round-off and precision issues.
These accelerated styles are part of the ackage. They are only
enabled if LAMMPS was built with that package. See the :ref:`Making LAMMPS <start_3>` section for more info.
These accelerated styles are part of the GPU, USER-INTEL, KOKKOS,
USER-OMP and OPT packages, respectively. They are only enabled if
LAMMPS was built with those packages. See the :ref:`Making LAMMPS <start_3>` section for more info.
You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the :ref:`-suffix command-line switch <start_7>` when you invoke LAMMPS, or you can

9
doc/html/_sources/replicate.txt
View File

@ -85,15 +85,6 @@ the time the replicate command is used that require vectors of atom
information to be stored. This is because the replicate command does
not know how to replicate that information for new atoms it creates.
Replicating a system that has rigid bodies (defined via the :doc:`fix rigid <fix_rigid>` command), either currently defined or that
created the restart file which was read in before replicating, can
cause problems if there is a bond between a pair of rigid bodies that
straddle a periodic boundary. This is because the periodic image
information for particles in the rigid bodies are set differently than
for a non-rigid system and can result in a new bond being created that
spans the periodic box. Thus you cannot use the replicate command in
this scenario.
**Related commands:** none
**Default:** none