[ViewVC] Diff of: group/trunk/tengDissertation/Appendix.tex

Comparing trunk/tengDissertation/Appendix.tex (file contents):
Revision 2685 by tim, Mon Apr 3 18:07:54 2006 UTC vs.
Revision 2836 by tim, Fri Jun 9 02:12:42 2006 UTC

-<
+\chapter{\label{chapt:appendix}APPENDIX}
->
+\appendix
->
+\chapter{\label{chapt:oopse}Object-Oriented Parallel Simulation Engine}
-+
+Designing object-oriented software is hard, and designing reusable
-+
+object-oriented scientific software is even harder. Absence of
-+
+applying modern software development practices is the bottleneck of
-+
+Scientific Computing community\cite{Wilson2006}. For instance, in
-+
+the last 20 years , there are quite a few MD packages that were
-+
+developed to solve common MD problems and perform robust simulations
-+
+. However, many of the codes are legacy programs that are either
-+
+poorly organized or extremely complex. Usually, these packages were
-+
+contributed by scientists without official computer science
-+
+training. The development of most MD applications are lack of strong
-+
+coordination to enforce design and programming guidelines. Moreover,
-+
+most MD programs also suffer from missing design and implement
-+
+documents which is crucial to the maintenance and extensibility.
-+
+Along the way of studying structural and dynamic processes in
-+
+condensed phase systems like biological membranes and nanoparticles,
-+
+we developed and maintained an Object-Oriented Parallel Simulation
-+
+Engine ({\sc OOPSE}). This new molecular dynamics package has some
-+
+unique features
-+
+\begin{enumerate}
-+
+  \item {\sc OOPSE} performs Molecular Dynamics (MD) simulations on non-standard
-+
+atom types (transition metals, point dipoles, sticky potentials,
-+
+Gay-Berne ellipsoids, or other "lumpy"atoms with orientational
-+
+degrees of freedom), as well as rigid bodies.
-+
+  \item {\sc OOPSE} uses a force-based decomposition algorithm using MPI on cheap
-+
+Beowulf clusters to obtain very efficient parallelism.
-+
+  \item {\sc OOPSE} integrates the equations of motion using advanced methods for
-+
+orientational dynamics in NVE, NVT, NPT, NPAT, and NP$\gamma$T
-+
+ensembles.
-+
+  \item {\sc OOPSE} can carry out simulations on metallic systems using the
-+
+Embedded Atom Method (EAM) as well as the Sutton-Chen potential.
-+
+  \item {\sc OOPSE} can perform simulations on Gay-Berne liquid crystals.
-+
+  \item  {\sc OOPSE} can simulate systems containing the extremely efficient
-+
+extended-Soft Sticky Dipole (SSD/E) model for water.
-+
+\end{enumerate}
-+
-+
+\section{\label{appendixSection:architecture }Architecture}
-+
-+
+Mainly written by \texttt{C/C++} and \texttt{Fortran90}, {\sc OOPSE}
-+
+uses C++ Standard Template Library (STL) and fortran modules as the
-+
+foundation. As an extensive set of the STL and Fortran90 modules,
-+
+{\sc Base Classes} provide generic implementations of mathematical
-+
+objects (e.g., matrices, vectors, polynomials, random number
-+
+generators) and advanced data structures and algorithms(e.g., tuple,
-+
+bitset, generic data, string manipulation). The molecular data
-+
+structures for the representation of atoms, bonds, bends, torsions,
-+
+rigid bodies and molecules \textit{etc} are contained in the {\sc
-+
+Kernel} which is implemented with {\sc Base Classes} and are
-+
+carefully designed to provide maximum extensibility and flexibility.
-+
+The functionality required for applications is provide by the third
-+
+layer which contains Input/Output, Molecular Mechanics and Structure
-+
+modules. Input/Output module not only implements general methods for
-+
+file handling, but also defines a generic force field interface.
-+
+Another important component of Input/Output module is the meta-data
-+
+file parser, which is rewritten using ANother Tool for Language
-+
+Recognition(ANTLR)\cite{Parr1995, Schaps1999} syntax. The Molecular
-+
+Mechanics module consists of energy minimization and a wide
-+
+varieties of integration methods(see Chap.~\ref{chapt:methodology}).
-+
+The structure module contains a flexible and powerful selection
-+
+library which syntax is elaborated in
-+
+Sec.~\ref{appendixSection:syntax}. The top layer is made of the main
-+
+program of the package, \texttt{oopse} and it corresponding parallel
-+
+version \texttt{oopse\_MPI}, as well as other useful utilities, such
-+
+as \texttt{StatProps} (see Sec.~\ref{appendixSection:StaticProps}),
-+
+\texttt{DynamicProps} (see
-+
+Sec.~\ref{appendixSection:appendixSection:DynamicProps}),
-+
+\texttt{Dump2XYZ} (see
-+
+Sec.~\ref{appendixSection:appendixSection:Dump2XYZ}), \texttt{Hydro}
-+
+(see Sec.~\ref{appendixSection:appendixSection:hydrodynamics})
-+
+\textit{etc}.
-+
-+
+\begin{figure}
-+
+\centering
-+
+\includegraphics[width=\linewidth]{architecture.eps}
-+
+\caption[The architecture of {\sc OOPSE}] {Overview of the structure
-+
+of {\sc OOPSE}} \label{appendixFig:architecture}
-+
+\end{figure}
-+
+\section{\label{appendixSection:desginPattern}Design Pattern}
-+
+Design patterns are optimal solutions to commonly-occurring problems
-+
+in software design. Although originated as an architectural concept
-+
+for buildings and towns by Christopher Alexander
-+
+\cite{Alexander1987}, software patterns first became popular with
-+
+the wide acceptance of the book, Design Patterns: Elements of
-+
+Reusable Object-Oriented Software \cite{Gamma1994}. Patterns reflect
-+
+the experience, knowledge and insights of developers who have
-+
+successfully used these patterns in their own work. Patterns are
-+
+reusable. They provide a ready-made solution that can be adapted to
-+
+different problems as necessary. Pattern are expressive. they
-+
+provide a common vocabulary of solutions that can express large
-+
+solutions succinctly.
-<
+\subsection{\label{appendixSection:visitorPattern}Visitor Pattern}
->
+Patterns are usually described using a format that includes the
->
+following information:
->
+\begin{enumerate}
->
+  \item The \emph{name} that is commonly used for the pattern. Good pattern names form a vocabulary for
->
+  discussing conceptual abstractions. a pattern may have more than one commonly used or recognizable name
->
+  in the literature. In this case it is common practice to document these nicknames or synonyms under
->
+  the heading of \emph{Aliases} or \emph{Also Known As}.
->
+  \item The \emph{motivation} or \emph{context} that this pattern applies
->
+  to. Sometimes, it will include some prerequisites that should be satisfied before deciding to use a pattern
->
+  \item The \emph{solution} to the problem that the pattern
->
+  addresses. It describes how to construct the necessary work products. The description may include
->
+  pictures, diagrams and prose which identify the pattern's structure, its participants, and their
->
+  collaborations, to show how the problem is solved.
->
+  \item The \emph{consequences} of using the given solution to solve a
->
+  problem, both positive and negative.
->
+\end{enumerate}
-<
+\subsection{\label{appendixSection:templatePattern}Template Pattern}
->
+As one of the latest advanced techniques emerged from
->
+object-oriented community, design patterns were applied in some of
->
+the modern scientific software applications, such as JMol, {\sc
->
+OOPSE}\cite{Meineke05} and PROTOMOL\cite{Matthey05} \textit{etc}.
->
+The following sections enumerates some of the patterns used in {\sc
->
+OOPSE}.
-<
+\subsection{\label{appendixSection:factoryPattern}Factory Pattern}
->
+\subsection{\label{appendixSection:singleton}Singleton}
-<
+\section{\label{appendixSection:hierarchy}Hierarchy}
->
+The Singleton pattern not only provides a mechanism to restrict
->
+instantiation of a class to one object, but also provides a global
->
+point of access to the object. Currently implemented as a global
->
+variable, the logging utility which reports error and warning
->
+messages to the console in {\sc OOPSE} is a good candidate for
->
+applying the Singleton pattern to avoid the global namespace
->
+pollution.Although the singleton pattern can be implemented in
->
+various ways  to account for different aspects of the software
->
+designs, such as lifespan control \textit{etc}, we only use the
->
+static data approach in {\sc OOPSE}. IntegratorFactory class is
->
+declared as
-<
+\section{\label{appendixSection:selectionSyntax}Selection Syntax}
->
+\begin{lstlisting}[float,caption={[A classic Singleton design pattern implementation(I)] The declaration of of simple Singleton pattern.},label={appendixScheme:singletonDeclaration}]
-<
+\section{\label{appendixSection:hydrodynamics}Hydrodynamics}
->
+class IntegratorFactory {
->
+public:
->
+  static IntegratorFactory*
->
+  getInstance();
->
+protected:
->
+  IntegratorFactory();
->
+private:
->
+  static IntegratorFactory* instance_;
->
+};
-<
+\section{\label{appendixSection:analysisFramework}Analysis Framework}
->
+\end{lstlisting}
-<
+\subsection{\label{appendixSection:staticProps}Factory Properties}
->
+The corresponding implementation is
-<
+\subsection{\label{appendixSection:dynamicProps}Dynamics Properties}
->
+\begin{lstlisting}[float,caption={[A classic implementation of Singleton design pattern (II)] The implementation of simple Singleton pattern.},label={appendixScheme:singletonImplementation}]
->
->
+IntegratorFactory::instance_ = NULL;
->
->
+IntegratorFactory* getInstance() {
->
+  if (instance_ == NULL){
->
+    instance_ = new IntegratorFactory;
->
+  }
->
+  return instance_;
->
+}
->
->
+\end{lstlisting}
->
->
+Since constructor is declared as protected, a client can not
->
+instantiate IntegratorFactory directly. Moreover, since the member
->
+function getInstance serves as the only entry of access to
->
+IntegratorFactory, this approach fulfills the basic requirement, a
->
+single instance. Another consequence of this approach is the
->
+automatic destruction since static data are destroyed upon program
->
+termination.
->
->
+\subsection{\label{appendixSection:factoryMethod}Factory Method}
->
->
+Categoried as a creational pattern, the Factory Method pattern deals
->
+with the problem of creating objects without specifying the exact
->
+class of object that will be created. Factory Method is typically
->
+implemented by delegating the creation operation to the subclasses.
->
+Parameterized Factory pattern where factory method (
->
+createIntegrator member function) creates products based on the
->
+identifier (see List.~\ref{appendixScheme:factoryDeclaration}). If
->
+the identifier has been already registered, the factory method will
->
+invoke the corresponding creator (see List.~\ref{integratorCreator})
->
+which utilizes the modern C++ template technique to avoid excess
->
+subclassing.
->
->
+\begin{lstlisting}[float,caption={[The implementation of Parameterized Factory pattern (I)]Source code of IntegratorFactory class.},label={appendixScheme:factoryDeclaration}]
->
->
+class IntegratorFactory {
->
+public:
->
+  typedef std::map<string, IntegratorCreator*> CreatorMapType;
->
->
+  bool registerIntegrator(IntegratorCreator* creator) {
->
+    return creatorMap_.insert(creator->getIdent(), creator).second;
->
+  }
->
->
+  Integrator* createIntegrator(const string& id, SimInfo* info) {
->
+    Integrator* result = NULL;
->
+    CreatorMapType::iterator i = creatorMap_.find(id);
->
+    if (i != creatorMap_.end()) {
->
+      result = (i->second)->create(info);
->
+    }
->
+    return result;
->
+  }
->
->
+private:
->
+  CreatorMapType creatorMap_;
->
+};
->
+\end{lstlisting}
->
->
+\begin{lstlisting}[float,caption={[The implementation of Parameterized Factory pattern (III)]Source code of creator classes.},label={appendixScheme:integratorCreator}]
->
->
+class IntegratorCreator {
->
+public:
->
+    IntegratorCreator(const string& ident) : ident_(ident) {}
->
->
+    const string& getIdent() const { return ident_; }
->
->
+    virtual Integrator* create(SimInfo* info) const = 0;
->
->
+private:
->
+    string ident_;
->
+};
->
->
+template<class ConcreteIntegrator>
->
+class IntegratorBuilder : public IntegratorCreator {
->
+public:
->
+  IntegratorBuilder(const string& ident)
->
+                   : IntegratorCreator(ident) {}
->
+  virtual  Integrator* create(SimInfo* info) const {
->
+    return new ConcreteIntegrator(info);
->
+  }
->
+};
->
+\end{lstlisting}
->
->
+\subsection{\label{appendixSection:visitorPattern}Visitor}
->
->
+The visitor pattern is designed to decouple the data structure and
->
+algorithms used upon them by collecting related operation from
->
+element classes into other visitor classes, which is equivalent to
->
+adding virtual functions into a set of classes without modifying
->
+their interfaces. Fig.~\ref{appendixFig:visitorUML} demonstrates the
->
+structure of Visitor pattern which is used extensively in {\tt
->
+Dump2XYZ}. In order to convert an OOPSE dump file, a series of
->
+distinct operations are performed on different StuntDoubles (See the
->
+class hierarchy in Fig.~\ref{oopseFig:hierarchy} and the declaration
->
+in List.~\ref{appendixScheme:element}). Since the hierarchies
->
+remains stable, it is easy to define a visit operation (see
->
+List.~\ref{appendixScheme:visitor}) for each class of StuntDouble.
->
+Note that using Composite pattern\cite{Gamma1994}, CompositVisitor
->
+manages a priority visitor list and handles the execution of every
->
+visitor in the priority list on different StuntDoubles.
->
->
+\begin{figure}
->
+\centering
->
+\includegraphics[width=\linewidth]{visitor.eps}
->
+\caption[The UML class diagram of Visitor patten] {The UML class
->
+diagram of Visitor patten.} \label{appendixFig:visitorUML}
->
+\end{figure}
->
->
+%\begin{figure}
->
+%\centering
->
+%\includegraphics[width=\linewidth]{hierarchy.eps}
->
+%\caption[Class hierarchy for ojects in {\sc OOPSE}]{ A diagram of
->
+%the class hierarchy.
->
+%\begin{itemize}
->
+%\item A {\bf StuntDouble} is {\it any} object that can be manipulated by the
->
+%integrators and minimizers.
->
+%\item An {\bf Atom} is a fundamental point-particle that can be moved around during a simulation.
->
+%\item A {\bf DirectionalAtom} is an atom which has {\it orientational} as well as translational degrees of freedom.
->
+%\item A {\bf RigidBody} is a collection of {\bf Atom}s or {\bf
->
+%DirectionalAtom}s which behaves as a single unit.
->
+%\end{itemize}
->
+%} \label{oopseFig:hierarchy}
->
+%\end{figure}
->
->
+\begin{lstlisting}[float,caption={[The implementation of Visitor pattern (II)]Source code of the element classes.},label={appendixScheme:element}]
->
->
+class StuntDouble { public:
->
+  virtual void accept(BaseVisitor* v) = 0;
->
+};
->
->
+class Atom: public StuntDouble { public:
->
+  virtual void accept{BaseVisitor* v*} {
->
+    v->visit(this);
->
+  }
->
+};
->
->
+class DirectionalAtom: public Atom { public:
->
+  virtual void accept{BaseVisitor* v*} {
->
+    v->visit(this);
->
+  }
->
+};
->
->
+class RigidBody: public StuntDouble { public:
->
+  virtual void accept{BaseVisitor* v*} {
->
+    v->visit(this);
->
+  }
->
+};
->
->
+\end{lstlisting}
->
->
+\begin{lstlisting}[float,caption={[The implementation of Visitor pattern (I)]Source code of the visitor classes.},label={appendixScheme:visitor}]
->
->
+class BaseVisitor{
->
+public:
->
+  virtual void visit(Atom* atom);
->
+  virtual void visit(DirectionalAtom* datom);
->
+  virtual void visit(RigidBody* rb);
->
+};
->
->
+class BaseAtomVisitor:public BaseVisitor{ public:
->
+  virtual void visit(Atom* atom);
->
+  virtual void visit(DirectionalAtom* datom);
->
+  virtual void visit(RigidBody* rb);
->
+};
->
->
+class SSDAtomVisitor:public BaseAtomVisitor{ public:
->
+  virtual void visit(Atom* atom);
->
+  virtual void visit(DirectionalAtom* datom);
->
+  virtual void visit(RigidBody* rb);
->
+};
->
->
+class CompositeVisitor: public BaseVisitor {
->
+public:
->
->
+  typedef list<pair<BaseVisitor*, int> > VistorListType;
->
+  typedef VistorListType::iterator VisitorListIterator;
->
+  virtual void visit(Atom* atom) {
->
+    VisitorListIterator i;
->
+    BaseVisitor* curVisitor;
->
+    for(i = visitorList.begin();i != visitorList.end();++i) {
->
+      atom->accept(*i);
->
+    }
->
+  }
->
->
+  virtual void visit(DirectionalAtom* datom) {
->
+    VisitorListIterator i;
->
+    BaseVisitor* curVisitor;
->
+    for(i = visitorList.begin();i != visitorList.end();++i) {
->
+      atom->accept(*i);
->
+    }
->
+  }
->
->
+  virtual void visit(RigidBody* rb) {
->
+    VisitorListIterator i;
->
+    std::vector<Atom*> myAtoms;
->
+    std::vector<Atom*>::iterator ai;
->
+    myAtoms = rb->getAtoms();
->
+    for(i = visitorList.begin();i != visitorList.end();++i) {{
->
+      rb->accept(*i);
->
+      for(ai = myAtoms.begin(); ai != myAtoms.end(); ++ai){
->
+        (*ai)->accept(*i);
->
+    }
->
+  }
->
->
+  void addVisitor(BaseVisitor* v, int priority);
->
->
+  protected:
->
+    VistorListType visitorList;
->
+};
->
->
+\end{lstlisting}
->
->
+\section{\label{appendixSection:concepts}Concepts}
->
->
+OOPSE manipulates both traditional atoms as well as some objects
->
+that {\it behave like atoms}.  These objects can be rigid
->
+collections of atoms or atoms which have orientational degrees of
->
+freedom.  A diagram of the class hierarchy is illustrated in
->
+Fig.~\ref{oopseFig:hierarchy}. Every Molecule, Atom and
->
+DirectionalAtom in {\sc OOPSE} have their own names which are
->
+specified in the {\tt .md} file. In contrast, RigidBodies are
->
+denoted by their membership and index inside a particular molecule:
->
+[MoleculeName]\_RB\_[index] (the contents inside the brackets depend
->
+on the specifics of the simulation). The names of rigid bodies are
->
+generated automatically. For example, the name of the first rigid
->
+body in a DMPC molecule is DMPC\_RB\_0.
->
->
+\section{\label{appendixSection:syntax}Syntax of the Select Command}
->
->
+The most general form of the select command is: {\tt select {\it
->
+expression}}. This expression represents an arbitrary set of
->
+StuntDoubles (Atoms or RigidBodies) in {\sc OOPSE}. Expressions are
->
+composed of either name expressions, index expressions, predefined
->
+sets, user-defined expressions, comparison operators, within
->
+expressions, or logical combinations of the above expression types.
->
+Expressions can be combined using parentheses and the Boolean
->
+operators.
->
->
+\subsection{\label{appendixSection:logical}Logical expressions}
->
->
+The logical operators allow complex queries to be constructed out of
->
+simpler ones using the standard boolean connectives {\bf and}, {\bf
->
+or}, {\bf not}. Parentheses can be used to alter the precedence of
->
+the operators.
->
->
+\begin{center}
->
+\begin{tabular}{|ll|}
->
+\hline
->
+{\bf logical operator} & {\bf equivalent operator}  \\
->
+\hline
->
+and & ``\&'', ``\&\&'' \\
->
+or & ``$|$'', ``$||$'', ``,'' \\
->
+not & ``!''  \\
->
+\hline
->
+\end{tabular}
->
+\end{center}
->
->
+\subsection{\label{appendixSection:name}Name expressions}
->
->
+\begin{center}
->
+\begin{tabular}{|llp{2in}|}
->
+\hline {\bf type of expression} & {\bf examples} & {\bf translation
->
+of
->
+examples} \\
->
+\hline expression without ``.'' & select DMPC & select all
->
+StuntDoubles
->
+belonging to all DMPC molecules \\
->
+ & select C* & select all atoms which have atom types beginning with C
->
+\\
->
+ & select DMPC\_RB\_* & select all RigidBodies in DMPC molecules (but
->
+only select the rigid bodies, and not the atoms belonging to them). \\
->
+\hline expression has one ``.'' & select TIP3P.O\_TIP3P & select the
->
+O\_TIP3P
->
+atoms belonging to TIP3P molecules \\
->
+ & select DMPC\_RB\_O.PO4 & select the PO4 atoms belonging to
->
+the first
->
+RigidBody in each DMPC molecule \\
->
+ & select DMPC.20 & select the twentieth StuntDouble in each DMPC
->
+molecule \\
->
+\hline expression has two ``.''s & select DMPC.DMPC\_RB\_?.* &
->
+select all atoms
->
+belonging to all rigid bodies within all DMPC molecules \\
->
+\hline
->
+\end{tabular}
->
+\end{center}
->
->
+\subsection{\label{appendixSection:index}Index expressions}
->
->
+\begin{center}
->
+\begin{tabular}{|lp{4in}|}
->
+\hline
->
+{\bf examples} & {\bf translation of examples} \\
->
+\hline
->
+select 20 & select all of the StuntDoubles belonging to Molecule 20 \\
->
+select 20 to 30 & select all of the StuntDoubles belonging to
->
+molecules which have global indices between 20 (inclusive) and 30
->
+(exclusive) \\
->
+\hline
->
+\end{tabular}
->
+\end{center}
->
->
+\subsection{\label{appendixSection:predefined}Predefined sets}
->
->
+\begin{center}
->
+\begin{tabular}{|ll|}
->
+\hline
->
+{\bf keyword} & {\bf description} \\
->
+\hline
->
+all & select all StuntDoubles \\
->
+none & select none of the StuntDoubles \\
->
+\hline
->
+\end{tabular}
->
+\end{center}
->
->
+\subsection{\label{appendixSection:userdefined}User-defined expressions}
->
->
+Users can define arbitrary terms to represent groups of
->
+StuntDoubles, and then use the define terms in select commands. The
->
+general form for the define command is: {\bf define {\it term
->
+expression}}. Once defined, the user can specify such terms in
->
+boolean expressions
->
->
+{\tt define SSDWATER SSD or SSD1 or SSDRF}
->
->
+{\tt select SSDWATER}
->
->
+\subsection{\label{appendixSection:comparison}Comparison expressions}
->
->
+StuntDoubles can be selected by using comparision operators on their
->
+properties. The general form for the comparison command is: a
->
+property name, followed by a comparision operator and then a number.
->
->
+\begin{center}
->
+\begin{tabular}{|l|l|}
->
+\hline
->
+{\bf property} & mass, charge \\
->
+{\bf comparison operator} & ``$>$'', ``$<$'', ``$=$'', ``$>=$'',
->
+``$<=$'', ``$!=$'' \\
->
+\hline
->
+\end{tabular}
->
+\end{center}
->
->
+For example, the phrase {\tt select mass > 16.0 and charge < -2}
->
+would select StuntDoubles which have mass greater than 16.0 and
->
+charges less than -2.
->
->
+\subsection{\label{appendixSection:within}Within expressions}
->
->
+The ``within'' keyword allows the user to select all StuntDoubles
->
+within the specified distance (in Angstroms) from a selection,
->
+including the selected atom itself. The general form for within
->
+selection is: {\tt select within(distance, expression)}
->
->
+For example, the phrase {\tt select within(2.5, PO4 or NC4)} would
->
+select all StuntDoubles which are within 2.5 angstroms of PO4 or NC4
->
+atoms.
->
->
->
+\section{\label{appendixSection:analysisFramework}Analysis Framework}
->
->
+\subsection{\label{appendixSection:StaticProps}StaticProps}
->
->
+{\tt StaticProps} can compute properties which are averaged over
->
+some or all of the configurations that are contained within a dump
->
+file. The most common example of a static property that can be
->
+computed is the pair distribution function between atoms of type $A$
->
+and other atoms of type $B$, $g_{AB}(r)$.  {\tt StaticProps} can
->
+also be used to compute the density distributions of other molecules
->
+in a reference frame {\it fixed to the body-fixed reference frame}
->
+of a selected atom or rigid body.
->
->
+There are five seperate radial distribution functions availiable in
->
+OOPSE. Since every radial distrbution function invlove the
->
+calculation between pairs of bodies, {\tt -{}-sele1} and {\tt
->
+-{}-sele2} must be specified to tell StaticProps which bodies to
->
+include in the calculation.
->
->
+\begin{description}
->
+\item[{\tt -{}-gofr}] Computes the pair distribution function,
->
+\begin{equation*}
->
+g_{AB}(r) = \frac{1}{\rho_B}\frac{1}{N_A} \langle \sum_{i \in A}
->
+\sum_{j \in B} \delta(r - r_{ij}) \rangle
->
+\end{equation*}
->
+\item[{\tt -{}-r\_theta}] Computes the angle-dependent pair distribution
->
+function. The angle is defined by the intermolecular vector
->
+$\vec{r}$ and $z$-axis of DirectionalAtom A,
->
+\begin{equation*}
->
+g_{AB}(r, \cos \theta) = \frac{1}{\rho_B}\frac{1}{N_A} \langle
->
+\sum_{i \in A} \sum_{j \in B} \delta(r - r_{ij}) \delta(\cos
->
+\theta_{ij} - \cos \theta)\rangle
->
+\end{equation*}
->
+\item[{\tt -{}-r\_omega}] Computes the angle-dependent pair distribution
->
+function. The angle is defined by the $z$-axes of the two
->
+DirectionalAtoms A and B.
->
+\begin{equation*}
->
+g_{AB}(r, \cos \omega) = \frac{1}{\rho_B}\frac{1}{N_A} \langle
->
+\sum_{i \in A} \sum_{j \in B} \delta(r - r_{ij}) \delta(\cos
->
+\omega_{ij} - \cos \omega)\rangle
->
+\end{equation*}
->
+\item[{\tt -{}-theta\_omega}] Computes the pair distribution in the angular
->
+space $\theta, \omega$ defined by the two angles mentioned above.
->
+\begin{equation*}
->
+g_{AB}(\cos\theta, \cos \omega) = \frac{1}{\rho_B}\frac{1}{N_A}
->
+\langle \sum_{i \in A} \sum_{j \in B} \langle \delta(\cos
->
+\theta_{ij} - \cos \theta) \delta(\cos \omega_{ij} - \cos
->
+\omega)\rangle
->
+\end{equation*}
->
+\item[{\tt -{}-gxyz}] Calculates the density distribution of particles of type
->
+B in the body frame of particle A. Therefore, {\tt -{}-originsele}
->
+and {\tt -{}-refsele} must be given to define A's internal
->
+coordinate set as the reference frame for the calculation.
->
+\end{description}
->
->
+The vectors (and angles) associated with these angular pair
->
+distribution functions are most easily seen in the figure below:
->
->
+\begin{figure}
->
+\centering
->
+\includegraphics[width=3in]{definition.eps}
->
+\caption[Definitions of the angles between directional objects]{ \\
->
+Any two directional objects (DirectionalAtoms and RigidBodies) have
->
+a set of two angles ($\theta$, and $\omega$) between the z-axes of
->
+their body-fixed frames.} \label{oopseFig:gofr}
->
+\end{figure}
->
->
+Due to the fact that the selected StuntDoubles from two selections
->
+may be overlapped, {\tt StaticProps} performs the calculation in
->
+three stages which are illustrated in
->
+Fig.~\ref{oopseFig:staticPropsProcess}.
->
->
+\begin{figure}
->
+\centering
->
+\includegraphics[width=\linewidth]{staticPropsProcess.eps}
->
+\caption[A representation of the three-stage correlations in
->
+\texttt{StaticProps}]{This diagram illustrates three-stage
->
+processing used by \texttt{StaticProps}. $S_1$ and $S_2$ are the
->
+numbers of selected stuntdobules from {\tt -{}-sele1} and {\tt
->
+-{}-sele2} respectively, while $C$ is the number of stuntdobules
->
+appearing at both sets. The first stage($S_1-C$ and $S_2$) and
->
+second stages ($S_1$ and $S_2-C$) are completely non-overlapping. On
->
+the contrary, the third stage($C$ and $C$) are completely
->
+overlapping} \label{oopseFig:staticPropsProcess}
->
+\end{figure}
->
->
+The options available for {\tt StaticProps} are as follows:
->
+\begin{longtable}[c]{|EFG|}
->
+\caption{StaticProps Command-line Options}
->
+\\ \hline
->
+{\bf option} & {\bf verbose option} & {\bf behavior} \\ \hline
->
+\endhead
->
+\hline
->
+\endfoot
->
+  -h& {\tt -{}-help}                    &  Print help and exit \\
->
+  -V& {\tt -{}-version}                 &  Print version and exit \\
->
+  -i& {\tt -{}-input}          &  input dump file \\
->
+  -o& {\tt -{}-output}         &  output file name \\
->
+  -n& {\tt -{}-step}                &  process every n frame  (default=`1') \\
->
+  -r& {\tt -{}-nrbins}              &  number of bins for distance  (default=`100') \\
->
+  -a& {\tt -{}-nanglebins}          &  number of bins for cos(angle)  (default= `50') \\
->
+  -l& {\tt -{}-length}           &  maximum length (Defaults to 1/2 smallest length of first frame) \\
->
+    & {\tt -{}-sele1}   & select the first StuntDouble set \\
->
+    & {\tt -{}-sele2}   & select the second StuntDouble set \\
->
+    & {\tt -{}-sele3}   & select the third StuntDouble set \\
->
+    & {\tt -{}-refsele} & select reference (can only be used with {\tt -{}-gxyz}) \\
->
+    & {\tt -{}-molname}           & molecule name \\
->
+    & {\tt -{}-begin}                & begin internal index \\
->
+    & {\tt -{}-end}                  & end internal index \\
->
+\hline
->
+\multicolumn{3}{|l|}{One option from the following group of options is required:} \\
->
+\hline
->
+    &  {\tt -{}-gofr}                    &  $g(r)$ \\
->
+    &  {\tt -{}-r\_theta}                 &  $g(r, \cos(\theta))$ \\
->
+    &  {\tt -{}-r\_omega}                 &  $g(r, \cos(\omega))$ \\
->
+    &  {\tt -{}-theta\_omega}             &  $g(\cos(\theta), \cos(\omega))$ \\
->
+    &  {\tt -{}-gxyz}                    &  $g(x, y, z)$ \\
->
+    &  {\tt -{}-p2}                      &  $P_2$ order parameter ({\tt -{}-sele1} and {\tt -{}-sele2} must be specified) \\
->
+    &  {\tt -{}-scd}                     &  $S_{CD}$ order parameter(either {\tt -{}-sele1}, {\tt -{}-sele2}, {\tt -{}-sele3} are specified or {\tt -{}-molname}, {\tt -{}-begin}, {\tt -{}-end} are specified) \\
->
+    &  {\tt -{}-density}                 &  density plot ({\tt -{}-sele1} must be specified) \\
->
+    &  {\tt -{}-slab\_density}           &  slab density ({\tt -{}-sele1} must be specified)
->
+\end{longtable}
->
->
+\subsection{\label{appendixSection:DynamicProps}DynamicProps}
->
->
+{\tt DynamicProps} computes time correlation functions from the
->
+configurations stored in a dump file.  Typical examples of time
->
+correlation functions are the mean square displacement and the
->
+velocity autocorrelation functions.   Once again, the selection
->
+syntax can be used to specify the StuntDoubles that will be used for
->
+the calculation.  A general time correlation function can be thought
->
+of as:
->
+\begin{equation}
->
+C_{AB}(t) = \langle \vec{u}_A(t) \cdot \vec{v}_B(0) \rangle
->
+\end{equation}
->
+where $\vec{u}_A(t)$ is a vector property associated with an atom of
->
+type $A$ at time $t$, and $\vec{v}_B(t^{\prime})$ is a different
->
+vector property associated with an atom of type $B$ at a different
->
+time $t^{\prime}$.  In most autocorrelation functions, the vector
->
+properties ($\vec{v}$ and $\vec{u}$) and the types of atoms ($A$ and
->
+$B$) are identical, and the three calculations built in to {\tt
->
+DynamicProps} make these assumptions.  It is possible, however, to
->
+make simple modifications to the {\tt DynamicProps} code to allow
->
+the use of {\it cross} time correlation functions (i.e. with
->
+different vectors).  The ability to use two selection scripts to
->
+select different types of atoms is already present in the code.
->
->
+For large simulations, the trajectory files can sometimes reach
->
+sizes in excess of several gigabytes. In order to effectively
->
+analyze that amount of data. In order to prevent a situation where
->
+the program runs out of memory due to large trajectories,
->
+\texttt{dynamicProps} will estimate the size of free memory at
->
+first, and determine the number of frames in each block, which
->
+allows the operating system to load two blocks of data
->
+simultaneously without swapping. Upon reading two blocks of the
->
+trajectory, \texttt{dynamicProps} will calculate the time
->
+correlation within the first block and the cross correlations
->
+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, until all frame pairs have been correlated in time.
->
+This process is illustrated in
->
+Fig.~\ref{oopseFig:dynamicPropsProcess}.
->
->
+\begin{figure}
->
+\centering
->
+\includegraphics[width=\linewidth]{dynamicPropsProcess.eps}
->
+\caption[A representation of the block correlations in
->
+\texttt{dynamicProps}]{This diagram illustrates block correlations
->
+processing in \texttt{dynamicProps}. The shaded region represents
->
+the self correlation of the block, and the open blocks are read one
->
+at a time and the cross correlations between blocks are calculated.}
->
+\label{oopseFig:dynamicPropsProcess}
->
+\end{figure}
->
->
+The options available for DynamicProps are as follows:
->
+\begin{longtable}[c]{|EFG|}
->
+\caption{DynamicProps Command-line Options}
->
+\\ \hline
->
+{\bf option} & {\bf verbose option} & {\bf behavior} \\ \hline
->
+\endhead
->
+\hline
->
+\endfoot
->
+  -h& {\tt -{}-help}                   & Print help and exit \\
->
+  -V& {\tt -{}-version}                & Print version and exit \\
->
+  -i& {\tt -{}-input}         & input dump file \\
->
+  -o& {\tt -{}-output}        & output file name \\
->
+    & {\tt -{}-sele1} & select first StuntDouble set \\
->
+    & {\tt -{}-sele2} & select second StuntDouble set (if sele2 is not set, use script from sele1) \\
->
+\hline
->
+\multicolumn{3}{|l|}{One option from the following group of options is required:} \\
->
+\hline
->
+  -r& {\tt -{}-rcorr}                  & compute mean square displacement \\
->
+  -v& {\tt -{}-vcorr}                  & compute velocity correlation function \\
->
+  -d& {\tt -{}-dcorr}                  & compute dipole correlation function
->
+\end{longtable}
->
->
+\section{\label{appendixSection:tools}Other Useful Utilities}
->
->
+\subsection{\label{appendixSection:Dump2XYZ}Dump2XYZ}
->
->
+{\tt Dump2XYZ} can transform an OOPSE dump file into a xyz file
->
+which can be opened by other molecular dynamics viewers such as Jmol
->
+and VMD\cite{Humphrey1996}. The options available for Dump2XYZ are
->
+as follows:
->
->
->
+\begin{longtable}[c]{|EFG|}
->
+\caption{Dump2XYZ Command-line Options}
->
+\\ \hline
->
+{\bf option} & {\bf verbose option} & {\bf behavior} \\ \hline
->
+\endhead
->
+\hline
->
+\endfoot
->
+  -h & {\tt -{}-help} &                        Print help and exit \\
->
+  -V & {\tt -{}-version} &                     Print version and exit \\
->
+  -i & {\tt -{}-input}  &             input dump file \\
->
+  -o & {\tt -{}-output} &             output file name \\
->
+  -n & {\tt -{}-frame}   &                 print every n frame  (default=`1') \\
->
+  -w & {\tt -{}-water}       &                 skip the the waters  (default=off) \\
->
+  -m & {\tt -{}-periodicBox} &                 map to the periodic box  (default=off)\\
->
+  -z & {\tt -{}-zconstraint}  &                replace the atom types of zconstraint molecules  (default=off) \\
->
+  -r & {\tt -{}-rigidbody}  &                  add a pseudo COM atom to rigidbody  (default=off) \\
->
+  -t & {\tt -{}-watertype} &                   replace the atom type of water model (default=on) \\
->
+  -b & {\tt -{}-basetype}  &                   using base atom type  (default=off) \\
->
+     & {\tt -{}-repeatX}  &                 The number of images to repeat in the x direction  (default=`0') \\
->
+     & {\tt -{}-repeatY} &                 The number of images to repeat in the y direction  (default=`0') \\
->
+     &  {\tt -{}-repeatZ}  &                The number of images to repeat in the z direction  (default=`0') \\
->
+  -s & {\tt -{}-selection} & By specifying {\tt -{}-selection}=``selection command'' with Dump2XYZ, the user can select an arbitrary set of StuntDoubles to be
->
+converted. \\
->
+     & {\tt -{}-originsele} & By specifying {\tt -{}-originsele}=``selection command'' with Dump2XYZ, the user can re-center the origin of the system around a specific StuntDouble \\
->
+     & {\tt -{}-refsele} &  In order to rotate the system, {\tt -{}-originsele} and {\tt -{}-refsele} must be given to define the new coordinate set. A StuntDouble which contains a dipole (the direction of the dipole is always (0, 0, 1) in body frame) is specified by {\tt -{}-originsele}. The new x-z plane is defined by the direction of the dipole and the StuntDouble is specified by {\tt -{}-refsele}.
->
+\end{longtable}
->
->
+\subsection{\label{appendixSection:hydrodynamics}Hydro}
->
->
+{\tt Hydro} can calculate resistance and diffusion tensors at the
->
+center of resistance. Both tensors at the center of diffusion can
->
+also be reported from the program, as well as the coordinates for
->
+the beads which are used to approximate the arbitrary shapes. The
->
+options available for Hydro are as follows:
->
+\begin{longtable}[c]{|EFG|}
->
+\caption{Hydrodynamics Command-line Options}
->
+\\ \hline
->
+{\bf option} & {\bf verbose option} & {\bf behavior} \\ \hline
->
+\endhead
->
+\hline
->
+\endfoot
->
+  -h & {\tt -{}-help} &                        Print help and exit \\
->
+  -V & {\tt -{}-version} &                     Print version and exit \\
->
+  -i & {\tt -{}-input}  &             input dump file \\
->
+  -o & {\tt -{}-output} &             output file prefix  (default=`hydro') \\
->
+  -b & {\tt -{}-beads}  &                   generate the beads only, hydrodynamics calculation will not be performed (default=off)\\
->
+     & {\tt -{}-model}  &                 hydrodynamics model (supports ``AnalyticalModel'', ``RoughShell'' and ``BeadModel'') \\
->
+\end{longtable}

Diff Legend

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

Comparing trunk/tengDissertation/Appendix.tex (file contents): Revision 2685 by tim, Mon Apr 3 18:07:54 2006 UTC vs. Revision 2836 by tim, Fri Jun 9 02:12:42 2006 UTC

Diff Legend

Comparing trunk/tengDissertation/Appendix.tex (file contents):
Revision 2685 by tim, Mon Apr 3 18:07:54 2006 UTC vs.
Revision 2836 by tim, Fri Jun 9 02:12:42 2006 UTC