xmd-6.html

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

you run XMD on the input file <CODE>femelt.xm</CODE> with the following
command
<BLOCKQUOTE><CODE>
<PRE>
xmd femelt.xm  third 1200
</PRE>
</CODE></BLOCKQUOTE>

then the arguments
&quot;<CODE>third</CODE>&quot;
and
&quot;<CODE>1200</CODE>&quot;
can be used as varibles <CODE>$1</CODE> and <CODE>$2</CODE> in the file
femelt.xm as follows,
<BLOCKQUOTE><CODE>
<PRE>
#
#  Read initialize lattice and dynamics commands from another file
#
read femelt.pos
#
#  Initialize temperature to "1200"
#
itemp $2
#
#  Instruct XMD to save energies to file "third.e"
#
esave 10 $1.e
#
#  Perform dynamics
#
cmd 1000
</PRE>
</CODE></BLOCKQUOTE>

You can use up to 9 command line options labeled
<CODE>$1</CODE> to <CODE>$9</CODE>.
<P>
<P>You can also use the MACRO command to set macro with any name.
For example,
<BLOCKQUOTE><CODE>
<PRE>
...
macro $file femelt
...
esave 10 $file.e
bsave 10 $file.b
ssave 10 $file.s
cmd 1000
</PRE>
</CODE></BLOCKQUOTE>

Note that there is no equals sign (=) in this command.  Don't confuse
it with the CALC command!
The macro name is case insensitive, <CODE>$file</CODE> and <CODE>$FILE</CODE>
are identical.  Macro names can be any length and can consist of
any combination of letter and numbers, and they can start with a
number.  You can even change the value of the command line option
macros.
<P>
<P>
<P>
<H2><A NAME="implementation-plotcolor"></A> <A NAME="ss6.19">6.19 Using Color in Plots </A>
</H2>

<P>When plotting you have the option of selecting colors for atoms.  These
colors are selected using one of two color models, the RGB model
(red-green-blue) and the HSB model (hue-saturation-brightness).  In
order to obtain the desired color you must know who these models work.
<P>
<DL>
<DT><B>RGB red green blue</B><DD><P>The values of red, green and blue can range between 0 and 1, and specify the amount of red, green or
blue in the resulting color.  If (red,green,blue) are (0,0,0), then the color is black, if (1,1,1) then the color is
white, (1,0,0) is pure red, (0,1,0) pure green, et cetera.
<P>
<DT><B>HSB hue saturation brightness</B><DD><P>It may be useful to fix both saturation and brightness to one, and
control the color exclusively by the hue.  This will  give you bright
colors which are relatively easy to distinguish from one another.  Here
are descriptions of the HSB  parameters.  Hue is the shade of color,
starting from red and varying like the color spectrum (red, orange,
yellow, green, blue, violet, red).  Note that the color spectrum is
cyclic, and hue values of 0 and 1 are equivalent (and both red).
Saturation ranges from 0 to 1 - at 1 you get the pure hue (whatever it
is).  At 0 you get a gray.  Values of saturation between 0 and 1 mix a
corresponding amount of gray with the current hue.  The shade of gray is
controlled by the brightness (this needs to be confirmed).  Brightness
also varies from 0 to 1. A brightness of 0 gives black regardless of the
Hue and Saturation values.  A brightness of 1 gives the most color if
your saturation is 1, or gives a pure white if your saturation is
0.
</DL>
<P>
<P>
<H2><A NAME="implementation-parallel"></A> <A NAME="ss6.20">6.20 Parallel Processing </A>
</H2>

<P>XMD can be compiled to run on parallel computers which support POSIX
threads.  POSIX threads is a standard way of creating and controlling
concurrent processes on a parallel machine.  Only SMP computers are
likely to support POSIX threads, these are &quot;shared memory&quot;
systems that typically have up to 8 or 16 cpus.  Massively parallel
machines do not typically support this.  At this time (Aug 1998) the SMP
version of XMD has only been tested on a 2 CPU Pentium II 266 mhz
running Linux version 2.0.32.  It is expected that is will run fine
under other versions of Linux for Intel.  Other architectures are an
unknown.
<P>Currently only the EAM potential can take advantage of parallel
processing.  Typical speed up on our 2 cpu machine has been 1.95, that
is two cpus run 1.95 times faster than one cpu.
<P>To compile the parallel version, you must edit the Makefile and
uncomment the following lines,
<BLOCKQUOTE><CODE>
<PRE>
#THREAD_LIB=-lpthread
#DEF=-DUSE_THREAD_LIB -D_REENTRANT $(INTEL_PATCH)
</PRE>
</CODE></BLOCKQUOTE>

If you are using an Intel machine such as a Pentium, Pentium Pro or
Pentium II you must also uncomment the line
<BLOCKQUOTE><CODE>
<PRE>
#INTEL_PATCH=-DINTEL
</PRE>
</CODE></BLOCKQUOTE>

This is needed to turn on short assembly language patch which
compensates for a small bug in some Linux SMP kernels.
<P>
<P>
<H2><A NAME="implementation-reproducibility"></A> <A NAME="ss6.21">6.21 Reproducibility </A>
</H2>

<P>Theoretically, if you repeat a molecular dynamics simulation,
the results of the second should exactly equal the first.
We call this property "reproducibility".
In practice, however, this is not always true.
This is a consequence of subtle interactions between XMD
commands and computer round-off error.
Before we describe these subtle interactions, lets talk
briefly about computer round-off error.
<P>
<H3>Computer Round-off Error</H3>

<P>In mathematics, the addition and multiplication exhibit the
associative property, 
<BLOCKQUOTE><CODE>
<PRE>
   a + (b + c)  =  (a + b) + c
</PRE>
</CODE></BLOCKQUOTE>

On the computer, this property does not hold exactly.  
Consider the following numeric example of the above equation,
<BLOCKQUOTE><CODE>
<PRE>
   -1e50 + (1e50 + 1)  =  (-1e50 + 1e50) + 1
</PRE>
</CODE></BLOCKQUOTE>

Although you can see 
by the laws of algebra
that the two sides of this equation are equal,  
if you enter them into a typical calculator or computer program, 
the equation will become
<BLOCKQUOTE><CODE>
<PRE>
   0 = 1
</PRE>
</CODE></BLOCKQUOTE>

The problem is that the computer combines 1e50+1 to get 1e50 because
it does not have enough precision to differentiate between 1e50+1
and 1e50.  This is called Computer Round-off Error.  This is an
extreme example, but smaller versions occur all the time, where the
result of a large number of sums depends on the order in which the
sums were done.  These kinds of sums occur throughtout XMD in the
force and energy calculations.  If two otherwise identical runs
perform these sums in differing order, then there will be small 
differences in atomic forces, which in turn will affect the
values of velocities, positions and energies.  
Furthermore, it is a well known property of atomic ensemble 
trajectories that small
differences between two trajectories tend to grow larger
with time. 
So, after 1000 or more steps, these small differences can
become large enough to observe.
<P>
<P>
<H3>Subtle XMD Command Interactions</H3>

<P>We will describe here some specific cases in XMD simulations where
round-off error can affect reporoducibility.
<P>In versions of XMD prior to 2.5.22, atom that passed through
the walls of a repeating box would not be wrapped back until
a neighbor list was calculated, or until the atom coordinates were
written to a file using WRITE RCV, WRITE COR, WRITE STATE or 
WRITE PARTICLE.  Theoretically the simulation should not be affected
as long as the atoms neighbor are correctly identified.  
However, due to round-off error, results will differ when using
wrapped and un-wrapped coordinates.  
Thus, for instance, 
if you ran a simluation for 10000 steps without writing a COR file, 
and then reproduced the same simluation but wrote a COR file
every 1000 steps, 
the trajectory for the two simlulation would start
to diverge after the first 1000 steps, 
although it might not be detectable in the output for another 1
000 or more additional steps.
Version 2.5.22 of XMD wraps the particles after every CMD steps, 
eliminating this source of irreproducibility.
Prior to this change, one must be careful to reproduce all the
WRITE COR, WRITE RCV, WRITE PARTICLE, etc statements between
two runs to obtain identical results.
<P>Another source of irreproducibility is the STATE command.
In version of XMD prior to 2.5.22, 
if for instance you ran a simulations for 10000 steps
and saved the state halfway (at step 5000) using the
WRITE STATE command, you would find upon restarting 
the simulation at step 5000 from the state file that 
the trajectory diverged from the original.
The source of this descrepency is the neighbor list,
because upon restarting XMD with the state file 
at step 500 the
neighbor list is calculated fresh, but in all likelihood
the neighbor list at step 5000 in the original simulation
was older.  While the two neighobr lists give identical
neighbors, the may tabulate neighbors in a different order.
This difference in order can (and probably will) lead to
round-off error as described above.
This source of irreproducibility was addressed in XMD version
2.5.22, by recalculating the neighbor list in the original
simulation whenever WRITE STATE is called.  In this way
the neighobr lists for the two runs will be in identical
order at step 5000, and hence the trajectories will remain
in sync.
<P>However, a related source of irreproducility still 
persists in XMD Version 2.5.22 and beyond, but this
version does not exist in previous versions.
If you compare two otherwise identical runs, but one 
calls WRITE STATE during the simulation while the other doesn't,
then the WRITE STATE command will recalculate the neighbor list.
At this point in the trajectory, the neighbor lists will differ, 
and the atomic trajectories will diverge.
The cure for this is to only compare simulations which call
WRITE STATE in the exact same sequence.
<P>
<P>
<P>
<HR>
<A HREF="xmd-7.html">Next</A>
<A HREF="xmd-5.html">Previous</A>
<A HREF="xmd.html#toc6">Contents</A>
</BODY>
</HTML>