| 25 |
|
\title{{\sc oopse}: An Open Source Object-Oriented Parallel Simulation |
| 26 |
|
Engine for Molecular Dynamics} |
| 27 |
|
|
| 28 |
< |
\author{Matthew A. Meineke, Charles F. Vardeman II, Teng Lin, Christopher J. Fennell and J. Daniel Gezelter\\ |
| 28 |
> |
\author{Matthew A. Meineke, Charles F. Vardeman II, Teng Lin,\\ |
| 29 |
> |
Christopher J. Fennell and J. Daniel Gezelter\\ |
| 30 |
|
Department of Chemistry and Biochemistry\\ |
| 31 |
|
University of Notre Dame\\ |
| 32 |
|
Notre Dame, Indiana 46556} |
| 36 |
|
|
| 37 |
|
\begin{abstract} |
| 38 |
|
We detail the capabilities of a new open-source parallel simulation |
| 39 |
< |
package ({\sc oopse}) that can perform molecular dynamics simulations |
| 40 |
< |
on atom types that are missing from other popular packages. In |
| 41 |
< |
particular, {\sc oopse} is capable of performing orientational |
| 41 |
< |
dynamics on dipolar systems, and it can handle simulations of metallic |
| 39 |
> |
progrm for MD ({\sc oopse}) that can work with atom types that are missing from other popular packages. In |
| 40 |
> |
particular, {\sc oopse} is capable of performing efficient orientational |
| 41 |
> |
dynamics on dipolar or rigid body systems, and it can handle simulations of metallic |
| 42 |
|
systems using the embedded atom method ({\sc eam}). |
| 43 |
|
\end{abstract} |
| 44 |
|
|
| 88 |
|
considerations are presented in Sec.~\ref{oopseSec:design}. And |
| 89 |
|
lastly, Sec.~\ref{oopseSec:conclusion} concludes the chapter. |
| 90 |
|
|
| 91 |
< |
\section{\label{oopseSec:empiricalEnergy}The Empirical Energy Functions} |
| 91 |
> |
\section{\label{oopseSec:IOfiles}Concepts \& Files} |
| 92 |
|
|
| 93 |
< |
\subsection{\label{oopseSec:atomsMolecules}Atoms, Molecules and Rigid Bodies} |
| 93 |
> |
\subsection{{\sc bass} and Model Files} |
| 94 |
|
|
| 95 |
< |
The basic unit of an {\sc oopse} simulation is the atom. The |
| 96 |
< |
parameters describing the atom are generalized to make the atom as |
| 97 |
< |
flexible a representation as possible. They may represent specific |
| 98 |
< |
atoms of an element, or be used for collections of atoms such as |
| 99 |
< |
methyl and carbonyl groups. The atoms are also capable of having |
| 100 |
< |
directional components associated with them (\emph{e.g.}~permanent |
| 101 |
< |
dipoles). Charges, permanent dipoles, and Lennard-Jones parameters for |
| 102 |
< |
a given atom type are set in the force field parameter files. |
| 95 |
> |
Every {\sc oopse} simulation begins with a Bizarre Atom Simulation |
| 96 |
> |
Syntax ({\sc bass}) file. {\sc bass} is a script syntax that is parsed |
| 97 |
> |
by {\sc oopse} at runtime. The {\sc bass} file allows for the user to |
| 98 |
> |
completely describe the system they wish to simulate, as well as tailor |
| 99 |
> |
{\sc oopse}'s behavior during the simulation. {\sc bass} files are |
| 100 |
> |
denoted with the extension |
| 101 |
> |
\texttt{.bass}, an example file is shown in |
| 102 |
> |
Scheme~\ref{sch:bassExample}. |
| 103 |
|
|
| 104 |
< |
\begin{lstlisting}[float,caption={[Specifier for molecules and atoms] A sample specification of an Ar molecule},label=sch:AtmMole] |
| 104 |
> |
\begin{lstlisting}[float,caption={[An example of a complete {\sc bass} file] An example showing a complete {\sc bass} file.},label={sch:bassExample}] |
| 105 |
> |
|
| 106 |
|
molecule{ |
| 107 |
|
name = "Ar"; |
| 108 |
|
nAtoms = 1; |
| 111 |
|
position( 0.0, 0.0, 0.0 ); |
| 112 |
|
} |
| 113 |
|
} |
| 114 |
+ |
|
| 115 |
+ |
nComponents = 1; |
| 116 |
+ |
component{ |
| 117 |
+ |
type = "Ar"; |
| 118 |
+ |
nMol = 108; |
| 119 |
+ |
} |
| 120 |
+ |
|
| 121 |
+ |
initialConfig = "./argon.init"; |
| 122 |
+ |
|
| 123 |
+ |
forceField = "LJ"; |
| 124 |
+ |
ensemble = "NVE"; // specify the simulation ensemble |
| 125 |
+ |
dt = 1.0; // the time step for integration |
| 126 |
+ |
runTime = 1e3; // the total simulation run time |
| 127 |
+ |
sampleTime = 100; // trajectory file frequency |
| 128 |
+ |
statusTime = 50; // statistics file frequency |
| 129 |
+ |
|
| 130 |
|
\end{lstlisting} |
| 131 |
|
|
| 132 |
+ |
Within the \texttt{.bass} file it is necessary to provide a complete |
| 133 |
+ |
description of the molecule before it is actually placed in the |
| 134 |
+ |
simulation. The {\sc bass} syntax was originally developed with this |
| 135 |
+ |
goal in mind, and allows for the specification of all the atoms in a |
| 136 |
+ |
molecular prototype, as well as any bonds, bends, or torsions. These |
| 137 |
+ |
descriptions can become lengthy for complex molecules, and it would be |
| 138 |
+ |
inconvenient to duplicate the simulation at the beginning of each {\sc |
| 139 |
+ |
bass} script. Addressing this issue {\sc bass} allows for the |
| 140 |
+ |
inclusion of model files at the top of a \texttt{.bass} file. These |
| 141 |
+ |
model files, denoted with the \texttt{.mdl} extension, allow the user |
| 142 |
+ |
to describe a molecular prototype once, then simply include it into |
| 143 |
+ |
each simulation containing that molecule. Returning to the example in |
| 144 |
+ |
Scheme~\ref{sch:bassExample}, the \texttt{.mdl} file's contents would |
| 145 |
+ |
be Scheme~\ref{sch:mdlExample}, and the new \texttt{.bass} file would |
| 146 |
+ |
become Scheme~\ref{sch:bassExPrime}. |
| 147 |
|
|
| 148 |
+ |
\begin{lstlisting}[float,caption={An example \texttt{.mdl} file.},label={sch:mdlExample}] |
| 149 |
+ |
|
| 150 |
+ |
molecule{ |
| 151 |
+ |
name = "Ar"; |
| 152 |
+ |
nAtoms = 1; |
| 153 |
+ |
atom[0]{ |
| 154 |
+ |
type="Ar"; |
| 155 |
+ |
position( 0.0, 0.0, 0.0 ); |
| 156 |
+ |
} |
| 157 |
+ |
} |
| 158 |
+ |
|
| 159 |
+ |
\end{lstlisting} |
| 160 |
+ |
|
| 161 |
+ |
\begin{lstlisting}[float,caption={Revised {\sc bass} example.},label={sch:bassExPrime}] |
| 162 |
+ |
|
| 163 |
+ |
#include "argon.mdl" |
| 164 |
+ |
|
| 165 |
+ |
nComponents = 1; |
| 166 |
+ |
component{ |
| 167 |
+ |
type = "Ar"; |
| 168 |
+ |
nMol = 108; |
| 169 |
+ |
} |
| 170 |
+ |
|
| 171 |
+ |
initialConfig = "./argon.init"; |
| 172 |
+ |
|
| 173 |
+ |
forceField = "LJ"; |
| 174 |
+ |
ensemble = "NVE"; |
| 175 |
+ |
dt = 1.0; |
| 176 |
+ |
runTime = 1e3; |
| 177 |
+ |
sampleTime = 100; |
| 178 |
+ |
statusTime = 50; |
| 179 |
+ |
|
| 180 |
+ |
\end{lstlisting} |
| 181 |
+ |
|
| 182 |
+ |
\subsection{\label{oopseSec:atomsMolecules}Atoms, Molecules and Rigid Bodies} |
| 183 |
+ |
|
| 184 |
+ |
The basic unit of an {\sc oopse} simulation is the atom. The |
| 185 |
+ |
parameters describing the atom are generalized to make the atom as |
| 186 |
+ |
flexible a representation as possible. They may represent specific |
| 187 |
+ |
atoms of an element, or be used for collections of atoms such as |
| 188 |
+ |
methyl and carbonyl groups. The atoms are also capable of having |
| 189 |
+ |
directional components associated with them (\emph{e.g.}~permanent |
| 190 |
+ |
dipoles). Charges, permanent dipoles, and Lennard-Jones parameters for |
| 191 |
+ |
a given atom type are set in the force field parameter files. |
| 192 |
+ |
|
| 193 |
|
Atoms can be collected into secondary structures such as rigid bodies |
| 194 |
|
or molecules. The molecule is a way for {\sc oopse} to keep track of |
| 195 |
|
the atoms in a simulation in logical manner. Molecular units store the |
| 196 |
|
identities of all the atoms and rigid bodies associated with |
| 197 |
|
themselves, and are responsible for the evaluation of their own |
| 198 |
|
internal interactions (\emph{i.e.}~bonds, bends, and torsions). Scheme |
| 199 |
< |
\ref{sch:AtmMole} shows how one creates a molecule in a ``model'' or |
| 199 |
> |
\ref{sch:mdlExample} shows how one creates a molecule in a ``model'' or |
| 200 |
|
\texttt{.mdl} file. The position of the atoms given in the |
| 201 |
|
declaration are relative to the origin of the molecule, and is used |
| 202 |
|
when creating a system containing the molecule. |
| 209 |
|
included in most simulation packages because of the algorithmic |
| 210 |
|
complexity involved in propagating orientational degrees of |
| 211 |
|
freedom. Until recently, integrators which propagate orientational |
| 212 |
< |
motion have been much worse than those available for translational |
| 212 |
> |
motion have had energy conservation problems when compared to those available for translational |
| 213 |
|
motion. |
| 214 |
|
|
| 215 |
|
Moving a rigid body involves determination of both the force and |
| 251 |
|
entire nine parameter rotation matrix. Further discussion |
| 252 |
|
on this choice can be found in Sec.~\ref{oopseSec:integrate}. An example |
| 253 |
|
definition of a rigid body can be seen in Scheme |
| 254 |
< |
\ref{sch:rigidBody}. The positions in the atom definitions are the |
| 178 |
< |
placements of the atoms relative to the origin of the rigid body, |
| 179 |
< |
which itself has a position relative to the origin of the molecule. |
| 254 |
> |
\ref{sch:rigidBody}. |
| 255 |
|
|
| 256 |
< |
\begin{lstlisting}[float,caption={[Defining rigid bodies]A sample definition of a rigid body},label={sch:rigidBody}] |
| 256 |
> |
\begin{lstlisting}[float,caption={[Defining rigid bodies]A sample definition of a molecule containing a rigid body},label={sch:rigidBody}] |
| 257 |
|
molecule{ |
| 258 |
|
name = "TIP3P"; |
| 259 |
|
nAtoms = 3; |
| 275 |
|
nMembers = 3; |
| 276 |
|
members(0, 1, 2); |
| 277 |
|
} |
| 278 |
+ |
} |
| 279 |
+ |
\end{lstlisting} |
| 280 |
+ |
|
| 281 |
+ |
\subsection{\label{sec:miscConcepts}Putting a Script Together} |
| 282 |
+ |
|
| 283 |
+ |
The actual creation of a {\sc bass} script requires several key components. The first part of the script needs to be the declaration of all of the molecule prototypes used in the simulation. This is typically done through the inclusion of {\tt .mdl} files. Only the molecules actually present in the simulation need to be declared, however {\sc bass} allows for the declaration of more molecules than are needed. This gives the user the ability to build up a library of commonly used molecules into a single {\tt .mdl} file. |
| 284 |
+ |
|
| 285 |
+ |
Once all prototypes are declared, the ordering of the rest of the script is less stringent. Typically, the next to follow the molecular prototypes are the component statements. These statements specify which molecules are present within the simulation. The number of components must first be declared before the first component block statement (an example is seen in Sch.~\ref{sch:bassExPrime}). The component blocks tell {\sc oopse} the number of molecules that will be in the simulation, and the order in which the components blocks are declared sets the ordering of the real atoms within the simulation as well as in the output files. |
| 286 |
+ |
|
| 287 |
+ |
The remainder of the script then sets the various simulation parameters for the system of interest. The required set of parameters that must be present in all simulations is given in Table~\ref{table:reqParams}. The {\tt ensemble} statement is responsible for selecting the integration method used for the calculation of the equations of motion. An in depth discussion of the various methods available in {\sc oopse} can be found in Sec.~\ref{oopseSec:mechanics}. The {\tt forceField} statement is important for the selection of which forces will be used in the course of the simulation. {\sc oopse} supports several force fields, as outlined in Sec.~\ref{oopseSec:empericalEnergy}. The force fields are interchangeable between simulations, with the only requirement being that all atoms needed by the simulation are defined within the selected force field. The time step between force evaluations is set with the {\tt dt} parameter, and {\tt runTime} will set the time length of the simulation. Note, that {\tt runTime} is an absolute time, meaning if the simulation is started at t = 10.0~ns with a {\tt runTime} of 25.0~ns, the simulation will only run for an additional 15.0~ns. The final required parameter, is the {\tt initialConfig} statement. This will set the initial coordinates for the system, as well as the initial time if the {\tt useInitalTime = true;} flag is given. The format of the file specified in {\tt initialConfig}, is given in Sec.~\ref{oopseSec:coordFiles}. Additional parameters are summarized in Table~\ref{table:genParams}. |
| 288 |
+ |
|
| 289 |
+ |
\begin{table} |
| 290 |
+ |
\caption{The Global Keywords: Required Parameters} |
| 291 |
+ |
\label{table:reqParams} |
| 292 |
+ |
\begin{center} |
| 293 |
+ |
% Note when adding or removing columns, the \hsize numbers must add up to the total number |
| 294 |
+ |
% of columns. |
| 295 |
+ |
\begin{tabularx}{\linewidth}% |
| 296 |
+ |
{>{\setlength{\hsize}{1.00\hsize}}X% |
| 297 |
+ |
>{\setlength{\hsize}{0.4\hsize}}X% |
| 298 |
+ |
>{\setlength{\hsize}{1.2\hsize}}X% |
| 299 |
+ |
>{\setlength{\hsize}{1.4\hsize}}X} |
| 300 |
+ |
|
| 301 |
+ |
{\bf keyword} & {\bf units} & {\bf use} & {\bf remarks} \\ \hline |
| 302 |
+ |
|
| 303 |
+ |
{\tt forceField} & string & Sets the force field. & Possible force fields are "DUFF", "LJ", and "EAM". \\ |
| 304 |
+ |
{\tt ensemble} & string & Sets the ensemble. & Possible ensembles are "NVE", "NVT", "NPTi", "NPTf", and "NPTxyz".\\ |
| 305 |
+ |
{\tt dt} & fs & Sets the time step. & Selection of {\tt dt} should be small enough to sample the fastest motion of the simulation. \\ |
| 306 |
+ |
{\tt nComponents} & integer & Sets the number of components. & Needs to appear before the first {\tt Component} block. \\ |
| 307 |
+ |
{\tt initialConfig} & string & Sets the file containing the initial configuration. & Can point to any file containing the configuration in the correct order. \\ |
| 308 |
+ |
{\tt runTime} & fs & Sets the time at which the simulation should end. & This is an absolute time, and will end the simulation when the current time meets or exceeds the {\tt runTime}. \\ |
| 309 |
+ |
|
| 310 |
+ |
|
| 311 |
+ |
\end{tabularx} |
| 312 |
+ |
\end{center} |
| 313 |
+ |
\end{table} |
| 314 |
+ |
|
| 315 |
+ |
\begin{table} |
| 316 |
+ |
\caption{The Global Keywords: General Parameters} |
| 317 |
+ |
\label{table:genParams} |
| 318 |
+ |
\begin{center} |
| 319 |
+ |
% Note when adding or removing columns, the \hsize numbers must add up to the total number |
| 320 |
+ |
% of columns. |
| 321 |
+ |
\begin{tabularx}{\linewidth}% |
| 322 |
+ |
{>{\setlength{\hsize}{1.00\hsize}}X% |
| 323 |
+ |
>{\setlength{\hsize}{0.4\hsize}}X% |
| 324 |
+ |
>{\setlength{\hsize}{1.2\hsize}}X% |
| 325 |
+ |
>{\setlength{\hsize}{1.4\hsize}}X} |
| 326 |
+ |
|
| 327 |
+ |
{\bf keyword} & {\bf units} & {\bf use} & {\bf remarks} \\ \hline |
| 328 |
+ |
|
| 329 |
+ |
{\tt finalConfig} & string & Option to set the name of the final output file. & Useful when stringing simulations together. Defaults to the {\tt .bass} file with an {\tt .eor} extension. \\ |
| 330 |
+ |
{\tt useInitialTime} & logical & Sets whether the initial time is taken from the {\tt .init} file. & Useful when recovering a simulation from a crashed processor. Default is false. \\ |
| 331 |
+ |
{\tt sampleTime} & fs & Sets the frequency at which the {\tt .dump} file is written. & Default sets the frequency to the {\tt runTime}. \\ |
| 332 |
+ |
{\tt statusTime} & fs & Sets the frequency at which the {\tt .stat} file is written. & Defaults sets the frequency to the {\tt sampleTime}. \\ |
| 333 |
+ |
{\tt LJrcut} & $\mbox{\AA}$ & Manually sets the Lennard-Jones cutoff. & Defaults to $2.5\sigma_L$, where $\sigma_L$ is the largest LJ $\sigma$ in the simulation. \\ |
| 334 |
+ |
{\tt electrostaticCutoffRadius}& & & \\ |
| 335 |
+ |
& $\mbox{\AA}$ & Manually sets the cutoff used by the electrostatic potentials. & Defaults to $15\mbox{\AA}$ \\ |
| 336 |
+ |
{\tt electrostaticSkinThickness} & & & \\ |
| 337 |
+ |
& $\mbox{\AA}$ & Manually sets the skin thickness for the electrostatic switching function. & Defaults to 5~\% of the {\tt electrostaticSkinThickness}. \\ |
| 338 |
+ |
{\tt useReactionField} & logical & Turns the reaction field correction on/off. & Default is "false". \\ |
| 339 |
+ |
{\tt dielectric} & unitless & Sets the dielectric constant for reaction field. & If {\tt useReactionField} is true, then {\tt dielectric} must be set. \\ |
| 340 |
+ |
{\tt usePeriodicBoundaryConditions} & & & \\ |
| 341 |
+ |
& logical & Turns periodic boundary conditions on/off. & Default is "true". \\ |
| 342 |
+ |
{\tt seed } & integer & Sets the seed value for the random number generator. & The seed needs to be at least 9 digits long. The default is to take the seed from the CPU clock. |
| 343 |
+ |
|
| 344 |
+ |
\end{tabularx} |
| 345 |
+ |
\end{center} |
| 346 |
+ |
\end{table} |
| 347 |
+ |
|
| 348 |
+ |
|
| 349 |
+ |
|
| 350 |
+ |
\subsection{\label{oopseSec:coordFiles}Coordinate Files} |
| 351 |
+ |
|
| 352 |
+ |
The standard format for storage of a systems coordinates is a modified |
| 353 |
+ |
xyz-file syntax, the exact details of which can be seen in |
| 354 |
+ |
Scheme~\ref{sch:dumpFormat}. As all bonding and molecular information |
| 355 |
+ |
is stored in the \texttt{.bass} and \texttt{.mdl} files, the |
| 356 |
+ |
coordinate files are simply the complete set of coordinates for each |
| 357 |
+ |
atom at a given simulation time. One important note, although the |
| 358 |
+ |
simulation propagates the complete rotation matrix, directional |
| 359 |
+ |
entities are written out using quanternions, to save space in the |
| 360 |
+ |
output files. |
| 361 |
+ |
|
| 362 |
+ |
\begin{lstlisting}[float,caption={[The format of the coordinate files]Shows the format of the coordinate files. The fist line is the number of atoms. The second line begins with the time stamp followed by the three $\mathsf{H}$ column vectors. It is important to note, that for extended system ensembles, additional information pertinent to the integrators may be stored on this line as well. The next lines are the atomic coordinates for all atoms in the system. First is the name followed by position, velocity, quanternions, and lastly, body fixed angular momentum.},label=sch:dumpFormat] |
| 363 |
+ |
|
| 364 |
+ |
nAtoms |
| 365 |
+ |
time; Hxx Hyx Hzx; Hxy Hyy Hzy; Hxz Hyz Hzz; |
| 366 |
+ |
Name1 x y z vx vy vz q0 q1 q2 q3 jx jy jz |
| 367 |
+ |
Name2 x y z vx vy vz q0 q1 q2 q3 jx jy jz |
| 368 |
+ |
etc... |
| 369 |
+ |
|
| 370 |
+ |
\end{lstlisting} |
| 371 |
+ |
|
| 372 |
+ |
|
| 373 |
+ |
There are three major files used by {\sc oopse} written in the |
| 374 |
+ |
coordinate format, they are as follows: the initialization file |
| 375 |
+ |
(\texttt{.init}), the simulation trajectory file (\texttt{.dump}), and |
| 376 |
+ |
the final coordinates of the simulation (\texttt{.eor}). The initialization file is |
| 377 |
+ |
necessary for {\sc oopse} to start the simulation with the proper |
| 378 |
+ |
coordinates, and is generated before the simulation run. The |
| 379 |
+ |
trajectory file is created at the beginning of the simulation, and is |
| 380 |
+ |
used to store snapshots of the simulation at regular intervals. The |
| 381 |
+ |
first frame is a duplication of the |
| 382 |
+ |
\texttt{.init} file, and each subsequent frame is appended to the file |
| 383 |
+ |
at an interval specified in the \texttt{.bass} file with the |
| 384 |
+ |
\texttt{sampleTime} flag. The final coordinate file is the end of run file. The |
| 385 |
+ |
\texttt{.eor} file stores the final configuration of the system for a |
| 386 |
+ |
given simulation. The file is updated at the same time as the |
| 387 |
+ |
\texttt{.dump} file, however, it only contains the most recent |
| 388 |
+ |
frame. In this way, an \texttt{.eor} file may be used as the |
| 389 |
+ |
initialization file to a second simulation in order to continue a |
| 390 |
+ |
simulation or recover one from a processor that has crashed during the |
| 391 |
+ |
course of the run. |
| 392 |
+ |
|
| 393 |
+ |
\subsection{\label{oopseSec:initCoords}Generation of Initial Coordinates} |
| 394 |
+ |
|
| 395 |
+ |
As was stated in Sec.~\ref{oopseSec:coordFiles}, an initialization |
| 396 |
+ |
file is needed to provide the starting coordinates for a |
| 397 |
+ |
simulation. Several helper programs are provided with {\sc oopse} to illustrate possible build routes. However, as each simulation is different, system creation is left to the end user. The {\tt .init} file must list the atoms in the correct order or {\sc oopse} will give an atom mismatch error. |
| 398 |
+ |
|
| 399 |
+ |
The correct ordering of the atoms relies on the ordering of atoms and molecules within the model and {\sc bass} scripts. {\sc oopse} expects the order to comply with the following guidelines: |
| 400 |
+ |
\begin{enumerate} |
| 401 |
+ |
\item All of the molecules of the first declared component are given before proceeding to the molecules of the second component, and so on for all declared components. |
| 402 |
+ |
\item The ordering of the atoms for each molecule follows the order declared in the molecule's declaration within the model file. |
| 403 |
+ |
\end{enumerate} |
| 404 |
+ |
An example is given in Scheme~\ref{sch:initEx1} resulting in the {\tt .init} file shown in Scheme~\ref{sch:initEx2}. |
| 405 |
+ |
|
| 406 |
+ |
\begin{lstlisting}[float,caption={This scheme illustrates the declaration of the $\text{I}_2$ molecule and the HCl molecule. The two molecules are then included into a simulation.}, label=sch:initEx1] |
| 407 |
+ |
|
| 408 |
+ |
molecule{ |
| 409 |
+ |
name = "I2"; |
| 410 |
+ |
nAtoms = 2; |
| 411 |
+ |
atom[0]{ |
| 412 |
+ |
type = "I"; |
| 413 |
+ |
} |
| 414 |
+ |
atom[1]{ |
| 415 |
+ |
type = "I"; |
| 416 |
+ |
} |
| 417 |
+ |
nBonds = 1; |
| 418 |
+ |
bond[0]{ |
| 419 |
+ |
members( 0, 1); |
| 420 |
+ |
} |
| 421 |
+ |
} |
| 422 |
+ |
|
| 423 |
+ |
molecule{ |
| 424 |
+ |
name = "HCl" |
| 425 |
+ |
nAtoms = 2; |
| 426 |
+ |
atom[0]{ |
| 427 |
+ |
type = "H"; |
| 428 |
+ |
} |
| 429 |
+ |
atom[1]{ |
| 430 |
+ |
type = "Cl"; |
| 431 |
+ |
} |
| 432 |
+ |
nBonds = 1; |
| 433 |
+ |
bond[0]{ |
| 434 |
+ |
members( 0, 1); |
| 435 |
+ |
} |
| 436 |
+ |
} |
| 437 |
+ |
|
| 438 |
+ |
nComponents = 2; |
| 439 |
+ |
component{ |
| 440 |
+ |
type = "HCl"; |
| 441 |
+ |
nMol = 4; |
| 442 |
+ |
} |
| 443 |
+ |
component{ |
| 444 |
+ |
type = "I2"; |
| 445 |
+ |
nMol = 1; |
| 446 |
|
} |
| 447 |
+ |
|
| 448 |
+ |
initialConfig = "mixture.init"; |
| 449 |
+ |
|
| 450 |
|
\end{lstlisting} |
| 451 |
|
|
| 452 |
+ |
\begin{lstlisting}[float,caption={This is the contents of the {\tt mixture.init} file matching the declarations in Scheme~\ref{sch:initEx1}. Note that even though $\text{I}_2$ is declared before HCl, the {\tt .init} file follows the order in which the components were included.},label=sch:initEx2] |
| 453 |
+ |
|
| 454 |
+ |
10 |
| 455 |
+ |
0.0; 10.0 0.0 0.0; 0.0 10.0 0.0; 0.0 0.0 10.0; |
| 456 |
+ |
H ... |
| 457 |
+ |
Cl ... |
| 458 |
+ |
H ... |
| 459 |
+ |
Cl ... |
| 460 |
+ |
H ... |
| 461 |
+ |
Cl ... |
| 462 |
+ |
H ... |
| 463 |
+ |
Cl ... |
| 464 |
+ |
I ... |
| 465 |
+ |
I ... |
| 466 |
+ |
|
| 467 |
+ |
\end{lstlisting} |
| 468 |
+ |
|
| 469 |
+ |
|
| 470 |
+ |
\subsection{The Statistics File} |
| 471 |
+ |
|
| 472 |
+ |
The last output file generated by {\sc oopse} is the statistics |
| 473 |
+ |
file. This file records such statistical quantities as the |
| 474 |
+ |
instantaneous temperature, volume, pressure, etc. It is written out |
| 475 |
+ |
with the frequency specified in the \texttt{.bass} file with the |
| 476 |
+ |
\texttt{statusTime} keyword. The file allows the user to observe the |
| 477 |
+ |
system variables as a function of simulation time while the simulation |
| 478 |
+ |
is in progress. One useful function the statistics file serves is to |
| 479 |
+ |
monitor the conserved quantity of a given simulation ensemble, this |
| 480 |
+ |
allows the user to observe the stability of the integrator. The |
| 481 |
+ |
statistics file is denoted with the \texttt{.stat} file extension. |
| 482 |
+ |
|
| 483 |
+ |
|
| 484 |
+ |
\section{\label{oopseSec:empiricalEnergy}The Empirical Energy Functions} |
| 485 |
+ |
|
| 486 |
+ |
\ |
| 487 |
|
\subsection{\label{sec:LJPot}The Lennard Jones Force Field} |
| 488 |
|
|
| 489 |
|
The most basic force field implemented in {\sc oopse} is the |
| 561 |
|
charges. Charge-neutral distributions were replaced with dipoles, |
| 562 |
|
while most atoms and groups of atoms were reduced to Lennard-Jones |
| 563 |
|
interaction sites. This simplification cuts the length scale of long |
| 564 |
< |
range interactions from $\frac{1}{r}$ to $\frac{1}{r^3}$, and allows |
| 284 |
< |
us to avoid the computationally expensive Ewald sum. Instead, we can |
| 285 |
< |
use neighbor-lists and cutoff radii for the dipolar interactions, or |
| 286 |
< |
include a reaction field to mimic larger range interactions. |
| 564 |
> |
range interactions from $\frac{1}{r}$ to $\frac{1}{r^3}$, removing the need for the computationally expensive Ewald sum. Instead, we Verlet neighbor-lists and cutoff radii are used for the dipolar interactions, or a reaction field is added to mimic longer range interactions. |
| 565 |
|
|
| 566 |
|
As an example, lipid head-groups in {\sc duff} are represented as |
| 567 |
|
point dipole interaction sites. By placing a dipole at the head |
| 571 |
|
site is located at the pseudoatom's center of mass. The model is |
| 572 |
|
illustrated by the red atom in Fig.~\ref{oopseFig:lipidModel}. The |
| 573 |
|
water model we use to complement the dipoles of the lipids is our |
| 574 |
< |
reparameterization of the soft sticky dipole (SSD) model of Ichiye |
| 574 |
> |
reparameterization\cite{fennell04} of the soft sticky dipole (SSD) model of Ichiye |
| 575 |
|
\emph{et al.}\cite{liu96:new_model} |
| 576 |
|
|
| 577 |
|
\begin{figure} |
| 594 |
|
$\text{CH}_2$ do not change depending on what species are bonded to |
| 595 |
|
it. |
| 596 |
|
|
| 597 |
< |
TraPPE also constrains all bonds to be of fixed length. Typically, |
| 597 |
> |
TraPPE and {\sc duff} also constrain all bonds to be of fixed length. Typically, |
| 598 |
|
bond vibrations are the fastest motions in a molecular dynamic |
| 599 |
|
simulation. Small time steps between force evaluations must be used to |
| 600 |
|
ensure adequate energy conservation in the bond degrees of freedom. By |
| 624 |
|
|
| 625 |
|
\end{lstlisting} |
| 626 |
|
|
| 627 |
< |
\subsection{\label{oopseSec:energyFunctions}{\sc duff} Energy Functions} |
| 627 |
> |
\subsubsection{\label{oopseSec:energyFunctions}{\sc duff} Energy Functions} |
| 628 |
|
|
| 629 |
|
The total potential energy function in {\sc duff} is |
| 630 |
|
\begin{equation} |
| 753 |
|
is the taper radius some given thickness less than the electrostatic |
| 754 |
|
cutoff. The switching thickness can be set in the \texttt{.bass} file. |
| 755 |
|
|
| 756 |
< |
\subsection{\label{oopseSec:SSD}The {\sc duff} Water Models: SSD/E and SSD/RF} |
| 756 |
> |
\subsubsection{\label{oopseSec:SSD}The {\sc duff} Water Models: SSD/E and SSD/RF} |
| 757 |
|
|
| 758 |
|
In the interest of computational efficiency, the default solvent used |
| 759 |
|
by {\sc oopse} is the extended Soft Sticky Dipole (SSD/E) water |
| 871 |
|
|
| 872 |
|
\subsection{\label{oopseSec:eam}Embedded Atom Method} |
| 873 |
|
|
| 874 |
< |
There are Molecular Dynamics packages which have the |
| 875 |
< |
capacity to simulate metallic systems, including some that have |
| 876 |
< |
parallel computational abilities\cite{plimpton93}. Potentials that |
| 599 |
< |
describe bonding transition metal |
| 600 |
< |
systems\cite{Finnis84,Ercolessi88,Chen90,Qi99,Ercolessi02} have an |
| 601 |
< |
attractive interaction which models ``Embedding'' |
| 874 |
> |
{\sc oopse} implements a potential that |
| 875 |
> |
describes bonding transition metal |
| 876 |
> |
systems\cite{Finnis84,Ercolessi88,Chen90,Qi99,Ercolessi02} and has attractive interaction which models ``Embedding'' |
| 877 |
|
a positively charged metal ion in the electron density due to the |
| 878 |
|
free valance ``sea'' of electrons created by the surrounding atoms in |
| 879 |
|
the system. A mostly-repulsive pairwise part of the potential |
| 965 |
|
In this way, particles are allowed to diffuse freely in $\mathbf{r}$, |
| 966 |
|
but their minimum images, $\mathbf{r}^{\prime}$ are used to compute |
| 967 |
|
the inter-atomic forces. |
| 693 |
– |
|
| 694 |
– |
|
| 695 |
– |
\section{\label{oopseSec:IOfiles}Input and Output Files} |
| 696 |
– |
|
| 697 |
– |
\subsection{{\sc bass} and Model Files} |
| 698 |
– |
|
| 699 |
– |
Every {\sc oopse} simulation begins with a Bizarre Atom Simulation |
| 700 |
– |
Syntax ({\sc bass}) file. {\sc bass} is a script syntax that is parsed |
| 701 |
– |
by {\sc oopse} at runtime. The {\sc bass} file allows for the user to |
| 702 |
– |
completely describe the system they wish to simulate, as well as tailor |
| 703 |
– |
{\sc oopse}'s behavior during the simulation. {\sc bass} files are |
| 704 |
– |
denoted with the extension |
| 705 |
– |
\texttt{.bass}, an example file is shown in |
| 706 |
– |
Scheme~\ref{sch:bassExample}. |
| 707 |
– |
|
| 708 |
– |
\begin{lstlisting}[float,caption={[An example of a complete {\sc bass} file] An example showing a complete {\sc bass} file.},label={sch:bassExample}] |
| 709 |
– |
|
| 710 |
– |
molecule{ |
| 711 |
– |
name = "Ar"; |
| 712 |
– |
nAtoms = 1; |
| 713 |
– |
atom[0]{ |
| 714 |
– |
type="Ar"; |
| 715 |
– |
position( 0.0, 0.0, 0.0 ); |
| 716 |
– |
} |
| 717 |
– |
} |
| 718 |
– |
|
| 719 |
– |
nComponents = 1; |
| 720 |
– |
component{ |
| 721 |
– |
type = "Ar"; |
| 722 |
– |
nMol = 108; |
| 723 |
– |
} |
| 724 |
– |
|
| 725 |
– |
initialConfig = "./argon.init"; |
| 726 |
– |
|
| 727 |
– |
forceField = "LJ"; |
| 728 |
– |
ensemble = "NVE"; // specify the simulation ensemble |
| 729 |
– |
dt = 1.0; // the time step for integration |
| 730 |
– |
runTime = 1e3; // the total simulation run time |
| 731 |
– |
sampleTime = 100; // trajectory file frequency |
| 732 |
– |
statusTime = 50; // statistics file frequency |
| 733 |
– |
|
| 734 |
– |
\end{lstlisting} |
| 735 |
– |
|
| 736 |
– |
Within the \texttt{.bass} file it is necessary to provide a complete |
| 737 |
– |
description of the molecule before it is actually placed in the |
| 738 |
– |
simulation. The {\sc bass} syntax was originally developed with this |
| 739 |
– |
goal in mind, and allows for the specification of all the atoms in a |
| 740 |
– |
molecular prototype, as well as any bonds, bends, or torsions. These |
| 741 |
– |
descriptions can become lengthy for complex molecules, and it would be |
| 742 |
– |
inconvenient to duplicate the simulation at the beginning of each {\sc |
| 743 |
– |
bass} script. Addressing this issue {\sc bass} allows for the |
| 744 |
– |
inclusion of model files at the top of a \texttt{.bass} file. These |
| 745 |
– |
model files, denoted with the \texttt{.mdl} extension, allow the user |
| 746 |
– |
to describe a molecular prototype once, then simply include it into |
| 747 |
– |
each simulation containing that molecule. Returning to the example in |
| 748 |
– |
Scheme~\ref{sch:bassExample}, the \texttt{.mdl} file's contents would |
| 749 |
– |
be Scheme~\ref{sch:mdlExample}, and the new \texttt{.bass} file would |
| 750 |
– |
become Scheme~\ref{sch:bassExPrime}. |
| 751 |
– |
|
| 752 |
– |
\begin{lstlisting}[float,caption={An example \texttt{.mdl} file.},label={sch:mdlExample}] |
| 753 |
– |
|
| 754 |
– |
molecule{ |
| 755 |
– |
name = "Ar"; |
| 756 |
– |
nAtoms = 1; |
| 757 |
– |
atom[0]{ |
| 758 |
– |
type="Ar"; |
| 759 |
– |
position( 0.0, 0.0, 0.0 ); |
| 760 |
– |
} |
| 761 |
– |
} |
| 762 |
– |
|
| 763 |
– |
\end{lstlisting} |
| 764 |
– |
|
| 765 |
– |
\begin{lstlisting}[float,caption={Revised {\sc bass} example.},label={sch:bassExPrime}] |
| 766 |
– |
|
| 767 |
– |
#include "argon.mdl" |
| 768 |
– |
|
| 769 |
– |
nComponents = 1; |
| 770 |
– |
component{ |
| 771 |
– |
type = "Ar"; |
| 772 |
– |
nMol = 108; |
| 773 |
– |
} |
| 774 |
– |
|
| 775 |
– |
initialConfig = "./argon.init"; |
| 968 |
|
|
| 777 |
– |
forceField = "LJ"; |
| 778 |
– |
ensemble = "NVE"; |
| 779 |
– |
dt = 1.0; |
| 780 |
– |
runTime = 1e3; |
| 781 |
– |
sampleTime = 100; |
| 782 |
– |
statusTime = 50; |
| 969 |
|
|
| 784 |
– |
\end{lstlisting} |
| 970 |
|
|
| 786 |
– |
\subsection{\label{oopseSec:coordFiles}Coordinate Files} |
| 787 |
– |
|
| 788 |
– |
The standard format for storage of a systems coordinates is a modified |
| 789 |
– |
xyz-file syntax, the exact details of which can be seen in |
| 790 |
– |
Scheme~\ref{sch:dumpFormat}. As all bonding and molecular information |
| 791 |
– |
is stored in the \texttt{.bass} and \texttt{.mdl} files, the |
| 792 |
– |
coordinate files are simply the complete set of coordinates for each |
| 793 |
– |
atom at a given simulation time. One important note, although the |
| 794 |
– |
simulation propagates the complete rotation matrix, directional |
| 795 |
– |
entities are written out using quanternions, to save space in the |
| 796 |
– |
output files. |
| 797 |
– |
|
| 798 |
– |
\begin{lstlisting}[float,caption={[The format of the coordinate files]Shows the format of the coordinate files. The fist line is the number of atoms. The second line begins with the time stamp followed by the three $\mathsf{H}$ column vectors. It is important to note, that for extended system ensembles, additional information pertinent to the integrators may be stored on this line as well. The next lines are the atomic coordinates for all atoms in the system. First is the name followed by position, velocity, quanternions, and lastly, body fixed angular momentum.},label=sch:dumpFormat] |
| 799 |
– |
|
| 800 |
– |
nAtoms |
| 801 |
– |
time; Hxx Hyx Hzx; Hxy Hyy Hzy; Hxz Hyz Hzz; |
| 802 |
– |
Name1 x y z vx vy vz q0 q1 q2 q3 jx jy jz |
| 803 |
– |
Name2 x y z vx vy vz q0 q1 q2 q3 jx jy jz |
| 804 |
– |
etc... |
| 805 |
– |
|
| 806 |
– |
\end{lstlisting} |
| 807 |
– |
|
| 808 |
– |
|
| 809 |
– |
There are three major files used by {\sc oopse} written in the |
| 810 |
– |
coordinate format, they are as follows: the initialization file |
| 811 |
– |
(\texttt{.init}), the simulation trajectory file (\texttt{.dump}), and |
| 812 |
– |
the final coordinates of the simulation (\texttt{.eor}). The initialization file is |
| 813 |
– |
necessary for {\sc oopse} to start the simulation with the proper |
| 814 |
– |
coordinates, and is generated before the simulation run. The |
| 815 |
– |
trajectory file is created at the beginning of the simulation, and is |
| 816 |
– |
used to store snapshots of the simulation at regular intervals. The |
| 817 |
– |
first frame is a duplication of the |
| 818 |
– |
\texttt{.init} file, and each subsequent frame is appended to the file |
| 819 |
– |
at an interval specified in the \texttt{.bass} file with the |
| 820 |
– |
\texttt{sampleTime} flag. The final coordinate file is the end of run file. The |
| 821 |
– |
\texttt{.eor} file stores the final configuration of the system for a |
| 822 |
– |
given simulation. The file is updated at the same time as the |
| 823 |
– |
\texttt{.dump} file, however, it only contains the most recent |
| 824 |
– |
frame. In this way, an \texttt{.eor} file may be used as the |
| 825 |
– |
initialization file to a second simulation in order to continue a |
| 826 |
– |
simulation or recover one from a processor that has crashed during the |
| 827 |
– |
course of the run. |
| 828 |
– |
|
| 829 |
– |
\subsection{\label{oopseSec:initCoords}Generation of Initial Coordinates} |
| 830 |
– |
|
| 831 |
– |
As was stated in Sec.~\ref{oopseSec:coordFiles}, an initialization |
| 832 |
– |
file is needed to provide the starting coordinates for a |
| 833 |
– |
simulation. Several helper programs are provided with {\sc oopse} to illustrate possible build routes. However, as each simulation is different, system creation is left to the end user. The {\tt .init} file must list the atoms in the correct order or {\sc oopse} will give an atom mismatch error. |
| 834 |
– |
|
| 835 |
– |
The correct ordering of the atoms relies on the ordering of atoms and molecules within the model and {\sc bass} scripts. {\sc oopse} expects the order to comply with the following guidelines: |
| 836 |
– |
\begin{enumerate} |
| 837 |
– |
\item All of the molecules of the first declared component are given before proceeding to the molecules of the second component, and so on for all declared components. |
| 838 |
– |
\item The ordering of the atoms for each molecule follows the order declared in the molecule's declaration within the model file. |
| 839 |
– |
\end{enumerate} |
| 840 |
– |
An example is given in Scheme~\ref{sch:initEx1} resulting in the {\tt .init} file shown in Scheme~\ref{sch:initEx2}. |
| 841 |
– |
|
| 842 |
– |
\begin{lstlisting}[float,caption={This scheme illustrates the declaration of the $\text{I}_2$ molecule and the HCl molecule. The two molecules are then included into a simulation.}, label=sch:initEx1] |
| 843 |
– |
|
| 844 |
– |
molecule{ |
| 845 |
– |
name = "I2"; |
| 846 |
– |
nAtoms = 2; |
| 847 |
– |
atom[0]{ |
| 848 |
– |
type = "I"; |
| 849 |
– |
} |
| 850 |
– |
atom[1]{ |
| 851 |
– |
type = "I"; |
| 852 |
– |
} |
| 853 |
– |
nBonds = 1; |
| 854 |
– |
bond[0]{ |
| 855 |
– |
members( 0, 1); |
| 856 |
– |
} |
| 857 |
– |
} |
| 858 |
– |
|
| 859 |
– |
molecule{ |
| 860 |
– |
name = "HCl" |
| 861 |
– |
nAtoms = 2; |
| 862 |
– |
atom[0]{ |
| 863 |
– |
type = "H"; |
| 864 |
– |
} |
| 865 |
– |
atom[1]{ |
| 866 |
– |
type = "Cl"; |
| 867 |
– |
} |
| 868 |
– |
nBonds = 1; |
| 869 |
– |
bond[0]{ |
| 870 |
– |
members( 0, 1); |
| 871 |
– |
} |
| 872 |
– |
} |
| 873 |
– |
|
| 874 |
– |
nComponents = 2; |
| 875 |
– |
component{ |
| 876 |
– |
type = "HCl"; |
| 877 |
– |
nMol = 4; |
| 878 |
– |
} |
| 879 |
– |
component{ |
| 880 |
– |
type = "I2"; |
| 881 |
– |
nMol = 1; |
| 882 |
– |
} |
| 883 |
– |
|
| 884 |
– |
initialConfig = "mixture.init"; |
| 885 |
– |
|
| 886 |
– |
\end{lstlisting} |
| 887 |
– |
|
| 888 |
– |
\begin{lstlisting}[float,caption={This is the contents of the {\tt mixture.init} file matching the declarations in Scheme~\ref{sch:initEx1}. Note that even though $\text{I}_2$ is declared before HCl, the {\tt .init} file follows the order in which the components were included.},label=sch:initEx2] |
| 889 |
– |
|
| 890 |
– |
10 |
| 891 |
– |
0.0; 10.0 0.0 0.0; 0.0 10.0 0.0; 0.0 0.0 10.0; |
| 892 |
– |
H ... |
| 893 |
– |
Cl ... |
| 894 |
– |
H ... |
| 895 |
– |
Cl ... |
| 896 |
– |
H ... |
| 897 |
– |
Cl ... |
| 898 |
– |
H ... |
| 899 |
– |
Cl ... |
| 900 |
– |
I ... |
| 901 |
– |
I ... |
| 902 |
– |
|
| 903 |
– |
\end{lstlisting} |
| 904 |
– |
|
| 905 |
– |
|
| 906 |
– |
\subsection{The Statistics File} |
| 907 |
– |
|
| 908 |
– |
The last output file generated by {\sc oopse} is the statistics |
| 909 |
– |
file. This file records such statistical quantities as the |
| 910 |
– |
instantaneous temperature, volume, pressure, etc. It is written out |
| 911 |
– |
with the frequency specified in the \texttt{.bass} file with the |
| 912 |
– |
\texttt{statusTime} keyword. The file allows the user to observe the |
| 913 |
– |
system variables as a function of simulation time while the simulation |
| 914 |
– |
is in progress. One useful function the statistics file serves is to |
| 915 |
– |
monitor the conserved quantity of a given simulation ensemble, this |
| 916 |
– |
allows the user to observe the stability of the integrator. The |
| 917 |
– |
statistics file is denoted with the \texttt{.stat} file extension. |
| 918 |
– |
|
| 971 |
|
\section{\label{oopseSec:mechanics}Mechanics} |
| 972 |
|
|
| 973 |
|
\subsection{\label{oopseSec:integrate}Integrating the Equations of Motion: the |
