ViewVC Help
View File | Revision Log | Show Annotations | View Changeset | Root Listing
root/group/trunk/tengDissertation/Appendix.tex
Revision: 2883
Committed: Sun Jun 25 17:39:42 2006 UTC (18 years ago) by tim
Content type: application/x-tex
File size: 31533 byte(s)
Log Message:
more corrections

File Contents

# Content
1 \appendix
2 \chapter{\label{chapt:oopse}Object-Oriented Parallel Simulation Engine}
3
4 The absence of modern software development practices has been a
5 bottleneck limiting progress in the Scientific Computing
6 community\cite{Wilson2006}. In the last 20 years , a large number of
7 few MD packages\cite{Brooks1983, Vincent1995, Kale1999} were
8 developed to solve common MD problems and perform robust simulations
9 . Most of these are commercial programs that are either poorly
10 written or extremely complicated to use correctly. This situation
11 prevents researchers from reusing or extending those packages to do
12 cutting-edge research effectively. In the process of studying
13 structural and dynamic processes in condensed phase systems like
14 biological 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 C++ and Fortran90, {\sc OOPSE} uses C++ Standard
37 Template Library (STL) and fortran modules as a foundation. As an
38 extensive set of the STL and Fortran90 modules, {\sc Base Classes}
39 provide generic implementations of mathematical objects (e.g.,
40 matrices, vectors, polynomials, random number generators) and
41 advanced data structures and algorithms(e.g., tuple, bitset, generic
42 data and string manipulation). The molecular data structures for the
43 representation of atoms, bonds, bends, torsions, rigid bodies and
44 molecules \textit{etc} are contained in the {\sc Kernel} which is
45 implemented with {\sc Base Classes} and are carefully designed to
46 provide maximum extensibility and flexibility. The functionality
47 required for applications is provided by the third layer which
48 contains Input/Output, Molecular Mechanics and Structure modules.
49 The Input/Output module not only implements general methods for file
50 handling, but also defines a generic force field interface. Another
51 important component of Input/Output module is the parser for
52 meta-data files, which has been implemented using the ANother Tool
53 for Language Recognition(ANTLR)\cite{Parr1995, Schaps1999} syntax.
54 The Molecular Mechanics module consists of energy minimization and a
55 wide varieties of integration methods(see
56 Chap.~\ref{chapt:methodology}). The structure module contains a
57 flexible and powerful selection library which syntax is elaborated
58 in Sec.~\ref{appendixSection:syntax}. The top layer is made of the
59 main program of the package, \texttt{oopse} and it corresponding
60 parallel version \texttt{oopse\_MPI}, as well as other useful
61 utilities, such as \texttt{StatProps} (see
62 Sec.~\ref{appendixSection:StaticProps}), \texttt{DynamicProps} (see
63 Sec.~\ref{appendixSection:DynamicProps}), \texttt{Dump2XYZ} (see
64 Sec.~\ref{appendixSection:Dump2XYZ}), \texttt{Hydro} (see
65 Sec.~\ref{appendixSection:hydrodynamics}) \textit{etc}.
66
67 \begin{figure}
68 \centering
69 \includegraphics[width=\linewidth]{architecture.eps}
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 Patterns}
75
76 Design patterns are optimal solutions to commonly-occurring problems
77 in software design. Although originated as an architectural concept
78 for buildings and towns by Christopher Alexander
79 \cite{Alexander1987}, software patterns first became popular with
80 the wide acceptance of the book, Design Patterns: Elements of
81 Reusable Object-Oriented Software \cite{Gamma1994}. Patterns reflect
82 the experience, knowledge and insights of developers who have
83 successfully used these patterns in their own work. Patterns are
84 reusable. They provide a ready-made solution that can be adapted to
85 different problems as necessary. As one of the latest advanced
86 techniques to emerge from object-oriented community, design patterns
87 were applied in some of the modern scientific software applications,
88 such as JMol, {\sc OOPSE}\cite{Meineke2005} and
89 PROTOMOL\cite{Matthey2004} \textit{etc}. The following sections
90 enumerates some of the patterns used in {\sc OOPSE}.
91
92 \subsection{\label{appendixSection:singleton}Singletons}
93
94 The Singleton pattern not only provides a mechanism to restrict
95 instantiation of a class to one object, but also provides a global
96 point of access to the object. Although the singleton pattern can be
97 implemented in various ways to account for different aspects of the
98 software designs, such as lifespan control \textit{etc}, we only use
99 the static data approach in {\sc OOPSE}. The declaration and
100 implementation of IntegratorFactory class are given by declared in
101 List.~\ref{appendixScheme:singletonDeclaration} and
102 Scheme.~\ref{appendixScheme:singletonImplementation} respectively.
103 Since the constructor is declared as protected, a client can not
104 instantiate IntegratorFactory directly. Moreover, since the member
105 function getInstance serves as the only entry of access to
106 IntegratorFactory, this approach fulfills the basic requirement, a
107 single instance. Another consequence of this approach is the
108 automatic destruction since static data are destroyed upon program
109 termination.
110
111 \subsection{\label{appendixSection:factoryMethod}Factory Methods}
112
113 The Factory Method pattern is a creational pattern and deals with
114 the problem of creating objects without specifying the exact class
115 of object that will be created. Factory method is typically
116 implemented by delegating the creation operation to the subclasses.
117 One of the most popular Factory pattern is Parameterized Factory
118 pattern which creates products based on their identifiers (see
119 Scheme.~\ref{appendixScheme:factoryDeclaration}). If the identifier
120 has been already registered, the factory method will invoke the
121 corresponding creator (see
122 Scheme.~\ref{appendixScheme:integratorCreator}) which utilizes the
123 modern C++ template technique to avoid excess subclassing.
124
125 \subsection{\label{appendixSection:visitorPattern}Visitor}
126
127 The visitor pattern is designed to decouple the data structure and
128 algorithms used upon them by collecting related operation from
129 element classes into other visitor classes, which is equivalent to
130 adding virtual functions into a set of classes without modifying
131 their interfaces. Fig.~\ref{appendixFig:visitorUML} demonstrates the
132 structure of a Visitor pattern which is used extensively in {\tt
133 Dump2XYZ}. In order to convert an OOPSE dump file, a series of
134 distinct operations are performed on different StuntDoubles (See the
135 class hierarchy in Fig.~\ref{oopseFig:hierarchy} and the declaration
136 in Scheme.~\ref{appendixScheme:element}). Since the hierarchies
137 remain stable, it is easy to define a visit operation (see
138 Scheme.~\ref{appendixScheme:visitor}) for each class of StuntDouble.
139 Note that using Composite pattern\cite{Gamma1994}, CompositeVisitor
140 manages a priority visitor list and handles the execution of every
141 visitor in the priority list on different StuntDoubles.
142
143 \begin{lstlisting}[float,caption={[A classic Singleton design pattern implementation(I)] The declaration of of simple Singleton pattern.},label={appendixScheme:singletonDeclaration}]
144
145 class IntegratorFactory { public:
146 static IntegratorFactory* getInstance(); protected:
147 IntegratorFactory();
148 private:
149 static IntegratorFactory* instance_;
150 };
151
152 \end{lstlisting}
153
154 \begin{lstlisting}[float,caption={[A classic implementation of Singleton design pattern (II)] The implementation of simple Singleton pattern.},label={appendixScheme:singletonImplementation}]
155
156 IntegratorFactory::instance_ = NULL;
157
158 IntegratorFactory* getInstance() {
159 if (instance_ == NULL){
160 instance_ = new IntegratorFactory;
161 }
162 return instance_;
163 }
164
165 \end{lstlisting}
166
167 \begin{lstlisting}[float,caption={[The implementation of Parameterized Factory pattern (I)]Source code of IntegratorFactory class.},label={appendixScheme:factoryDeclaration}]
168
169 class IntegratorFactory { public:
170 typedef std::map<string, IntegratorCreator*> CreatorMapType;
171
172 bool registerIntegrator(IntegratorCreator* creator) {
173 return creatorMap_.insert(creator->getIdent(), creator).second;
174 }
175
176 Integrator* createIntegrator(const string& id, SimInfo* info) {
177 Integrator* result = NULL;
178 CreatorMapType::iterator i = creatorMap_.find(id);
179 if (i != creatorMap_.end()) {
180 result = (i->second)->create(info);
181 }
182 return result;
183 }
184
185 private:
186 CreatorMapType creatorMap_;
187 };
188 \end{lstlisting}
189
190 \begin{lstlisting}[float,caption={[The implementation of Parameterized Factory pattern (III)]Source code of creator classes.},label={appendixScheme:integratorCreator}]
191
192 class IntegratorCreator {
193 public:
194 IntegratorCreator(const string& ident) : ident_(ident) {}
195
196 const string& getIdent() const { return ident_; }
197
198 virtual Integrator* create(SimInfo* info) const = 0;
199
200 private:
201 string ident_;
202 };
203
204 template<class ConcreteIntegrator> class IntegratorBuilder : public
205 IntegratorCreator {
206 public:
207 IntegratorBuilder(const string& ident)
208 : IntegratorCreator(ident) {}
209 virtual Integrator* create(SimInfo* info) const {
210 return new ConcreteIntegrator(info);
211 }
212 };
213 \end{lstlisting}
214
215 \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (II)]Source code of the element classes.},label={appendixScheme:element}]
216
217 class StuntDouble {
218 public:
219 virtual void accept(BaseVisitor* v) = 0;
220 };
221
222 class Atom: public StuntDouble {
223 public:
224 virtual void accept{BaseVisitor* v*} {
225 v->visit(this);
226 }
227 };
228
229 class DirectionalAtom: public Atom {
230 public:
231 virtual void accept{BaseVisitor* v*} {
232 v->visit(this);
233 }
234 };
235
236 class RigidBody: public StuntDouble {
237 public:
238 virtual void accept{BaseVisitor* v*} {
239 v->visit(this);
240 }
241 };
242
243 \end{lstlisting}
244
245 \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (I)]Source code of the visitor classes.},label={appendixScheme:visitor}]
246
247 class BaseVisitor{
248 public:
249 virtual void visit(Atom* atom);
250 virtual void visit(DirectionalAtom* datom);
251 virtual void visit(RigidBody* rb);
252 };
253
254 class BaseAtomVisitor:public BaseVisitor{
255 public:
256 virtual void visit(Atom* atom);
257 virtual void visit(DirectionalAtom* datom);
258 virtual void visit(RigidBody* rb);
259 };
260
261 class CompositeVisitor: public BaseVisitor {
262 public:
263 typedef list<pair<BaseVisitor*, int> > VistorListType;
264 typedef VistorListType::iterator VisitorListIterator;
265 virtual void visit(Atom* atom) {
266 VisitorListIterator i;
267 BaseVisitor* curVisitor;
268 for(i = visitorScheme.begin();i != visitorScheme.end();++i) {
269 atom->accept(*i);
270 }
271 }
272
273 virtual void visit(DirectionalAtom* datom) {
274 VisitorListIterator i;
275 BaseVisitor* curVisitor;
276 for(i = visitorScheme.begin();i != visitorScheme.end();++i) {
277 atom->accept(*i);
278 }
279 }
280
281 virtual void visit(RigidBody* rb) {
282 VisitorListIterator i;
283 std::vector<Atom*> myAtoms;
284 std::vector<Atom*>::iterator ai;
285 myAtoms = rb->getAtoms();
286 for(i = visitorScheme.begin();i != visitorScheme.end();++i) {
287 rb->accept(*i);
288 for(ai = myAtoms.begin(); ai != myAtoms.end(); ++ai){
289 (*ai)->accept(*i);
290 }
291 }
292
293 void addVisitor(BaseVisitor* v, int priority);
294 protected:
295 VistorListType visitorList;
296 };
297 \end{lstlisting}
298
299 \begin{figure}
300 \centering
301 \includegraphics[width=\linewidth]{visitor.eps}
302 \caption[The UML class diagram of Visitor patten] {The UML class
303 diagram of Visitor patten.} \label{appendixFig:visitorUML}
304 \end{figure}
305
306 \begin{figure}
307 \centering
308 \includegraphics[width=\linewidth]{hierarchy.eps}
309 \caption[Class hierarchy for ojects in {\sc OOPSE}]{ A diagram of
310 the class hierarchy. Objects below others on the diagram inherit
311 data structures and functions from their parent classes above them.}
312 \label{oopseFig:hierarchy}
313 \end{figure}
314
315 \section{\label{appendixSection:concepts}Concepts}
316
317 OOPSE manipulates both traditional atoms as well as some objects
318 that {\it behave like atoms}. These objects can be rigid
319 collections of atoms or atoms which have orientational degrees of
320 freedom. A diagram of the class hierarchy is illustrated in
321 Fig.~\ref{oopseFig:hierarchy}. Every Molecule, Atom and
322 DirectionalAtom in {\sc OOPSE} have their own names which are
323 specified in the meta data file. In contrast, RigidBodies are
324 denoted by their membership and index inside a particular molecule:
325 [MoleculeName]\_RB\_[index] (the contents inside the brackets depend
326 on the specifics of the simulation). The names of rigid bodies are
327 generated automatically. For example, the name of the first rigid
328 body in a DMPC molecule is DMPC\_RB\_0.
329 \begin{itemize}
330 \item A {\bf StuntDouble} is {\it any} object that can be manipulated by the
331 integrators and minimizers.
332 \item An {\bf Atom} is a fundamental point-particle that can be moved around during a simulation.
333 \item A {\bf DirectionalAtom} is an atom which has {\it orientational} as well as translational degrees of freedom.
334 \item A {\bf RigidBody} is a collection of {\bf Atom}s or {\bf
335 DirectionalAtom}s which behaves as a single unit.
336 \end{itemize}
337
338 \section{\label{appendixSection:syntax}Syntax of the Select Command}
339
340 {\sc OOPSE} provides a powerful selection utility to select
341 StuntDoubles. The most general form of the select command is:
342
343 {\tt select {\it expression}}.
344
345 This expression represents an arbitrary set of StuntDoubles (Atoms
346 or RigidBodies) in {\sc OOPSE}. Expressions are composed of either
347 name expressions, index expressions, predefined sets, user-defined
348 expressions, comparison operators, within expressions, or logical
349 combinations of the above expression types. Expressions can be
350 combined using parentheses and the Boolean operators.
351
352 \subsection{\label{appendixSection:logical}Logical expressions}
353
354 The logical operators allow complex queries to be constructed out of
355 simpler ones using the standard boolean connectives {\bf and}, {\bf
356 or}, {\bf not}. Parentheses can be used to alter the precedence of
357 the operators.
358
359 \begin{center}
360 \begin{tabular}{|ll|}
361 \hline
362 {\bf logical operator} & {\bf equivalent operator} \\
363 \hline
364 and & ``\&'', ``\&\&'' \\
365 or & ``$|$'', ``$||$'', ``,'' \\
366 not & ``!'' \\
367 \hline
368 \end{tabular}
369 \end{center}
370
371 \subsection{\label{appendixSection:name}Name expressions}
372
373 \begin{center}
374 \begin{tabular}{|llp{2in}|}
375 \hline {\bf type of expression} & {\bf examples} & {\bf translation
376 of
377 examples} \\
378 \hline expression without ``.'' & select DMPC & select all
379 StuntDoubles
380 belonging to all DMPC molecules \\
381 & select C* & select all atoms which have atom types beginning with C
382 \\
383 & select DMPC\_RB\_* & select all RigidBodies in DMPC molecules (but
384 only select the rigid bodies, and not the atoms belonging to them). \\
385 \hline expression has one ``.'' & select TIP3P.O\_TIP3P & select the
386 O\_TIP3P
387 atoms belonging to TIP3P molecules \\
388 & select DMPC\_RB\_O.PO4 & select the PO4 atoms belonging to
389 the first
390 RigidBody in each DMPC molecule \\
391 & select DMPC.20 & select the twentieth StuntDouble in each DMPC
392 molecule \\
393 \hline expression has two ``.''s & select DMPC.DMPC\_RB\_?.* &
394 select all atoms
395 belonging to all rigid bodies within all DMPC molecules \\
396 \hline
397 \end{tabular}
398 \end{center}
399
400 \subsection{\label{appendixSection:index}Index expressions}
401
402 \begin{center}
403 \begin{tabular}{|lp{4in}|}
404 \hline
405 {\bf examples} & {\bf translation of examples} \\
406 \hline
407 select 20 & select all of the StuntDoubles belonging to Molecule 20 \\
408 select 20 to 30 & select all of the StuntDoubles belonging to
409 molecules which have global indices between 20 (inclusive) and 30
410 (exclusive) \\
411 \hline
412 \end{tabular}
413 \end{center}
414
415 \subsection{\label{appendixSection:predefined}Predefined sets}
416
417 \begin{center}
418 \begin{tabular}{|ll|}
419 \hline
420 {\bf keyword} & {\bf description} \\
421 \hline
422 all & select all StuntDoubles \\
423 none & select none of the StuntDoubles \\
424 \hline
425 \end{tabular}
426 \end{center}
427
428 \subsection{\label{appendixSection:userdefined}User-defined expressions}
429
430 Users can define arbitrary terms to represent groups of
431 StuntDoubles, and then use the define terms in select commands. The
432 general form for the define command is: {\bf define {\it term
433 expression}}. Once defined, the user can specify such terms in
434 boolean expressions
435
436 {\tt define SSDWATER SSD or SSD1 or SSDRF}
437
438 {\tt select SSDWATER}
439
440 \subsection{\label{appendixSection:comparison}Comparison expressions}
441
442 StuntDoubles can be selected by using comparision operators on their
443 properties. The general form for the comparison command is: a
444 property name, followed by a comparision operator and then a number.
445
446 \begin{center}
447 \begin{tabular}{|l|l|}
448 \hline
449 {\bf property} & mass, charge \\
450 {\bf comparison operator} & ``$>$'', ``$<$'', ``$=$'', ``$>=$'',
451 ``$<=$'', ``$!=$'' \\
452 \hline
453 \end{tabular}
454 \end{center}
455
456 For example, the phrase {\tt select mass > 16.0 and charge < -2}
457 would select StuntDoubles which have mass greater than 16.0 and
458 charges less than -2.
459
460 \subsection{\label{appendixSection:within}Within expressions}
461
462 The ``within'' keyword allows the user to select all StuntDoubles
463 within the specified distance (in Angstroms) from a selection,
464 including the selected atom itself. The general form for within
465 selection is: {\tt select within(distance, expression)}
466
467 For example, the phrase {\tt select within(2.5, PO4 or NC4)} would
468 select all StuntDoubles which are within 2.5 angstroms of PO4 or NC4
469 atoms.
470
471
472 \section{\label{appendixSection:analysisFramework}Analysis Framework}
473
474 \subsection{\label{appendixSection:StaticProps}StaticProps}
475
476 {\tt StaticProps} can compute properties which are averaged over
477 some or all of the configurations that are contained within a dump
478 file. The most common example of a static property that can be
479 computed is the pair distribution function between atoms of type $A$
480 and other atoms of type $B$, $g_{AB}(r)$. {\tt StaticProps} can
481 also be used to compute the density distributions of other molecules
482 in a reference frame {\it fixed to the body-fixed reference frame}
483 of a selected atom or rigid body. Due to the fact that the selected
484 StuntDoubles from two selections may be overlapped, {\tt
485 StaticProps} performs the calculation in three stages which are
486 illustrated in Fig.~\ref{oopseFig:staticPropsProcess}.
487
488 \begin{figure}
489 \centering
490 \includegraphics[width=\linewidth]{staticPropsProcess.eps}
491 \caption[A representation of the three-stage correlations in
492 \texttt{StaticProps}]{This diagram illustrates three-stage
493 processing used by \texttt{StaticProps}. $S_1$ and $S_2$ are the
494 numbers of selected StuntDobules from {\tt -{}-sele1} and {\tt
495 -{}-sele2} respectively, while $C$ is the number of StuntDobules
496 appearing at both sets. The first stage($S_1-C$ and $S_2$) and
497 second stages ($S_1$ and $S_2-C$) are completely non-overlapping. On
498 the contrary, the third stage($C$ and $C$) are completely
499 overlapping} \label{oopseFig:staticPropsProcess}
500 \end{figure}
501
502 \begin{figure}
503 \centering
504 \includegraphics[width=3in]{definition.eps}
505 \caption[Definitions of the angles between directional objects]{Any
506 two directional objects (DirectionalAtoms and RigidBodies) have a
507 set of two angles ($\theta$, and $\omega$) between the z-axes of
508 their body-fixed frames.} \label{oopseFig:gofr}
509 \end{figure}
510
511 There are five seperate radial distribution functions availiable in
512 OOPSE. Since every radial distrbution function invlove the
513 calculation between pairs of bodies, {\tt -{}-sele1} and {\tt
514 -{}-sele2} must be specified to tell StaticProps which bodies to
515 include in the calculation.
516
517 \begin{description}
518 \item[{\tt -{}-gofr}] Computes the pair distribution function,
519 \begin{equation*}
520 g_{AB}(r) = \frac{1}{\rho_B}\frac{1}{N_A} \langle \sum_{i \in A}
521 \sum_{j \in B} \delta(r - r_{ij}) \rangle
522 \end{equation*}
523 \item[{\tt -{}-r\_theta}] Computes the angle-dependent pair distribution
524 function. The angle is defined by the intermolecular vector
525 $\vec{r}$ and $z$-axis of DirectionalAtom A,
526 \begin{equation*}
527 g_{AB}(r, \cos \theta) = \frac{1}{\rho_B}\frac{1}{N_A} \langle
528 \sum_{i \in A} \sum_{j \in B} \delta(r - r_{ij}) \delta(\cos
529 \theta_{ij} - \cos \theta)\rangle
530 \end{equation*}
531 \item[{\tt -{}-r\_omega}] Computes the angle-dependent pair distribution
532 function. The angle is defined by the $z$-axes of the two
533 DirectionalAtoms A and B.
534 \begin{equation*}
535 g_{AB}(r, \cos \omega) = \frac{1}{\rho_B}\frac{1}{N_A} \langle
536 \sum_{i \in A} \sum_{j \in B} \delta(r - r_{ij}) \delta(\cos
537 \omega_{ij} - \cos \omega)\rangle
538 \end{equation*}
539 \item[{\tt -{}-theta\_omega}] Computes the pair distribution in the angular
540 space $\theta, \omega$ defined by the two angles mentioned above.
541 \begin{equation*}
542 g_{AB}(\cos\theta, \cos \omega) = \frac{1}{\rho_B}\frac{1}{N_A}
543 \langle \sum_{i \in A} \sum_{j \in B} \langle \delta(\cos
544 \theta_{ij} - \cos \theta) \delta(\cos \omega_{ij} - \cos
545 \omega)\rangle
546 \end{equation*}
547 \item[{\tt -{}-gxyz}] Calculates the density distribution of particles of type
548 B in the body frame of particle A. Therefore, {\tt -{}-originsele}
549 and {\tt -{}-refsele} must be given to define A's internal
550 coordinate set as the reference frame for the calculation.
551 \end{description}
552
553 The vectors (and angles) associated with these angular pair
554 distribution functions are most easily seen in
555 Fig.~\ref{oopseFig:gofr}.
556
557 The options available for {\tt StaticProps} are as follows:
558 \begin{longtable}[c]{|EFG|}
559 \caption{StaticProps Command-line Options}
560 \\ \hline
561 {\bf option} & {\bf verbose option} & {\bf behavior} \\ \hline
562 \endhead
563 \hline
564 \endfoot
565 -h& {\tt -{}-help} & Print help and exit \\
566 -V& {\tt -{}-version} & Print version and exit \\
567 -i& {\tt -{}-input} & input dump file \\
568 -o& {\tt -{}-output} & output file name \\
569 -n& {\tt -{}-step} & process every n frame (default=`1') \\
570 -r& {\tt -{}-nrbins} & number of bins for distance (default=`100') \\
571 -a& {\tt -{}-nanglebins} & number of bins for cos(angle) (default= `50') \\
572 -l& {\tt -{}-length} & maximum length (Defaults to 1/2 smallest length of first frame) \\
573 & {\tt -{}-sele1} & select the first StuntDouble set \\
574 & {\tt -{}-sele2} & select the second StuntDouble set \\
575 & {\tt -{}-sele3} & select the third StuntDouble set \\
576 & {\tt -{}-refsele} & select reference (can only be used with {\tt -{}-gxyz}) \\
577 & {\tt -{}-molname} & molecule name \\
578 & {\tt -{}-begin} & begin internal index \\
579 & {\tt -{}-end} & end internal index \\
580 \hline
581 \multicolumn{3}{|l|}{One option from the following group of options is required:} \\
582 \hline
583 & {\tt -{}-gofr} & $g(r)$ \\
584 & {\tt -{}-r\_theta} & $g(r, \cos(\theta))$ \\
585 & {\tt -{}-r\_omega} & $g(r, \cos(\omega))$ \\
586 & {\tt -{}-theta\_omega} & $g(\cos(\theta), \cos(\omega))$ \\
587 & {\tt -{}-gxyz} & $g(x, y, z)$ \\
588 & {\tt -{}-p2} & $P_2$ order parameter ({\tt -{}-sele1} and {\tt -{}-sele2} must be specified) \\
589 & {\tt -{}-scd} & $S_{CD}$ order parameter(either {\tt -{}-sele1}, {\tt -{}-sele2}, {\tt -{}-sele3} are specified or {\tt -{}-molname}, {\tt -{}-begin}, {\tt -{}-end} are specified) \\
590 & {\tt -{}-density} & density plot ({\tt -{}-sele1} must be specified) \\
591 & {\tt -{}-slab\_density} & slab density ({\tt -{}-sele1} must be specified)
592 \end{longtable}
593
594 \subsection{\label{appendixSection:DynamicProps}DynamicProps}
595
596 {\tt DynamicProps} computes time correlation functions from the
597 configurations stored in a dump file. Typical examples of time
598 correlation functions are the mean square displacement and the
599 velocity autocorrelation functions. Once again, the selection
600 syntax can be used to specify the StuntDoubles that will be used for
601 the calculation. A general time correlation function can be thought
602 of as:
603 \begin{equation}
604 C_{AB}(t) = \langle \vec{u}_A(t) \cdot \vec{v}_B(0) \rangle
605 \end{equation}
606 where $\vec{u}_A(t)$ is a vector property associated with an atom of
607 type $A$ at time $t$, and $\vec{v}_B(t^{\prime})$ is a different
608 vector property associated with an atom of type $B$ at a different
609 time $t^{\prime}$. In most autocorrelation functions, the vector
610 properties ($\vec{v}$ and $\vec{u}$) and the types of atoms ($A$ and
611 $B$) are identical, and the three calculations built in to {\tt
612 DynamicProps} make these assumptions. It is possible, however, to
613 make simple modifications to the {\tt DynamicProps} code to allow
614 the use of {\it cross} time correlation functions (i.e. with
615 different vectors). The ability to use two selection scripts to
616 select different types of atoms is already present in the code.
617
618 For large simulations, the trajectory files can sometimes reach
619 sizes in excess of several gigabytes. In order to prevent a
620 situation where the program runs out of memory due to large
621 trajectories, \texttt{dynamicProps} will first estimate the size of
622 free memory, and determine the number of frames in each block, which
623 will allow the operating system to load two blocks of data
624 simultaneously without swapping. Upon reading two blocks of the
625 trajectory, \texttt{dynamicProps} will calculate the time
626 correlation within the first block and the cross correlations
627 between the two blocks. This second block is then freed and then
628 incremented and the process repeated until the end of the
629 trajectory. Once the end is reached, the first block is freed then
630 incremented, until all frame pairs have been correlated in time.
631 This process is illustrated in
632 Fig.~\ref{oopseFig:dynamicPropsProcess}.
633
634 \begin{figure}
635 \centering
636 \includegraphics[width=\linewidth]{dynamicPropsProcess.eps}
637 \caption[A representation of the block correlations in
638 \texttt{dynamicProps}]{This diagram illustrates block correlations
639 processing in \texttt{dynamicProps}. The shaded region represents
640 the self correlation of the block, and the open blocks are read one
641 at a time and the cross correlations between blocks are calculated.}
642 \label{oopseFig:dynamicPropsProcess}
643 \end{figure}
644
645 The options available for DynamicProps are as follows:
646 \begin{longtable}[c]{|EFG|}
647 \caption{DynamicProps Command-line Options}
648 \\ \hline
649 {\bf option} & {\bf verbose option} & {\bf behavior} \\ \hline
650 \endhead
651 \hline
652 \endfoot
653 -h& {\tt -{}-help} & Print help and exit \\
654 -V& {\tt -{}-version} & Print version and exit \\
655 -i& {\tt -{}-input} & input dump file \\
656 -o& {\tt -{}-output} & output file name \\
657 & {\tt -{}-sele1} & select first StuntDouble set \\
658 & {\tt -{}-sele2} & select second StuntDouble set (if sele2 is not set, use script from sele1) \\
659 \hline
660 \multicolumn{3}{|l|}{One option from the following group of options is required:} \\
661 \hline
662 -r& {\tt -{}-rcorr} & compute mean square displacement \\
663 -v& {\tt -{}-vcorr} & compute velocity correlation function \\
664 -d& {\tt -{}-dcorr} & compute dipole correlation function
665 \end{longtable}
666
667 \section{\label{appendixSection:tools}Other Useful Utilities}
668
669 \subsection{\label{appendixSection:Dump2XYZ}Dump2XYZ}
670
671 {\tt Dump2XYZ} can transform an OOPSE dump file into a xyz file
672 which can be opened by other molecular dynamics viewers such as Jmol
673 and VMD\cite{Humphrey1996}. The options available for Dump2XYZ are
674 as follows:
675
676
677 \begin{longtable}[c]{|EFG|}
678 \caption{Dump2XYZ Command-line Options}
679 \\ \hline
680 {\bf option} & {\bf verbose option} & {\bf behavior} \\ \hline
681 \endhead
682 \hline
683 \endfoot
684 -h & {\tt -{}-help} & Print help and exit \\
685 -V & {\tt -{}-version} & Print version and exit \\
686 -i & {\tt -{}-input} & input dump file \\
687 -o & {\tt -{}-output} & output file name \\
688 -n & {\tt -{}-frame} & print every n frame (default=`1') \\
689 -w & {\tt -{}-water} & skip the the waters (default=off) \\
690 -m & {\tt -{}-periodicBox} & map to the periodic box (default=off)\\
691 -z & {\tt -{}-zconstraint} & replace the atom types of zconstraint molecules (default=off) \\
692 -r & {\tt -{}-rigidbody} & add a pseudo COM atom to rigidbody (default=off) \\
693 -t & {\tt -{}-watertype} & replace the atom type of water model (default=on) \\
694 -b & {\tt -{}-basetype} & using base atom type (default=off) \\
695 & {\tt -{}-repeatX} & The number of images to repeat in the x direction (default=`0') \\
696 & {\tt -{}-repeatY} & The number of images to repeat in the y direction (default=`0') \\
697 & {\tt -{}-repeatZ} & The number of images to repeat in the z direction (default=`0') \\
698 -s & {\tt -{}-selection} & By specifying {\tt -{}-selection}=``selection command'' with Dump2XYZ, the user can select an arbitrary set of StuntDoubles to be
699 converted. \\
700 & {\tt -{}-originsele} & By specifying {\tt -{}-originsele}=``selection command'' with Dump2XYZ, the user can re-center the origin of the system around a specific StuntDouble \\
701 & {\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}.
702 \end{longtable}
703
704 \subsection{\label{appendixSection:hydrodynamics}Hydro}
705
706 {\tt Hydro} can calculate resistance and diffusion tensors at the
707 center of resistance. Both tensors at the center of diffusion can
708 also be reported from the program, as well as the coordinates for
709 the beads which are used to approximate the arbitrary shapes. The
710 options available for Hydro are as follows:
711 \begin{longtable}[c]{|EFG|}
712 \caption{Hydrodynamics Command-line Options}
713 \\ \hline
714 {\bf option} & {\bf verbose option} & {\bf behavior} \\ \hline
715 \endhead
716 \hline
717 \endfoot
718 -h & {\tt -{}-help} & Print help and exit \\
719 -V & {\tt -{}-version} & Print version and exit \\
720 -i & {\tt -{}-input} & input dump file \\
721 -o & {\tt -{}-output} & output file prefix (default=`hydro') \\
722 -b & {\tt -{}-beads} & generate the beads only, hydrodynamics calculation will not be performed (default=off)\\
723 & {\tt -{}-model} & hydrodynamics model (supports ``AnalyticalModel'', ``RoughShell'' and ``BeadModel'') \\
724 \end{longtable}