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{{\sc bass} and Model Files} |
94 |
> |
|
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={[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; |
109 |
> |
atom[0]{ |
110 |
> |
type="Ar"; |
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 |
292 |
|
} |
293 |
|
\end{lstlisting} |
294 |
|
|
295 |
+ |
\subsection{\label{sec:miscConcepts}Putting a Script Together} |
296 |
+ |
|
297 |
+ |
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. |
298 |
+ |
|
299 |
+ |
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}). |
300 |
+ |
|
301 |
+ |
\subsection{\label{oopseSec:coordFiles}Coordinate Files} |
302 |
+ |
|
303 |
+ |
The standard format for storage of a systems coordinates is a modified |
304 |
+ |
xyz-file syntax, the exact details of which can be seen in |
305 |
+ |
Scheme~\ref{sch:dumpFormat}. As all bonding and molecular information |
306 |
+ |
is stored in the \texttt{.bass} and \texttt{.mdl} files, the |
307 |
+ |
coordinate files are simply the complete set of coordinates for each |
308 |
+ |
atom at a given simulation time. One important note, although the |
309 |
+ |
simulation propagates the complete rotation matrix, directional |
310 |
+ |
entities are written out using quanternions, to save space in the |
311 |
+ |
output files. |
312 |
+ |
|
313 |
+ |
\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] |
314 |
+ |
|
315 |
+ |
nAtoms |
316 |
+ |
time; Hxx Hyx Hzx; Hxy Hyy Hzy; Hxz Hyz Hzz; |
317 |
+ |
Name1 x y z vx vy vz q0 q1 q2 q3 jx jy jz |
318 |
+ |
Name2 x y z vx vy vz q0 q1 q2 q3 jx jy jz |
319 |
+ |
etc... |
320 |
+ |
|
321 |
+ |
\end{lstlisting} |
322 |
+ |
|
323 |
+ |
|
324 |
+ |
There are three major files used by {\sc oopse} written in the |
325 |
+ |
coordinate format, they are as follows: the initialization file |
326 |
+ |
(\texttt{.init}), the simulation trajectory file (\texttt{.dump}), and |
327 |
+ |
the final coordinates of the simulation (\texttt{.eor}). The initialization file is |
328 |
+ |
necessary for {\sc oopse} to start the simulation with the proper |
329 |
+ |
coordinates, and is generated before the simulation run. The |
330 |
+ |
trajectory file is created at the beginning of the simulation, and is |
331 |
+ |
used to store snapshots of the simulation at regular intervals. The |
332 |
+ |
first frame is a duplication of the |
333 |
+ |
\texttt{.init} file, and each subsequent frame is appended to the file |
334 |
+ |
at an interval specified in the \texttt{.bass} file with the |
335 |
+ |
\texttt{sampleTime} flag. The final coordinate file is the end of run file. The |
336 |
+ |
\texttt{.eor} file stores the final configuration of the system for a |
337 |
+ |
given simulation. The file is updated at the same time as the |
338 |
+ |
\texttt{.dump} file, however, it only contains the most recent |
339 |
+ |
frame. In this way, an \texttt{.eor} file may be used as the |
340 |
+ |
initialization file to a second simulation in order to continue a |
341 |
+ |
simulation or recover one from a processor that has crashed during the |
342 |
+ |
course of the run. |
343 |
+ |
|
344 |
+ |
\subsection{\label{oopseSec:initCoords}Generation of Initial Coordinates} |
345 |
+ |
|
346 |
+ |
As was stated in Sec.~\ref{oopseSec:coordFiles}, an initialization |
347 |
+ |
file is needed to provide the starting coordinates for a |
348 |
+ |
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. |
349 |
+ |
|
350 |
+ |
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: |
351 |
+ |
\begin{enumerate} |
352 |
+ |
\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. |
353 |
+ |
\item The ordering of the atoms for each molecule follows the order declared in the molecule's declaration within the model file. |
354 |
+ |
\end{enumerate} |
355 |
+ |
An example is given in Scheme~\ref{sch:initEx1} resulting in the {\tt .init} file shown in Scheme~\ref{sch:initEx2}. |
356 |
+ |
|
357 |
+ |
\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] |
358 |
+ |
|
359 |
+ |
molecule{ |
360 |
+ |
name = "I2"; |
361 |
+ |
nAtoms = 2; |
362 |
+ |
atom[0]{ |
363 |
+ |
type = "I"; |
364 |
+ |
} |
365 |
+ |
atom[1]{ |
366 |
+ |
type = "I"; |
367 |
+ |
} |
368 |
+ |
nBonds = 1; |
369 |
+ |
bond[0]{ |
370 |
+ |
members( 0, 1); |
371 |
+ |
} |
372 |
+ |
} |
373 |
+ |
|
374 |
+ |
molecule{ |
375 |
+ |
name = "HCl" |
376 |
+ |
nAtoms = 2; |
377 |
+ |
atom[0]{ |
378 |
+ |
type = "H"; |
379 |
+ |
} |
380 |
+ |
atom[1]{ |
381 |
+ |
type = "Cl"; |
382 |
+ |
} |
383 |
+ |
nBonds = 1; |
384 |
+ |
bond[0]{ |
385 |
+ |
members( 0, 1); |
386 |
+ |
} |
387 |
+ |
} |
388 |
+ |
|
389 |
+ |
nComponents = 2; |
390 |
+ |
component{ |
391 |
+ |
type = "HCl"; |
392 |
+ |
nMol = 4; |
393 |
+ |
} |
394 |
+ |
component{ |
395 |
+ |
type = "I2"; |
396 |
+ |
nMol = 1; |
397 |
+ |
} |
398 |
+ |
|
399 |
+ |
initialConfig = "mixture.init"; |
400 |
+ |
|
401 |
+ |
\end{lstlisting} |
402 |
+ |
|
403 |
+ |
\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] |
404 |
+ |
|
405 |
+ |
10 |
406 |
+ |
0.0; 10.0 0.0 0.0; 0.0 10.0 0.0; 0.0 0.0 10.0; |
407 |
+ |
H ... |
408 |
+ |
Cl ... |
409 |
+ |
H ... |
410 |
+ |
Cl ... |
411 |
+ |
H ... |
412 |
+ |
Cl ... |
413 |
+ |
H ... |
414 |
+ |
Cl ... |
415 |
+ |
I ... |
416 |
+ |
I ... |
417 |
+ |
|
418 |
+ |
\end{lstlisting} |
419 |
+ |
|
420 |
+ |
|
421 |
+ |
\subsection{The Statistics File} |
422 |
+ |
|
423 |
+ |
The last output file generated by {\sc oopse} is the statistics |
424 |
+ |
file. This file records such statistical quantities as the |
425 |
+ |
instantaneous temperature, volume, pressure, etc. It is written out |
426 |
+ |
with the frequency specified in the \texttt{.bass} file with the |
427 |
+ |
\texttt{statusTime} keyword. The file allows the user to observe the |
428 |
+ |
system variables as a function of simulation time while the simulation |
429 |
+ |
is in progress. One useful function the statistics file serves is to |
430 |
+ |
monitor the conserved quantity of a given simulation ensemble, this |
431 |
+ |
allows the user to observe the stability of the integrator. The |
432 |
+ |
statistics file is denoted with the \texttt{.stat} file extension. |
433 |
+ |
|
434 |
+ |
|
435 |
+ |
\section{\label{oopseSec:empiricalEnergy}The Empirical Energy Functions} |
436 |
+ |
|
437 |
+ |
\ |
438 |
|
\subsection{\label{sec:LJPot}The Lennard Jones Force Field} |
439 |
|
|
440 |
|
The most basic force field implemented in {\sc oopse} is the |
922 |
|
In this way, particles are allowed to diffuse freely in $\mathbf{r}$, |
923 |
|
but their minimum images, $\mathbf{r}^{\prime}$ are used to compute |
924 |
|
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}. |
925 |
|
|
752 |
– |
\begin{lstlisting}[float,caption={An example \texttt{.mdl} file.},label={sch:mdlExample}] |
926 |
|
|
754 |
– |
molecule{ |
755 |
– |
name = "Ar"; |
756 |
– |
nAtoms = 1; |
757 |
– |
atom[0]{ |
758 |
– |
type="Ar"; |
759 |
– |
position( 0.0, 0.0, 0.0 ); |
760 |
– |
} |
761 |
– |
} |
927 |
|
|
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"; |
776 |
– |
|
777 |
– |
forceField = "LJ"; |
778 |
– |
ensemble = "NVE"; |
779 |
– |
dt = 1.0; |
780 |
– |
runTime = 1e3; |
781 |
– |
sampleTime = 100; |
782 |
– |
statusTime = 50; |
783 |
– |
|
784 |
– |
\end{lstlisting} |
785 |
– |
|
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 |
– |
|
928 |
|
\section{\label{oopseSec:mechanics}Mechanics} |
929 |
|
|
930 |
|
\subsection{\label{oopseSec:integrate}Integrating the Equations of Motion: the |