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 2822 by tim, Thu Jun 8 07:27:56 2006 UTC vs.
Revision 2841 by tim, Fri Jun 9 03:19:29 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
8 < the last 20 years , there are quite a few MD packages that were
9 < developed to solve common MD problems and perform robust simulations
10 < . However, many of the codes are legacy programs that are either
11 < poorly organized or extremely complex. Usually, these packages were
12 < contributed by scientists without official computer science
13 < training. The development of most MD applications are lack of strong
14 < coordination to enforce design and programming guidelines. Moreover,
15 < most MD programs also suffer from missing design and implement
16 < documents which is crucial to the maintenance and extensibility.
17 < Along the way of studying structural and dynamic processes in
18 < condensed phase systems like biological membranes and nanoparticles,
19 < we developed and maintained an Object-Oriented Parallel Simulation
20 < Engine ({\sc OOPSE}). This new molecular dynamics package has some
21 < unique features
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
7 > packages\cite{Brooks1983, Vincent1995, Kale1999} that were developed
8 > to solve common MD problems and perform robust simulations .
9 > Unfortunately, most of them are commercial programs that are either
10 > poorly written or extremely complicate. Consequently, it prevents
11 > the researchers to reuse or extend those packages to do cutting-edge
12 > research effectively. Along the way of studying structural and
13 > dynamic processes in condensed phase systems like biological
14 > membranes and nanoparticles, we developed an open source
15 > Object-Oriented Parallel Simulation Engine ({\sc OOPSE}). This new
16 > molecular dynamics package has some unique features
17   \begin{enumerate}
18    \item {\sc OOPSE} performs Molecular Dynamics (MD) simulations on non-standard
19   atom types (transition metals, point dipoles, sticky potentials,
# Line 64 | Line 59 | as \texttt{StatProps} (see Sec.~\ref{appendixSection:S
59   program of the package, \texttt{oopse} and it corresponding parallel
60   version \texttt{oopse\_MPI}, as well as other useful utilities, such
61   as \texttt{StatProps} (see Sec.~\ref{appendixSection:StaticProps}),
62 < \texttt{DynamicProps} (see
63 < Sec.~\ref{appendixSection:appendixSection:DynamicProps}),
64 < \texttt{Dump2XYZ} (see
70 < Sec.~\ref{appendixSection:appendixSection:Dump2XYZ}), \texttt{Hydro}
71 < (see Sec.~\ref{appendixSection:appendixSection:hydrodynamics})
62 > \texttt{DynamicProps} (see Sec.~\ref{appendixSection:DynamicProps}),
63 > \texttt{Dump2XYZ} (see Sec.~\ref{appendixSection:Dump2XYZ}),
64 > \texttt{Hydro} (see Sec.~\ref{appendixSection:hydrodynamics})
65   \textit{etc}.
66  
67   \begin{figure}
# Line 113 | Line 106 | OOPSE}\cite{Meineke05} and PROTOMOL\cite{Matthey05} \t
106   As one of the latest advanced techniques emerged from
107   object-oriented community, design patterns were applied in some of
108   the modern scientific software applications, such as JMol, {\sc
109 < OOPSE}\cite{Meineke05} and PROTOMOL\cite{Matthey05} \textit{etc}.
110 < The following sections enumerates some of the patterns used in {\sc
111 < OOPSE}.
109 > OOPSE}\cite{Meineke2005} and PROTOMOL\cite{Matthey2005}
110 > \textit{etc}. The following sections enumerates some of the patterns
111 > used in {\sc OOPSE}.
112  
113   \subsection{\label{appendixSection:singleton}Singleton}
114 +
115   The Singleton pattern not only provides a mechanism to restrict
116   instantiation of a class to one object, but also provides a global
117   point of access to the object. Currently implemented as a global
# Line 127 | Line 121 | static data approach in {\sc OOPSE}. {\tt IntegratorFa
121   pollution.Although the singleton pattern can be implemented in
122   various ways  to account for different aspects of the software
123   designs, such as lifespan control \textit{etc}, we only use the
124 < static data approach in {\sc OOPSE}. {\tt IntegratorFactory} class
125 < is declared as
132 < \begin{lstlisting}[float,caption={[A classic Singleton design pattern implementation(I)] Declaration of {\tt IntegratorFactory} class.},label={appendixScheme:singletonDeclaration}]
124 > static data approach in {\sc OOPSE}. IntegratorFactory class is
125 > declared as
126  
127 <  class IntegratorFactory {
128 <    public:
129 <      static IntegratorFactory* getInstance();
130 <    protected:
131 <      IntegratorFactory();
132 <    private:
133 <      static IntegratorFactory* instance_;
134 <  };
127 > \begin{lstlisting}[float,caption={[A classic Singleton design pattern implementation(I)] The declaration of of simple Singleton pattern.},label={appendixScheme:singletonDeclaration}]
128 >
129 > class IntegratorFactory {
130 > public:
131 >  static IntegratorFactory*
132 >  getInstance();
133 > protected:
134 >  IntegratorFactory();
135 > private:
136 >  static IntegratorFactory* instance_;
137 > };
138 >
139   \end{lstlisting}
140 +
141   The corresponding implementation is
144 – \begin{lstlisting}[float,caption={[A classic Singleton design pattern implementation(II)] Implementation of {\tt IntegratorFactory} class.},label={appendixScheme:singletonImplementation}]
142  
143 + \begin{lstlisting}[float,caption={[A classic implementation of Singleton design pattern (II)] The implementation of simple Singleton pattern.},label={appendixScheme:singletonImplementation}]
144 +
145   IntegratorFactory::instance_ = NULL;
146  
147   IntegratorFactory* getInstance() {
# Line 151 | Line 150 | IntegratorFactory* getInstance() {
150    }
151    return instance_;
152   }
153 +
154   \end{lstlisting}
155 – Since constructor is declared as {\tt protected}, a client can not
156 – instantiate {\tt IntegratorFactory} directly. Moreover, since the
157 – member function {\tt getInstance} serves as the only entry of access
158 – to {\tt IntegratorFactory}, this approach fulfills the basic
159 – requirement, a single instance. Another consequence of this approach
160 – is the automatic destruction since static data are destroyed upon
161 – program termination.
155  
156 + Since constructor is declared as protected, a client can not
157 + instantiate IntegratorFactory directly. Moreover, since the member
158 + function getInstance serves as the only entry of access to
159 + IntegratorFactory, this approach fulfills the basic requirement, a
160 + single instance. Another consequence of this approach is the
161 + automatic destruction since static data are destroyed upon program
162 + termination.
163 +
164   \subsection{\label{appendixSection:factoryMethod}Factory Method}
165  
166   Categoried as a creational pattern, the Factory Method pattern deals
167   with the problem of creating objects without specifying the exact
168   class of object that will be created. Factory Method is typically
169   implemented by delegating the creation operation to the subclasses.
170 + Parameterized Factory pattern where factory method (
171 + createIntegrator member function) creates products based on the
172 + identifier (see List.~\ref{appendixScheme:factoryDeclaration}). If
173 + the identifier has been already registered, the factory method will
174 + invoke the corresponding creator (see List.~\ref{integratorCreator})
175 + which utilizes the modern C++ template technique to avoid excess
176 + subclassing.
177  
178 < Registers a creator with a type identifier. Looks up the type
171 < identifier in the internal map. If it is found, it invokes the
172 < corresponding creator for the type identifier and returns its
173 < result.
174 < \begin{lstlisting}[float,caption={[].},label={appendixScheme:factoryDeclaration}]
175 <  class IntegratorCreator;
176 <  class IntegratorFactory {
177 <    public:
178 <      typedef std::map<std::string, IntegratorCreator*> CreatorMapType;
178 > \begin{lstlisting}[float,caption={[The implementation of Parameterized Factory pattern (I)]Source code of IntegratorFactory class.},label={appendixScheme:factoryDeclaration}]
179  
180 <      bool registerIntegrator(IntegratorCreator* creator);
180 > class IntegratorFactory {
181 > public:
182 >  typedef std::map<string, IntegratorCreator*> CreatorMapType;
183  
184 <      Integrator* createIntegrator(const std::string& id, SimInfo* info);
185 <
184 <    private:
185 <      CreatorMapType creatorMap_;
186 <  };
187 < \end{lstlisting}
188 <
189 < \begin{lstlisting}[float,caption={[].},label={appendixScheme:factoryDeclarationImplementation}]
190 <  bool IntegratorFactory::unregisterIntegrator(const std::string& id) {
191 <    return creatorMap_.erase(id) == 1;
184 >  bool registerIntegrator(IntegratorCreator* creator) {
185 >    return creatorMap_.insert(creator->getIdent(), creator).second;
186    }
187  
188 <  Integrator*
189 <  IntegratorFactory::createIntegrator(const std::string& id, SimInfo* info) {
188 >  Integrator* createIntegrator(const string& id, SimInfo* info) {
189 >    Integrator* result = NULL;
190      CreatorMapType::iterator i = creatorMap_.find(id);
191      if (i != creatorMap_.end()) {
192 <      //invoke functor to create object
199 <      return (i->second)->create(info);
200 <    } else {
201 <      return NULL;
192 >      result = (i->second)->create(info);
193      }
194 +    return result;
195    }
196 +
197 + private:
198 +  CreatorMapType creatorMap_;
199 + };
200   \end{lstlisting}
201  
202 < \begin{lstlisting}[float,caption={[].},label={appendixScheme:integratorCreator}]
202 > \begin{lstlisting}[float,caption={[The implementation of Parameterized Factory pattern (III)]Source code of creator classes.},label={appendixScheme:integratorCreator}]
203  
204 <  class IntegratorCreator {
205 <  public:
206 <    IntegratorCreator(const std::string& ident) : ident_(ident) {}
204 > class IntegratorCreator {
205 > public:
206 >    IntegratorCreator(const string& ident) : ident_(ident) {}
207  
208 <    const std::string& getIdent() const { return ident_; }
208 >    const string& getIdent() const { return ident_; }
209  
210      virtual Integrator* create(SimInfo* info) const = 0;
211  
212 <  private:
213 <    std::string ident_;
214 <  };
212 > private:
213 >    string ident_;
214 > };
215  
216 <  template<class ConcreteIntegrator>
217 <  class IntegratorBuilder : public IntegratorCreator {
218 <  public:
219 <    IntegratorBuilder(const std::string& ident) : IntegratorCreator(ident) {}
220 <    virtual  Integrator* create(SimInfo* info) const {
221 <      return new ConcreteIntegrator(info);
222 <    }
223 <  };
216 > template<class ConcreteIntegrator>
217 > class IntegratorBuilder : public IntegratorCreator {
218 > public:
219 >  IntegratorBuilder(const string& ident)
220 >                   : IntegratorCreator(ident) {}
221 >  virtual  Integrator* create(SimInfo* info) const {
222 >    return new ConcreteIntegrator(info);
223 >  }
224 > };
225   \end{lstlisting}
226  
227   \subsection{\label{appendixSection:visitorPattern}Visitor}
228  
229 < The purpose of the Visitor Pattern is to encapsulate an operation
230 < that you want to perform on the elements of a data structure. In
231 < this way, you can change the operation being performed on a
232 < structure without the need of changing the class heirarchy of the
233 < elements that you are operating on.
229 > The visitor pattern is designed to decouple the data structure and
230 > algorithms used upon them by collecting related operation from
231 > element classes into other visitor classes, which is equivalent to
232 > adding virtual functions into a set of classes without modifying
233 > their interfaces. Fig.~\ref{appendixFig:visitorUML} demonstrates the
234 > structure of Visitor pattern which is used extensively in {\tt
235 > Dump2XYZ}. In order to convert an OOPSE dump file, a series of
236 > distinct operations are performed on different StuntDoubles (See the
237 > class hierarchy in Fig.~\ref{oopseFig:hierarchy} and the declaration
238 > in List.~\ref{appendixScheme:element}). Since the hierarchies
239 > remains stable, it is easy to define a visit operation (see
240 > List.~\ref{appendixScheme:visitor}) for each class of StuntDouble.
241 > Note that using Composite pattern\cite{Gamma1994}, CompositVisitor
242 > manages a priority visitor list and handles the execution of every
243 > visitor in the priority list on different StuntDoubles.
244  
245 < \begin{lstlisting}[float,caption={[].},label={appendixScheme:visitor}]
246 <  class BaseVisitor{
247 <    public:
248 <      virtual void visit(Atom* atom);
249 <      virtual void visit(DirectionalAtom* datom);
250 <      virtual void visit(RigidBody* rb);
251 <  };
245 > \begin{figure}
246 > \centering
247 > \includegraphics[width=\linewidth]{visitor.eps}
248 > \caption[The UML class diagram of Visitor patten] {The UML class
249 > diagram of Visitor patten.} \label{appendixFig:visitorUML}
250 > \end{figure}
251 >
252 > \begin{figure}
253 > \centering
254 > \includegraphics[width=\linewidth]{hierarchy.eps}
255 > \caption[Class hierarchy for ojects in {\sc OOPSE}]{ A diagram of
256 > the class hierarchy. } \label{oopseFig:hierarchy}
257 > \end{figure}
258 >
259 > \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (II)]Source code of the element classes.},label={appendixScheme:element}]
260 >
261 > class StuntDouble { public:
262 >  virtual void accept(BaseVisitor* v) = 0;
263 > };
264 >
265 > class Atom: public StuntDouble { public:
266 >  virtual void accept{BaseVisitor* v*} {
267 >    v->visit(this);
268 >  }
269 > };
270 >
271 > class DirectionalAtom: public Atom { public:
272 >  virtual void accept{BaseVisitor* v*} {
273 >    v->visit(this);
274 >  }
275 > };
276 >
277 > class RigidBody: public StuntDouble { public:
278 >  virtual void accept{BaseVisitor* v*} {
279 >    v->visit(this);
280 >  }
281 > };
282 >
283   \end{lstlisting}
246 – \begin{lstlisting}[float,caption={[].},label={appendixScheme:element}]
247 –  class StuntDouble {
248 –    public:
249 –      virtual void accept(BaseVisitor* v) = 0;
250 –  };
284  
285 <  class Atom: public StuntDouble {
253 <    public:
254 <      virtual void accept{BaseVisitor* v*} {v->visit(this);}
255 <  };
285 > \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (I)]Source code of the visitor classes.},label={appendixScheme:visitor}]
286  
287 <  class DirectionalAtom: public Atom {
288 <    public:
289 <      virtual void accept{BaseVisitor* v*} {v->visit(this);}
290 <  };
287 > class BaseVisitor{
288 > public:
289 >  virtual void visit(Atom* atom);
290 >  virtual void visit(DirectionalAtom* datom);
291 >  virtual void visit(RigidBody* rb);
292 > };
293  
294 <  class RigidBody: public StuntDouble {
295 <    public:
296 <      virtual void accept{BaseVisitor* v*} {v->visit(this);}
297 <  };
294 > class BaseAtomVisitor:public BaseVisitor{ public:
295 >  virtual void visit(Atom* atom);
296 >  virtual void visit(DirectionalAtom* datom);
297 >  virtual void visit(RigidBody* rb);
298 > };
299 >
300 > class SSDAtomVisitor:public BaseAtomVisitor{ public:
301 >  virtual void visit(Atom* atom);
302 >  virtual void visit(DirectionalAtom* datom);
303 >  virtual void visit(RigidBody* rb);
304 > };
305 >
306 > class CompositeVisitor: public BaseVisitor {
307 > public:
308  
309 +  typedef list<pair<BaseVisitor*, int> > VistorListType;
310 +  typedef VistorListType::iterator VisitorListIterator;
311 +  virtual void visit(Atom* atom) {
312 +    VisitorListIterator i;
313 +    BaseVisitor* curVisitor;
314 +    for(i = visitorList.begin();i != visitorList.end();++i) {
315 +      atom->accept(*i);
316 +    }
317 +  }
318 +
319 +  virtual void visit(DirectionalAtom* datom) {
320 +    VisitorListIterator i;
321 +    BaseVisitor* curVisitor;
322 +    for(i = visitorList.begin();i != visitorList.end();++i) {
323 +      atom->accept(*i);
324 +    }
325 +  }
326 +
327 +  virtual void visit(RigidBody* rb) {
328 +    VisitorListIterator i;
329 +    std::vector<Atom*> myAtoms;
330 +    std::vector<Atom*>::iterator ai;
331 +    myAtoms = rb->getAtoms();
332 +    for(i = visitorList.begin();i != visitorList.end();++i) {{
333 +      rb->accept(*i);
334 +      for(ai = myAtoms.begin(); ai != myAtoms.end(); ++ai){
335 +        (*ai)->accept(*i);
336 +    }
337 +  }
338 +
339 +  void addVisitor(BaseVisitor* v, int priority);
340 +
341 +  protected:
342 +    VistorListType visitorList;
343 + };
344 +
345   \end{lstlisting}
346 +
347   \section{\label{appendixSection:concepts}Concepts}
348  
349   OOPSE manipulates both traditional atoms as well as some objects
350   that {\it behave like atoms}.  These objects can be rigid
351   collections of atoms or atoms which have orientational degrees of
352 < freedom.  Here is a diagram of the class heirarchy:
353 <
354 < %\begin{figure}
355 < %\centering
356 < %\includegraphics[width=3in]{heirarchy.eps}
357 < %\caption[Class heirarchy for StuntDoubles in {\sc oopse}-3.0]{ \\
358 < %The class heirarchy of StuntDoubles in {\sc oopse}-3.0. The
359 < %selection syntax allows the user to select any of the objects that
360 < %are descended from a StuntDouble.} \label{oopseFig:heirarchy}
282 < %\end{figure}
283 <
352 > freedom.  A diagram of the class hierarchy is illustrated in
353 > Fig.~\ref{oopseFig:hierarchy}. Every Molecule, Atom and
354 > DirectionalAtom in {\sc OOPSE} have their own names which are
355 > specified in the {\tt .md} file. In contrast, RigidBodies are
356 > denoted by their membership and index inside a particular molecule:
357 > [MoleculeName]\_RB\_[index] (the contents inside the brackets depend
358 > on the specifics of the simulation). The names of rigid bodies are
359 > generated automatically. For example, the name of the first rigid
360 > body in a DMPC molecule is DMPC\_RB\_0.
361   \begin{itemize}
362   \item A {\bf StuntDouble} is {\it any} object that can be manipulated by the
363   integrators and minimizers.
# Line 289 | Line 366 | DirectionalAtom}s which behaves as a single unit.
366   \item A {\bf RigidBody} is a collection of {\bf Atom}s or {\bf
367   DirectionalAtom}s which behaves as a single unit.
368   \end{itemize}
292 –
293 – Every Molecule, Atom and DirectionalAtom in {\sc OOPSE} have their
294 – own names which are specified in the {\tt .md} file. In contrast,
295 – RigidBodies are denoted by their membership and index inside a
296 – particular molecule: [MoleculeName]\_RB\_[index] (the contents
297 – inside the brackets depend on the specifics of the simulation). The
298 – names of rigid bodies are generated automatically. For example, the
299 – name of the first rigid body in a DMPC molecule is DMPC\_RB\_0.
369  
370   \section{\label{appendixSection:syntax}Syntax of the Select Command}
371  
372 < The most general form of the select command is: {\tt select {\it
373 < expression}}. This expression represents an arbitrary set of
305 < StuntDoubles (Atoms or RigidBodies) in {\sc OOPSE}. Expressions are
306 < composed of either name expressions, index expressions, predefined
307 < sets, user-defined expressions, comparison operators, within
308 < expressions, or logical combinations of the above expression types.
309 < Expressions can be combined using parentheses and the Boolean
310 < operators.
372 > {\sc OOPSE} provides a powerful selection utility to select
373 > StuntDoubles. The most general form of the select command is:
374  
375 + {\tt select {\it expression}}.
376 +
377 + This expression represents an arbitrary set of StuntDoubles (Atoms
378 + or RigidBodies) in {\sc OOPSE}. Expressions are composed of either
379 + name expressions, index expressions, predefined sets, user-defined
380 + expressions, comparison operators, within expressions, or logical
381 + combinations of the above expression types. Expressions can be
382 + combined using parentheses and the Boolean operators.
383 +
384   \subsection{\label{appendixSection:logical}Logical expressions}
385  
386   The logical operators allow complex queries to be constructed out of

Diff Legend

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