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 2813 by tim, Wed Jun 7 02:49:09 2006 UTC vs.
Revision 2880 by tim, Thu Jun 22 22:19:02 2006 UTC

# Line 1 | Line 1
1   \appendix
2 < \chapter{\label{chapt:oopse}Object-Oriented Parallel Simulation Engine (OOPSE)}
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.
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,
20 > Gay-Berne ellipsoids, or other "lumpy"atoms with orientational
21 > degrees of freedom), as well as rigid bodies.
22 >  \item {\sc OOPSE} uses a force-based decomposition algorithm using MPI on cheap
23 > Beowulf clusters to obtain very efficient parallelism.
24 >  \item {\sc OOPSE} integrates the equations of motion using advanced methods for
25 > orientational dynamics in NVE, NVT, NPT, NPAT, and NP$\gamma$T
26 > ensembles.
27 >  \item {\sc OOPSE} can carry out simulations on metallic systems using the
28 > Embedded Atom Method (EAM) as well as the Sutton-Chen potential.
29 >  \item {\sc OOPSE} can perform simulations on Gay-Berne liquid crystals.
30 >  \item  {\sc OOPSE} can simulate systems containing the extremely efficient
31 > extended-Soft Sticky Dipole (SSD/E) model for water.
32 > \end{enumerate}
33  
34   \section{\label{appendixSection:architecture }Architecture}
35  
36 + Mainly written by \texttt{C/C++} and \texttt{Fortran90}, {\sc OOPSE}
37 + uses C++ Standard Template Library (STL) and fortran modules as the
38 + foundation. As an extensive set of the STL and Fortran90 modules,
39 + {\sc Base Classes} provide generic implementations of mathematical
40 + objects (e.g., matrices, vectors, polynomials, random number
41 + generators) and advanced data structures and algorithms(e.g., tuple,
42 + bitset, generic data, string manipulation). The molecular data
43 + structures for the representation of atoms, bonds, bends, torsions,
44 + rigid bodies and molecules \textit{etc} are contained in the {\sc
45 + Kernel} which is implemented with {\sc Base Classes} and are
46 + carefully designed to provide maximum extensibility and flexibility.
47 + The functionality required for applications is provide by the third
48 + layer which contains Input/Output, Molecular Mechanics and Structure
49 + modules. Input/Output module not only implements general methods for
50 + file handling, but also defines a generic force field interface.
51 + Another important component of Input/Output module is the meta-data
52 + file parser, which is rewritten using ANother Tool for Language
53 + Recognition(ANTLR)\cite{Parr1995, Schaps1999} syntax. The Molecular
54 + Mechanics module consists of energy minimization and a wide
55 + varieties of integration methods(see Chap.~\ref{chapt:methodology}).
56 + The structure module contains a flexible and powerful selection
57 + library which syntax is elaborated in
58 + Sec.~\ref{appendixSection:syntax}. The top layer is made of the main
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 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}
68   \centering
69   \includegraphics[width=\linewidth]{architecture.eps}
70 < \caption[The architecture of {\sc oopse}-3.0] {The architecture of
71 < {\sc oopse}-3.0.} \label{appendixFig:architecture}
70 > \caption[The architecture of {\sc OOPSE}] {Overview of the structure
71 > of {\sc OOPSE}} \label{appendixFig:architecture}
72   \end{figure}
73  
74   \section{\label{appendixSection:desginPattern}Design Pattern}
# Line 37 | Line 84 | solutions succinctly.
84   reusable. They provide a ready-made solution that can be adapted to
85   different problems as necessary. Pattern are expressive. they
86   provide a common vocabulary of solutions that can express large
87 < solutions succinctly.
87 > solutions succinctly. As one of the latest advanced techniques
88 > emerged from object-oriented community, design patterns were applied
89 > in some of the modern scientific software applications, such as
90 > JMol, {\sc OOPSE}\cite{Meineke2005} and PROTOMOL\cite{Matthey2004}
91 > \textit{etc}. The following sections enumerates some of the patterns
92 > used in {\sc OOPSE}.
93  
94 < Patterns are usually described using a format that includes the
43 < following information:
44 < \begin{enumerate}
45 <  \item The \emph{name} that is commonly used for the pattern. Good pattern names form a vocabulary for
46 <  discussing conceptual abstractions. a pattern may have more than one commonly used or recognizable name
47 <  in the literature. In this case it is common practice to document these nicknames or synonyms under
48 <  the heading of \emph{Aliases} or \emph{Also Known As}.
49 <  \item The \emph{motivation} or \emph{context} that this pattern applies
50 <  to. Sometimes, it will include some prerequisites that should be satisfied before deciding to use a pattern
51 <  \item The \emph{solution} to the problem that the pattern
52 <  addresses. It describes how to construct the necessary work products. The description may include
53 <  pictures, diagrams and prose which identify the pattern's structure, its participants, and their
54 <  collaborations, to show how the problem is solved.
55 <  \item The \emph{consequences} of using the given solution to solve a
56 <  problem, both positive and negative.
57 < \end{enumerate}
94 > \subsection{\label{appendixSection:singleton}Singleton}
95  
96 < As one of the latest advanced techniques emerged from
97 < object-oriented community, design patterns were applied in some of
98 < the modern scientific software applications, such as JMol, OOPSE
99 < \cite{Meineke05} and PROTOMOL \cite{Matthey05} \textit{etc}.
96 > The Singleton pattern not only provides a mechanism to restrict
97 > instantiation of a class to one object, but also provides a global
98 > point of access to the object. Currently implemented as a global
99 > variable, the logging utility which reports error and warning
100 > messages to the console in {\sc OOPSE} is a good candidate for
101 > applying the Singleton pattern to avoid the global namespace
102 > pollution. Although the singleton pattern can be implemented in
103 > various ways  to account for different aspects of the software
104 > designs, such as lifespan control \textit{etc}, we only use the
105 > static data approach in {\sc OOPSE}. The declaration and
106 > implementation of IntegratorFactory class are given by declared in
107 > List.~\ref{appendixScheme:singletonDeclaration} and
108 > Scheme.~\ref{appendixScheme:singletonImplementation} respectively.
109 > Since constructor is declared as protected, a client can not
110 > instantiate IntegratorFactory directly. Moreover, since the member
111 > function getInstance serves as the only entry of access to
112 > IntegratorFactory, this approach fulfills the basic requirement, a
113 > single instance. Another consequence of this approach is the
114 > automatic destruction since static data are destroyed upon program
115 > termination.
116 > \begin{lstlisting}[float,caption={[A classic Singleton design pattern implementation(I)] The declaration of of simple Singleton pattern.},label={appendixScheme:singletonDeclaration}]
117  
118 < \subsection{\label{appendixSection:singleton}Singleton}
119 < The Singleton pattern ensures that only one instance of a class is
120 < created. All objects that use an instance of that class use the same
121 < instance.
118 > class IntegratorFactory {
119 > public:
120 >  static IntegratorFactory*
121 >  getInstance();
122 > protected:
123 >  IntegratorFactory();
124 > private:
125 >  static IntegratorFactory* instance_;
126 > };
127  
128 + \end{lstlisting}
129 +
130 + \begin{lstlisting}[float,caption={[A classic implementation of Singleton design pattern (II)] The implementation of simple Singleton pattern.},label={appendixScheme:singletonImplementation}]
131 +
132 + IntegratorFactory::instance_ = NULL;
133 +
134 + IntegratorFactory* getInstance() {
135 +  if (instance_ == NULL){
136 +    instance_ = new IntegratorFactory;
137 +  }
138 +  return instance_;
139 + }
140 +
141 + \end{lstlisting}
142 +
143 +
144   \subsection{\label{appendixSection:factoryMethod}Factory Method}
70 – The Factory Method pattern is a creational pattern which deals with
71 – the problem of creating objects without specifying the exact class
72 – of object that will be created. Factory Method solves this problem
73 – by defining a separate method for creating the objects, which
74 – subclasses can then override to specify the derived type of product
75 – that will be created.
145  
146 + Categoried as a creational pattern, the Factory Method pattern deals
147 + with the problem of creating objects without specifying the exact
148 + class of object that will be created. Factory Method is typically
149 + implemented by delegating the creation operation to the subclasses.
150 + Parameterized Factory pattern where factory method (
151 + createIntegrator member function) creates products based on the
152 + identifier (see Scheme.~\ref{appendixScheme:factoryDeclaration}). If
153 + the identifier has been already registered, the factory method will
154 + invoke the corresponding creator (see
155 + Scheme.~\ref{appendixScheme:integratorCreator}) which utilizes the
156 + modern C++ template technique to avoid excess subclassing.
157  
158 < \subsection{\label{appendixSection:visitorPattern}Visitor}
79 < The purpose of the Visitor Pattern is to encapsulate an operation
80 < that you want to perform on the elements of a data structure. In
81 < this way, you can change the operation being performed on a
82 < structure without the need of changing the classes of the elements
83 < that you are operating on.
158 > \begin{lstlisting}[float,caption={[The implementation of Parameterized Factory pattern (I)]Source code of IntegratorFactory class.},label={appendixScheme:factoryDeclaration}]
159  
160 + class IntegratorFactory {
161 + public:
162 +  typedef std::map<string, IntegratorCreator*> CreatorMapType;
163  
164 < \subsection{\label{appendixSection:templateMethod}Template Method}
164 >  bool registerIntegrator(IntegratorCreator* creator) {
165 >    return creatorMap_.insert(creator->getIdent(), creator).second;
166 >  }
167 >
168 >  Integrator* createIntegrator(const string& id, SimInfo* info) {
169 >    Integrator* result = NULL;
170 >    CreatorMapType::iterator i = creatorMap_.find(id);
171 >    if (i != creatorMap_.end()) {
172 >      result = (i->second)->create(info);
173 >    }
174 >    return result;
175 >  }
176 >
177 > private:
178 >  CreatorMapType creatorMap_;
179 > };
180 > \end{lstlisting}
181 >
182 > \begin{lstlisting}[float,caption={[The implementation of Parameterized Factory pattern (III)]Source code of creator classes.},label={appendixScheme:integratorCreator}]
183 >
184 > class IntegratorCreator {
185 > public:
186 >    IntegratorCreator(const string& ident) : ident_(ident) {}
187 >
188 >    const string& getIdent() const { return ident_; }
189 >
190 >    virtual Integrator* create(SimInfo* info) const = 0;
191 >
192 > private:
193 >    string ident_;
194 > };
195 >
196 > template<class ConcreteIntegrator>
197 > class IntegratorBuilder : public IntegratorCreator {
198 > public:
199 >  IntegratorBuilder(const string& ident)
200 >                   : IntegratorCreator(ident) {}
201 >  virtual  Integrator* create(SimInfo* info) const {
202 >    return new ConcreteIntegrator(info);
203 >  }
204 > };
205 > \end{lstlisting}
206 >
207 > \subsection{\label{appendixSection:visitorPattern}Visitor}
208  
209 + The visitor pattern is designed to decouple the data structure and
210 + algorithms used upon them by collecting related operation from
211 + element classes into other visitor classes, which is equivalent to
212 + adding virtual functions into a set of classes without modifying
213 + their interfaces. Fig.~\ref{appendixFig:visitorUML} demonstrates the
214 + structure of Visitor pattern which is used extensively in {\tt
215 + Dump2XYZ}. In order to convert an OOPSE dump file, a series of
216 + distinct operations are performed on different StuntDoubles (See the
217 + class hierarchy in Fig.~\ref{oopseFig:hierarchy} and the declaration
218 + in Scheme.~\ref{appendixScheme:element}). Since the hierarchies
219 + remains stable, it is easy to define a visit operation (see
220 + Scheme.~\ref{appendixScheme:visitor}) for each class of StuntDouble.
221 + Note that using Composite pattern\cite{Gamma1994}, CompositVisitor
222 + manages a priority visitor list and handles the execution of every
223 + visitor in the priority list on different StuntDoubles.
224 +
225 + \begin{figure}
226 + \centering
227 + \includegraphics[width=\linewidth]{visitor.eps}
228 + \caption[The UML class diagram of Visitor patten] {The UML class
229 + diagram of Visitor patten.} \label{appendixFig:visitorUML}
230 + \end{figure}
231 +
232 + \begin{figure}
233 + \centering
234 + \includegraphics[width=\linewidth]{hierarchy.eps}
235 + \caption[Class hierarchy for ojects in {\sc OOPSE}]{ A diagram of
236 + the class hierarchy. } \label{oopseFig:hierarchy}
237 + \end{figure}
238 +
239 + \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (II)]Source code of the element classes.},label={appendixScheme:element}]
240 +
241 + class StuntDouble { public:
242 +  virtual void accept(BaseVisitor* v) = 0;
243 + };
244 +
245 + class Atom: public StuntDouble { public:
246 +  virtual void accept{BaseVisitor* v*} {
247 +    v->visit(this);
248 +  }
249 + };
250 +
251 + class DirectionalAtom: public Atom { public:
252 +  virtual void accept{BaseVisitor* v*} {
253 +    v->visit(this);
254 +  }
255 + };
256 +
257 + class RigidBody: public StuntDouble { public:
258 +  virtual void accept{BaseVisitor* v*} {
259 +    v->visit(this);
260 +  }
261 + };
262 +
263 + \end{lstlisting}
264 +
265 + \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (I)]Source code of the visitor classes.},label={appendixScheme:visitor}]
266 +
267 + class BaseVisitor{
268 + public:
269 +  virtual void visit(Atom* atom);
270 +  virtual void visit(DirectionalAtom* datom);
271 +  virtual void visit(RigidBody* rb);
272 + };
273 +
274 + class BaseAtomVisitor:public BaseVisitor{ public:
275 +  virtual void visit(Atom* atom);
276 +  virtual void visit(DirectionalAtom* datom);
277 +  virtual void visit(RigidBody* rb);
278 + };
279 +
280 + class CompositeVisitor: public BaseVisitor {
281 + public:
282 +
283 +  typedef list<pair<BaseVisitor*, int> > VistorListType;
284 +  typedef VistorListType::iterator VisitorListIterator;
285 +  virtual void visit(Atom* atom) {
286 +    VisitorListIterator i;
287 +    BaseVisitor* curVisitor;
288 +    for(i = visitorScheme.begin();i != visitorScheme.end();++i) {
289 +      atom->accept(*i);
290 +    }
291 +  }
292 +
293 +  virtual void visit(DirectionalAtom* datom) {
294 +    VisitorListIterator i;
295 +    BaseVisitor* curVisitor;
296 +    for(i = visitorScheme.begin();i != visitorScheme.end();++i) {
297 +      atom->accept(*i);
298 +    }
299 +  }
300 +
301 +  virtual void visit(RigidBody* rb) {
302 +    VisitorListIterator i;
303 +    std::vector<Atom*> myAtoms;
304 +    std::vector<Atom*>::iterator ai;
305 +    myAtoms = rb->getAtoms();
306 +    for(i = visitorScheme.begin();i != visitorScheme.end();++i) {{
307 +      rb->accept(*i);
308 +      for(ai = myAtoms.begin(); ai != myAtoms.end(); ++ai){
309 +        (*ai)->accept(*i);
310 +    }
311 +  }
312 +
313 +  void addVisitor(BaseVisitor* v, int priority);
314 +
315 +  protected:
316 +    VistorListType visitorList;
317 + };
318 + \end{lstlisting}
319 +
320   \section{\label{appendixSection:concepts}Concepts}
321  
322   OOPSE manipulates both traditional atoms as well as some objects
323   that {\it behave like atoms}.  These objects can be rigid
324   collections of atoms or atoms which have orientational degrees of
325 < freedom.  Here is a diagram of the class heirarchy:
326 <
327 < %\begin{figure}
328 < %\centering
329 < %\includegraphics[width=3in]{heirarchy.eps}
330 < %\caption[Class heirarchy for StuntDoubles in {\sc oopse}-3.0]{ \\
331 < %The class heirarchy of StuntDoubles in {\sc oopse}-3.0. The
332 < %selection syntax allows the user to select any of the objects that
333 < %are descended from a StuntDouble.} \label{oopseFig:heirarchy}
102 < %\end{figure}
103 <
325 > freedom.  A diagram of the class hierarchy is illustrated in
326 > Fig.~\ref{oopseFig:hierarchy}. Every Molecule, Atom and
327 > DirectionalAtom in {\sc OOPSE} have their own names which are
328 > specified in the {\tt .md} file. In contrast, RigidBodies are
329 > denoted by their membership and index inside a particular molecule:
330 > [MoleculeName]\_RB\_[index] (the contents inside the brackets depend
331 > on the specifics of the simulation). The names of rigid bodies are
332 > generated automatically. For example, the name of the first rigid
333 > body in a DMPC molecule is DMPC\_RB\_0.
334   \begin{itemize}
335   \item A {\bf StuntDouble} is {\it any} object that can be manipulated by the
336   integrators and minimizers.
# Line 110 | Line 340 | Every Molecule, Atom and DirectionalAtom in {\sc oopse
340   DirectionalAtom}s which behaves as a single unit.
341   \end{itemize}
342  
113 – Every Molecule, Atom and DirectionalAtom in {\sc oopse} have their
114 – own names which are specified in the {\tt .md} file. In contrast,
115 – RigidBodies are denoted by their membership and index inside a
116 – particular molecule: [MoleculeName]\_RB\_[index] (the contents
117 – inside the brackets depend on the specifics of the simulation). The
118 – names of rigid bodies are generated automatically. For example, the
119 – name of the first rigid body in a DMPC molecule is DMPC\_RB\_0.
120 –
343   \section{\label{appendixSection:syntax}Syntax of the Select Command}
344  
345 < The most general form of the select command is: {\tt select {\it
346 < expression}}
345 > {\sc OOPSE} provides a powerful selection utility to select
346 > StuntDoubles. The most general form of the select command is:
347  
348 + {\tt select {\it expression}}.
349 +
350   This expression represents an arbitrary set of StuntDoubles (Atoms
351 < or RigidBodies) in {\sc oopse}. Expressions are composed of either
351 > or RigidBodies) in {\sc OOPSE}. Expressions are composed of either
352   name expressions, index expressions, predefined sets, user-defined
353   expressions, comparison operators, within expressions, or logical
354   combinations of the above expression types. Expressions can be
# Line 211 | Line 435 | expression}}
435   Users can define arbitrary terms to represent groups of
436   StuntDoubles, and then use the define terms in select commands. The
437   general form for the define command is: {\bf define {\it term
438 < expression}}
438 > expression}}. Once defined, the user can specify such terms in
439 > boolean expressions
440  
216 – Once defined, the user can specify such terms in boolean expressions
217 –
441   {\tt define SSDWATER SSD or SSD1 or SSDRF}
442  
443   {\tt select SSDWATER}
# Line 259 | Line 482 | and other atoms of type $B$, $g_{AB}(r)$.  StaticProps
482   some or all of the configurations that are contained within a dump
483   file. The most common example of a static property that can be
484   computed is the pair distribution function between atoms of type $A$
485 < and other atoms of type $B$, $g_{AB}(r)$.  StaticProps can also be
486 < used to compute the density distributions of other molecules in a
487 < reference frame {\it fixed to the body-fixed reference frame} of a
488 < selected atom or rigid body.
485 > and other atoms of type $B$, $g_{AB}(r)$.  {\tt StaticProps} can
486 > also be used to compute the density distributions of other molecules
487 > in a reference frame {\it fixed to the body-fixed reference frame}
488 > of a selected atom or rigid body. Due to the fact that the selected
489 > StuntDoubles from two selections may be overlapped, {\tt
490 > StaticProps} performs the calculation in three stages which are
491 > illustrated in Fig.~\ref{oopseFig:staticPropsProcess}.
492 >
493 > \begin{figure}
494 > \centering
495 > \includegraphics[width=\linewidth]{staticPropsProcess.eps}
496 > \caption[A representation of the three-stage correlations in
497 > \texttt{StaticProps}]{This diagram illustrates three-stage
498 > processing used by \texttt{StaticProps}. $S_1$ and $S_2$ are the
499 > numbers of selected stuntdobules from {\tt -{}-sele1} and {\tt
500 > -{}-sele2} respectively, while $C$ is the number of stuntdobules
501 > appearing at both sets. The first stage($S_1-C$ and $S_2$) and
502 > second stages ($S_1$ and $S_2-C$) are completely non-overlapping. On
503 > the contrary, the third stage($C$ and $C$) are completely
504 > overlapping} \label{oopseFig:staticPropsProcess}
505 > \end{figure}
506  
507   There are five seperate radial distribution functions availiable in
508   OOPSE. Since every radial distrbution function invlove the
# Line 307 | Line 547 | distribution functions are most easily seen in the fig
547   \end{description}
548  
549   The vectors (and angles) associated with these angular pair
550 < distribution functions are most easily seen in the figure below:
550 > distribution functions are most easily seen in
551 > Fig.~\ref{oopseFig:gofr}
552  
553   \begin{figure}
554   \centering
# Line 379 | Line 620 | The options available for DynamicProps are as follows:
620   different vectors).  The ability to use two selection scripts to
621   select different types of atoms is already present in the code.
622  
623 + For large simulations, the trajectory files can sometimes reach
624 + sizes in excess of several gigabytes. In order to prevent a
625 + situation where the program runs out of memory due to large
626 + trajectories, \texttt{dynamicProps} will estimate the size of free
627 + memory at first, and determine the number of frames in each block,
628 + which allows the operating system to load two blocks of data
629 + simultaneously without swapping. Upon reading two blocks of the
630 + trajectory, \texttt{dynamicProps} will calculate the time
631 + correlation within the first block and the cross correlations
632 + between the two blocks. This second block is then freed and then
633 + incremented and the process repeated until the end of the
634 + trajectory. Once the end is reached, the first block is freed then
635 + incremented, until all frame pairs have been correlated in time.
636 + This process is illustrated in
637 + Fig.~\ref{oopseFig:dynamicPropsProcess}.
638 +
639 + \begin{figure}
640 + \centering
641 + \includegraphics[width=\linewidth]{dynamicPropsProcess.eps}
642 + \caption[A representation of the block correlations in
643 + \texttt{dynamicProps}]{This diagram illustrates block correlations
644 + processing in \texttt{dynamicProps}. The shaded region represents
645 + the self correlation of the block, and the open blocks are read one
646 + at a time and the cross correlations between blocks are calculated.}
647 + \label{oopseFig:dynamicPropsProcess}
648 + \end{figure}
649 +
650   The options available for DynamicProps are as follows:
651   \begin{longtable}[c]{|EFG|}
652   \caption{DynamicProps Command-line Options}
# Line 405 | Line 673 | Dump2XYZ can transform an OOPSE dump file into a xyz f
673  
674   \subsection{\label{appendixSection:Dump2XYZ}Dump2XYZ}
675  
676 < Dump2XYZ can transform an OOPSE dump file into a xyz file which can
677 < be opened by other molecular dynamics viewers such as Jmol and VMD.
678 < The options available for Dump2XYZ are as follows:
676 > {\tt Dump2XYZ} can transform an OOPSE dump file into a xyz file
677 > which can be opened by other molecular dynamics viewers such as Jmol
678 > and VMD\cite{Humphrey1996}. The options available for Dump2XYZ are
679 > as follows:
680  
681  
682   \begin{longtable}[c]{|EFG|}
# Line 437 | Line 706 | converted. \\
706       & {\tt -{}-refsele} &  In order to rotate the system, {\tt -{}-originsele} and {\tt -{}-refsele} must be given to define the new coordinate set. A StuntDouble which contains a dipole (the direction of the dipole is always (0, 0, 1) in body frame) is specified by {\tt -{}-originsele}. The new x-z plane is defined by the direction of the dipole and the StuntDouble is specified by {\tt -{}-refsele}.
707   \end{longtable}
708  
709 < \subsection{\label{appendixSection:hydrodynamics}Hydrodynamics}
709 > \subsection{\label{appendixSection:hydrodynamics}Hydro}
710  
711 + {\tt Hydro} can calculate resistance and diffusion tensors at the
712 + center of resistance. Both tensors at the center of diffusion can
713 + also be reported from the program, as well as the coordinates for
714 + the beads which are used to approximate the arbitrary shapes. The
715 + options available for Hydro are as follows:
716   \begin{longtable}[c]{|EFG|}
717   \caption{Hydrodynamics Command-line Options}
718   \\ \hline
# Line 451 | Line 725 | converted. \\
725    -i & {\tt -{}-input}  &             input dump file \\
726    -o & {\tt -{}-output} &             output file prefix  (default=`hydro') \\
727    -b & {\tt -{}-beads}  &                   generate the beads only, hydrodynamics calculation will not be performed (default=off)\\
728 <     & {\tt -{}-model}  &                 hydrodynamics model (support ``AnalyticalModel'', ``RoughShell'' and ``BeadModel'') \\
728 >     & {\tt -{}-model}  &                 hydrodynamics model (supports ``AnalyticalModel'', ``RoughShell'' and ``BeadModel'') \\
729   \end{longtable}

Diff Legend

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