xmd.sgml

一个很好的分子动力学程序

The SELECTION, SET and TAG values are lost whenever a new set of
particles is read, the commands that do this are PARTICLE, COR, RCV
and STATE.  Sometimes it is desireable to read in coordinates
with the COR or RCV command but preserve the SELECTION, SET and TAG
values from a previous set of particles.  For instance, in a simulation
you might be curious about the current position of a set of particle
which started inside a spherical region at step 0.  If these particle
positions are storead in a COR file at steps 0 and 2000, you
can do the following, 
<tscreen><verb>
cor input.cor 0
select ellipse   5 5 5    2 2 2
select keep on 
cor input.cor 2000
write sel particle
</verb></tscreen>
This reads the particle positions from file input.cor at step 0, 
and selects those particle within an ellipsoid centered at (5,5,5)
with axises of length (2,2,2).  Since the axises lengths are equal, 
this is a sphere.  The <em>select keep on</em> commmand says that
SELECT, SET and TAG information will not be forgotten when the
COR command is used.  The next command reads the positions at
step 2000, and lastly these positions are written to the output file.

<sect1> Neighbor List

<p>
When calculating the energy and forces over all the atoms, the neighbors
for each atom must be known.  This calculation is done separately and
stored for future use in a set of arrays called the neighbor list.  This
list is calculated at the beginning of each run, and it includes all the
atom pairs that fall within the potential cutoffs plus an extra 10 &percnt;.
This extra insures that the neighbor list will be valid until the atoms
move enough to warrant a recalculation of the neighbor list.  When two
particles move a total of more than 10 &percnt;, then it is time to
recalculate.
This value of 10 &percnt; can be changed by the command NRANGE.  It specifies
the neighbor list cutoff range as a factor of the potential cutoff
range.  The default value is 1.1 (which yields a difference of 10 &percnt;).

<sect1> External Forces

<p>
The term external force means a force that is applied by an external
agent, in other words a force which is not due to the atoms themselves.
For some simulations it is necessary to apply an external force to some
or all of the particles.  This is sometimes the case in crack simulations.
Each atom can experience a unique external force, the only limitation
being the convenience (or lack) of setting the forces.  The command
EXTFORCE assigns a single value of the external force to the selected
particles.

<sect1> Velocity Damping

<p>
In some simulations it is desirable to dampen the atomic motion, perhaps
to absorb lattice vibrations generated by a moving dislocation, for
example.  This can be done with the DAMP command.  This command assigns
a damping term to the selected particles.  The force is altered by the
addition of the damping term,

<tscreen><verb>
-Fdamp * v
</verb></tscreen>

where Fdamp is the vector force due to the damping term, and v is the vector velocity.

<sect1> Temperature Control <label id="implementation-temp">

<p>
In molecular dynamics it is usually necessary to control the temperature
of the simulation.  There are two types of control, temperature
initialization and temperature maintenance.  Typically at the beginning
of a simulation the  position of every particle is specified but the
velocities are not known, only the desired temperature is known.  The
command ITEMP will assign random velocities to all the particles with
the appropriate Maxwell-Boltzmann distribution for the specified
temperature.  The command also has the option of assigning velocities in
only one or two of the three x,y,z directions (leaving the other
velocities unchanged).  This can be employed to simulate a two or one
dimensional solid, for if the initial coordinates are all confined to a
plane or line, and all the velocities normal to the plane or line are
zero, then the particles will remained confined to the required
geometry.  The velocities default to zero at the beginning of a run, and
if a run has already been in progress, you can initialize the velocities
to zero explicitly (using the command ITEMP 0).  Temperature maintenance
is used to obtain a simulation at a constant temperature.  Often one
will simulate a phenomena which liberates heat, such as a phase
transformation or work done by an external force, or perhaps one will
simulate a system which absorbs heat.  In order to maintain an
approximate constant temperature a "temperature clamp" is applied.  This
is an algorithm which scales the instantaneous velocities in order to
bring the temperature to its desired value.  Scaling is accomplished by
multiplying each particle velocity component by the same factor.
Typically you do not want to reach your desired temperature in one step,
because the temperature change will be too abrupt.  Early simulations
using just such a scheme produced marked noise in the high frequency end
of the phonon spectrum.  So instead the velocities are scaled by the
33'rd (default value) root of this "one step" factor.  This has the
approximate effect of reaching the desired temperature after 33 steps.
This number along with the desired temperature is specified by the CLAMP
command.  If no clamp is specified (or if a negative clamp is specified)
then no temperature maintenance is done, and a adiabatic simulation
results.  Such a simulation is useful for testing the stability of the
simulation (and hence time step size, see the THEORY section above).  If
the total energy reported by the program for an adiabatic simulation is
not constant, then most likely the time step size is too large.  See the
section on TECHNIQUES below for more information on adjusting the time
step size.  Note that the temperature can also be affects by the
VELOCITY command.


<sect1> Quenching <label id="implementation-quench">

<p>
In some simulations it is desirable to "quench" the atomic motions
during a dynamics simulation.  The purpose of quenching is to rapidly
relax the system to the current local minimum potential energy.
Quenching acts to alter the atomic motion but differs from the algorithm
used by the CLAMP command.  Whereas CLAMP scales velocities up or down
in order to maintain a specific temperature, quenching sets the atomic
velocities to zero whenever certain conditions are met.  XMD currently
implements two styles of quenching.  In the first method, every atoms'
velocity is zeroed whenever the total potential energy rises relative to
the preceding time step.  In the second method, an individual atom's
velocity is zeroed whenever its energy alone rises relative to the
preceding step.  A rise in energy for a particular atom is determined by
calculated   for each atom.  Whenever this quantity is negative for an
atom, its velocity is set to zero.  Quenching is controlled with the
QUENCH command.


<sect1> Fixing Particle Positions for Molecular Dynamics
<label id="implementation-fix">

<p>
For molecular dynamics simulations the box dimensions for a repeating
box is always fixed, there is currently no provision for dynamic
simulations with a varying box.  However individual particles may be
fixed using the FIX command.  For example to study the structure of
transformation interface you may want to hold BCC and FCC structures
fixed at opposite ends of the box (to insure that neither BCC or FCC
disappears entirely from the box) and allow the atoms in between move
freely in order to study the resulting arrangement.  The information
about which particles are fixed are stored in an array of flags, one for
each particle.  The command FIX [ON|OFF] will set or unset the flags of
the currently selected particles.  Initially all flags are unset.  The
particles which are fixed are totally equivalent to other particles as
far as the force and energy calculations are concerned, but their
positions are not updated, and their velocities and higher time
derivatives are set to zero.  When particles are fixed, they cannot
contribute kinetic energy to the system.  However, when the kinetic
energy per atom is reported (using the ESAVE or the WRITE EKIN commands)
it is normalized by the number of both fixed and free particles.
On the other hand, when the temperature is calculated (whose value is
reported by the WRITE TEMP command), it is the temperature of the free
particles only (that is, the total system kinetic energy divided by the
number of free particles).


<sect1> Repeating Boundary Conditions

<p>
By default repeating boundary conditions are in effect - this can be
altered with the SURFACE command.  The purpose of the repeating boundary
is to avoid the free surface inherent in a finite system of particles.
In the simulation the repeating boundaries form a rectangular box.  The
coordinates of the box range from 0 to some value specified with the BOX
command.  Repeating boundaries have primarily two effects on a
simulation: (1) particles close to opposite walls are considered to be
neighbors (and hence interact via the potential) with particles close to
far wall and (2) particles which travel through one wall are translated
by the length of the box so they come back in the opposite wall.  This
translation is called "wrapping".  Wrapping takes place whenever
particles are defined or displaced, and whenever repeating boundary
conditions are created using the SURFACE command.  Because the repeating
boundary conditions can only be in the form of a rectangular box,  their
use enforces a orthonormal, tetragonal or cubic symmetry depending on
the box symmetry.


<sect1> Constraints

<p>
It is possible to apply a variety of constraints to particles using the
CONSTRAIN command.  The first form of the command restricts particles to
motion along a line, or within a plane.  This constraint can be applied
individually to particles, each particle can have its own line or plane.
The second form of the constraint command imposes a spherical wall
around the particles.  Any particles which attempt to pass through the
wall are reflected back by a harmonic spring.  This can be used to
impose a pressure on a simulation - the resulting pressure can be
monitored by using the WRITE or SSAVE commands to display the system
stress.  Care must be taken with the choice of spring constant, if the
choice is too large then the motion integration may become unstable.  It
is recommended that before doing a production run, the user first do a
short run with no temperature clamp to insure that the total energy is
conserved (see discussion of under TIME STEP SIZE, page 3).


<sect1> Run Identification
<label id="implementation-run">

<p>
Typically in research one will conduct a series of runs.  To aid in the
subsequent identification of a computer run, the user can assign a run
number 
(with the <ref id="command-run" name="RUN command">) 
that will be stored in the STATE and RCV
files produced by XMD.  Furthermore every step is identified by a
number, starting with 0 for the first step (i.e. the particle
coordinates before the first integration step).  In addition to the
above output files, the step is also saved in the ESAVE, BSAVE and SSAVE
files.  Additional identification can be provided by a user specified
title, entered with the TITLE command.  The title is composed of 8 ASCII
strings each up to 80 characters long, it is stored in the STATE, RCV,
and COR files and is written out to the plot output.  The current value
of the run, step or title can be displayed into the standard output via
the WRITE RUN, WRITE STEP, or WRITE TITLE command.


<sect1> RCV File Format

<p>
The RCV file format was originally designed for sending molecular
dynamics results (particle coordinates for various time steps) from
remote super computers to local workstations using normal phone lines.
Some computers would freely translate non-ASCII characters from one
value to another, so the RCV file format avoids these  characters.  The
resulting format uses standard ASCII text for miscellaneous data (i.e.
temperature, box size, time step, etc.) but the file format uses a type
of encoding for particle coordinates.  Although better schemes could be
implemented today, the RCV format persists because of the many utility
program written that require it.  The RCV file consists of one or more
equivalent sections, each containing coordinate data and other data for
a single simulation step.  Besides coordinate data each section contains
a 100 point histogram of the coordinate RDF (radial distribution
function). This was originally included in the RCV file because the RDF
was used regularly and calculating the RDF was too slow on PC class
workstations.  The RDF is calculated as the number of atom pairs whose
radii fall between 0 and twice the "unit cell distance".  This unit cell
distance can be an arbitrary number but is intended to be the unit cell
length of a BCC lattice of the same density as the system being
simulated.  The assumption about the identity of the "unit cell length"
is important only for some existing RCV analysis programs.  The RDF
function is encoded using the same encoding scheme as the particle
encoding.


<sect2> Coordinate and RDF Encoding Scheme

<p>
 All the particle coordinates are mapped onto a range of integers from 0
to 9999.  For dimensions with repeating boundaries the integer 0
corresponds to a coordinate of 0, and the integer 9999 corresponds to a
coordinate equal to the box size.  For dimensions with free surfaces, 0
corresponds to the smallest  coordinate (which could be less than zero)
and 9999 corresponds to the largest.  Each resulting integer is coded as
a pair of ASCII characters.  Each ASCII character serves as a single
digit in a base 100 representation and ranges from 0 to 99.  The first
digit (call it i) is the low order digit, the second (call it j) is the
high order digit, so that the resulting integer is 100*j+i.  The ASCII
characters 27 to 126 are mapped into the digits 0 to 99.

<p>
When coding dimensions with free surfaces the box size becomes the
distance between the smallest and greatest coordinate.  In addition a
second value is stored in ASCII format: the translation.  This number is
subtracted from 0 or the box size to obtain the smallest or greatest
coordinate respectively.  The x, y and z coordinates of each particle
are stored sequentially, up to 13 particles (or 39 coordinates or 78
characters) per line.  The encoding for the RDF is very similar, the
main difference being that (1) only 100 points are encoded (the points
of the RDF) and (2) the integers 0 to 9999 are mapped onto the interval
from 0 to MAXTABLE, where MAXTABLE is the maximum value of the RDF.



<sect1> COR File Format

<p>
The COR file format is a replacement for the RCV file format.  Its
design was not restricted by the requirement to send files over normal
phone lines.  The primary differences between the COR and RCV formats
are

<itemize>

<item>  the COR file stores the atom types along with the coordinates,

<item>  the particle coordinates are stored as two byte integers (i.e.
integers between 0 and 65355).

<item>  the RDF is not stored in the COR file and

<item>  the COR file uses non-ascii characters, consequently it is
difficult (or impossible) to edit with a typical text editor.  Other
information stored in a COR file

<item>  Number of particles,

<item>  Boundary conditions,

<item>  Run and Step Number,

<item>  Title,

<item>  Energies - Kinetic, Potential, Total and "Bath".

</itemize>



<sect1> Atom Plots

<p>
XMD can produce graphical output of the simulation atoms.  This is done
with the PLOT commands.  With these commands you can

<itemize>

<item> assign various symbols, sizes and colors to atoms,

<item> select the orientation of the plot,

<item> set the number of pages,

<item> plot 'tails' (lines which emanate from each atom to show their motion),

<item> plot bonds (lines connecting atoms within a certain distance from
one another),

<item> set the output destination (typically a file or device) and
format (typically Postscript).

</itemize>



<sect1> REPEAT Command

<p>
Often XMD simulations involve repeating blocks of instructions.
To make these easier to handle there is the REPEAT command.
The REPEAT command is a simple loop command that looks like this,
<tscreen><verb>
repeat 10