| 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 |
| 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 |
| 89 |
> |
OOPSE}\cite{Meineke2005} and PROTOMOL\cite{Matthey2004}. |
| 90 |
> |
The following sections enumerates some of the patterns |
| 91 |
|
used in {\sc OOPSE}. |
| 92 |
|
|
| 93 |
|
\subsection{\label{appendixSection:singleton}Singletons} |
| 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 Scheme.~\ref{oopseFig:hierarchy} and 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 |
| 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 |
