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

Comparing trunk/tengDissertation/Appendix.tex (file contents):
Revision 2815 by tim, Wed Jun 7 18:34:05 2006 UTC vs.
Revision 2840 by tim, Fri Jun 9 02:54:01 2006 UTC

+\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
->
+Absence of applying modern software development practices is the
->
+bottleneck of Scientific Computing community\cite{Wilson2006}. 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
+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})
->
+\texttt{DynamicProps} (see Sec.~\ref{appendixSection:DynamicProps}),
->
+\texttt{Dump2XYZ} (see Sec.~\ref{appendixSection:Dump2XYZ}),
->
+\texttt{Hydro} (see Sec.~\ref{appendixSection:hydrodynamics})
+\textit{etc}.
+\begin{figure}
+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}.
->
+OOPSE}\cite{Meineke2005} and PROTOMOL\cite{Matthey2005}
->
+\textit{etc}. The following sections enumerates some of the patterns
->
+used in {\sc OOPSE}.
+\subsection{\label{appendixSection:singleton}Singleton}
-–
+The Singleton pattern ensures that only one instance of a class is
-–
+created. All objects that use an instance of that class use the same
-–
+instance.
-+
+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
-+
-+
+\begin{lstlisting}[float,caption={[A classic Singleton design pattern implementation(I)] The declaration of of simple Singleton pattern.},label={appendixScheme:singletonDeclaration}]
-+
-+
+class IntegratorFactory {
-+
+public:
-+
+  static IntegratorFactory*
-+
+  getInstance();
-+
+protected:
-+
+  IntegratorFactory();
-+
+private:
-+
+  static IntegratorFactory* instance_;
-+
+};
-+
-+
+\end{lstlisting}
-+
-+
+The corresponding implementation is
-+
-+
+\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}
-–
+The Factory Method pattern is a creational pattern which deals with
-–
+the problem of creating objects without specifying the exact class
-–
+of object that will be created. Factory Method solves this problem
-–
+by defining a separate method for creating the objects, which
-–
+subclasses can then override to specify the derived type of product
-–
+that will be created.
-+
+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 purpose of the Visitor Pattern is to encapsulate an operation
-–
+that you want to perform on the elements of a data structure. In
-–
+this way, you can change the operation being performed on a
-–
+structure without the need of changing the classes of the elements
-–
+that you are operating on.
-+
+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. } \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.  Here is a diagram of the class heirarchy:
-<
-<
+%\begin{figure}
-<
+%\centering
-<
+%\includegraphics[width=3in]{heirarchy.eps}
-<
+%\caption[Class heirarchy for StuntDoubles in {\sc oopse}-3.0]{ \\
-<
+%The class heirarchy of StuntDoubles in {\sc oopse}-3.0. The
-<
+%selection syntax allows the user to select any of the objects that
-<
+%are descended from a StuntDouble.} \label{oopseFig:heirarchy}
-<
+%\end{figure}
-<
->
+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.
+\begin{itemize}
+\item A {\bf StuntDouble} is {\it any} object that can be manipulated by the
+integrators and minimizers.
+DirectionalAtom}s which behaves as a single unit.
+\end{itemize}
-–
+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.
->
+{\sc OOPSE} provides a powerful selection utility to select
->
+StuntDoubles. 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
+\centering
+\includegraphics[width=\linewidth]{staticPropsProcess.eps}
+\caption[A representation of the three-stage correlations in
-<
+\texttt{StaticProps}]{Three-stage processing in
-<
+\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}
->
+\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:
+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}
+\subsection{\label{appendixSection:Dump2XYZ}Dump2XYZ}
-<
+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:
->
+{\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|}
+\end{longtable}
+\subsection{\label{appendixSection:hydrodynamics}Hydro}
-<
+The options available for Hydro are as follows:
->
->
+{\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

Diff Legend

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

Comparing trunk/tengDissertation/Appendix.tex (file contents): Revision 2815 by tim, Wed Jun 7 18:34:05 2006 UTC vs. Revision 2840 by tim, Fri Jun 9 02:54:01 2006 UTC

Diff Legend

Comparing trunk/tengDissertation/Appendix.tex (file contents):
Revision 2815 by tim, Wed Jun 7 18:34:05 2006 UTC vs.
Revision 2840 by tim, Fri Jun 9 02:54:01 2006 UTC