[ViewVC] Diff of: group/trunk/oopsePaper/oopsePaper.tex

Comparing trunk/oopsePaper/oopsePaper.tex (file contents):
Revision 1121 by mmeineke, Mon Apr 19 21:00:24 2004 UTC vs.
Revision 1155 by mmeineke, Tue May 11 19:36:28 2004 UTC

+\usepackage{amsmath}
+\usepackage{amssymb}
+\usepackage{endfloat}
-–
+%\usepackage{berkeley}
+\usepackage{listings}
-+
+\usepackage{palatino}
+\usepackage{graphicx}
+\usepackage[ref]{overcite}
+\usepackage{setspace}
+\renewcommand\citemid{\ } % no comma in optional reference note
+\begin{document}
-<
+\lstset{language=C,float,frame=tblr,frameround=tttt}
->
+\lstset{language=C,frame=TB,basicstyle=\small,basicstyle=\ttfamily, %
->
+        xleftmargin=0.5in, xrightmargin=0.5in,captionpos=b, %
->
+        abovecaptionskip=0.5cm, belowcaptionskip=0.5cm}
+\renewcommand{\lstlistingname}{Scheme}
+\title{{\sc oopse}: An Open Source Object-Oriented Parallel Simulation
+Engine for Molecular Dynamics}
-<
+\author{Matthew A. Meineke, Charles F. Vardeman II, Teng Lin, Christopher J. Fennell and J. Daniel Gezelter\\
->
+\author{Matthew A. Meineke, Charles F. Vardeman II, Teng Lin,\\
->
+ Christopher J. Fennell and J. Daniel Gezelter\\
+Department of Chemistry and Biochemistry\\
+University of Notre Dame\\
+Notre Dame, Indiana 46556}
+\begin{abstract}
+We detail the capabilities of a new open-source parallel simulation
-<
+package ({\sc oopse}) that can perform molecular dynamics simulations
-<
+on atom types that are missing from other popular packages.  In
-<
+particular, {\sc oopse} is capable of performing orientational
-<
+dynamics on dipolar systems, and it can handle simulations of metallic
->
+progrm for MD ({\sc oopse}) that can work with  atom types that are missing from other popular packages.  In
->
+particular, {\sc oopse} is capable of performing efficient orientational
->
+dynamics on dipolar or rigid body systems, and it can handle simulations of metallic
+systems using the embedded atom method ({\sc eam}).
+\end{abstract}
+those of the community of scientists who contribute back to the
+project.
-<
+We have structured this chapter to first discuss the empirical energy
->
+We have structured this paper to first discuss the empirical energy
+functions that {\sc oopse } implements in
+Sec.~\ref{oopseSec:empiricalEnergy}. Following that is a discussion of
+the various input and output files associated with the package
+(Sec.~\ref{oopseSec:IOfiles}). Sec.~\ref{oopseSec:mechanics}
+elucidates the various Molecular Dynamics algorithms {\sc oopse}
+implements in the integration of the Newtonian equations of
-<
+motion. Basic analysis of the trajectories obtained from the
-<
+simulation is discussed in Sec.~\ref{oopseSec:props}. Program design
->
+motion.  Program design
+considerations are presented in Sec.~\ref{oopseSec:design}. And
+lastly, Sec.~\ref{oopseSec:conclusion} concludes the chapter.
-<
+\section{\label{oopseSec:empiricalEnergy}The Empirical Energy Functions}
->
+\section{\label{oopseSec:IOfiles}Concepts \& Files}
-+
+\subsection{{\sc bass} and Model Files}
-+
-+
+Every {\sc oopse} simulation begins with a Bizarre Atom Simulation
-+
+Syntax ({\sc bass}) file. {\sc bass} is a script syntax that is parsed
-+
+by {\sc oopse} at runtime. The {\sc bass} file allows for the user to
-+
+completely describe the system they wish to simulate, as well as tailor
-+
+{\sc oopse}'s behavior during the simulation. {\sc bass} files are
-+
+denoted with the extension
-+
+\texttt{.bass}, an example file is shown in
-+
+Scheme~\ref{sch:bassExample}.
-+
-+
+\begin{lstlisting}[float,caption={[An example of a complete {\sc bass} file] An example showing a complete {\sc bass} file.},label={sch:bassExample}]
-+
-+
+molecule{
-+
+  name = "Ar";
-+
+  nAtoms = 1;
-+
+  atom[0]{
-+
+    type="Ar";
-+
+    position( 0.0, 0.0, 0.0 );
-+
+  }
-+
+}
-+
-+
+nComponents = 1;
-+
+component{
-+
+  type = "Ar";
-+
+  nMol = 108;
-+
+}
-+
-+
+initialConfig = "./argon.init";
-+
-+
+forceField = "LJ";
-+
+ensemble = "NVE"; // specify the simulation ensemble
-+
+dt = 1.0;         // the time step for integration
-+
+runTime = 1e3;    // the total simulation run time
-+
+sampleTime = 100; // trajectory file frequency
-+
+statusTime = 50;  // statistics file frequency
-+
-+
+\end{lstlisting}
-+
-+
+Within the \texttt{.bass} file it is necessary to provide a complete
-+
+description of the molecule before it is actually placed in the
-+
+simulation. The {\sc bass} syntax was originally developed with this
-+
+goal in mind, and allows for the specification of all the atoms in a
-+
+molecular prototype, as well as any bonds, bends, or torsions. These
-+
+descriptions can become lengthy for complex molecules, and it would be
-+
+inconvenient to duplicate the simulation at the beginning of each {\sc
-+
+bass} script. Addressing this issue {\sc bass} allows for the
-+
+inclusion of model files at the top of a \texttt{.bass} file. These
-+
+model files, denoted with the \texttt{.mdl} extension, allow the user
-+
+to describe a molecular prototype once, then simply include it into
-+
+each simulation containing that molecule. Returning to the example in
-+
+Scheme~\ref{sch:bassExample}, the \texttt{.mdl} file's contents would
-+
+be Scheme~\ref{sch:mdlExample}, and the new \texttt{.bass} file would
-+
+become Scheme~\ref{sch:bassExPrime}.
-+
-+
+\begin{lstlisting}[float,caption={An example \texttt{.mdl} file.},label={sch:mdlExample}]
-+
-+
+molecule{
-+
+  name = "Ar";
-+
+  nAtoms = 1;
-+
+  atom[0]{
-+
+    type="Ar";
-+
+    position( 0.0, 0.0, 0.0 );
-+
+  }
-+
+}
-+
-+
+\end{lstlisting}
-+
-+
+\begin{lstlisting}[float,caption={Revised {\sc bass} example.},label={sch:bassExPrime}]
-+
-+
+#include "argon.mdl"
-+
-+
+nComponents = 1;
-+
+component{
-+
+  type = "Ar";
-+
+  nMol = 108;
-+
+}
-+
-+
+initialConfig = "./argon.init";
-+
-+
+forceField = "LJ";
-+
+ensemble = "NVE";
-+
+dt = 1.0;
-+
+runTime = 1e3;
-+
+sampleTime = 100;
-+
+statusTime = 50;
-+
-+
+\end{lstlisting}
-+
+\subsection{\label{oopseSec:atomsMolecules}Atoms, Molecules and Rigid Bodies}
+The basic unit of an {\sc oopse} simulation is the atom. The
+  rigidBody[0]{
+    nMembers = 3;
+    members(0, 1, 2);
-+
+  }
-+
+}
-+
+\end{lstlisting}
-+
-+
+\subsection{\label{sec:miscConcepts}Putting a Script Together}
-+
-+
+The actual creation of a {\sc bass} script requires several key components. The first  part of the script needs to be the declaration of all of the molecule prototypes used in the simulation. This is typically done through the inclusion of {\tt .mdl} files. Only the molecules actually present in the simulation need to be declared, however {\sc bass} allows for the declaration of more molecules than are needed. This gives the user the ability to build up a library of commonly used molecules into a single {\tt .mdl} file.
-+
-+
+Once all prototypes are declared, the ordering of the rest of the script is less stringent. Typically, the next to follow the molecular prototypes are the component statements. These statements specify which molecules are present within the simulation. The number of components must first be declared before the first component block statement (an example is seen in Sch.~\ref{sch:bassExPrime}).
-+
-+
+\subsection{\label{oopseSec:coordFiles}Coordinate Files}
-+
-+
+The standard format for storage of a systems coordinates is a modified
-+
+xyz-file syntax, the exact details of which can be seen in
-+
+Scheme~\ref{sch:dumpFormat}. As all bonding and molecular information
-+
+is stored in the \texttt{.bass} and \texttt{.mdl} files, the
-+
+coordinate files are simply the complete set of coordinates for each
-+
+atom at a given simulation time. One important note, although the
-+
+simulation propagates the complete rotation matrix, directional
-+
+entities are written out using quanternions, to save space in the
-+
+output files.
-+
-+
+\begin{lstlisting}[float,caption={[The format of the coordinate files]Shows the format of the coordinate files. The fist line is the number of atoms. The second line begins with the time stamp followed by the three $\mathsf{H}$ column vectors. It is important to note, that for extended system ensembles, additional information pertinent to the integrators may be stored on this line as well. The next lines are the atomic coordinates for all atoms in the system. First is the name followed by position, velocity, quanternions, and lastly, body fixed angular momentum.},label=sch:dumpFormat]
-+
-+
+nAtoms
-+
+time; Hxx Hyx Hzx; Hxy Hyy Hzy; Hxz Hyz Hzz;
-+
+Name1 x y z vx vy vz q0 q1 q2 q3 jx jy jz
-+
+Name2 x y z vx vy vz q0 q1 q2 q3 jx jy jz
-+
+etc...
-+
-+
+\end{lstlisting}
-+
-+
-+
+There are three major files used by {\sc oopse} written in the
-+
+coordinate format, they are as follows: the initialization file
-+
+(\texttt{.init}), the simulation trajectory file (\texttt{.dump}), and
-+
+the final coordinates of the simulation (\texttt{.eor}). The initialization file is
-+
+necessary for {\sc oopse} to start the simulation with the proper
-+
+coordinates, and is generated before the simulation run. The
-+
+trajectory file is created at the beginning of the simulation, and is
-+
+used to store snapshots of the simulation at regular intervals. The
-+
+first frame is a duplication of the
-+
+\texttt{.init} file, and each subsequent frame is appended to the file
-+
+at an interval specified in the \texttt{.bass} file with the
-+
+\texttt{sampleTime} flag. The final coordinate file is the end of run file. The
-+
+\texttt{.eor} file stores the final configuration of the system for a
-+
+given simulation. The file is updated at the same time as the
-+
+\texttt{.dump} file, however, it only contains the most recent
-+
+frame. In this way, an \texttt{.eor} file may be used as the
-+
+initialization file to a second simulation in order to continue a
-+
+simulation or recover one from a processor that has crashed during the
-+
+course of the run.
-+
-+
+\subsection{\label{oopseSec:initCoords}Generation of Initial Coordinates}
-+
-+
+As was stated in Sec.~\ref{oopseSec:coordFiles}, an initialization
-+
+file is needed to provide the starting coordinates for a
-+
+simulation.  Several helper programs are provided with {\sc oopse} to illustrate possible build routes. However, as each simulation is different, system creation is left to the end user. The {\tt .init} file must list the atoms in the correct order or {\sc oopse} will give an atom mismatch error.
-+
-+
+The correct ordering of the atoms relies on the ordering of atoms and molecules within the model and {\sc bass} scripts. {\sc oopse} expects the order to comply with the following guidelines:
-+
+\begin{enumerate}
-+
+\item All of the molecules of the first declared component are given before proceeding to the molecules of the second component, and so on for all declared components.
-+
+\item The ordering of the atoms for each molecule follows the order declared in the molecule's declaration within the model file.
-+
+\end{enumerate}
-+
+An example is given in Scheme~\ref{sch:initEx1} resulting in the {\tt .init} file shown in Scheme~\ref{sch:initEx2}.
-+
-+
+\begin{lstlisting}[float,caption={This scheme illustrates the declaration of the $\text{I}_2$ molecule and the HCl molecule. The two molecules are then included into a simulation.}, label=sch:initEx1]
-+
-+
+molecule{
-+
+  name = "I2";
-+
+  nAtoms = 2;
-+
+  atom[0]{
-+
+    type = "I";
-+
+  }
-+
+  atom[1]{
-+
+    type = "I";
-+
+  }
-+
+  nBonds = 1;
-+
+  bond[0]{
-+
+    members( 0, 1);
-+
+  }
-+
+}
-+
-+
+molecule{
-+
+  name = "HCl"
-+
+  nAtoms = 2;
-+
+  atom[0]{
-+
+    type = "H";
-+
+  }
-+
+  atom[1]{
-+
+    type = "Cl";
-+
+  }
-+
+  nBonds = 1;
-+
+  bond[0]{
-+
+    members( 0, 1);
-+
-+
+nComponents = 2;
-+
+component{
-+
+  type = "HCl";
-+
+  nMol = 4;
-+
+}
-+
+component{
-+
+  type = "I2";
-+
+  nMol = 1;
-+
+}
-+
-+
+initialConfig = "mixture.init";
-+
+\end{lstlisting}
-+
+\begin{lstlisting}[float,caption={This is the contents of the {\tt mixture.init} file matching the declarations in Scheme~\ref{sch:initEx1}. Note that even though $\text{I}_2$ is declared before HCl, the {\tt .init} file follows the order in which the components were included.},label=sch:initEx2]
-+
-+
-+
+.0;  10.0  0.0  0.0;  0.0  10.0  0.0;  0.0  0.0  10.0;
-+
+H  ...
-+
+Cl ...
-+
+H  ...
-+
+Cl ...
-+
+H  ...
-+
+Cl ...
-+
+H  ...
-+
+Cl ...
-+
+I  ...
-+
+I  ...
-+
-+
+\end{lstlisting}
-+
-+
-+
+\subsection{The Statistics File}
-+
-+
+The last output file generated by {\sc oopse} is the statistics
-+
+file. This file records such statistical quantities as the
-+
+instantaneous temperature, volume, pressure, etc. It is written out
-+
+with the frequency specified in the \texttt{.bass} file with the
-+
+\texttt{statusTime} keyword. The file allows the user to observe the
-+
+system variables as a function of simulation time while the simulation
-+
+is in progress. One useful function the statistics file serves is to
-+
+monitor the conserved quantity of a given simulation ensemble, this
-+
+allows the user to observe the stability of the integrator. The
-+
+statistics file is denoted with the \texttt{.stat} file extension.
-+
-+
-+
+\section{\label{oopseSec:empiricalEnergy}The Empirical Energy Functions}
-+
-+
+\
+\subsection{\label{sec:LJPot}The Lennard Jones Force Field}
+The most basic force field implemented in {\sc oopse} is the
+the inter-atomic forces.
-–
+\section{\label{oopseSec:IOfiles}Input and Output Files}
-–
+\subsection{{\sc bass} and Model Files}
-–
-–
+Every {\sc oopse} simulation begins with a Bizarre Atom Simulation
-–
+Syntax ({\sc bass}) file. {\sc bass} is a script syntax that is parsed
-–
+by {\sc oopse} at runtime. The {\sc bass} file allows for the user to
-–
+completely describe the system they wish to simulate, as well as tailor
-–
+{\sc oopse}'s behavior during the simulation. {\sc bass} files are
-–
+denoted with the extension
-–
+\texttt{.bass}, an example file is shown in
-–
+Scheme~\ref{sch:bassExample}.
-–
-–
+\begin{lstlisting}[float,caption={[An example of a complete {\sc bass} file] An example showing a complete {\sc bass} file.},label={sch:bassExample}]
-–
-–
+molecule{
-–
+  name = "Ar";
-–
+  nAtoms = 1;
-–
+  atom[0]{
-–
+    type="Ar";
-–
+    position( 0.0, 0.0, 0.0 );
-–
+  }
-–
+}
-–
-–
+nComponents = 1;
-–
+component{
-–
+  type = "Ar";
-–
+  nMol = 108;
-–
+}
-–
-–
+initialConfig = "./argon.init";
-–
-–
+forceField = "LJ";
-–
+ensemble = "NVE"; // specify the simulation ensemble
-–
+dt = 1.0;         // the time step for integration
-–
+runTime = 1e3;    // the total simulation run time
-–
+sampleTime = 100; // trajectory file frequency
-–
+statusTime = 50;  // statistics file frequency
-–
-–
+\end{lstlisting}
-–
-–
+Within the \texttt{.bass} file it is necessary to provide a complete
-–
+description of the molecule before it is actually placed in the
-–
+simulation. The {\sc bass} syntax was originally developed with this
-–
+goal in mind, and allows for the specification of all the atoms in a
-–
+molecular prototype, as well as any bonds, bends, or torsions. These
-–
+descriptions can become lengthy for complex molecules, and it would be
-–
+inconvenient to duplicate the simulation at the beginning of each {\sc
-–
+bass} script. Addressing this issue {\sc bass} allows for the
-–
+inclusion of model files at the top of a \texttt{.bass} file. These
-–
+model files, denoted with the \texttt{.mdl} extension, allow the user
-–
+to describe a molecular prototype once, then simply include it into
-–
+each simulation containing that molecule. Returning to the example in
-–
+Scheme~\ref{sch:bassExample}, the \texttt{.mdl} file's contents would
-–
+be Scheme~\ref{sch:mdlExample}, and the new \texttt{.bass} file would
-–
+become Scheme~\ref{sch:bassExPrime}.
-–
-–
+\begin{lstlisting}[float,caption={An example \texttt{.mdl} file.},label={sch:mdlExample}]
-–
-–
+molecule{
-–
+  name = "Ar";
-–
+  nAtoms = 1;
-–
+  atom[0]{
-–
+    type="Ar";
-–
+    position( 0.0, 0.0, 0.0 );
-–
+  }
-–
+}
-–
-–
+\end{lstlisting}
-–
-–
+\begin{lstlisting}[float,caption={Revised {\sc bass} example.},label={sch:bassExPrime}]
-–
-–
+#include "argon.mdl"
-–
-–
+nComponents = 1;
-–
+component{
-–
+  type = "Ar";
-–
+  nMol = 108;
-–
+}
-–
-–
+initialConfig = "./argon.init";
-–
-–
+forceField = "LJ";
-–
+ensemble = "NVE";
-–
+dt = 1.0;
-–
+runTime = 1e3;
-–
+sampleTime = 100;
-–
+statusTime = 50;
-–
-–
+\end{lstlisting}
-–
-–
+\subsection{\label{oopseSec:coordFiles}Coordinate Files}
-–
-–
+The standard format for storage of a systems coordinates is a modified
-–
+xyz-file syntax, the exact details of which can be seen in
-–
+Scheme~\ref{sch:dumpFormat}. As all bonding and molecular information
-–
+is stored in the \texttt{.bass} and \texttt{.mdl} files, the
-–
+coordinate files are simply the complete set of coordinates for each
-–
+atom at a given simulation time. One important note, although the
-–
+simulation propagates the complete rotation matrix, directional
-–
+entities are written out using quanternions, to save space in the
-–
+output files.
-–
-–
+\begin{lstlisting}[float,caption={[The format of the coordinate files]Shows the format of the coordinate files. The fist line is the number of atoms. The second line begins with the time stamp followed by the three $\mathsf{H}$ column vectors. It is important to note, that for extended system ensembles, additional information pertinent to the integrators may be stored on this line as well. The next lines are the atomic coordinates for all atoms in the system. First is the name followed by position, velocity, quanternions, and lastly angular velocities.},label=sch:dumpFormat]
-–
-–
+nAtoms
-–
+time; Hxx Hyx Hzx; Hxy Hyy Hzy; Hxz Hyz Hzz;
-–
+Name1 x y z vx vy vz q0 q1 q2 q3 jx jy jz
-–
+Name2 x y z vx vy vz q0 q1 q2 q3 jx jy jz
-–
+etc...
-–
-–
+\end{lstlisting}
-–
-–
-–
+There are three major files used by {\sc oopse} written in the
-–
+coordinate format, they are as follows: the initialization file
-–
+(\texttt{.init}), the simulation trajectory file (\texttt{.dump}), and
-–
+the final coordinates of the simulation. The initialization file is
-–
+necessary for {\sc oopse} to start the simulation with the proper
-–
+coordinates, and is generated before the simulation run. The
-–
+trajectory file is created at the beginning of the simulation, and is
-–
+used to store snapshots of the simulation at regular intervals. The
-–
+first frame is a duplication of the
-–
+\texttt{.init} file, and each subsequent frame is appended to the file
-–
+at an interval specified in the \texttt{.bass} file with the
-–
+\texttt{sampleTime} flag. The final coordinate file is the end of run file. The
-–
+\texttt{.eor} file stores the final configuration of the system for a
-–
+given simulation. The file is updated at the same time as the
-–
+\texttt{.dump} file, however, it only contains the most recent
-–
+frame. In this way, an \texttt{.eor} file may be used as the
-–
+initialization file to a second simulation in order to continue a
-–
+simulation or recover one from a processor that has crashed during the
-–
+course of the run.
-–
-–
+\subsection{\label{oopseSec:initCoords}Generation of Initial Coordinates}
-–
-–
+As was stated in Sec.~\ref{oopseSec:coordFiles}, an initialization
-–
+file is needed to provide the starting coordinates for a
-–
+simulation. The {\sc oopse} package provides several system building
-–
+programs to aid in the creation of the \texttt{.init}
-–
+file. The programs use {\sc bass}, and will recognize
-–
+arguments and parameters in the \texttt{.bass} file that would
-–
+otherwise be ignored by the simulation.
-–
-–
+\subsection{The Statistics File}
-–
-–
+The last output file generated by {\sc oopse} is the statistics
-–
+file. This file records such statistical quantities as the
-–
+instantaneous temperature, volume, pressure, etc. It is written out
-–
+with the frequency specified in the \texttt{.bass} file with the
-–
+\texttt{statusTime} keyword. The file allows the user to observe the
-–
+system variables as a function of simulation time while the simulation
-–
+is in progress. One useful function the statistics file serves is to
-–
+monitor the conserved quantity of a given simulation ensemble, this
-–
+allows the user to observe the stability of the integrator. The
-–
+statistics file is denoted with the \texttt{.stat} file extension.
-–
+\section{\label{oopseSec:mechanics}Mechanics}
+\subsection{\label{oopseSec:integrate}Integrating the Equations of Motion: the
+orientational anisotropy in the system (i.e. in lipid bilayer
+simulations).
-<
+\subsection{\label{oopseSec:rattle}The {\sc rattle} Method for Bond
->
+\subsection{\label{sec:constraints}Constraint Methods}
->
->
+\subsubsection{\label{oopseSec:rattle}The {\sc rattle} Method for Bond
+        Constraints}
+In order to satisfy the constraints of fixed bond lengths within {\sc
+oopse}, we have implemented the {\sc rattle} algorithm of
+Andersen.\cite{andersen83} The algorithm is a velocity verlet
+formulation of the {\sc shake} method\cite{ryckaert77} of iteratively
-<
+solving the Lagrange multipliers of constraint. The system of Lagrange
-<
+multipliers allows one to reformulate the equations of motion with
-<
+explicit constraint forces.\cite{fowles99:lagrange}
->
+solving the Lagrange multipliers of constraint.
-<
+Consider a system described by coordinates $q_1$ and $q_2$ subject to an
-<
+equation of constraint:
-<
+\begin{equation}
-<
+\sigma(q_1, q_2,t) = 0
-<
+\label{oopseEq:lm1}
-<
+\end{equation}
-<
+The Lagrange formulation of the equations of motion can be written:
-<
+\begin{equation}
-<
+\delta\int_{t_1}^{t_2}L\, dt =
-<
+        \int_{t_1}^{t_2} \sum_i \biggl [ \frac{\partial L}{\partial q_i}
-<
+        - \frac{d}{dt}\biggl(\frac{\partial L}{\partial \dot{q}_i}
-<
+        \biggr ) \biggr] \delta q_i \, dt = 0.
-<
+\label{oopseEq:lm2}
-<
+\end{equation}
-<
+Here, $\delta q_i$ is not independent for each $q$, as $q_1$ and $q_2$
-<
+are linked by $\sigma$. However, $\sigma$ is fixed at any given
-<
+instant of time, giving:
-<
+\begin{align}
-<
+\delta\sigma &= \biggl( \frac{\partial\sigma}{\partial q_1} \delta q_1 %
-<
+        + \frac{\partial\sigma}{\partial q_2} \delta q_2 \biggr) = 0 ,\\
-<
+%
-<
+\frac{\partial\sigma}{\partial q_1} \delta q_1 &= %
-<
+        - \frac{\partial\sigma}{\partial q_2} \delta q_2, \\
-<
+%
-<
+\delta q_2 &= - \biggl(\frac{\partial\sigma}{\partial q_1} \bigg / %
-<
+        \frac{\partial\sigma}{\partial q_2} \biggr) \delta q_1.
-<
+\end{align}
-<
+Substituted back into Eq.~\ref{oopseEq:lm2},
-<
+\begin{equation}
-<
+\int_{t_1}^{t_2}\biggl [ \biggl(\frac{\partial L}{\partial q_1}
-<
+        - \frac{d}{dt}\,\frac{\partial L}{\partial \dot{q}_1}
-<
+        \biggr)
-<
+        - \biggl( \frac{\partial L}{\partial q_1}
-<
+        - \frac{d}{dt}\,\frac{\partial L}{\partial \dot{q}_1}
-<
+        \biggr) \biggl(\frac{\partial\sigma}{\partial q_1} \bigg / %
-<
+        \frac{\partial\sigma}{\partial q_2} \biggr)\biggr] \delta q_1 \, dt = 0.
-<
+\label{oopseEq:lm3}
-<
+\end{equation}
-<
+Leading to,
-<
+\begin{equation}
-<
+\frac{\biggl(\frac{\partial L}{\partial q_1}
-<
+        - \frac{d}{dt}\,\frac{\partial L}{\partial \dot{q}_1}
-<
+        \biggr)}{\frac{\partial\sigma}{\partial q_1}} =
-<
+\frac{\biggl(\frac{\partial L}{\partial q_2}
-<
+        - \frac{d}{dt}\,\frac{\partial L}{\partial \dot{q}_2}
-<
+        \biggr)}{\frac{\partial\sigma}{\partial q_2}}.
-<
+\label{oopseEq:lm4}
-<
+\end{equation}
-<
+This relation can only be statisfied, if both are equal to a single
-<
+function $-\lambda(t)$,
-<
+\begin{align}
-<
+\frac{\biggl(\frac{\partial L}{\partial q_1}
-<
+        - \frac{d}{dt}\,\frac{\partial L}{\partial \dot{q}_1}
-<
+        \biggr)}{\frac{\partial\sigma}{\partial q_1}} &= -\lambda(t), \\
-<
+%
-<
+\frac{\partial L}{\partial q_1}
-<
+        - \frac{d}{dt}\,\frac{\partial L}{\partial \dot{q}_1} &=
-<
+         -\lambda(t)\,\frac{\partial\sigma}{\partial q_1} ,\\
-<
+%
-<
+\frac{\partial L}{\partial q_1}
-<
+        - \frac{d}{dt}\,\frac{\partial L}{\partial \dot{q}_1}
-<
+         + \mathcal{G}_i &= 0,
-<
+\end{align}
-<
+where $\mathcal{G}_i$, the force of constraint on $i$, is:
-<
+\begin{equation}
-<
+\mathcal{G}_i = \lambda(t)\,\frac{\partial\sigma}{\partial q_1}.
-<
+\label{oopseEq:lm5}
-<
+\end{equation}
-<
-<
+In a simulation, this would involve the solution of a set of $(m + n)$
-<
+number of equations. Where $m$ is the number of constraints, and $n$
-<
+is the number of constrained coordinates. In practice, this is not
-<
+done, as the matrix inversion necessary to solve the system of
-<
+equations would be very time consuming to solve. Additionally, the
-<
+numerical error in the solution of the set of $\lambda$'s would be
-<
+compounded by the error inherent in propagating by the Velocity Verlet
-<
+algorithm ($\Delta t^4$). The Verlet propagation error is negligible
-<
+in an unconstrained system, as one is interested in the statistics of
-<
+the run, and not that the run be numerically exact to the ``true''
-<
+integration. This relates back to the ergodic hypothesis that a time
-<
+integral of a valid trajectory will still give the correct ensemble
-<
+average. However, in the case of constraints, if the equations of
-<
+motion leave the ``true'' trajectory, they are departing from the
-<
+constrained surface. The method that is used, is to iteratively solve
-<
+for $\lambda(t)$ at each time step.
-<
-<
+In {\sc rattle} the equations of motion are modified subject to the
-<
+following two constraints:
-<
+\begin{align}
-<
+\sigma_{ij}[\mathbf{r}(t)] \equiv
-<
+        [ \mathbf{r}_i(t) - \mathbf{r}_j(t)]^2  - d_{ij}^2 &= 0 %
-<
+        \label{oopseEq:c1}, \\
-<
+%
-<
+[\mathbf{\dot{r}}_i(t) - \mathbf{\dot{r}}_j(t)] \cdot
-<
+        [\mathbf{r}_i(t) - \mathbf{r}_j(t)] &= 0 .\label{oopseEq:c2}
-<
+\end{align}
-<
+Eq.~\ref{oopseEq:c1} is the set of bond constraints, where $d_{ij}$ is
-<
+the constrained distance between atom $i$ and
-<
+$j$. Eq.~\ref{oopseEq:c2} constrains the velocities of $i$ and $j$ to
-<
+be perpendicular to the bond vector, so that the bond can neither grow
-<
+nor shrink. The constrained dynamics equations become:
-<
+\begin{equation}
-<
+m_i \mathbf{\ddot{r}}_i = \mathbf{F}_i + \mathbf{\mathcal{G}}_i,
-<
+\label{oopseEq:r1}
-<
+\end{equation}
-<
+where,$\mathbf{\mathcal{G}}_i$ are the forces of constraint on $i$,
-<
+and are defined:
-<
+\begin{equation}
-<
+\mathbf{\mathcal{G}}_i = - \sum_j \lambda_{ij}(t)\,\nabla \sigma_{ij}.
-<
+\label{oopseEq:r2}
-<
+\end{equation}
-<
-<
+In Velocity Verlet, if $\Delta t = h$, the propagation can be written:
-<
+\begin{align}
-<
+\mathbf{r}_i(t+h) &=
-<
+        \mathbf{r}_i(t) + h\mathbf{\dot{r}}(t) +
-<
+        \frac{h^2}{2m_i}\,\Bigl[ \mathbf{F}_i(t) +
-<
+        \mathbf{\mathcal{G}}_{Ri}(t) \Bigr] \label{oopseEq:vv1}, \\
-<
+%
-<
+\mathbf{\dot{r}}_i(t+h) &=
-<
+        \mathbf{\dot{r}}_i(t) + \frac{h}{2m_i}
-<
+        \Bigl[ \mathbf{F}_i(t) + \mathbf{\mathcal{G}}_{Ri}(t) +
-<
+        \mathbf{F}_i(t+h) + \mathbf{\mathcal{G}}_{Vi}(t+h) \Bigr] ,%
-<
+        \label{oopseEq:vv2}
-<
+\end{align}
-<
+where:
-<
+\begin{align}
-<
+\mathbf{\mathcal{G}}_{Ri}(t) &=
-<
+        -2 \sum_j \lambda_{Rij}(t) \mathbf{r}_{ij}(t) ,\\
-<
+%
-<
+\mathbf{\mathcal{G}}_{Vi}(t+h) &=
-<
+        -2 \sum_j \lambda_{Vij}(t+h) \mathbf{r}(t+h).
-<
+\end{align}
-<
+Next, define:
-<
+\begin{align}
-<
+g_{ij} &= h \lambda_{Rij}(t) ,\\
-<
+k_{ij} &= h \lambda_{Vij}(t+h), \\
-<
+\mathbf{q}_i &= \mathbf{\dot{r}}_i(t) + \frac{h}{2m_i} \mathbf{F}_i(t)
-<
+        - \frac{1}{m_i}\sum_j g_{ij}\mathbf{r}_{ij}(t).
-<
+\end{align}
-<
+Using these definitions, Eq.~\ref{oopseEq:vv1} and \ref{oopseEq:vv2}
-<
+can be rewritten as,
-<
+\begin{align}
-<
+\mathbf{r}_i(t+h) &= \mathbf{r}_i(t) + h \mathbf{q}_i ,\\
-<
+%
-<
+\mathbf{\dot{r}}(t+h) &= \mathbf{q}_i + \frac{h}{2m_i}\mathbf{F}_i(t+h)
-<
+        -\frac{1}{m_i}\sum_j k_{ij} \mathbf{r}_{ij}(t+h).
-<
+\end{align}
-<
-<
+To integrate the equations of motion, the {\sc rattle} algorithm first
-<
+solves for $\mathbf{r}(t+h)$. Let,
-<
+\begin{equation}
-<
+\mathbf{q}_i = \mathbf{\dot{r}}(t) + \frac{h}{2m_i}\mathbf{F}_i(t).
-<
+\end{equation}
-<
+Here $\mathbf{q}_i$ corresponds to an initial unconstrained move. Next
-<
+pick a constraint $j$, and let,
-<
+\begin{equation}
-<
+\mathbf{s} = \mathbf{r}_i(t) + h\mathbf{q}_i(t)
-<
+        - \mathbf{r}_j(t) + h\mathbf{q}_j(t).
-<
+\label{oopseEq:ra1}
-<
+\end{equation}
-<
+If
-<
+\begin{equation}
-<
+\Big| |\mathbf{s}|^2 - d_{ij}^2 \Big| > \text{tolerance},
-<
+\end{equation}
-<
+then the constraint is unsatisfied, and corrections are made to the
-<
+positions. First we define a test corrected configuration as,
-<
+\begin{align}
-<
+\mathbf{r}_i^T(t+h) = \mathbf{r}_i(t) + h\biggl[\mathbf{q}_i -
-<
+        g_{ij}\,\frac{\mathbf{r}_{ij}(t)}{m_i} \biggr] ,\\
-<
+%
-<
+\mathbf{r}_j^T(t+h) = \mathbf{r}_j(t) + h\biggl[\mathbf{q}_j +
-<
+        g_{ij}\,\frac{\mathbf{r}_{ij}(t)}{m_j} \biggr].
-<
+\end{align}
-<
+And we chose $g_{ij}$ such that, $|\mathbf{r}_i^T - \mathbf{r}_j^T|^2
-<
+= d_{ij}^2$. Solving the quadratic for $g_{ij}$ we obtain the
-<
+approximation,
-<
+\begin{equation}
-<
+g_{ij} = \frac{(s^2 - d^2)}{2h[\mathbf{s}\cdot\mathbf{r}_{ij}(t)]
-<
+        (\frac{1}{m_i} + \frac{1}{m_j})}.
-<
+\end{equation}
-<
+Although not an exact solution for $g_{ij}$, as this is an iterative
-<
+scheme overall, the eventual solution will converge. With a trial
-<
+$g_{ij}$, the new $\mathbf{q}$'s become,
-<
+\begin{align}
-<
+\mathbf{q}_i &= \mathbf{q}^{\text{old}}_i - g_{ij}\,
-<
+        \frac{\mathbf{r}_{ij}(t)}{m_i} ,\\
-<
+%
-<
+\mathbf{q}_j &= \mathbf{q}^{\text{old}}_j + g_{ij}\,
-<
+        \frac{\mathbf{r}_{ij}(t)}{m_j} .
-<
+\end{align}
-<
+The whole algorithm is then repeated from Eq.~\ref{oopseEq:ra1} until
-<
+all constraints are satisfied.
-<
-<
+The second step of {\sc rattle}, is to then update the velocities. The
-<
+step starts with,
-<
+\begin{equation}
-<
+\mathbf{\dot{r}}_i(t+h) = \mathbf{q}_i + \frac{h}{2m_i}\mathbf{F}_i(t+h).
-<
+\end{equation}
-<
+Next we pick a constraint $j$, and calculate the dot product $\ell$.
-<
+\begin{equation}
-<
+\ell = \mathbf{r}_{ij}(t+h) \cdot \mathbf{\dot{r}}_{ij}(t+h).
-<
+\label{oopseEq:rv1}
-<
+\end{equation}
-<
+Here if constraint Eq.~\ref{oopseEq:c2} holds, $\ell$ should be
-<
+zero. Therefore if $\ell$ is greater than some tolerance, then
-<
+corrections are made to the $i$ and $j$ velocities.
-<
+\begin{align}
-<
+\mathbf{\dot{r}}_i^T &= \mathbf{\dot{r}}_i(t+h) - k_{ij}
-<
+        \frac{\mathbf{\dot{r}}_{ij}(t+h)}{m_i}, \\
-<
+%
-<
+\mathbf{\dot{r}}_j^T &= \mathbf{\dot{r}}_j(t+h) + k_{ij}
-<
+        \frac{\mathbf{\dot{r}}_{ij}(t+h)}{m_j}.
-<
+\end{align}
-<
+Like in the previous step, we select a value for $k_{ij}$ such that
-<
+$\ell$ is zero.
-<
+\begin{equation}
-<
+k_{ij} = \frac{\ell}{d^2_{ij}(\frac{1}{m_i} + \frac{1}{m_j})}.
-<
+\end{equation}
-<
+The test velocities, $\mathbf{\dot{r}}^T_i$ and
-<
+$\mathbf{\dot{r}}^T_j$, then replace their respective velocities, and
-<
+the algorithm is iterated from Eq.~\ref{oopseEq:rv1} until all
-<
+constraints are satisfied.
->
+\subsubsection{\label{oopseSec:zcons}Z-Constraint Method}
-–
-–
+\subsection{\label{oopseSec:zcons}Z-Constraint Method}
-–
+Based on the fluctuation-dissipation theorem, a force auto-correlation
+method was developed by Roux and Karplus to investigate the dynamics
+of ions inside ion channels.\cite{Roux91} The time-dependent friction
+        -k_{\text{Harmonic}}(z(t)-z_{\text{cons}}).
+\end{equation}
-–
+\section{\label{oopseSec:props}Trajectory Analysis}
-–
-–
+\subsection{\label{oopseSec:staticProps}Static Property Analysis}
-–
-–
+The static properties of the trajectories are analyzed with the
-–
+program \texttt{staticProps}. The code is capable of calculating a
-–
+number of pair correlations between species A and B. Some of which
-–
+only apply to directional entities. The summary of pair correlations
-–
+can be found in Table~\ref{oopseTb:gofrs}
-–
-–
+\begin{table}
-–
+\caption{THE DIFFERENT PAIR CORRELATIONS IN \texttt{staticProps}}
-–
+\label{oopseTb:gofrs}
-–
+\begin{center}
-–
+\begin{tabular}{|l|c|c|}
-–
+\hline
-–
+Name      & Equation & Directional Atom \\ \hline
-–
+$g_{\text{AB}}(r)$              & Eq.~\ref{eq:gofr}         & neither \\ \hline
-–
+$g_{\text{AB}}(r, \cos \theta)$ & Eq.~\ref{eq:gofrCosTheta} & A \\ \hline
-–
+$g_{\text{AB}}(r, \cos \omega)$ & Eq.~\ref{eq:gofrCosOmega} & both \\ \hline
-–
+$g_{\text{AB}}(x, y, z)$        & Eq.~\ref{eq:gofrXYZ}      & neither \\ \hline
-–
+$\langle \cos \omega \rangle_{\text{AB}}(r)$ & Eq.~\ref{eq:cosOmegaOfR} &%
-–
+        both \\ \hline
-–
+\end{tabular}
-–
+\begin{minipage}{\linewidth}
-–
+\centering
-–
+\vspace{2mm}
-–
+The third column specifies which atom, if any, need be a directional entity.
-–
+\end{minipage}
-–
+\end{center}
-–
+\end{table}
-–
-–
+The first pair correlation, $g_{\text{AB}}(r)$, is defined as follows:
-–
+\begin{equation}
-–
+g_{\text{AB}}(r) = \frac{V}{N_{\text{A}}N_{\text{B}}}\langle %%
-–
+        \sum_{i \in \text{A}} \sum_{j \in \text{B}} %%
-–
+        \delta( r - |\mathbf{r}_{ij}|) \rangle, \label{eq:gofr}
-–
+\end{equation}
-–
+where $\mathbf{r}_{ij}$ is the vector
-–
+\begin{equation*}
-–
+\mathbf{r}_{ij} = \mathbf{r}_j - \mathbf{r}_i, \notag
-–
+\end{equation*}
-–
+and $\frac{V}{N_{\text{A}}N_{\text{B}}}$ normalizes the average over
-–
+the expected pair density at a given $r$.
-–
-–
+The next two pair correlations, $g_{\text{AB}}(r, \cos \theta)$ and
-–
+$g_{\text{AB}}(r, \cos \omega)$, are similar in that they are both two
-–
+dimensional histograms. Both use $r$ for the primary axis then a
-–
+$\cos$ for the secondary axis ($\cos \theta$ for
-–
+Eq.~\ref{eq:gofrCosTheta} and $\cos \omega$ for
-–
+Eq.~\ref{eq:gofrCosOmega}). This allows for the investigator to
-–
+correlate alignment on directional entities. $g_{\text{AB}}(r, \cos
-–
+\theta)$ is defined as follows:
-–
+\begin{equation}
-–
+g_{\text{AB}}(r, \cos \theta) = \frac{V}{N_{\text{A}}N_{\text{B}}}\langle
-–
+\sum_{i \in \text{A}} \sum_{j \in \text{B}}
-–
+\delta( \cos \theta - \cos \theta_{ij})
-–
+\delta( r - |\mathbf{r}_{ij}|) \rangle.
-–
+\label{eq:gofrCosTheta}
-–
+\end{equation}
-–
+Here
-–
+\begin{equation*}
-–
+\cos \theta_{ij} = \mathbf{\hat{i}} \cdot \mathbf{\hat{r}}_{ij},
-–
+\end{equation*}
-–
+where $\mathbf{\hat{i}}$ is the unit directional vector of species $i$
-–
+and $\mathbf{\hat{r}}_{ij}$ is the unit vector associated with vector
-–
+$\mathbf{r}_{ij}$.
-–
-–
+The second two dimensional histogram is of the form:
-–
+\begin{equation}
-–
+g_{\text{AB}}(r, \cos \omega) =
-–
+        \frac{V}{N_{\text{A}}N_{\text{B}}}\langle
-–
+        \sum_{i \in \text{A}} \sum_{j \in \text{B}}
-–
+        \delta( \cos \omega - \cos \omega_{ij})
-–
+        \delta( r - |\mathbf{r}_{ij}|) \rangle. \label{eq:gofrCosOmega}
-–
+\end{equation}
-–
+Here
-–
+\begin{equation*}
-–
+\cos \omega_{ij} = \mathbf{\hat{i}} \cdot \mathbf{\hat{j}}.
-–
+\end{equation*}
-–
+Again, $\mathbf{\hat{i}}$ and $\mathbf{\hat{j}}$ are the unit
-–
+directional vectors of species $i$ and $j$.
-–
-–
+The static analysis code is also cable of calculating a three
-–
+dimensional pair correlation of the form:
-–
+\begin{equation}\label{eq:gofrXYZ}
-–
+g_{\text{AB}}(x, y, z) =
-–
+        \frac{V}{N_{\text{A}}N_{\text{B}}}\langle
-–
+        \sum_{i \in \text{A}} \sum_{j \in \text{B}}
-–
+        \delta( x - x_{ij})
-–
+        \delta( y - y_{ij})
-–
+        \delta( z - z_{ij}) \rangle,
-–
+\end{equation}
-–
+where $x_{ij}$, $y_{ij}$, and $z_{ij}$ are the $x$, $y$, and $z$
-–
+components respectively of vector $\mathbf{r}_{ij}$.
-–
-–
+The final pair correlation is similar to
-–
+Eq.~\ref{eq:gofrCosOmega}. $\langle \cos \omega
-–
+\rangle_{\text{AB}}(r)$ is calculated in the following way:
-–
+\begin{equation}\label{eq:cosOmegaOfR}
-–
+\langle \cos \omega \rangle_{\text{AB}}(r)  =
-–
+        \langle \sum_{i \in \text{A}} \sum_{j \in \text{B}}
-–
+        (\cos \omega_{ij}) \delta( r - |\mathbf{r}_{ij}|) \rangle.
-–
+\end{equation}
-–
+Here $\cos \omega_{ij}$ is defined in the same way as in
-–
+Eq.~\ref{eq:gofrCosOmega}. This equation is a single dimensional pair
-–
+correlation that gives the average correlation of two directional
-–
+entities as a function of their distance from each other.
-–
-–
+\subsection{\label{dynamicProps}Dynamic Property Analysis}
-–
-–
+The dynamic properties of a trajectory are calculated with the program
-–
+\texttt{dynamicProps}. The program calculates the following properties:
-–
+\begin{gather}
-–
+\langle | \mathbf{r}(t) - \mathbf{r}(0) |^2 \rangle, \label{eq:rms}\\
-–
+\langle \mathbf{v}(t) \cdot \mathbf{v}(0) \rangle, \label{eq:velCorr} \\
-–
+\langle \mathbf{j}(t) \cdot \mathbf{j}(0) \rangle. \label{eq:angularVelCorr}
-–
+\end{gather}
-–
-–
+Eq.~\ref{eq:rms} is the root mean square displacement function. Which
-–
+allows one to observe the average displacement of an atom as a
-–
+function of time. The quantity is useful when calculating diffusion
-–
+coefficients because of the Einstein Relation, which is valid at long
-–
+times.\cite{allen87:csl}
-–
+\begin{equation}
-–
+tD = \langle | \mathbf{r}(t) - \mathbf{r}(0) |^2 \rangle.
-–
+\label{oopseEq:einstein}
-–
+\end{equation}
-–
-–
+Eq.~\ref{eq:velCorr} and \ref{eq:angularVelCorr} are the translational
-–
+velocity and angular velocity correlation functions respectively. The
-–
+latter is only applicable to directional species in the
-–
+simulation. The velocity autocorrelation functions are useful when
-–
+determining vibrational information about the system of interest.
-–
+\section{\label{oopseSec:design}Program Design}
+\subsection{\label{sec:architecture} {\sc oopse} Architecture}
+and favorably compete with spatial methods up to 100,000
+atoms.\cite{plimpton95}
-–
+\subsection{\label{oopseSec:memAlloc}Memory Issues in Trajectory Analysis}
-–
-–
+For large simulations, the trajectory files can sometimes reach sizes
-–
+in excess of several gigabytes. In order to effectively analyze that
-–
+amount of data, two memory management schemes have been devised for
-–
+\texttt{staticProps} and for \texttt{dynamicProps}. The first scheme,
-–
+developed for \texttt{staticProps}, is the simplest. As each frame's
-–
+statistics are calculated independent of each other, memory is
-–
+allocated for each frame, then freed once correlation calculations are
-–
+complete for the snapshot. To prevent multiple passes through a
-–
+potentially large file, \texttt{staticProps} is capable of calculating
-–
+all requested correlations per frame with only a single pair loop in
-–
+each frame and a single read of the file.
-–
-–
+The second, more advanced memory scheme, is used by
-–
+\texttt{dynamicProps}. Here, the program must have multiple frames in
-–
+memory to calculate time dependent correlations. In order to prevent a
-–
+situation where the program runs out of memory due to large
-–
+trajectories, the user is able to specify that the trajectory be read
-–
+in blocks. The number of frames in each block is specified by the
-–
+user, and upon reading a block of the trajectory,
-–
+\texttt{dynamicProps} will calculate all of the time correlation frame
-–
+pairs within the block. After in-block correlations are complete, a
-–
+second block of the trajectory is read, and the cross correlations are
-–
+calculated between the two blocks. This second block is then freed and
-–
+then incremented and the process repeated until the end of the
-–
+trajectory. Once the end is reached, the first block is freed then
-–
+incremented, and the again the internal time correlations are
-–
+calculated. The algorithm with the second block is then repeated with
-–
+the new origin block, until all frame pairs have been correlated in
-–
+time. This process is illustrated in
-–
+Fig.~\ref{oopseFig:dynamicPropsMemory}.
-–
-–
+%\begin{figure}
-–
+%\centering
-–
+%\includegraphics[width=\linewidth]{dynamicPropsMem.eps}
-–
+%\caption[A representation of the block correlations in \texttt{dynamicProps}]{This diagram illustrates the memory management used by \texttt{dynamicProps}, which follows the scheme: $\sum^{N_{\text{memory blocks}}}_{i=1}[ \operatorname{self}(i) + \sum^{N_{\text{memory blocks}}}_{j>i} \operatorname{cross}(i,j)]$. The shaded region represents the self correlation of the memory block, and the open blocks are read one at a time and the cross correlations between blocks are calculated.}
-–
+%\label{oopseFig:dynamicPropsMemory}
-–
+%\end{figure}
-–
+\section{\label{oopseSec:conclusion}Conclusion}
+We have presented the design and implementation of our open source
+\newpage
+\section{Acknowledgments}
-<
+The authors would like to thank espresso for fueling this work, and
-<
+would also like to send a special acknowledgement to single malt
-<
+scotch for its wonderful calming effects and its ability to make the
-<
+troubles of the world float away.
->
+The authors would like to thank the Notre Dame BoB computer cluster where much of this project was tested. Additionally, the authors would like to acknowledge their funding from {\LARGE FIX ME}.
+\bibliographystyle{achemso}
+\bibliography{oopsePaper}

Diff Legend

-–
+Removed lines
-+
+Added lines
-<
+Changed lines
->
+Changed lines

Comparing trunk/oopsePaper/oopsePaper.tex (file contents): Revision 1121 by mmeineke, Mon Apr 19 21:00:24 2004 UTC vs. Revision 1155 by mmeineke, Tue May 11 19:36:28 2004 UTC

Diff Legend

Comparing trunk/oopsePaper/oopsePaper.tex (file contents):
Revision 1121 by mmeineke, Mon Apr 19 21:00:24 2004 UTC vs.
Revision 1155 by mmeineke, Tue May 11 19:36:28 2004 UTC