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 2816 by tim, Wed Jun 7 19:51:57 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}
121 – The Singleton pattern ensures that only one instance of a class is
122 – created. All objects that use an instance of that class use the same
123 – instance.
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
118 + variable, the logging utility which reports error and warning
119 + messages to the console in {\sc OOPSE} is a good candidate for
120 + applying the Singleton pattern to avoid the global namespace
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}. IntegratorFactory class is
125 + declared as
126 +
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
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() {
148 +  if (instance_ == NULL){
149 +    instance_ = new IntegratorFactory;
150 +  }
151 +  return instance_;
152 + }
153 +
154 + \end{lstlisting}
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}
126 – The Factory Method pattern is a creational pattern which deals with
127 – the problem of creating objects without specifying the exact class
128 – of object that will be created. Factory Method solves this problem
129 – by defining a separate method for creating the objects, which
130 – subclasses can then override to specify the derived type of product
131 – that will be created.
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 + \begin{lstlisting}[float,caption={[The implementation of Parameterized Factory pattern (I)]Source code of IntegratorFactory class.},label={appendixScheme:factoryDeclaration}]
179 +
180 + class IntegratorFactory {
181 + public:
182 +  typedef std::map<string, IntegratorCreator*> CreatorMapType;
183 +
184 +  bool registerIntegrator(IntegratorCreator* creator) {
185 +    return creatorMap_.insert(creator->getIdent(), creator).second;
186 +  }
187 +
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 +      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={[The implementation of Parameterized Factory pattern (III)]Source code of creator classes.},label={appendixScheme:integratorCreator}]
203 +
204 + class IntegratorCreator {
205 + public:
206 +    IntegratorCreator(const string& ident) : ident_(ident) {}
207 +
208 +    const string& getIdent() const { return ident_; }
209 +
210 +    virtual Integrator* create(SimInfo* info) const = 0;
211 +
212 + private:
213 +    string ident_;
214 + };
215 +
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}
134 – The purpose of the Visitor Pattern is to encapsulate an operation
135 – that you want to perform on the elements of a data structure. In
136 – this way, you can change the operation being performed on a
137 – structure without the need of changing the classes of the elements
138 – that you are operating on.
228  
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{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}
284 +
285 + \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (I)]Source code of the visitor classes.},label={appendixScheme:visitor}]
286 +
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 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}
154 < %\end{figure}
155 <
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 162 | Line 367 | Every Molecule, Atom and DirectionalAtom in {\sc OOPSE
367   DirectionalAtom}s which behaves as a single unit.
368   \end{itemize}
369  
165 – Every Molecule, Atom and DirectionalAtom in {\sc OOPSE} have their
166 – own names which are specified in the {\tt .md} file. In contrast,
167 – RigidBodies are denoted by their membership and index inside a
168 – particular molecule: [MoleculeName]\_RB\_[index] (the contents
169 – inside the brackets depend on the specifics of the simulation). The
170 – names of rigid bodies are generated automatically. For example, the
171 – name of the first rigid body in a DMPC molecule is DMPC\_RB\_0.
172 –
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
374 < StuntDoubles (Atoms or RigidBodies) in {\sc OOPSE}. Expressions are
375 < composed of either name expressions, index expressions, predefined
376 < sets, user-defined expressions, comparison operators, within
377 < expressions, or logical combinations of the above expression types.
378 < Expressions can be combined using parentheses and the Boolean
379 < 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  
# Line 502 | Line 702 | Dump2XYZ can transform an OOPSE dump file into a xyz f
702  
703   \subsection{\label{appendixSection:Dump2XYZ}Dump2XYZ}
704  
705 < Dump2XYZ can transform an OOPSE dump file into a xyz file which can
706 < be opened by other molecular dynamics viewers such as Jmol and
707 < VMD\cite{Humphrey1996}. The options available for Dump2XYZ are as
708 < follows:
705 > {\tt Dump2XYZ} can transform an OOPSE dump file into a xyz file
706 > which can be opened by other molecular dynamics viewers such as Jmol
707 > and VMD\cite{Humphrey1996}. The options available for Dump2XYZ are
708 > as follows:
709  
710  
711   \begin{longtable}[c]{|EFG|}
# Line 536 | Line 736 | The options available for Hydro are as follows:
736   \end{longtable}
737  
738   \subsection{\label{appendixSection:hydrodynamics}Hydro}
739 < The options available for Hydro are as follows:
739 >
740 > {\tt Hydro} can calculate resistance and diffusion tensors at the
741 > center of resistance. Both tensors at the center of diffusion can
742 > also be reported from the program, as well as the coordinates for
743 > the beads which are used to approximate the arbitrary shapes. The
744 > options available for Hydro are as follows:
745   \begin{longtable}[c]{|EFG|}
746   \caption{Hydrodynamics Command-line Options}
747   \\ \hline

Diff Legend

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