ViewVC Help
View File | Revision Log | Show Annotations | View Changeset | Root Listing
root/group/trunk/tengDissertation/Appendix.tex
(Generate patch)

Comparing trunk/tengDissertation/Appendix.tex (file contents):
Revision 2835 by tim, Thu Jun 8 22:39:54 2006 UTC vs.
Revision 2840 by tim, Fri Jun 9 02:54:01 2006 UTC

# Line 1 | Line 1
1   \appendix
2   \chapter{\label{chapt:oopse}Object-Oriented Parallel Simulation Engine}
3  
4 < Designing object-oriented software is hard, and designing reusable
5 < object-oriented scientific software is even harder. Absence of
6 < applying modern software development practices is the bottleneck of
7 < Scientific Computing community\cite{Wilson2006}. For instance, in
4 > Absence of applying modern software development practices is the
5 > bottleneck of Scientific Computing community\cite{Wilson2006}. In
6   the last 20 years , there are quite a few MD packages that were
7   developed to solve common MD problems and perform robust simulations
8   . However, many of the codes are legacy programs that are either
# Line 64 | Line 62 | as \texttt{StatProps} (see Sec.~\ref{appendixSection:S
62   program of the package, \texttt{oopse} and it corresponding parallel
63   version \texttt{oopse\_MPI}, as well as other useful utilities, such
64   as \texttt{StatProps} (see Sec.~\ref{appendixSection:StaticProps}),
65 < \texttt{DynamicProps} (see
66 < Sec.~\ref{appendixSection:appendixSection:DynamicProps}),
67 < \texttt{Dump2XYZ} (see
70 < Sec.~\ref{appendixSection:appendixSection:Dump2XYZ}), \texttt{Hydro}
71 < (see Sec.~\ref{appendixSection:appendixSection:hydrodynamics})
65 > \texttt{DynamicProps} (see Sec.~\ref{appendixSection:DynamicProps}),
66 > \texttt{Dump2XYZ} (see Sec.~\ref{appendixSection:Dump2XYZ}),
67 > \texttt{Hydro} (see Sec.~\ref{appendixSection:hydrodynamics})
68   \textit{etc}.
69  
70   \begin{figure}
# Line 113 | Line 109 | OOPSE}\cite{Meineke05} and PROTOMOL\cite{Matthey05} \t
109   As one of the latest advanced techniques emerged from
110   object-oriented community, design patterns were applied in some of
111   the modern scientific software applications, such as JMol, {\sc
112 < OOPSE}\cite{Meineke05} and PROTOMOL\cite{Matthey05} \textit{etc}.
113 < The following sections enumerates some of the patterns used in {\sc
114 < OOPSE}.
112 > OOPSE}\cite{Meineke2005} and PROTOMOL\cite{Matthey2005}
113 > \textit{etc}. The following sections enumerates some of the patterns
114 > used in {\sc OOPSE}.
115  
116   \subsection{\label{appendixSection:singleton}Singleton}
117 +
118   The Singleton pattern not only provides a mechanism to restrict
119   instantiation of a class to one object, but also provides a global
120   point of access to the object. Currently implemented as a global
# Line 127 | Line 124 | static data approach in {\sc OOPSE}. {\tt IntegratorFa
124   pollution.Although the singleton pattern can be implemented in
125   various ways  to account for different aspects of the software
126   designs, such as lifespan control \textit{etc}, we only use the
127 < static data approach in {\sc OOPSE}. {\tt IntegratorFactory} class
128 < is declared as
127 > static data approach in {\sc OOPSE}. IntegratorFactory class is
128 > declared as
129 >
130   \begin{lstlisting}[float,caption={[A classic Singleton design pattern implementation(I)] The declaration of of simple Singleton pattern.},label={appendixScheme:singletonDeclaration}]
131  
132   class IntegratorFactory {
# Line 142 | Line 140 | The corresponding implementation is
140   };
141  
142   \end{lstlisting}
143 +
144   The corresponding implementation is
145 +
146   \begin{lstlisting}[float,caption={[A classic implementation of Singleton design pattern (II)] The implementation of simple Singleton pattern.},label={appendixScheme:singletonImplementation}]
147  
148   IntegratorFactory::instance_ = NULL;
# Line 155 | Line 155 | Since constructor is declared as {\tt protected}, a cl
155   }
156  
157   \end{lstlisting}
158 – Since constructor is declared as {\tt protected}, a client can not
159 – instantiate {\tt IntegratorFactory} directly. Moreover, since the
160 – member function {\tt getInstance} serves as the only entry of access
161 – to {\tt IntegratorFactory}, this approach fulfills the basic
162 – requirement, a single instance. Another consequence of this approach
163 – is the automatic destruction since static data are destroyed upon
164 – program termination.
158  
159 + Since constructor is declared as protected, a client can not
160 + instantiate IntegratorFactory directly. Moreover, since the member
161 + function getInstance serves as the only entry of access to
162 + IntegratorFactory, this approach fulfills the basic requirement, a
163 + single instance. Another consequence of this approach is the
164 + automatic destruction since static data are destroyed upon program
165 + termination.
166 +
167   \subsection{\label{appendixSection:factoryMethod}Factory Method}
168  
169   Categoried as a creational pattern, the Factory Method pattern deals
170   with the problem of creating objects without specifying the exact
171   class of object that will be created. Factory Method is typically
172   implemented by delegating the creation operation to the subclasses.
173 < {\tt Integrator} class Parameterized Factory pattern where factory
174 < method ({\tt createIntegrator} member function) creates products
175 < based on the identifier (see
176 < List.~\ref{appendixScheme:factoryDeclaration}). If the identifier
177 < has been already registered, the factory method will invoke the
178 < corresponding creator (see List.~\ref{integratorCreator}) which
179 < utilizes the modern C++ template technique to avoid subclassing.
180 < \begin{lstlisting}[float,caption={[The implementation of Parameterized Factory pattern (I)]Source code of {\tt IntegratorFactory} class.},label={appendixScheme:factoryDeclaration}]
173 > Parameterized Factory pattern where factory method (
174 > createIntegrator member function) creates products based on the
175 > identifier (see List.~\ref{appendixScheme:factoryDeclaration}). If
176 > the identifier has been already registered, the factory method will
177 > invoke the corresponding creator (see List.~\ref{integratorCreator})
178 > which utilizes the modern C++ template technique to avoid excess
179 > subclassing.
180 >
181 > \begin{lstlisting}[float,caption={[The implementation of Parameterized Factory pattern (I)]Source code of IntegratorFactory class.},label={appendixScheme:factoryDeclaration}]
182  
183   class IntegratorFactory {
184   public:
# Line 199 | Line 201 | class IntegratorFactory { (private)
201    CreatorMapType creatorMap_;
202   };
203   \end{lstlisting}
204 +
205   \begin{lstlisting}[float,caption={[The implementation of Parameterized Factory pattern (III)]Source code of creator classes.},label={appendixScheme:integratorCreator}]
206  
207   class IntegratorCreator {
# Line 226 | Line 229 | The purpose of the Visitor Pattern is to encapsulate a
229  
230   \subsection{\label{appendixSection:visitorPattern}Visitor}
231  
232 < The purpose of the Visitor Pattern is to encapsulate an operation
233 < that you want to perform on the elements. The operation being
234 < performed on a structure can be switched without changing the
235 < interfaces of the elements. In other words, one can add virtual
236 < functions into a set of classes without modifying their interfaces.
237 < Fig.~\ref{appendixFig:visitorUML} demonstrates the structure of
238 < Visitor pattern which is used extensively in {\tt Dump2XYZ}. In
239 < order to convert an OOPSE dump file, a series of distinct and
240 < unrelated operations are performed on different StuntDoubles.
241 < Visitor allows one to keep related operations together by packing
242 < them into one class. {\tt BaseAtomVisitor} is a typical example of
243 < visitor in {\tt Dump2XYZ} program{see
244 < List.~\ref{appendixScheme:visitor}}. In contrast to the operations,
245 < the object structure or element classes rarely change(See
246 < Fig.~\ref{oopseFig:heirarchy} and
244 < List.~\ref{appendixScheme:element}).
232 > The visitor pattern is designed to decouple the data structure and
233 > algorithms used upon them by collecting related operation from
234 > element classes into other visitor classes, which is equivalent to
235 > adding virtual functions into a set of classes without modifying
236 > their interfaces. Fig.~\ref{appendixFig:visitorUML} demonstrates the
237 > structure of Visitor pattern which is used extensively in {\tt
238 > Dump2XYZ}. In order to convert an OOPSE dump file, a series of
239 > distinct operations are performed on different StuntDoubles (See the
240 > class hierarchy in Fig.~\ref{oopseFig:hierarchy} and the declaration
241 > in List.~\ref{appendixScheme:element}). Since the hierarchies
242 > remains stable, it is easy to define a visit operation (see
243 > List.~\ref{appendixScheme:visitor}) for each class of StuntDouble.
244 > Note that using Composite pattern\cite{Gamma1994}, CompositVisitor
245 > manages a priority visitor list and handles the execution of every
246 > visitor in the priority list on different StuntDoubles.
247  
246 –
248   \begin{figure}
249   \centering
250   \includegraphics[width=\linewidth]{visitor.eps}
# Line 251 | Line 252 | diagram of Visitor patten.} \label{appendixFig:visitor
252   diagram of Visitor patten.} \label{appendixFig:visitorUML}
253   \end{figure}
254  
255 < \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (I)]Source code of the visitor classes.},label={appendixScheme:visitor}]
255 > \begin{figure}
256 > \centering
257 > \includegraphics[width=\linewidth]{hierarchy.eps}
258 > \caption[Class hierarchy for ojects in {\sc OOPSE}]{ A diagram of
259 > the class hierarchy. } \label{oopseFig:hierarchy}
260 > \end{figure}
261  
256 – class BaseVisitor{
257 – public:
258 –  virtual void visit(Atom* atom);
259 –  virtual void visit(DirectionalAtom* datom);
260 –  virtual void visit(RigidBody* rb);
261 – };
262 –
263 – class BaseAtomVisitor:public BaseVisitor{ public:
264 –  virtual void visit(Atom* atom);
265 –  virtual void visit(DirectionalAtom* datom);
266 –  virtual void visit(RigidBody* rb);
267 – };
268 –
269 – \end{lstlisting}
270 –
262   \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (II)]Source code of the element classes.},label={appendixScheme:element}]
263  
264 < class StuntDouble {
274 < public:
264 > class StuntDouble { public:
265    virtual void accept(BaseVisitor* v) = 0;
266   };
267  
268 < class Atom: public StuntDouble {
279 < public:
268 > class Atom: public StuntDouble { public:
269    virtual void accept{BaseVisitor* v*} {
270      v->visit(this);
271    }
272   };
273  
274 < class DirectionalAtom: public Atom {
286 < public:
274 > class DirectionalAtom: public Atom { public:
275    virtual void accept{BaseVisitor* v*} {
276      v->visit(this);
277    }
278   };
279  
280 < class RigidBody: public StuntDouble {
293 < public:
280 > class RigidBody: public StuntDouble { public:
281    virtual void accept{BaseVisitor* v*} {
282      v->visit(this);
283    }
# Line 298 | Line 285 | class RigidBody: public StuntDouble { (public)
285  
286   \end{lstlisting}
287  
288 + \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (I)]Source code of the visitor classes.},label={appendixScheme:visitor}]
289 +
290 + class BaseVisitor{
291 + public:
292 +  virtual void visit(Atom* atom);
293 +  virtual void visit(DirectionalAtom* datom);
294 +  virtual void visit(RigidBody* rb);
295 + };
296 +
297 + class BaseAtomVisitor:public BaseVisitor{ public:
298 +  virtual void visit(Atom* atom);
299 +  virtual void visit(DirectionalAtom* datom);
300 +  virtual void visit(RigidBody* rb);
301 + };
302 +
303 + class SSDAtomVisitor:public BaseAtomVisitor{ public:
304 +  virtual void visit(Atom* atom);
305 +  virtual void visit(DirectionalAtom* datom);
306 +  virtual void visit(RigidBody* rb);
307 + };
308 +
309 + class CompositeVisitor: public BaseVisitor {
310 + public:
311 +
312 +  typedef list<pair<BaseVisitor*, int> > VistorListType;
313 +  typedef VistorListType::iterator VisitorListIterator;
314 +  virtual void visit(Atom* atom) {
315 +    VisitorListIterator i;
316 +    BaseVisitor* curVisitor;
317 +    for(i = visitorList.begin();i != visitorList.end();++i) {
318 +      atom->accept(*i);
319 +    }
320 +  }
321 +
322 +  virtual void visit(DirectionalAtom* datom) {
323 +    VisitorListIterator i;
324 +    BaseVisitor* curVisitor;
325 +    for(i = visitorList.begin();i != visitorList.end();++i) {
326 +      atom->accept(*i);
327 +    }
328 +  }
329 +
330 +  virtual void visit(RigidBody* rb) {
331 +    VisitorListIterator i;
332 +    std::vector<Atom*> myAtoms;
333 +    std::vector<Atom*>::iterator ai;
334 +    myAtoms = rb->getAtoms();
335 +    for(i = visitorList.begin();i != visitorList.end();++i) {{
336 +      rb->accept(*i);
337 +      for(ai = myAtoms.begin(); ai != myAtoms.end(); ++ai){
338 +        (*ai)->accept(*i);
339 +    }
340 +  }
341 +
342 +  void addVisitor(BaseVisitor* v, int priority);
343 +
344 +  protected:
345 +    VistorListType visitorList;
346 + };
347 +
348 + \end{lstlisting}
349 +
350   \section{\label{appendixSection:concepts}Concepts}
351  
352   OOPSE manipulates both traditional atoms as well as some objects
353   that {\it behave like atoms}.  These objects can be rigid
354   collections of atoms or atoms which have orientational degrees of
355 < freedom.  A diagram of the class heirarchy is illustrated in
356 < Fig.~\ref{oopseFig:heirarchy}. Every Molecule, Atom and
355 > freedom.  A diagram of the class hierarchy is illustrated in
356 > Fig.~\ref{oopseFig:hierarchy}. Every Molecule, Atom and
357   DirectionalAtom in {\sc OOPSE} have their own names which are
358   specified in the {\tt .md} file. In contrast, RigidBodies are
359   denoted by their membership and index inside a particular molecule:
# Line 312 | Line 361 | body in a DMPC molecule is DMPC\_RB\_0.
361   on the specifics of the simulation). The names of rigid bodies are
362   generated automatically. For example, the name of the first rigid
363   body in a DMPC molecule is DMPC\_RB\_0.
364 < %\begin{figure}
365 < %\centering
366 < %\includegraphics[width=\linewidth]{heirarchy.eps}
367 < %\caption[Class heirarchy for ojects in {\sc OOPSE}]{ A diagram of
368 < %the class heirarchy.
369 < %\begin{itemize}
370 < %\item A {\bf StuntDouble} is {\it any} object that can be manipulated by the
371 < %integrators and minimizers.
323 < %\item An {\bf Atom} is a fundamental point-particle that can be moved around during a simulation.
324 < %\item A {\bf DirectionalAtom} is an atom which has {\it orientational} as well as translational degrees of freedom.
325 < %\item A {\bf RigidBody} is a collection of {\bf Atom}s or {\bf
326 < %DirectionalAtom}s which behaves as a single unit.
327 < %\end{itemize}
328 < %} \label{oopseFig:heirarchy}
329 < %\end{figure}
364 > \begin{itemize}
365 > \item A {\bf StuntDouble} is {\it any} object that can be manipulated by the
366 > integrators and minimizers.
367 > \item An {\bf Atom} is a fundamental point-particle that can be moved around during a simulation.
368 > \item A {\bf DirectionalAtom} is an atom which has {\it orientational} as well as translational degrees of freedom.
369 > \item A {\bf RigidBody} is a collection of {\bf Atom}s or {\bf
370 > DirectionalAtom}s which behaves as a single unit.
371 > \end{itemize}
372  
373   \section{\label{appendixSection:syntax}Syntax of the Select Command}
374  
375 < The most general form of the select command is: {\tt select {\it
376 < expression}}. This expression represents an arbitrary set of
335 < StuntDoubles (Atoms or RigidBodies) in {\sc OOPSE}. Expressions are
336 < composed of either name expressions, index expressions, predefined
337 < sets, user-defined expressions, comparison operators, within
338 < expressions, or logical combinations of the above expression types.
339 < Expressions can be combined using parentheses and the Boolean
340 < operators.
375 > {\sc OOPSE} provides a powerful selection utility to select
376 > StuntDoubles. The most general form of the select command is:
377  
378 + {\tt select {\it expression}}.
379 +
380 + This expression represents an arbitrary set of StuntDoubles (Atoms
381 + or RigidBodies) in {\sc OOPSE}. Expressions are composed of either
382 + name expressions, index expressions, predefined sets, user-defined
383 + expressions, comparison operators, within expressions, or logical
384 + combinations of the above expression types. Expressions can be
385 + combined using parentheses and the Boolean operators.
386 +
387   \subsection{\label{appendixSection:logical}Logical expressions}
388  
389   The logical operators allow complex queries to be constructed out of

Diff Legend

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