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 2815 by tim, Wed Jun 7 18:34:05 2006 UTC vs.
Revision 2839 by tim, Fri Jun 9 02:41:58 2006 UTC

# Line 113 | Line 113 | the modern scientific software applications, such as J
113   As one of the latest advanced techniques emerged from
114   object-oriented community, design patterns were applied in some of
115   the modern scientific software applications, such as JMol, {\sc
116 < OOPSE}\cite{Meineke05} and PROTOMOL\cite{Matthey05} \textit{etc}.
117 < The following sections enumerates some of the patterns used in {\sc
118 < OOPSE}.
116 > OOPSE}\cite{Meineke2005} and PROTOMOL\cite{Matthey2005}
117 > \textit{etc}. The following sections enumerates some of the patterns
118 > used in {\sc OOPSE}.
119  
120   \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.
121  
122 + The Singleton pattern not only provides a mechanism to restrict
123 + instantiation of a class to one object, but also provides a global
124 + point of access to the object. Currently implemented as a global
125 + variable, the logging utility which reports error and warning
126 + messages to the console in {\sc OOPSE} is a good candidate for
127 + applying the Singleton pattern to avoid the global namespace
128 + pollution.Although the singleton pattern can be implemented in
129 + various ways  to account for different aspects of the software
130 + designs, such as lifespan control \textit{etc}, we only use the
131 + static data approach in {\sc OOPSE}. IntegratorFactory class is
132 + declared as
133 +
134 + \begin{lstlisting}[float,caption={[A classic Singleton design pattern implementation(I)] The declaration of of simple Singleton pattern.},label={appendixScheme:singletonDeclaration}]
135 +
136 + class IntegratorFactory {
137 + public:
138 +  static IntegratorFactory*
139 +  getInstance();
140 + protected:
141 +  IntegratorFactory();
142 + private:
143 +  static IntegratorFactory* instance_;
144 + };
145 +
146 + \end{lstlisting}
147 +
148 + The corresponding implementation is
149 +
150 + \begin{lstlisting}[float,caption={[A classic implementation of Singleton design pattern (II)] The implementation of simple Singleton pattern.},label={appendixScheme:singletonImplementation}]
151 +
152 + IntegratorFactory::instance_ = NULL;
153 +
154 + IntegratorFactory* getInstance() {
155 +  if (instance_ == NULL){
156 +    instance_ = new IntegratorFactory;
157 +  }
158 +  return instance_;
159 + }
160 +
161 + \end{lstlisting}
162 +
163 + Since constructor is declared as protected, a client can not
164 + instantiate IntegratorFactory directly. Moreover, since the member
165 + function getInstance serves as the only entry of access to
166 + IntegratorFactory, this approach fulfills the basic requirement, a
167 + single instance. Another consequence of this approach is the
168 + automatic destruction since static data are destroyed upon program
169 + termination.
170 +
171   \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.
172  
173 + Categoried as a creational pattern, the Factory Method pattern deals
174 + with the problem of creating objects without specifying the exact
175 + class of object that will be created. Factory Method is typically
176 + implemented by delegating the creation operation to the subclasses.
177 + Parameterized Factory pattern where factory method (
178 + createIntegrator member function) creates products based on the
179 + identifier (see List.~\ref{appendixScheme:factoryDeclaration}). If
180 + the identifier has been already registered, the factory method will
181 + invoke the corresponding creator (see List.~\ref{integratorCreator})
182 + which utilizes the modern C++ template technique to avoid excess
183 + subclassing.
184 +
185 + \begin{lstlisting}[float,caption={[The implementation of Parameterized Factory pattern (I)]Source code of IntegratorFactory class.},label={appendixScheme:factoryDeclaration}]
186 +
187 + class IntegratorFactory {
188 + public:
189 +  typedef std::map<string, IntegratorCreator*> CreatorMapType;
190 +
191 +  bool registerIntegrator(IntegratorCreator* creator) {
192 +    return creatorMap_.insert(creator->getIdent(), creator).second;
193 +  }
194 +
195 +  Integrator* createIntegrator(const string& id, SimInfo* info) {
196 +    Integrator* result = NULL;
197 +    CreatorMapType::iterator i = creatorMap_.find(id);
198 +    if (i != creatorMap_.end()) {
199 +      result = (i->second)->create(info);
200 +    }
201 +    return result;
202 +  }
203 +
204 + private:
205 +  CreatorMapType creatorMap_;
206 + };
207 + \end{lstlisting}
208 +
209 + \begin{lstlisting}[float,caption={[The implementation of Parameterized Factory pattern (III)]Source code of creator classes.},label={appendixScheme:integratorCreator}]
210 +
211 + class IntegratorCreator {
212 + public:
213 +    IntegratorCreator(const string& ident) : ident_(ident) {}
214 +
215 +    const string& getIdent() const { return ident_; }
216 +
217 +    virtual Integrator* create(SimInfo* info) const = 0;
218 +
219 + private:
220 +    string ident_;
221 + };
222 +
223 + template<class ConcreteIntegrator>
224 + class IntegratorBuilder : public IntegratorCreator {
225 + public:
226 +  IntegratorBuilder(const string& ident)
227 +                   : IntegratorCreator(ident) {}
228 +  virtual  Integrator* create(SimInfo* info) const {
229 +    return new ConcreteIntegrator(info);
230 +  }
231 + };
232 + \end{lstlisting}
233 +
234   \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.
235  
236 + The visitor pattern is designed to decouple the data structure and
237 + algorithms used upon them by collecting related operation from
238 + element classes into other visitor classes, which is equivalent to
239 + adding virtual functions into a set of classes without modifying
240 + their interfaces. Fig.~\ref{appendixFig:visitorUML} demonstrates the
241 + structure of Visitor pattern which is used extensively in {\tt
242 + Dump2XYZ}. In order to convert an OOPSE dump file, a series of
243 + distinct operations are performed on different StuntDoubles (See the
244 + class hierarchy in Fig.~\ref{oopseFig:hierarchy} and the declaration
245 + in List.~\ref{appendixScheme:element}). Since the hierarchies
246 + remains stable, it is easy to define a visit operation (see
247 + List.~\ref{appendixScheme:visitor}) for each class of StuntDouble.
248 + Note that using Composite pattern\cite{Gamma1994}, CompositVisitor
249 + manages a priority visitor list and handles the execution of every
250 + visitor in the priority list on different StuntDoubles.
251 +
252 + \begin{figure}
253 + \centering
254 + \includegraphics[width=\linewidth]{visitor.eps}
255 + \caption[The UML class diagram of Visitor patten] {The UML class
256 + diagram of Visitor patten.} \label{appendixFig:visitorUML}
257 + \end{figure}
258 +
259 + \begin{figure}
260 + \centering
261 + \includegraphics[width=\linewidth]{hierarchy.eps}
262 + \caption[Class hierarchy for ojects in {\sc OOPSE}]{ A diagram of
263 + the class hierarchy. } \label{oopseFig:hierarchy}
264 + \end{figure}
265 +
266 + \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (II)]Source code of the element classes.},label={appendixScheme:element}]
267 +
268 + class StuntDouble { public:
269 +  virtual void accept(BaseVisitor* v) = 0;
270 + };
271 +
272 + class Atom: public StuntDouble { public:
273 +  virtual void accept{BaseVisitor* v*} {
274 +    v->visit(this);
275 +  }
276 + };
277 +
278 + class DirectionalAtom: public Atom { public:
279 +  virtual void accept{BaseVisitor* v*} {
280 +    v->visit(this);
281 +  }
282 + };
283 +
284 + class RigidBody: public StuntDouble { public:
285 +  virtual void accept{BaseVisitor* v*} {
286 +    v->visit(this);
287 +  }
288 + };
289 +
290 + \end{lstlisting}
291 +
292 + \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (I)]Source code of the visitor classes.},label={appendixScheme:visitor}]
293 +
294 + class BaseVisitor{
295 + public:
296 +  virtual void visit(Atom* atom);
297 +  virtual void visit(DirectionalAtom* datom);
298 +  virtual void visit(RigidBody* rb);
299 + };
300 +
301 + class BaseAtomVisitor:public BaseVisitor{ public:
302 +  virtual void visit(Atom* atom);
303 +  virtual void visit(DirectionalAtom* datom);
304 +  virtual void visit(RigidBody* rb);
305 + };
306 +
307 + class SSDAtomVisitor:public BaseAtomVisitor{ public:
308 +  virtual void visit(Atom* atom);
309 +  virtual void visit(DirectionalAtom* datom);
310 +  virtual void visit(RigidBody* rb);
311 + };
312 +
313 + class CompositeVisitor: public BaseVisitor {
314 + public:
315 +
316 +  typedef list<pair<BaseVisitor*, int> > VistorListType;
317 +  typedef VistorListType::iterator VisitorListIterator;
318 +  virtual void visit(Atom* atom) {
319 +    VisitorListIterator i;
320 +    BaseVisitor* curVisitor;
321 +    for(i = visitorList.begin();i != visitorList.end();++i) {
322 +      atom->accept(*i);
323 +    }
324 +  }
325 +
326 +  virtual void visit(DirectionalAtom* datom) {
327 +    VisitorListIterator i;
328 +    BaseVisitor* curVisitor;
329 +    for(i = visitorList.begin();i != visitorList.end();++i) {
330 +      atom->accept(*i);
331 +    }
332 +  }
333 +
334 +  virtual void visit(RigidBody* rb) {
335 +    VisitorListIterator i;
336 +    std::vector<Atom*> myAtoms;
337 +    std::vector<Atom*>::iterator ai;
338 +    myAtoms = rb->getAtoms();
339 +    for(i = visitorList.begin();i != visitorList.end();++i) {{
340 +      rb->accept(*i);
341 +      for(ai = myAtoms.begin(); ai != myAtoms.end(); ++ai){
342 +        (*ai)->accept(*i);
343 +    }
344 +  }
345 +
346 +  void addVisitor(BaseVisitor* v, int priority);
347 +
348 +  protected:
349 +    VistorListType visitorList;
350 + };
351 +
352 + \end{lstlisting}
353 +
354   \section{\label{appendixSection:concepts}Concepts}
355  
356   OOPSE manipulates both traditional atoms as well as some objects
357   that {\it behave like atoms}.  These objects can be rigid
358   collections of atoms or atoms which have orientational degrees of
359 < freedom.  Here is a diagram of the class heirarchy:
360 <
361 < %\begin{figure}
362 < %\centering
363 < %\includegraphics[width=3in]{heirarchy.eps}
364 < %\caption[Class heirarchy for StuntDoubles in {\sc oopse}-3.0]{ \\
365 < %The class heirarchy of StuntDoubles in {\sc oopse}-3.0. The
366 < %selection syntax allows the user to select any of the objects that
367 < %are descended from a StuntDouble.} \label{oopseFig:heirarchy}
154 < %\end{figure}
155 <
359 > freedom.  A diagram of the class hierarchy is illustrated in
360 > Fig.~\ref{oopseFig:hierarchy}. Every Molecule, Atom and
361 > DirectionalAtom in {\sc OOPSE} have their own names which are
362 > specified in the {\tt .md} file. In contrast, RigidBodies are
363 > denoted by their membership and index inside a particular molecule:
364 > [MoleculeName]\_RB\_[index] (the contents inside the brackets depend
365 > on the specifics of the simulation). The names of rigid bodies are
366 > generated automatically. For example, the name of the first rigid
367 > body in a DMPC molecule is DMPC\_RB\_0.
368   \begin{itemize}
369   \item A {\bf StuntDouble} is {\it any} object that can be manipulated by the
370   integrators and minimizers.
# Line 162 | Line 374 | DirectionalAtom}s which behaves as a single unit.
374   DirectionalAtom}s which behaves as a single unit.
375   \end{itemize}
376  
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 –
377   \section{\label{appendixSection:syntax}Syntax of the Select Command}
378  
379 < The most general form of the select command is: {\tt select {\it
380 < expression}}. This expression represents an arbitrary set of
177 < StuntDoubles (Atoms or RigidBodies) in {\sc OOPSE}. Expressions are
178 < composed of either name expressions, index expressions, predefined
179 < sets, user-defined expressions, comparison operators, within
180 < expressions, or logical combinations of the above expression types.
181 < Expressions can be combined using parentheses and the Boolean
182 < operators.
379 > {\sc OOPSE} provides a powerful selection utility to select
380 > StuntDoubles. The most general form of the select command is:
381  
382 + {\tt select {\it expression}}.
383 +
384 + This expression represents an arbitrary set of StuntDoubles (Atoms
385 + or RigidBodies) in {\sc OOPSE}. Expressions are composed of either
386 + name expressions, index expressions, predefined sets, user-defined
387 + expressions, comparison operators, within expressions, or logical
388 + combinations of the above expression types. Expressions can be
389 + combined using parentheses and the Boolean operators.
390 +
391   \subsection{\label{appendixSection:logical}Logical expressions}
392  
393   The logical operators allow complex queries to be constructed out of
# Line 377 | Line 584 | Fig.~\ref{oopseFig:staticPropsProcess}.
584   \centering
585   \includegraphics[width=\linewidth]{staticPropsProcess.eps}
586   \caption[A representation of the three-stage correlations in
587 < \texttt{StaticProps}]{Three-stage processing in
588 < \texttt{StaticProps}. $S_1$ and $S_2$ are the numbers of selected
589 < stuntdobules from {\tt -{}-sele1} and {\tt -{}-sele2} respectively,
590 < while $C$ is the number of stuntdobules appearing at both sets. The
591 < first stage($S_1-C$ and $S_2$) and second stages ($S_1$ and $S_2-C$)
592 < are completely non-overlapping. On the contrary, the third stage($C$
593 < and $C$) are completely overlapping}
594 < \label{oopseFig:staticPropsProcess}
587 > \texttt{StaticProps}]{This diagram illustrates three-stage
588 > processing used by \texttt{StaticProps}. $S_1$ and $S_2$ are the
589 > numbers of selected stuntdobules from {\tt -{}-sele1} and {\tt
590 > -{}-sele2} respectively, while $C$ is the number of stuntdobules
591 > appearing at both sets. The first stage($S_1-C$ and $S_2$) and
592 > second stages ($S_1$ and $S_2-C$) are completely non-overlapping. On
593 > the contrary, the third stage($C$ and $C$) are completely
594 > overlapping} \label{oopseFig:staticPropsProcess}
595   \end{figure}
596  
597   The options available for {\tt StaticProps} are as follows:
# Line 462 | Line 669 | incremented, until all frame pairs have been correlate
669   incremented and the process repeated until the end of the
670   trajectory. Once the end is reached, the first block is freed then
671   incremented, until all frame pairs have been correlated in time.
672 + This process is illustrated in
673 + Fig.~\ref{oopseFig:dynamicPropsProcess}.
674  
675 + \begin{figure}
676 + \centering
677 + \includegraphics[width=\linewidth]{dynamicPropsProcess.eps}
678 + \caption[A representation of the block correlations in
679 + \texttt{dynamicProps}]{This diagram illustrates block correlations
680 + processing in \texttt{dynamicProps}. The shaded region represents
681 + the self correlation of the block, and the open blocks are read one
682 + at a time and the cross correlations between blocks are calculated.}
683 + \label{oopseFig:dynamicPropsProcess}
684 + \end{figure}
685 +
686   The options available for DynamicProps are as follows:
687   \begin{longtable}[c]{|EFG|}
688   \caption{DynamicProps Command-line Options}
# Line 489 | Line 709 | The options available for DynamicProps are as follows:
709  
710   \subsection{\label{appendixSection:Dump2XYZ}Dump2XYZ}
711  
712 < Dump2XYZ can transform an OOPSE dump file into a xyz file which can
713 < be opened by other molecular dynamics viewers such as Jmol and
714 < VMD\cite{Humphrey1996}. The options available for Dump2XYZ are as
715 < follows:
712 > {\tt Dump2XYZ} can transform an OOPSE dump file into a xyz file
713 > which can be opened by other molecular dynamics viewers such as Jmol
714 > and VMD\cite{Humphrey1996}. The options available for Dump2XYZ are
715 > as follows:
716  
717  
718   \begin{longtable}[c]{|EFG|}
# Line 523 | Line 743 | converted. \\
743   \end{longtable}
744  
745   \subsection{\label{appendixSection:hydrodynamics}Hydro}
746 < The options available for Hydro are as follows:
746 >
747 > {\tt Hydro} can calculate resistance and diffusion tensors at the
748 > center of resistance. Both tensors at the center of diffusion can
749 > also be reported from the program, as well as the coordinates for
750 > the beads which are used to approximate the arbitrary shapes. The
751 > options available for Hydro are as follows:
752   \begin{longtable}[c]{|EFG|}
753   \caption{Hydrodynamics Command-line Options}
754   \\ \hline

Diff Legend

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