| 4 |
|
The absence of modern software development practices has been a |
| 5 |
|
bottleneck limiting progress in the Scientific Computing |
| 6 |
|
community. In the last 20 years, a large number of |
| 7 |
< |
few MD packages\cite{Brooks1983, Vincent1995, Kale1999} were |
| 7 |
> |
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 |
| 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 |
| 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, |
| 38 |
|
extensive set of the STL and Fortran90 modules, the {\sc Base |
| 39 |
|
Classes} provide generic implementations of mathematical objects |
| 40 |
|
(e.g., matrices, vectors, polynomials, random number generators) and |
| 41 |
< |
advanced data structures and algorithms(e.g., tuple, bitset, generic |
| 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 |
| 44 |
> |
molecules 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 |
| 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. |
| 53 |
> |
for Language Recognition (ANTLR)\cite{Parr1995, Schaps1999} syntax. |
| 54 |
|
The Molecular Mechanics module consists of energy minimization and a |
| 55 |
|
wide variety of integration methods(see |
| 56 |
< |
Chap.~\ref{chapt:methodology}). The structure module contains a |
| 56 |
> |
Chapter.~\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 |
| 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}. |
| 65 |
> |
Sec.~\ref{appendixSection:hydrodynamics}). |
| 66 |
|
|
| 67 |
|
\begin{figure} |
| 68 |
|
\centering |
| 75 |
|
|
| 76 |
|
Design patterns are optimal solutions to commonly-occurring problems |
| 77 |
|
in software design. Although they originated as an architectural |
| 78 |
< |
concept for buildings and towns by Christopher Alexander |
| 79 |
< |
\cite{Alexander1987}, design patterns first became popular in |
| 80 |
< |
software engineering with the wide acceptance of the book, Design |
| 81 |
< |
Patterns: Elements of Reusable Object-Oriented Software |
| 82 |
< |
\cite{Gamma1994}. Patterns reflect the experience, knowledge and |
| 83 |
< |
insights of developers who have successfully used these patterns in |
| 84 |
< |
their own work. Patterns are reusable. They provide a ready-made |
| 78 |
> |
concept for buildings and towns by Christopher |
| 79 |
> |
Alexander,\cite{Alexander1987} design patterns first became popular |
| 80 |
> |
in software engineering with the wide acceptance of the book, Design |
| 81 |
> |
Patterns: Elements of Reusable Object-Oriented |
| 82 |
> |
Software.\cite{Gamma1994} Patterns reflect the experience, knowledge |
| 83 |
> |
and insights of developers who have successfully used these patterns |
| 84 |
> |
in their own work. Patterns are reusable. They provide a ready-made |
| 85 |
|
solution that can be adapted to different problems as necessary. As |
| 86 |
|
one of the latest advanced techniques to emerge from object-oriented |
| 87 |
|
community, design patterns were applied in some of the modern |
| 88 |
|
scientific software applications, such as JMol, {\sc |
| 89 |
< |
OOPSE}\cite{Meineke2005} and PROTOMOL\cite{Matthey2004} |
| 90 |
< |
\textit{etc}. The following sections enumerates some of the patterns |
| 91 |
< |
used in {\sc OOPSE}. |
| 89 |
> |
OOPSE}\cite{Meineke2005} and PROTOMOL\cite{Matthey2004}. The |
| 90 |
> |
following sections enumerates some of the patterns used in {\sc |
| 91 |
> |
OOPSE}. |
| 92 |
|
|
| 93 |
|
\subsection{\label{appendixSection:singleton}Singletons} |
| 94 |
|
|
| 96 |
|
instantiation of a class to one object, but also provides a global |
| 97 |
|
point of access to the object. Although the singleton pattern can be |
| 98 |
|
implemented in various ways to account for different aspects of the |
| 99 |
< |
software design, such as lifespan control \textit{etc}, we only use |
| 99 |
> |
software design, such as lifespan control, we only use |
| 100 |
|
the static data approach in {\sc OOPSE}. The declaration and |
| 101 |
|
implementation of IntegratorFactory class are given by declared in |
| 102 |
|
List.~\ref{appendixScheme:singletonDeclaration} and |
| 133 |
|
structure of a Visitor pattern which is used extensively in {\tt |
| 134 |
|
Dump2XYZ}. In order to convert an OOPSE dump file, a series of |
| 135 |
|
distinct operations are performed on different StuntDoubles (See the |
| 136 |
< |
class hierarchy in Fig.~\ref{oopseFig:hierarchy} and the |
| 137 |
< |
declaration in Scheme.~\ref{appendixScheme:element}). Since the |
| 138 |
< |
hierarchies remain stable, it is easy to define a visit operation |
| 139 |
< |
(see Scheme.~\ref{appendixScheme:visitor}) for each class of |
| 140 |
< |
StuntDouble. Note that by using the Composite |
| 141 |
< |
pattern\cite{Gamma1994}, CompositeVisitor manages a priority visitor |
| 142 |
< |
list and handles the execution of every visitor in the priority list |
| 143 |
< |
on different StuntDoubles. |
| 136 |
> |
class hierarchy in Fig.~\ref{oopseFig:hierarchy} and the declaration |
| 137 |
> |
in Scheme.~\ref{appendixScheme:element}). Since the hierarchies |
| 138 |
> |
remain stable, it is easy to define a visit operation (see |
| 139 |
> |
Scheme.~\ref{appendixScheme:visitor}) for each class of StuntDouble. |
| 140 |
> |
Note that by using the Composite pattern,\cite{Gamma1994} |
| 141 |
> |
CompositeVisitor manages a priority visitor list and handles the |
| 142 |
> |
execution of every visitor in the priority list on different |
| 143 |
> |
StuntDoubles. |
| 144 |
|
|
| 145 |
|
\begin{figure} |
| 146 |
|
\centering |
| 282 |
|
virtual void visit(Atom* atom) { |
| 283 |
|
VisitorListIterator i; |
| 284 |
|
BaseVisitor* curVisitor; |
| 285 |
< |
for(i = visitorScheme.begin();i != visitorScheme.end();++i) |
| 285 |
> |
for(i = visitorList.begin();i != visitorList.end();++i) |
| 286 |
|
atom->accept(*i); |
| 287 |
|
} |
| 288 |
|
virtual void visit(DirectionalAtom* datom) { |
| 380 |
|
\hline expression has one ``.'' & select TIP3P.O\_TIP3P & select the |
| 381 |
|
O\_TIP3P |
| 382 |
|
atoms belonging to TIP3P molecules \\ |
| 383 |
< |
& select DMPC\_RB\_O.PO4 & select the PO4 atoms belonging to |
| 383 |
> |
& select DMPC\_RB\_0.PO4 & select the PO4 atoms belonging to |
| 384 |
|
the first |
| 385 |
|
RigidBody in each DMPC molecule \\ |
| 386 |
|
& select DMPC.20 & select the twentieth StuntDouble in each DMPC |
| 668 |
|
|
| 669 |
|
{\tt Dump2XYZ} can transform an OOPSE dump file into a xyz file |
| 670 |
|
which can be opened by other molecular dynamics viewers such as Jmol |
| 671 |
< |
and VMD\cite{Humphrey1996}. The options available for Dump2XYZ are |
| 671 |
> |
and VMD.\cite{Humphrey1996} The options available for Dump2XYZ are |
| 672 |
|
as follows: |
| 673 |
|
|
| 674 |
|
\begin{longtable}[c]{|EFG|} |
