ViewVC Help
View File | Revision Log | Show Annotations | View Changeset | Root Listing
root/group/trunk/oopsePaper/oopsePaper.tex
(Generate patch)

Comparing trunk/oopsePaper/oopsePaper.tex (file contents):
Revision 1168 by mmeineke, Wed May 12 19:32:47 2004 UTC vs.
Revision 1434 by chrisfen, Thu Jul 29 18:01:05 2004 UTC

# Line 3 | Line 3
3   \usepackage{amssymb}
4   \usepackage{endfloat}
5   \usepackage{listings}
6 < \usepackage{palatino}
6 > \usepackage{berkeley}
7   \usepackage{graphicx}
8   \usepackage[ref]{overcite}
9   \usepackage{setspace}
# Line 35 | Line 35 | We detail the capabilities of a new open-source parall
35   \maketitle
36  
37   \begin{abstract}
38 < We detail the capabilities of a new open-source parallel simulation
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}).
38 > {\sc oopse} is a new molecular dynamics simulation program which is
39 > capable of efficiently integrating equations of motion for atom types
40 > with orientational degrees of freedom (e.g. ``sticky'' atoms and point
41 > dipoles).  Transition metals can also be simulated using the embedded
42 > atom method ({\sc eam}) potential included in the code.  Parallel
43 > simulations are carried out using the force-based decomposition
44 > method.  Simulations are specified using a very simple C-based
45 > meta-data language.  A number of advanced integrators are included,
46 > and the base integrator for orientational dynamics provides
47 > substantial improvements over older quaternion-base schemes.  All
48 > source code is available under a very permissive (BSD-style) Open
49 > Source license.
50   \end{abstract}
51  
52   \section{\label{sec:intro}Introduction}
53  
54 < When choosing to simulate a chemical system with molecular dynamics,
55 < there are a variety of options available. For simple systems, one
56 < might consider writing one's own programming code. However, as systems
57 < grow larger and more complex, building and maintaining code for the
58 < simulations becomes a time consuming task. In such cases it is usually
59 < more convenient for a researcher to turn to pre-existing simulation
60 < packages. These packages, such as {\sc amber}\cite{pearlman:1995} and
61 < {\sc charmm}\cite{Brooks83}, provide powerful tools for researchers to
62 < conduct simulations of their systems without spending their time
63 < developing a code base to conduct their research. This then frees them
64 < to perhaps explore experimental analogues to their models.
54 > There are a number of excellent molecular dynamics packages available
55 > to the chemical physics
56 > community.\cite{Brooks83,MacKerell98,pearlman:1995,Gromacs,Gromacs3,DL_POLY,Tinker,Paradyn}
57 > All of these packages are stable, polished programs which solve many
58 > problems of interest.  Most are now capable of performing molecular
59 > dynamics simulations on parallel computers.  Some have source code
60 > which is freely available to the entire scientific community.  Few,
61 > however, are capable of efficiently integrating the equations of
62 > motion for atom types with orientational degrees of freedom
63 > (e.g. point dipoles, and ``sticky'' atoms).  And only one of the
64 > programs referenced can handle transition metal force fields like the
65 > Embedded Atom Method ({\sc eam}).  The direction our research program
66 > has taken us now involves the use of atoms with orientational degrees
67 > of freedom and transition metals.  Since these simulation methods may
68 > be of some use to other researchers, we have decided to release our
69 > program to the scientific community with a permissive open source
70 > license.
71  
72 < Despite their utility, problems with these packages arise when
73 < researchers try to develop techniques or energetic models that the
74 < code was not originally designed to simulate. Examples of techniques
75 < and energetics not commonly implemented include; dipole-dipole
76 < interactions, rigid body dynamics, and metallic potentials. When faced
77 < with these obstacles, a researcher must either develop their own code
78 < or license and extend one of the commercial packages. What we have
79 < elected to do is develop a body of simulation code capable of
80 < implementing the types of models upon which our research is based.
72 > This paper communicates the algorithmic details of our program, which
73 > we have been calling the Open source Object-oriented Parallel
74 > Simulation Engine (i.e. {\sc oopse}).  We have structured this paper
75 > to first discuss the underlying concepts in this simulation package
76 > (Sec. \ref{oopseSec:IOfiles}).  The empirical energy functions
77 > implemented are discussed in Sec.~\ref{oopseSec:empiricalEnergy}.
78 > Sec.~\ref{oopseSec:mechanics} describes the various Molecular Dynamics
79 > algorithms {\sc oopse} implements in the integration of Hamilton's
80 > equations of motion.  Program design considerations for parallel
81 > computing are presented in
82 > Sec.~\ref{oopseSec:parallelization}. Concluding remarks are presented
83 > in Sec.~\ref{oopseSec:conclusion}.
84  
85 < In developing {\sc oopse}, we have adhered to the precepts of Open
70 < Source development, and are releasing our source code with a
71 < permissive license. It is our intent that by doing so, other
72 < researchers might benefit from our work, and add their own
73 < contributions to the package. The license under which {\sc oopse} is
74 < distributed allows any researcher to download and modify the source
75 < code for their own use. In this way further development of {\sc oopse}
76 < is not limited to only the models of interest to ourselves, but also
77 < those of the community of scientists who contribute back to the
78 < project.
85 > \section{\label{oopseSec:IOfiles}Concepts \& Files}
86  
87 < We have structured this paper to first discuss the empirical energy
88 < functions that {\sc oopse } implements in
89 < Sec.~\ref{oopseSec:empiricalEnergy}. Following that is a discussion of
90 < the various input and output files associated with the package
91 < (Sec.~\ref{oopseSec:IOfiles}). Sec.~\ref{oopseSec:mechanics}
92 < elucidates the various Molecular Dynamics algorithms {\sc oopse}
86 < implements in the integration of the Newtonian equations of
87 < motion.  Program design
88 < considerations are presented in Sec.~\ref{oopseSec:design}. And
89 < lastly, Sec.~\ref{oopseSec:conclusion} concludes the chapter.
87 > A simulation in {\sc oopse} is built using a few fundamental
88 > conceptual building blocks most of which are chemically intuitive.
89 > The basic unit of a simulation is an {\tt atom}.  The parameters
90 > describing an {\tt atom} have been generalized to make it as flexible
91 > as possible; this means that in addition to translational degrees of
92 > freedom, {\tt Atoms} may also have {\it orientational} degrees of freedom.
93  
94 < \section{\label{oopseSec:IOfiles}Concepts \& Files}
94 > The fundamental (static) properties of {\tt atoms} are defined by the
95 > {\tt forceField} chosen for the simulation.  The atomic properties
96 > specified by a {\tt forceField} might include (but are not limited to)
97 > charge, $\sigma$ and $\epsilon$ values for Lennard-Jones interactions,
98 > the strength of the dipole moment ($\mu$), the mass, and the moments
99 > of inertia.  Other more complicated properties of atoms might also be
100 > specified by the {\tt forceField}.
101  
102 < \subsection{{\sc bass} and Model Files}
102 > {\tt Atoms} can be grouped together in many ways.  A {\tt rigidBody}
103 > contains atoms that exert no forces on one another and which move as a
104 > single rigid unit.  A {\tt cutoffGroup} may contain atoms which
105 > function together as a (rigid {\it or} non-rigid) unit for potential
106 > energy calculations,
107 > \begin{equation}
108 > V_{ab} = s(r_{ab}) \sum_{i \in a} \sum_{j \in b} V_{ij}(r_{ij})
109 > \end{equation}
110 > Here, $a$ and $b$ are two {\tt cutoffGroups} containing multiple atoms
111 > ($a = \left\{i\right\}$ and $b = \left\{j\right\}$).  $s(r_{ab})$ is a
112 > generalized switching function which insures that the atoms in the two
113 > {\tt cutoffGroups} are treated identically as the two groups enter or
114 > leave an interaction region.
115  
116 < Every {\sc oopse} simulation begins with a Bizarre Atom Simulation
117 < Syntax ({\sc bass}) file. {\sc bass} is a script syntax that is parsed
118 < by {\sc oopse} at runtime. The {\sc bass} file allows for the user to
119 < 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}.
116 > {\tt Atoms} may also be grouped in more traditional ways into {\tt
117 > bonds}, {\tt bends}, and {\tt torsions}.  These groupings allow the
118 > correct choice of interaction parameters for short-range interactions
119 > to be chosen from the definitions in the {\tt forceField}.
120  
121 < \begin{lstlisting}[float,caption={[An example of a complete {\sc bass} file] An example showing a complete {\sc bass} file.},label={sch:bassExample}]
121 > All of these groups of {\tt atoms} are brought together in the {\tt
122 > molecule}, which is the fundamental structure for setting up and {\sc
123 > oopse} simulation.  {\tt Molecules} contain lists of {\tt atoms}
124 > followed by listings of the other atomic groupings ({\tt bonds}, {\tt
125 > bends}, {\tt torsions}, {\tt rigidBodies}, and {\tt cutoffGroups})
126 > which relate the atoms to one another.
127  
128 + Simulations often involve heterogeneous collections of molecules.  To
129 + specify a mixture of {\tt molecule} types, {\sc oopse} uses {\tt
130 + components}.  Even simulations containing only one type of molecule
131 + must specify a single {\tt component}.
132 +
133 + Starting a simulation requires two types of information: {\it
134 + meta-data}, which describes the types of objects present in the
135 + simulation, and {\it configuration} information, which describes the
136 + initial state of these objects.  The meta-data is given to {\sc oopse}
137 + using a C-based syntax that is parsed at the beginning of the
138 + simulation.  Configuration information is specified using an extended
139 + XYZ file format.  Both the meta-data and configuration file formats
140 + are described in the following sections.
141 +
142 + \subsection{Meta-data Files}
143 +
144 + {\sc oopse} uses a C-based script syntax to parse the meta-data files
145 + at run time.  These files allow the user to completely describe the
146 + system they wish to simulate, as well as tailor {\sc oopse}'s behavior
147 + during the simulation.  Meta-data files are typically denoted with the
148 + extension {\tt .md} (which can stand for Meta-Data or Molecular
149 + Dynamics or Molecule Definition depending on the user's mood). An
150 + example meta-data file is shown in Scheme~\ref{sch:mdExample}.
151 +
152 + \begin{lstlisting}[float,caption={[An example of a complete meta-data
153 + file] An example showing a complete meta-data
154 + file.},label={sch:mdExample}]
155 +
156   molecule{
157    name = "Ar";
158    nAtoms = 1;
# Line 118 | Line 168 | initialConfig = "./argon.init";
168    nMol = 108;
169   }
170  
171 < initialConfig = "./argon.init";
171 > initialConfig = "./argon.in";
172  
173   forceField = "LJ";
174   ensemble = "NVE"; // specify the simulation ensemble
# Line 129 | Line 179 | Within the \texttt{.bass} file it is necessary to prov
179  
180   \end{lstlisting}
181  
182 < Within the \texttt{.bass} file it is necessary to provide a complete
182 > Within the meta-data file it is necessary to provide a complete
183   description of the molecule before it is actually placed in the
184 < simulation. The {\sc bass} syntax was originally developed with this
185 < goal in mind, and allows for the specification of all the atoms in a
186 < molecular prototype, as well as any bonds, bends, or torsions. These
187 < descriptions can become lengthy for complex molecules, and it would be
188 < inconvenient to duplicate the simulation at the beginning of each {\sc
189 < bass} script. Addressing this issue {\sc bass} allows for the
190 < inclusion of model files at the top of a \texttt{.bass} file. These
191 < model files, denoted with the \texttt{.mdl} extension, allow the user
192 < 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}.
184 > simulation. {\sc oopse}'s meta-data syntax was originally developed
185 > with this goal in mind, and allows for the use of {\it include files}
186 > to specify all atoms in a molecular prototype, as well as any bonds,
187 > bends, or torsions.  Include files allow the user to describe a
188 > molecular prototype once, then simply include it into each simulation
189 > containing that molecule. Returning to the example in
190 > Scheme~\ref{sch:mdExample}, the include file's contents would be
191 > Scheme~\ref{sch:mdIncludeExample}, and the new meta-data file would
192 > become Scheme~\ref{sch:mdExPrime}.
193  
194 < \begin{lstlisting}[float,caption={An example \texttt{.mdl} file.},label={sch:mdlExample}]
194 > \begin{lstlisting}[float,caption={An example molecule definition in an
195 > include file.},label={sch:mdIncludeExample}]
196  
197   molecule{
198    name = "Ar";
# Line 158 | Line 205 | molecule{
205  
206   \end{lstlisting}
207  
208 < \begin{lstlisting}[float,caption={Revised {\sc bass} example.},label={sch:bassExPrime}]
208 > \begin{lstlisting}[float,caption={Revised meta-data example.},label={sch:mdExPrime}]
209  
210 < #include "argon.mdl"
210 > #include "argon.md"
211  
212   nComponents = 1;
213   component{
# Line 168 | Line 215 | initialConfig = "./argon.init";
215    nMol = 108;
216   }
217  
218 < initialConfig = "./argon.init";
218 > initialConfig = "./argon.in";
219  
220   forceField = "LJ";
221   ensemble = "NVE";
# Line 179 | Line 226 | statusTime = 50;
226  
227   \end{lstlisting}
228  
229 < \subsection{\label{oopseSec:atomsMolecules}Atoms, Molecules and Rigid Bodies}
229 > \subsection{\label{oopseSec:atomsMolecules}Atoms, Molecules, and other
230 > ways of grouping atoms}
231  
232 < The basic unit of an {\sc oopse} simulation is the atom. The
233 < parameters describing the atom are generalized to make the atom as
234 < flexible a representation as possible. They may represent specific
235 < atoms of an element, or be used for collections of atoms such as
236 < methyl and carbonyl groups. The atoms are also capable of having
237 < directional components associated with them (\emph{e.g.}~permanent
238 < dipoles). Charges, permanent dipoles, and Lennard-Jones parameters for
239 < a given atom type are set in the force field parameter files.
232 > As mentioned above, the fundamental unit for an {\sc oopse} simulation
233 > is the {\tt atom}.  Atoms can be collected into secondary structures
234 > such as {\tt rigidBodies}, {\tt cutoffGroups}, or {\tt molecules}. The
235 > {\tt molecule} is a way for {\sc oopse} to keep track of the atoms in
236 > a simulation in logical manner. Molecular units store the identities
237 > of all the atoms and rigid bodies associated with themselves, and they
238 > are responsible for the evaluation of their own internal interactions
239 > (\emph{i.e.}~bonds, bends, and torsions). Scheme
240 > \ref{sch:mdIncludeExample} shows how one creates a molecule in an
241 > included meta-data file. The positions of the atoms given in the
242 > declaration are relative to the origin of the molecule, and the origin
243 > is used when creating a system containing the molecule.
244  
245 < Atoms can be collected into secondary structures such as rigid bodies
246 < or molecules. The molecule is a way for {\sc oopse} to keep track of
247 < the atoms in a simulation in logical manner. Molecular units store the
248 < 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: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.
203 <
204 < As stated previously, one of the features that sets {\sc oopse} apart
205 < from most of the current molecular simulation packages is the ability
206 < to handle rigid body dynamics. Rigid bodies are non-spherical
207 < particles or collections of particles that have a constant internal
245 > One of the features that sets {\sc oopse} apart from most of the
246 > current molecular simulation packages is the ability to handle rigid
247 > body dynamics. Rigid bodies are non-spherical particles or collections
248 > of particles (e.g. $\mbox{C}_{60}$) that have a constant internal
249   potential and move collectively.\cite{Goldstein01} They are not
250   included in most simulation packages because of the algorithmic
251 < complexity involved in propagating orientational degrees of
252 < freedom. Until recently, integrators which propagate orientational
253 < motion have had energy conservation problems when compared to  those available for translational
254 < motion.
251 > complexity involved in propagating orientational degrees of freedom.
252 > Integrators which propagate orientational motion with an acceptable
253 > level of energy conservation for molecular dynamics are relatively
254 > new inventions.  
255  
256   Moving a rigid body involves determination of both the force and
257   torque applied by the surroundings, which directly affect the
# Line 220 | Line 261 | the rigid body. The torque on rigid body $i$ is
261   the rigid body is simply the sum of these external forces.
262   Accumulation of the total torque on the rigid body is more complex
263   than the force because the torque is applied to the center of mass of
264 < the rigid body. The torque on rigid body $i$ is
264 > the rigid body. The space-fixed torque on rigid body $i$ is
265   \begin{equation}
266   \boldsymbol{\tau}_i=
267          \sum_{a}\biggl[(\mathbf{r}_{ia}-\mathbf{r}_i)\times \mathbf{f}_{ia}
# Line 247 | Line 288 | systems.\cite{Evans77}
288   performance enhancements, particularly for very small
289   systems.\cite{Evans77}
290  
291 < {\sc oopse} utilizes a relatively new scheme that propagates the
292 < entire nine parameter rotation matrix. Further discussion
293 < on this choice can be found in Sec.~\ref{oopseSec:integrate}. An example
294 < definition of a rigid body can be seen in Scheme
291 > Rather than use one of the previously stated methods, {\sc oopse}
292 > utilizes a relatively new scheme that propagates the entire nine
293 > parameter rotation matrix. Further discussion on this choice can be
294 > found in Sec.~\ref{oopseSec:integrate}. An example definition of a
295 > rigid body can be seen in Scheme
296   \ref{sch:rigidBody}.
297  
298 < \begin{lstlisting}[float,caption={[Defining rigid bodies]A sample definition of a molecule containing a rigid body},label={sch:rigidBody}]
298 > \begin{lstlisting}[float,caption={[Defining rigid bodies]A sample
299 > definition of a molecule containing a rigid body and a cutoff
300 > group},label={sch:rigidBody}]
301   molecule{
302    name = "TIP3P";
303    nAtoms = 3;
# Line 275 | Line 319 | molecule{
319      nMembers = 3;
320      members(0, 1, 2);
321    }
322 +
323 +  nCutoffGroups = 1;
324 +  cutoffGroup[0]{
325 +    nMembers = 3;
326 +    members(0, 1, 2);
327 +  }
328   }
329   \end{lstlisting}
330  
331 < \subsection{\label{sec:miscConcepts}Putting a Script Together}
331 > \subsection{\label{sec:miscConcepts}Creating a Metadata File}
332  
333 < 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.
333 > The actual creation of a metadata file requires several key
334 > components. The first part of the file needs to be the declaration of
335 > all of the molecule prototypes used in the simulation. This is
336 > typically done through included meta-data files. Only the molecules
337 > actually present in the simulation need to be declared; however, {\sc
338 > oopse} allows for the declaration of more molecules than are
339 > needed. This gives the user the ability to build up a library of
340 > commonly used molecules into a single include file.
341  
342 < 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.
342 > Once all prototypes are declared, the ordering of the rest of the
343 > script is less stringent.  The molecular composition of the simulation
344 > is specified with {\tt component} statements. Each different type of
345 > molecule present in the simulation is considered a separate
346 > component. The number of components must be declared before the first
347 > component block statement (an example is shown in
348 > Sch.~\ref{sch:mdExPrime}).  The component blocks tell {\sc oopse} the
349 > number of molecules that will be in the simulation, and the order in
350 > which the components blocks are declared sets the ordering of the real
351 > atoms in the configuration file as well as in the output files. The
352 > remainder of the script then sets the various simulation parameters
353 > for the system of interest.
354  
355 < 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}.
355 > The required set of parameters that must be present in all simulations
356 > is given in Table~\ref{table:reqParams}.  Since the user can use {\sc
357 > oopse} to perform energy minimizations as well as molecular dynamics
358 > simulations, one of the {\tt minimizer} or {\tt ensemble} keywords
359 > must be present.  The {\tt ensemble} keyword is responsible for
360 > selecting the integration method used for the calculation of the
361 > equations of motion. An in depth discussion of the various methods
362 > available in {\sc oopse} can be found in
363 > Sec.~\ref{oopseSec:mechanics}.  The {\tt minimizer} keyword selects
364 > which minimization method to use, and more details on the choices of
365 > minimizer parameters can be found in
366 > Sec.~\ref{oopseSec:minimizer}. The {\tt forceField} statement is
367 > important for the selection of which forces will be used in the course
368 > of the simulation. {\sc oopse} supports several force fields, as
369 > outlined in Sec.~\ref{oopseSec:empiricalEnergy}. The force fields are
370 > interchangeable between simulations, with the only requirement being
371 > that all atoms needed by the simulation are defined within the
372 > selected force field.
373  
374 + For molecular dynamics simulations, the time step between force
375 + evaluations is set with the {\tt dt} parameter, and {\tt runTime} will
376 + set the time length of the simulation. Note, that {\tt runTime} is an
377 + absolute time, meaning if the simulation is started at t = 10.0~ns
378 + with a {\tt runTime} of 25.0~ns, the simulation will only run for an
379 + additional 15.0~ns.  
380 +
381 + For energy minimizations, it is not necessary to specify {\tt dt} or
382 + {\tt runTime}.
383 +
384 + The final required parameter is the {\tt initialConfig}
385 + statement. This will set the initial coordinates for the system, as
386 + well as the initial time if the {\tt useInitalTime} flag is set to
387 + {\tt true}. The format of the file specified in {\tt initialConfig},
388 + is given in Sec.~\ref{oopseSec:coordFiles}. Additional parameters are
389 + summarized in Table~\ref{table:genParams}.
390 +
391 + It is important to note the fundamental units in all files which are
392 + read and written by {\sc oopse}.  Energies are in $\mbox{kcal
393 + mol}^{-1}$, distances are in $\mbox{\AA}$, times are in $\mbox{fs}$,
394 + translational velocities are in $\mbox{\AA fs}^{-1}$, and masses are
395 + in $\mbox{amu}$.  Orientational degrees of freedom are described using
396 + quaternions (unitless, but $q_w^2 + q_x^2 + q_y^2 + q_z^2 = 1$),
397 + body-fixed angular momenta ($\mbox{amu \AA}^{2} \mbox{radians
398 + fs}^{-1}$), and body-fixed moments of inertia ($\mbox{amu \AA}^{2}$).
399 +
400   \begin{table}
401 < \caption{The Global Keywords: Required Parameters}
401 > \caption{Meta-data Keywords: Required Parameters}
402   \label{table:reqParams}
403   \begin{center}
404   % Note when adding or removing columns, the \hsize numbers must add up to the total number
# Line 301 | Line 412 | The remainder of the script then sets the various simu
412   {\bf keyword} & {\bf units} & {\bf use} & {\bf remarks} \\ \hline
413  
414   {\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. \\
415   {\tt nComponents} & integer & Sets the number of components. & Needs to appear before the first {\tt Component} block. \\
416   {\tt initialConfig} & string & Sets the file containing the initial configuration. & Can point to any file containing the configuration in the correct order. \\
417 < {\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}. \\
417 > {\tt minimizer}& string & Chooses a minimizer & Possible minimizers
418 > are "SD" and "CG". Either {\tt ensemble} or {\tt minimizer} must be specified. \\
419 > {\tt ensemble} & string & Sets the ensemble. & Possible ensembles are
420 > "NVE", "NVT", "NPTi", "NPTf", and "NPTxyz".  Either {\tt ensemble}
421 > or {\tt minimizer} must be specified. \\
422 > {\tt dt} & fs & Sets the time step. & Selection of {\tt dt} should be
423 > small enough to sample the fastest motion of the simulation. (required
424 > for molecular dynamics simulations)\\
425 > {\tt runTime} & fs & Sets the time at which the simulation should
426 > end. & This is an absolute time, and will end the simulation when the
427 > current time meets or exceeds the {\tt runTime}. (required for
428 > molecular dynamics simulations)\\
429  
310
430   \end{tabularx}
431   \end{center}
432   \end{table}
433  
434   \begin{table}
435 < \caption{The Global Keywords: General Parameters}
435 > \caption{Meta-data Keywords: General Parameters}
436   \label{table:genParams}
437   \begin{center}
438   % Note when adding or removing columns, the \hsize numbers must add up to the total number
# Line 326 | Line 445 | The remainder of the script then sets the various simu
445  
446   {\bf keyword} & {\bf units} & {\bf use} & {\bf remarks} \\ \hline
447  
448 < {\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. \\
449 < {\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. \\
448 > {\tt finalConfig} & string & Sets the name of the final
449 > output file. & Useful when stringing simulations together. Defaults to
450 > the root name of the initial meta-data file but with an {\tt .eor}
451 > extension. \\
452 > {\tt useInitialTime} & logical & Sets whether the initial time is taken from the {\tt .in} file. & Useful when recovering a simulation from a crashed processor. Default is false. \\
453   {\tt sampleTime} & fs & Sets the frequency at which the {\tt .dump} file is written. & Default sets the frequency to the {\tt runTime}. \\
454 < {\tt statusTime} & fs & Sets the frequency at which the {\tt .stat} file is written. & Defaults sets the frequency to the {\tt sampleTime}. \\
455 < {\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. \\
456 < {\tt electrostaticCutoffRadius}& & & \\
457 <      & $\mbox{\AA}$ & Manually sets the cutoff used by the electrostatic potentials. & Defaults to $15\mbox{\AA}$ \\
458 < {\tt electrostaticSkinThickness} & & & \\
459 <     & $\mbox{\AA}$  & Manually sets the skin thickness for the electrostatic switching function. & Defaults to 5~\% of the {\tt electrostaticSkinThickness}. \\
454 > {\tt statusTime} & fs & Sets the frequency at which the {\tt .stat} file is written. & Defaults set the frequency to the {\tt sampleTime}. \\
455 > {\tt cutoffRadius} & $\mbox{\AA}$ & Manually sets the cutoffRadius & Defaults to
456 > $15\mbox{\AA}$ for systems containing charges or dipoles or to $2.5
457 > \sigma_{L}$, where $\sigma_{L}$ is the largest LJ $\sigma$ in the
458 > simulation. \\
459 > {\tt switchingRadius} & $\mbox{\AA}$  & Manually sets the inner radius for the switching function. & Defaults to 95~\% of the {\tt cutoffRadius}. \\
460   {\tt useReactionField} & logical & Turns the reaction field correction on/off. & Default is "false". \\
461   {\tt dielectric} & unitless & Sets the dielectric constant for reaction field. & If {\tt useReactionField} is true, then {\tt dielectric} must be set. \\
462   {\tt usePeriodicBoundaryConditions} & & & \\
463          & logical & Turns periodic boundary conditions on/off. & Default is "true". \\
464 < {\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.
464 > {\tt seed } & integer & Sets the seed value for the random number
465 > generator. & The seed needs to be at least 9 digits long. The default
466 > is to take the seed from the CPU clock. \\
467 > {\tt forceFieldVariant} & string & Sets the name of the variant of the
468 > force field.  ({\sc eam} has three variants: {\tt u3}, {\tt u6}, and
469 > {\tt VC}.
470  
471   \end{tabularx}
472   \end{center}
473   \end{table}
474  
475  
349
476   \subsection{\label{oopseSec:coordFiles}Coordinate Files}
477  
478   The standard format for storage of a systems coordinates is a modified
479   xyz-file syntax, the exact details of which can be seen in
480   Scheme~\ref{sch:dumpFormat}. As all bonding and molecular information
481 < is stored in the \texttt{.bass} and \texttt{.mdl} files, the
482 < coordinate files are simply the complete set of coordinates for each
483 < atom at a given simulation time. One important note, although the
484 < simulation propagates the complete rotation matrix, directional
485 < entities are written out using quanternions, to save space in the
486 < output files.
481 > is stored in the meta-data files, the coordinate files contain only
482 > the coordinates of the objects which move independently during the
483 > simulation.  It is important to note that {\it not all atoms} are
484 > capable of independent motion.  Atoms which are part of rigid bodies
485 > are not ``integrable objects'' in the equations of motion; the rigid
486 > bodies themselves are the integrable objects.  Therefore, the
487 > coordinate file contains coordinates of all the {\tt
488 > integrableObjects} in the system.  For systems without rigid bodies,
489 > this is simply the coordinates of all the atoms.
490  
491 < \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]
491 > It is important to note that although the simulation propagates the
492 > complete rotation matrix, directional entities are written out using
493 > quaternions to save space in the output files.  All objects (atoms,
494 > orientational atoms, and rigid bodies) are given quaternions and
495 > angular momenta in coordinate files which are output by OOPSE, but it
496 > is not necessary for the user to specify the quaternions or angular
497 > momenta for atoms without orientational degrees of freedom.
498  
499 < nAtoms
499 > \begin{lstlisting}[float,caption={[The format of the coordinate
500 > files] An example of the format of the coordinate files. The fist line
501 > is the number of {\tt integrableObjects} (freely-moving atoms and
502 > rigid bodies). The second line begins with the time stamp followed by
503 > the three $\mathsf{H}$ column vectors. It is important to note that
504 > for extended system ensembles, additional information pertinent to the
505 > integrators may be stored on this line as well. The next lines are the
506 > coordinates for all integrable objects in the system.  The name of the
507 > integrable object is followed by position, velocity, quaternions, and
508 > lastly, body fixed angular momentum.},label=sch:dumpFormat]
509 >
510 > nIntegrable
511   time; Hxx Hyx Hzx; Hxy Hyy Hzy; Hxz Hyz Hzz;
512 < Name1 x y z vx vy vz q0 q1 q2 q3 jx jy jz
513 < Name2 x y z vx vy vz q0 q1 q2 q3 jx jy jz
512 > Name1 x y z vx vy vz qw qx qy qz jx jy jz
513 > Name2 x y z vx vy vz qw qx qy qz jx jy jz
514   etc...
515  
516   \end{lstlisting}
517  
518 + The {\tt name} field for atoms is simply the atom type as specified in
519 + the meta-data file.  The {\tt name} field for a rigid body is
520 + specified as {\tt MOLTYPE\_RB\_N}, to specify that this is {\tt
521 + rigidBody} N in a molecule of type MOLTYPE.  In simulations with rigid
522 + body models of water, a sample coordinate line might be:
523  
524 < There are three major files used by {\sc oopse} written in the
525 < coordinate format, they are as follows: the initialization file
526 < (\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.
524 > \begin{tt}
525 > TIP3P\_RB\_0  x y z vx vy vz qw qx qy qz jx jy jz
526 > \end{tt}
527  
528 < \subsection{\label{oopseSec:initCoords}Generation of Initial Coordinates}
528 > which tells the program that the rigid body representing a TIP3P
529 > molecule (rigid body \# 0) is listed on that line.
530  
531 < As was stated in Sec.~\ref{oopseSec:coordFiles}, an initialization
532 < file is needed to provide the starting coordinates for a
533 < 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.
531 > There are three files used by {\sc oopse} which are written in the
532 > coordinate format.  They are: the initial coordinate file
533 > (\texttt{.in}), the simulation trajectory file (\texttt{.dump}), and
534 > the final coordinates or ``end-of-run'' for the simulation
535 > (\texttt{.eor}). The initial coordinate file is necessary for {\sc
536 > oopse} to start the simulation with the proper coordinates, and this
537 > file must be generated by the user before the simulation run. The
538 > trajectory (or ``dump'') file is updated during simulation and is used
539 > to store snapshots of the coordinates at regular intervals. The first
540 > frame is a duplication of the
541 > \texttt{.in} file, and each subsequent frame is appended to the file
542 > at an interval specified in the meta-data file with the
543 > \texttt{sampleTime} flag. The final coordinate file is the
544 > ``end-of-run'' file.  The \texttt{.eor} file stores the final
545 > configuration of the system for a given simulation. The file is
546 > updated at the same time as the \texttt{.dump} file, but it only
547 > contains the most recent frame. In this way, an \texttt{.eor} file may
548 > be used to initialize a second simulation should it be necessary to
549 > recover from a crash or power outage.
550  
551 < 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:
551 > \subsection{\label{oopseSec:initCoords}Generation of Initial Coordinates}
552 >
553 > As was stated in Sec.~\ref{oopseSec:coordFiles}, an initial coordinate
554 > file is needed to provide the starting coordinates for a simulation.
555 > Since each simulation is different, system creation is left to the end
556 > user; however, we have included a few sample programs which make some
557 > specialized structures.  The {\tt .in} file must list the integrable
558 > objects in the correct order.  The ordering of the integrable objects
559 > relies on the ordering of molecules within the meta-data file. {\sc
560 > oopse} expects the order to comply with the following guidelines:
561   \begin{enumerate}
562 < \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.
563 < \item The ordering of the atoms for each molecule follows the order declared in the molecule's declaration within the model file.
562 > \item All of the molecules of the first declared component are given
563 > before proceeding to the molecules of the second component, and so on
564 > for all subsequently declared components.
565 > \item The ordering of the atoms for each molecule follows the order
566 > declared in the molecule's declaration within the model file.
567 > \item Only atoms which are not members of a {\tt rigidBody} are
568 > included
569 > \item Rigid Body coordinates for a molecule are listed immediately
570 > after the the other atoms in a molecule.  Some molecules may be
571 > entirely rigid, in which case, only the rigid body coordinates are
572 > given.
573   \end{enumerate}
574 < An example is given in Scheme~\ref{sch:initEx1} resulting in the {\tt .init} file shown in Scheme~\ref{sch:initEx2}.
574 > An example is given in the meta-data file in Scheme~\ref{sch:initEx1}
575 > which results in the {\tt .in} file shown in Scheme~\ref{sch:initEx2}.
576  
577 < \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]
577 > \begin{lstlisting}[float,caption={Example declaration of the
578 > $\text{I}_2$ molecule and the HCl molecule. The two molecules are then
579 > included into a simulation.}, label=sch:initEx1]
580  
581   molecule{
582    name = "I2";
# Line 445 | Line 618 | initialConfig = "mixture.init";
618    nMol = 1;
619   }
620  
621 < initialConfig = "mixture.init";
621 > initialConfig = "mixture.in";
622  
623   \end{lstlisting}
624  
625 < \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]
625 > \begin{lstlisting}[float,caption={The contents of the {\tt
626 > mixture.in} file matching the declarations in
627 > Scheme~\ref{sch:initEx1}. Note that even though $\text{I}_2$ is
628 > declared before HCl, the {\tt .in} file follows the order {\it in
629 > which the components were included}.},label=sch:initEx2]
630  
631   10
632   0.0;  10.0  0.0  0.0;  0.0  10.0  0.0;  0.0  0.0  10.0;
# Line 471 | Line 648 | instantaneous temperature, volume, pressure, etc. It i
648  
649   The last output file generated by {\sc oopse} is the statistics
650   file. This file records such statistical quantities as the
651 < instantaneous temperature, volume, pressure, etc. It is written out
652 < with the frequency specified in the \texttt{.bass} file with the
651 > instantaneous temperature (in $K$), volume (in $\mbox{\AA}^{3}$),
652 > pressure (in $\mbox{atm}$), etc. It is written out with the frequency
653 > specified in the meta-data file with the
654   \texttt{statusTime} keyword. The file allows the user to observe the
655   system variables as a function of simulation time while the simulation
656   is in progress. One useful function the statistics file serves is to
657 < monitor the conserved quantity of a given simulation ensemble, this
658 < allows the user to observe the stability of the integrator. The
657 > monitor the conserved quantity of a given simulation ensemble,
658 > allowing the user to gauge the stability of the integrator. The
659   statistics file is denoted with the \texttt{.stat} file extension.
660  
661 + \section{\label{oopseSec:empiricalEnergy}The Empirical Energy
662 + Functions}
663  
664 < \section{\label{oopseSec:empiricalEnergy}The Empirical Energy Functions}
664 > Like many simulation packages, {\sc oopse} splits the potential energy
665 > into the short-ranged (bonded) portion and a long-range (non-bonded)
666 > potential,
667 > \begin{equation}
668 > V = V_{\mathrm{short-range}} + V_{\mathrm{long-range}}.
669 > \end{equation}
670 > The short-ranged portion includes explicit bonds, bends and torsions,
671 > which have been defined in the meta-data file for the molecules which
672 > present in the simulation.  The functional forms and parameters for
673 > these interactions are defined by the force field which is chosen.
674  
675 < \
675 > Calculating long-range (non-bonded) potential involves a sum over all
676 > pairs of atoms (except for those atoms which are involved in a bond,
677 > bend, or torsion with each other).  If done poorly, calculating the
678 > the long-range interactions for $N$ atoms would involve $N^2$
679 > evaluations of atomic distance.  To reduce the number of distance
680 > evaluations between pairs of atoms, {\sc oopse} uses a switched cutoff
681 > with Verlet neighbor lists.\cite{allen87:csl} It is well known that
682 > neutral groups which contain charges will exhibit pathological forces
683 > unless the cutoff is applied to the neutral groups evenly instead of
684 > to the individual atoms.\cite{leach01:mm} {\sc oopse} allows users to
685 > specify cutoff groups which may contain an arbitrary number of atoms
686 > in the molecule.  Atoms in a cutoff group are treated as a single unit
687 > for the evaluation of the switching function:
688 > \begin{equation}
689 > V_{\mathrm{long-range}} = \sum_{a} \sum_{b>a} s(r_{ab}) \sum_{i \in a} \sum_{j \in b} V_{ij}(r_{ij}),
690 > \end{equation}
691 > where $r_{ab}$ is the distance between the centers of mass of the two
692 > cutoff groups ($a$ and $b$).
693 >
694 > The sums over $a$ and $b$ are over the cutoffGroups that are present
695 > in the simulation.  Atoms which are not explicitly defined as members
696 > of a {\tt cutoffGroup} are treated as a group consisting of only one
697 > atom.  The switching function, $s(r)$ is the standard cubic switching
698 > function,
699 > \begin{equation}
700 > S(r) =
701 >        \begin{cases}
702 >        1 & \text{if $r \le r_{\text{sw}}$},\\
703 >        \frac{(r_{\text{cut}} + 2r - 3r_{\text{sw}})(r_{\text{cut}} - r)^2}
704 >        {(r_{\text{cut}} - r_{\text{sw}})^2}
705 >        & \text{if $r_{\text{sw}} < r \le r_{\text{cut}}$}, \\
706 >        0 & \text{if $r > r_{\text{cut}}$.}
707 >        \end{cases}
708 > \label{eq:dipoleSwitching}
709 > \end{equation}
710 > Here, $r_{\text{sw}}$ is the {\tt switchingRadius}, or the distance
711 > beyond which interactions are reduced, and $r_{\text{cut}}$ is the
712 > {\tt cutoffRadius}, or the distance at which interactions are
713 > truncated.
714 >
715 > Users of {\sc oopse} do not need to specify the {\tt cutoffRadius} or
716 > {\tt switchingRadius}.  In simulations containing only Lennard-Jones
717 > atoms, the cutoff radius has a default value of $2.5\sigma_{ii}$,
718 > where $\sigma_{ii}$ is the largest Lennard-Jones length parameter
719 > present in the simulation.  In simulations containing charged or
720 > dipolar atoms, the default cutoff Radius is $15 \mbox{\AA}$.  
721 >
722 > The {\tt switchingRadius} is set to a default value of 95\% of the
723 > {\tt cutoffRadius}.  In the special case of a simulation containing
724 > {\it only} Lennard-Jones atoms, the default switching radius takes the
725 > same value as the cutoff radius, and {\sc oopse} will use a shifted
726 > potential to remove discontinuities in the potential at the cutoff.
727 > Both radii may be specified in the meta-data file.
728 >
729 > Force fields can easily be added to {\sc oopse}, although it comes
730 > with a few simple examples (Lennard-Jones, {\sc duff}, {\sc water},
731 > and {\sc eam}) which are explained in the following sections.
732 >
733   \subsection{\label{sec:LJPot}The Lennard Jones Force Field}
734  
735   The most basic force field implemented in {\sc oopse} is the
736 < Lennard-Jones force field, which mimics the van der Waals interaction at
737 < long distances, and uses an empirical repulsion at short
736 > Lennard-Jones force field, which mimics the van der Waals interaction
737 > at long distances and uses an empirical repulsion at short
738   distances. The Lennard-Jones potential is given by:
739   \begin{equation}
740   V_{\text{LJ}}(r_{ij}) =
# Line 501 | Line 747 | $\epsilon_{ij}$ scales the well depth of the potential
747   where $r_{ij}$ is the distance between particles $i$ and $j$,
748   $\sigma_{ij}$ scales the length of the interaction, and
749   $\epsilon_{ij}$ scales the well depth of the potential. Scheme
750 < \ref{sch:LJFF} gives an example \texttt{.bass} file that
750 > \ref{sch:LJFF} gives an example meta-data file that
751   sets up a system of 108 Ar particles to be simulated using the
752   Lennard-Jones force field.
753  
754 < \begin{lstlisting}[float,caption={[Invocation of the Lennard-Jones force field] A sample system using the Lennard-Jones force field.},label={sch:LJFF}]
754 > \begin{lstlisting}[float,caption={[Invocation of the Lennard-Jones
755 > force field] A sample meta-data file for a small Lennard-Jones
756 > simulation.},label={sch:LJFF}]
757  
758 < #include "argon.mdl"
758 > #include "argon.md"
759  
760   nComponents = 1;
761   component{
# Line 515 | Line 763 | initialConfig = "./argon.init";
763    nMol = 108;
764   }
765  
766 < initialConfig = "./argon.init";
766 > initialConfig = "./argon.in";
767  
768   forceField = "LJ";
769   \end{lstlisting}
522
523 Because this potential is calculated between all pairs, the force
524 evaluation can become computationally expensive for large systems. To
525 keep the pair evaluations to a manageable number, {\sc oopse} employs
526 a cut-off radius.\cite{allen87:csl} The cutoff radius can either be
527 specified in the \texttt{.bass} file, or left as its default value of
528 $2.5\sigma_{ii}$, where $\sigma_{ii}$ is the largest Lennard-Jones
529 length parameter present in the simulation. Truncating the calculation
530 at $r_{\text{cut}}$ introduces a discontinuity into the potential
531 energy and the force. To offset this discontinuity in the potential,
532 the energy value at $r_{\text{cut}}$ is subtracted from the
533 potential. This causes the potential to go to zero smoothly at the
534 cut-off radius, and preserves conservation of energy in integrating
535 the equations of motion. There still remains a discontinuity in the derivative (the forces), however, this does not significantly affect the dynamics.
770  
771   Interactions between dissimilar particles requires the generation of
772 < cross term parameters for $\sigma$ and $\epsilon$. These are
773 < calculated through the Lorentz-Berthelot mixing
772 > cross term parameters for $\sigma$ and $\epsilon$. These parameters
773 > are determined using the Lorentz-Berthelot mixing
774   rules:\cite{allen87:csl}
775   \begin{equation}
776   \sigma_{ij} = \frac{1}{2}[\sigma_{ii} + \sigma_{jj}],
# Line 551 | Line 785 | simulate lipid bilayers. The simulations require a mod
785   \subsection{\label{oopseSec:DUFF}Dipolar Unified-Atom Force Field}
786  
787   The dipolar unified-atom force field ({\sc duff}) was developed to
788 < simulate lipid bilayers. The simulations require a model capable of
789 < forming bilayers, while still being sufficiently computationally
790 < efficient to allow large systems ($\sim$100's of phospholipids,
791 < $\sim$1000's of waters) to be simulated for long times
792 < ($\sim$10's of nanoseconds).
788 > simulate lipid bilayers. These types of simulations require a model
789 > capable of forming bilayers, while still being sufficiently
790 > computationally efficient to allow large systems ($\sim$100's of
791 > phospholipids, $\sim$1000's of waters) to be simulated for long times
792 > ($\sim$10's of nanoseconds). With this goal in mind, {\sc duff} has no
793 > point charges. Charge-neutral distributions are replaced with dipoles,
794 > while most atoms and groups of atoms are reduced to Lennard-Jones
795 > interaction sites. This simplification reduces the length scale of
796 > long range interactions from $\frac{1}{r}$ to $\frac{1}{r^3}$,
797 > removing the need for the computationally expensive Ewald
798 > sum. Instead, Verlet neighbor-lists and cutoff radii are used for the
799 > dipolar interactions, and, if desired, a reaction field may be added
800 > to mimic longer range interactions.
801  
560 With this goal in mind, {\sc duff} has no point
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}$, 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
802   As an example, lipid head-groups in {\sc duff} are represented as
803 < point dipole interaction sites. By placing a dipole at the head
804 < group's center of mass, our model mimics the charge separation found
805 < in common phospholipid head groups such as
806 < phosphatidylcholine.\cite{Cevc87} Additionally, a large Lennard-Jones
807 < site is located at the pseudoatom's center of mass. The model is
808 < illustrated by the red atom in Fig.~\ref{oopseFig:lipidModel}. The
809 < water model we use to complement the dipoles of the lipids is our
810 < reparameterization\cite{fennell04} of the soft sticky dipole (SSD) model of Ichiye
803 > point dipole interaction sites.  Placing a dipole at the head group's
804 > center of mass mimics the charge separation found in common
805 > phospholipid head groups such as phosphatidylcholine.\cite{Cevc87}
806 > Additionally, a large Lennard-Jones site is located at the
807 > pseudoatom's center of mass. The model is illustrated by the red atom
808 > in Fig.~\ref{oopseFig:lipidModel}. The water model we use to
809 > complement the dipoles of the lipids is a
810 > reparameterization\cite{fennell04} of the soft sticky dipole (SSD)
811 > model of Ichiye
812   \emph{et al.}\cite{liu96:new_model}
813  
814   \begin{figure}
815   \centering
816 < \includegraphics[width=\linewidth]{twoChainFig.pdf}
817 < \caption[A representation of a lipid model in {\sc duff}]{A representation of the lipid model. $\phi$ is the torsion angle, $\theta$ %
818 < is the bend angle, and $\mu$ is the dipole moment of the head group.}
816 > \includegraphics[width=\linewidth]{lipidModel.eps}
817 > \caption[A representation of a lipid model in {\sc duff}]{A
818 > representation of the lipid model. $\phi$ is the torsion angle,
819 > $\theta$ is the bend angle, and $\mu$ is the dipole moment of the head
820 > group.}
821   \label{oopseFig:lipidModel}
822   \end{figure}
823  
824 < We have used a set of scalable parameters to model the alkyl groups
825 < with Lennard-Jones sites. For this, we have borrowed parameters from
826 < the TraPPE force field of Siepmann
827 < \emph{et al}.\cite{Siepmann1998} TraPPE is a unified-atom
828 < representation of n-alkanes, which is parametrized against phase
829 < equilibria using Gibbs ensemble Monte Carlo simulation
830 < techniques.\cite{Siepmann1998} One of the advantages of TraPPE is that
831 < it generalizes the types of atoms in an alkyl chain to keep the number
832 < of pseudoatoms to a minimum; the parameters for a unified atom such as
833 < $\text{CH}_2$ do not change depending on what species are bonded to
595 < it.
824 > A set of scalable parameters has been used to model the alkyl groups
825 > with Lennard-Jones sites. For this, parameters from the TraPPE force
826 > field of Siepmann \emph{et al.}\cite{Siepmann1998} have been
827 > utilized. TraPPE is a unified-atom representation of n-alkanes which
828 > is parametrized against phase equilibria using Gibbs ensemble Monte
829 > Carlo simulation techniques.\cite{Siepmann1998} One of the advantages
830 > of TraPPE is that it generalizes the types of atoms in an alkyl chain
831 > to keep the number of pseudoatoms to a minimum; thus, the parameters
832 > for a unified atom such as $\text{CH}_2$ do not change depending on
833 > what species are bonded to it.
834  
835 < TraPPE and {\sc duff} also constrain all bonds to be of fixed length. Typically,
836 < bond vibrations are the fastest motions in a molecular dynamic
837 < simulation. Small time steps between force evaluations must be used to
838 < ensure adequate energy conservation in the bond degrees of freedom. By
839 < constraining the bond lengths, larger time steps may be used when
840 < integrating the equations of motion. A simulation using {\sc duff} is
841 < illustrated in Scheme \ref{sch:DUFF}.
842 <
605 < \begin{lstlisting}[float,caption={[Invocation of {\sc duff}]A portion of a \texttt{.bass} file showing a simulation utilizing {\sc duff}},label={sch:DUFF}]
835 > As is required by TraPPE, {\sc duff} also constrains all bonds to be
836 > of fixed length. Typically, bond vibrations are the fastest motions in
837 > a molecular dynamic simulation.  With these vibrations present, small
838 > time steps between force evaluations must be used to ensure adequate
839 > energy conservation in the bond degrees of freedom. By constraining
840 > the bond lengths, larger time steps may be used when integrating the
841 > equations of motion. A simulation using {\sc duff} is illustrated in
842 > Scheme \ref{sch:DUFF}.
843  
844 < #include "water.mdl"
845 < #include "lipid.mdl"
844 > \begin{lstlisting}[float,caption={[Invocation of {\sc duff}]A portion
845 > of a meta-data file showing a simulation utilizing {\sc
846 > duff}},label={sch:DUFF}]  
847  
848 + #include "water.md"
849 + #include "lipid.md"
850 +
851   nComponents = 2;
852   component{
853    type = "simpleLipid_16";
# Line 618 | Line 859 | initialConfig = "bilayer.init";
859    nMol = 1936;
860   }
861  
862 < initialConfig = "bilayer.init";
862 > initialConfig = "bilayer.in";
863  
864   forceField = "DUFF";
865  
# Line 644 | Line 885 | within the molecule $I$, and $V_{\text{torsion}}$ is t
885   \label{eq:internalPotential}
886   \end{equation}
887   Here $V_{\text{bend}}$ is the bend potential for all 1, 3 bonded pairs
888 < within the molecule $I$, and $V_{\text{torsion}}$ is the torsion potential
889 < for all 1, 4 bonded pairs. The pairwise portions of the internal
890 < potential are excluded for atom pairs that are involved in the same bond, bend, or torsion. All other atom pairs within the molecule are subject to the LJ pair potential.
888 > within the molecule $I$, and $V_{\text{torsion}}$ is the torsion
889 > potential for all 1, 4 bonded pairs.  The pairwise portions of the
890 > non-bonded interactions are excluded for atom pairs that are involved
891 > in the smae bond, bend, or torsion. All other atom pairs within a
892 > molecule are subject to the LJ pair potential.
893  
651
894   The bend potential of a molecule is represented by the following function:
895   \begin{equation}
896 < V_{\text{bend}}(\theta_{ijk}) = k_{\theta}( \theta_{ijk} - \theta_0 )^2, \label{eq:bendPot}
896 > V_{\text{bend}}(\theta_{ijk}) = k_{\theta}( \theta_{ijk} - \theta_0
897 > )^2, \label{eq:bendPot}
898   \end{equation}
899   where $\theta_{ijk}$ is the angle defined by atoms $i$, $j$, and $k$
900   (see Fig.~\ref{oopseFig:lipidModel}), $\theta_0$ is the equilibrium
# Line 691 | Line 934 | evaluations are avoided during the calculation of the
934   k_3 &= 4c_3.
935   \end{align*}
936   By recasting the potential as a power series, repeated trigonometric
937 < evaluations are avoided during the calculation of the potential energy.
937 > evaluations are avoided during the calculation of the potential
938 > energy.
939  
940  
941 < The cross potential between molecules $I$ and $J$, $V^{IJ}_{\text{Cross}}$, is
942 < as follows:
941 > The cross potential between molecules $I$ and $J$,
942 > $V^{IJ}_{\text{Cross}}$, is as follows:
943   \begin{equation}
944   V^{IJ}_{\text{Cross}} =
945          \sum_{i \in I} \sum_{j \in J}
# Line 725 | Line 969 | respectively. $|\mu_i|$ is the magnitude of the dipole
969   Here $\mathbf{r}_{ij}$ is the vector starting at atom $i$ pointing
970   towards $j$, and $\boldsymbol{\Omega}_i$ and $\boldsymbol{\Omega}_j$
971   are the orientational degrees of freedom for atoms $i$ and $j$
972 < respectively. $|\mu_i|$ is the magnitude of the dipole moment of atom
973 < $i$, $\boldsymbol{\hat{u}}_i$ is the standard unit orientation vector
974 < of $\boldsymbol{\Omega}_i$, and $\boldsymbol{\hat{r}}_{ij}$ is the
975 < unit vector pointing along $\mathbf{r}_{ij}$
972 > respectively. The magnitude of the dipole moment of atom $i$ is
973 > $|\mu_i|$, $\boldsymbol{\hat{u}}_i$ is the standard unit orientation
974 > vector of $\boldsymbol{\Omega}_i$, and $\boldsymbol{\hat{r}}_{ij}$ is
975 > the unit vector pointing along $\mathbf{r}_{ij}$
976   ($\boldsymbol{\hat{r}}_{ij}=\mathbf{r}_{ij}/|\mathbf{r}_{ij}|$).
977  
978 < To improve computational efficiency of the dipole-dipole interactions,
979 < {\sc oopse} employs an electrostatic cutoff radius. This parameter can
736 < be set in the \texttt{.bass} file, and controls the length scale over
737 < which dipole interactions are felt. To compensate for the
738 < discontinuity in the potential and the forces at the cutoff radius, we
739 < have implemented a switching function to smoothly scale the
740 < dipole-dipole interaction at the cutoff.
741 < \begin{equation}
742 < S(r_{ij}) =
743 <        \begin{cases}
744 <        1 & \text{if $r_{ij} \le r_t$},\\
745 <        \frac{(r_{\text{cut}} + 2r_{ij} - 3r_t)(r_{\text{cut}} - r_{ij})^2}
746 <        {(r_{\text{cut}} - r_t)^2}
747 <        & \text{if $r_t < r_{ij} \le r_{\text{cut}}$}, \\
748 <        0 & \text{if $r_{ij} > r_{\text{cut}}$.}
749 <        \end{cases}
750 < \label{eq:dipoleSwitching}
751 < \end{equation}
752 < Here $S(r_{ij})$ scales the potential at a given $r_{ij}$, and $r_t$
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.
978 > \subsubsection{\label{oopseSec:SSD}The {\sc duff} Water Models: SSD/E
979 > and SSD/RF}
980  
756 \subsubsection{\label{oopseSec:SSD}The {\sc duff} Water Models: SSD/E and SSD/RF}
757
981   In the interest of computational efficiency, the default solvent used
982   by {\sc oopse} is the extended Soft Sticky Dipole (SSD/E) water
983   model.\cite{fennell04} The original SSD was developed by Ichiye
# Line 813 | Line 1036 | Since SSD/E is a single-point {\it dipolar} model, the
1036   can be found in the original SSD
1037   articles.\cite{liu96:new_model,liu96:monte_carlo,chandra99:ssd_md,Ichiye03}
1038  
1039 + \begin{figure}
1040 + \centering
1041 + \includegraphics[width=\linewidth]{waterAngle.eps}
1042 + \caption[Coordinate definition for the SSD/E water model]{Coordinates
1043 + for the interaction between two SSD/E water molecules.  $\theta_{ij}$
1044 + is the angle that $r_{ij}$ makes with the $\hat{z}$ vector in the
1045 + body-fixed frame for molecule $i$.  The $\hat{z}$ vector bisects the
1046 + HOH angle in each water molecule. }
1047 + \label{oopseFig:ssd}
1048 + \end{figure}
1049 +
1050 +
1051   Since SSD/E is a single-point {\it dipolar} model, the force
1052   calculations are simplified significantly relative to the standard
1053   {\it charged} multi-point models. In the original Monte Carlo
1054   simulations using this model, Ichiye {\it et al.} reported that using
1055   SSD decreased computer time by a factor of 6-7 compared to other
1056 < models.\cite{liu96:new_model} What is most impressive is that these savings
1057 < did not come at the expense of accurate depiction of the liquid state
1058 < properties.  Indeed, SSD/E maintains reasonable agreement with the Head-Gordon
1059 < diffraction data for the structural features of liquid
1060 < water.\cite{hura00,liu96:new_model} Additionally, the dynamical properties
1061 < exhibited by SSD/E agree with experiment better than those of more
1062 < computationally expensive models (like TIP3P and
1063 < SPC/E).\cite{chandra99:ssd_md} The combination of speed and accurate depiction
1064 < of solvent properties makes SSD/E a very attractive model for the
1065 < simulation of large scale biochemical simulations.
1056 > models.\cite{liu96:new_model} What is most impressive is that these
1057 > savings did not come at the expense of accurate depiction of the
1058 > liquid state properties.  Indeed, SSD/E maintains reasonable agreement
1059 > with the Head-Gordon diffraction data for the structural features of
1060 > liquid water.\cite{hura00,liu96:new_model} Additionally, the dynamical
1061 > properties exhibited by SSD/E agree with experiment better than those
1062 > of more computationally expensive models (like TIP3P and
1063 > SPC/E).\cite{chandra99:ssd_md} The combination of speed and accurate
1064 > depiction of solvent properties makes SSD/E a very attractive model
1065 > for the simulation of large scale biochemical simulations.
1066  
1067   Recent constant pressure simulations revealed issues in the original
1068   SSD model that led to lower than expected densities at all target
# Line 836 | Line 1071 | model (an SSD variant  parameterized for reaction fiel
1071   exhibits improved liquid structure and transport behavior. If the use
1072   of a reaction field long-range interaction correction is desired, it
1073   is recommended that the parameters be modified to those of the SSD/RF
1074 < model (an SSD variant  parameterized for reaction field). Solvent parameters can be easily modified in an accompanying
1075 < \texttt{.bass} file as illustrated in the scheme below. A table of the
1076 < parameter values and the drawbacks and benefits of the different
1077 < density corrected SSD models can be found in
1078 < reference~\cite{fennell04}.
1074 > model (an SSD variant parameterized for reaction field). These solvent
1075 > parameters are listed and can be easily modified in the {\sc duff}
1076 > force field file ({\tt DUFF.frc}).  A table of the parameter values
1077 > and the drawbacks and benefits of the different density corrected SSD
1078 > models can be found in reference~\citen{fennell04}.
1079  
1080 < \begin{lstlisting}[float,caption={[A simulation of {\sc ssd} water]A portion of a \texttt{.bass} file showing a simulation including {\sc ssd} water.},label={sch:ssd}]
1080 > \subsection{\label{oopseSec:WATER}The {\sc water} Force Field}
1081  
1082 < #include "water.mdl"
1082 > In addition to the {\sc duff} force field's solvent description, a
1083 > separate {\sc water} force field has been included for simulating many
1084 > of the common rigid-body water models. In addition to the simple or
1085 > dipolar models (SSD, SSD1, SSD/E, SSD/RF, and DPD water), the common
1086 > charge-based models were included (SPC, SPC/E, TIP3P, TIP4P, and
1087 > TIP5P).\cite{liu96:new_model,Ichiye03,fennell04,Marrink01,Berendsen81,Berendsen87,Jorgensen83,Mahoney00}
1088 > In order to handle these models, charge-charge interactions were
1089 > included in the force-loop:
1090 > \begin{equation}
1091 > V_{\text{charge}}(r_{ij}) = \sum_{ij}\frac{q_iq_je^2}{r_{ij}},
1092 > \end{equation}
1093 > where $q$ represents the charge on particle $i$ or $j$, and $e$ is the
1094 > charge of an electron in Coulombs. The charge-charge interaction
1095 > support is rudimentary in the current version of {\sc oopse}. As with
1096 > the other pair interactions, charges can be simulated with a pure
1097 > cutoff or a reaction field. The various methods for performing the
1098 > Ewald summation have not yet been included. Also, the charge-dipole
1099 > and charge-quadrupole (for interactions between SSD type water and
1100 > charges) are not yet available, so it is currently inadvisable to mix
1101 > dipolar and charge based molecules in the same system.
1102  
1103 < nComponents = 1;
1104 < component{
1105 <  type = "SSD_water";
1106 <  nMol = 864;
1107 < }
1103 > The {\sc water} force field can be easily expanded through
1104 > modification of the {\sc water} force field file ({\tt WATER.frc}). By
1105 > adding atom types and inserting the appropriate parameters, it is
1106 > possible to extend the force field to handle rigid molecules other
1107 > than water.
1108  
855 initialConfig = "liquidWater.init";
856
857 forceField = "DUFF";
858
859 /*
860 * The following two flags set the cutoff
861 * radius for the electrostatic forces
862 * as well as the skin thickness of the switching
863 * function.
864 */
865
866 electrostaticCutoffRadius  = 9.2;
867 electrostaticSkinThickness = 1.38;
868
869 \end{lstlisting}
870
871
1109   \subsection{\label{oopseSec:eam}Embedded Atom Method}
1110  
1111 < {\sc oopse} implements a potential that
1112 < describes bonding transition metal
1113 < systems\cite{Finnis84,Ercolessi88,Chen90,Qi99,Ercolessi02} and has attractive interaction which models  ``Embedding''
1114 < a positively charged metal ion in the electron density due to the
1111 > {\sc oopse} implements a potential that describes bonding in
1112 > transition metal
1113 > systems.~\cite{Finnis84,Ercolessi88,Chen90,Qi99,Ercolessi02} This
1114 > potential has an attractive interaction which models ``Embedding'' a
1115 > positively charged pseudo-atom core in the electron density due to the
1116   free valance ``sea'' of electrons created by the surrounding atoms in
1117 < the system. A mostly-repulsive pairwise part of the potential
1118 < describes the interaction of the positively charged metal core ions
1119 < with one another. A particular potential description called the
1120 < Embedded Atom Method\cite{Daw84,FBD86,johnson89,Lu97}({\sc eam}) that has
1121 < particularly wide adoption has been selected for inclusion in {\sc oopse}. A
1122 < good review of {\sc eam} and other metallic potential formulations was written
1123 < by Voter.\cite{voter}
1117 > the system.  A pairwise part of the potential (which is primarily
1118 > repulsive) describes the interaction of the positively charged metal
1119 > core ions with one another.  The Embedded Atom Method ({\sc
1120 > eam})~\cite{Daw84,FBD86,johnson89,Lu97} has been widely adopted in the
1121 > materials science community and has been included in {\sc oopse}. A
1122 > good review of {\sc eam} and other formulations of metallic potentials
1123 > was given by Voter.\cite{Voter:95}
1124  
1125   The {\sc eam} potential has the form:
1126 < \begin{eqnarray}
1127 < V & = & \sum_{i} F_{i}\left[\rho_{i}\right] + \sum_{i} \sum_{j \neq i}
1128 < \phi_{ij}({\bf r}_{ij}),  \\
1129 < \rho_{i}  & = & \sum_{j \neq i} f_{j}({\bf r}_{ij}),
1130 < \end{eqnarray}
893 < where $F_{i} $ is the embedding function that equates the energy
1126 > \begin{equation}
1127 > V  =  \sum_{i} F_{i}\left[\rho_{i}\right] + \sum_{i} \sum_{j \neq i}
1128 > \phi_{ij}({\bf r}_{ij})
1129 > \end{equation}
1130 > where $F_{i} $ is an embedding functional that approximates the energy
1131   required to embed a positively-charged core ion $i$ into a linear
1132   superposition of spherically averaged atomic electron densities given
1133 < by $\rho_{i}$.  $\phi_{ij}$ is a primarily repulsive pairwise
1134 < interaction between atoms $i$ and $j$. In the original formulation of
1135 < {\sc eam}\cite{Daw84}, $\phi_{ij}$ was an entirely repulsive term,
1136 < however in later refinements to {\sc eam} have shown that non-uniqueness
1137 < between $F$ and $\phi$ allow for more general forms for
1138 < $\phi$.\cite{Daw89} There is a cutoff distance, $r_{cut}$, which
1139 < limits the summations in the {\sc eam} equation to the few dozen atoms
1133 > by $\rho_{i}$,
1134 > \begin{equation}
1135 > \rho_{i}   =  \sum_{j \neq i} f_{j}({\bf r}_{ij}),
1136 > \end{equation}
1137 > Since the density at site $i$ ($\rho_i$) must be computed before the
1138 > embedding functional can be evaluated, {\sc eam} and the related
1139 > transition metal potentials require two loops through the atom pairs
1140 > to compute the inter-atomic forces.
1141 >
1142 > The pairwise portion of the potential, $\phi_{ij}$, is a primarily
1143 > repulsive interaction between atoms $i$ and $j$. In the original
1144 > formulation of {\sc eam}\cite{Daw84}, $\phi_{ij}$ was an entirely
1145 > repulsive term; however later refinements to {\sc eam} allowed for
1146 > more general forms for $\phi$.\cite{Daw89} The effective cutoff
1147 > distance, $r_{{\text cut}}$ is the distance at which the values of
1148 > $f(r)$ and $\phi(r)$ drop to zero for all atoms present in the
1149 > simulation.  In practice, this distance is fairly small, limiting the
1150 > summations in the {\sc eam} equation to the few dozen atoms
1151   surrounding atom $i$ for both the density $\rho$ and pairwise $\phi$
1152 < interactions. Foiles \emph{et al}.~fit {\sc eam} potentials for the fcc
905 < metals Cu, Ag, Au, Ni, Pd, Pt and alloys of these metals.\cite{FBD86}
906 < These fits are included in {\sc oopse}.
1152 > interactions.
1153  
1154 + In computing forces for alloys, mixing rules as outlined by
1155 + Johnson~\cite{johnson89} are used to compute the heterogenous pair
1156 + potential,
1157 + \begin{eqnarray}
1158 + \label{eq:johnson}
1159 + \phi_{ab}(r)=\frac{1}{2}\left(
1160 + \frac{f_{b}(r)}{f_{a}(r)}\phi_{aa}(r)+
1161 + \frac{f_{a}(r)}{f_{b}(r)}\phi_{bb}(r)
1162 + \right).
1163 + \end{eqnarray}
1164 + No mixing rule is needed for the densities, since the density at site
1165 + $i$ is simply the linear sum of density contributions of all the other
1166 + atoms.
1167 +
1168 + The {\sc eam} force field illustrates an additional feature of {\sc
1169 + oopse}.  Foiles, Baskes and Daw fit {\sc eam} potentials for Cu, Ag,
1170 + Au, Ni, Pd, Pt and alloys of these metals.\cite{FBD86} These fits are
1171 + included in {\sc oopse} as the {\tt u3} variant of the {\sc eam} force
1172 + field.  Voter and Chen reparamaterized a set of {\sc eam} functions
1173 + which do a better job of predicting melting points.\cite{Voter:87}
1174 + These functions are included in {\sc oopse} as the {\tt VC} variant of
1175 + the {\sc eam} force field.  An additional set of functions (the
1176 + ``Universal 6'' functions) are included in {\sc oopse} as the {\tt u6}
1177 + variant of {\sc eam}.  For example, to specify the Voter-Chen variant
1178 + of the {\sc eam} force field, the user would add the {\tt
1179 + forceFieldVariant = "VC";} line to the meta-data file.
1180 +
1181 + The potential files used by the {\sc eam} force field are in the
1182 + standard {\tt funcfl} format, which is the format utilized by a number
1183 + of other codes (e.g. ParaDyn~\cite{Paradyn}, {\sc dynamo 86}).  It
1184 + should be noted that the energy units in these files are in eV, not
1185 + $\mbox{kcal mol}^{-1}$ as in the rest of the {\sc oopse} force field
1186 + files.  
1187 +
1188   \subsection{\label{oopseSec:pbc}Periodic Boundary Conditions}
1189  
1190   \newcommand{\roundme}{\operatorname{round}}
1191  
1192 < \textit{Periodic boundary conditions} are widely used to simulate bulk properties with a relatively small number of particles. The
1193 < simulation box is replicated throughout space to form an infinite
1192 > \textit{Periodic boundary conditions} are widely used to simulate bulk
1193 > properties with a relatively small number of particles. In this method
1194 > the simulation box is replicated throughout space to form an infinite
1195   lattice.  During the simulation, when a particle moves in the primary
1196   cell, its image in other cells move in exactly the same direction with
1197   exactly the same orientation. Thus, as a particle leaves the primary
1198   cell, one of its images will enter through the opposite face. If the
1199   simulation box is large enough to avoid ``feeling'' the symmetries of
1200   the periodic lattice, surface effects can be ignored. The available
1201 < periodic cells in OOPSE are cubic, orthorhombic and parallelepiped. We
1202 < use a $3 \times 3$ matrix, $\mathsf{H}$, to describe the shape and
1203 < size of the simulation box. $\mathsf{H}$ is defined:
1201 > periodic cells in {\sc oopse} are cubic, orthorhombic and
1202 > parallelepiped.  {\sc oopse} use a $3 \times 3$ matrix, $\mathsf{H}$,
1203 > to describe the shape and size of the simulation box. $\mathsf{H}$ is
1204 > defined:
1205   \begin{equation}
1206   \mathsf{H} = ( \mathbf{h}_x, \mathbf{h}_y, \mathbf{h}_z ),
1207   \end{equation}
# Line 936 | Line 1218 | directions. To find the minimum image of a vector $\ma
1218   \end{align}
1219   The vector $\mathbf{s}$ is now a vector expressed as the number of box
1220   lengths in the $\mathbf{h}_x$, $\mathbf{h}_y$, and $\mathbf{h}_z$
1221 < directions. To find the minimum image of a vector $\mathbf{r}$, we
1222 < first convert it to its corresponding vector in box space, and then,
1223 < cast each element to lie in the range $[-0.5,0.5]$:
1221 > directions. To find the minimum image of a vector $\mathbf{r}$, {\sc
1222 > oopse} first converts it to its corresponding vector in box space, and
1223 > then casts each element to lie in the range $[-0.5,0.5]$:
1224   \begin{equation}
1225   s_{i}^{\prime}=s_{i}-\roundme(s_{i}),
1226   \end{equation}
# Line 954 | Line 1236 | than $x$.  For example, $\roundme(3.6)=4$, $\roundme(3
1236   Here $\lfloor x \rfloor$ is the floor operator, and gives the largest
1237   integer value that is not greater than $x$, and $\lceil x \rceil$ is
1238   the ceiling operator, and gives the smallest integer that is not less
1239 < than $x$.  For example, $\roundme(3.6)=4$, $\roundme(3.1)=3$,
958 < $\roundme(-3.6)=-4$, $\roundme(-3.1)=-3$.
1239 > than $x$.
1240  
1241 < Finally, we obtain the minimum image coordinates $\mathbf{r}^{\prime}$ by
1242 < transforming back to real space,
1241 > Finally, the minimum image coordinates $\mathbf{r}^{\prime}$ are
1242 > obtained by transforming back to real space,
1243   \begin{equation}
1244   \mathbf{r}^{\prime}=\mathsf{H}^{-1}\mathbf{s}^{\prime}.%
1245   \end{equation}
1246   In this way, particles are allowed to diffuse freely in $\mathbf{r}$,
1247 < but their minimum images, $\mathbf{r}^{\prime}$ are used to compute
1247 > but their minimum images, or $\mathbf{r}^{\prime}$, are used to compute
1248   the inter-atomic forces.
1249  
1250  
# Line 984 | Line 1265 | motion for $\phi$ and $\psi$,\cite{allen87:csl} leadin
1265   Previous integration methods for orientational motion have problems
1266   that are avoided in the DLM method.  Direct propagation of the Euler
1267   angles has a known $1/\sin\theta$ divergence in the equations of
1268 < motion for $\phi$ and $\psi$,\cite{allen87:csl} leading to
1269 < numerical instabilities any time one of the directional atoms or rigid
1270 < bodies has an orientation near $\theta=0$ or $\theta=\pi$.  More
1271 < modern quaternion-based integration methods have relatively poor
1272 < energy conservation.  While quaternions work well for orientational
1273 < motion in other ensembles, the microcanonical ensemble has a
1274 < constant energy requirement that is quite sensitive to errors in the
1275 < equations of motion.  An earlier implementation of {\sc oopse}
1276 < utilized quaternions for propagation of rotational motion; however, a
1277 < detailed investigation showed that they resulted in a steady drift in
997 < the total energy, something that has been observed by
998 < Laird {\it et al.}\cite{Laird97}      
1268 > motion for $\phi$ and $\psi$,\cite{allen87:csl} leading to numerical
1269 > instabilities any time one of the directional atoms or rigid bodies
1270 > has an orientation near $\theta=0$ or $\theta=\pi$.  Quaternion-based
1271 > integration methods work well for propagating orientational motion;
1272 > however, energy conservation concerns arise when using the
1273 > microcanonical (NVE) ensemble.  An earlier implementation of {\sc
1274 > oopse} utilized quaternions for propagation of rotational motion;
1275 > however, a detailed investigation showed that they resulted in a
1276 > steady drift in the total energy, something that has been observed by
1277 > Laird {\it et al.}\cite{Laird97}
1278  
1279   The key difference in the integration method proposed by Dullweber
1280   \emph{et al.} is that the entire $3 \times 3$ rotation matrix is
# Line 1069 | Line 1348 | is equivalent to the more familiar body-fixed forms,
1348   represented by ${\bf j}$.  This equation of motion for angular momenta
1349   is equivalent to the more familiar body-fixed forms,
1350   \begin{eqnarray}
1351 < \dot{j_{x}} & = & \tau^b_x(t)  +
1352 < \left(\overleftrightarrow{\mathsf{I}}_{yy} - \overleftrightarrow{\mathsf{I}}_{zz} \right) j_y j_z, \\
1353 < \dot{j_{y}} & = & \tau^b_y(t) +
1354 < \left(\overleftrightarrow{\mathsf{I}}_{zz} - \overleftrightarrow{\mathsf{I}}_{xx} \right) j_z j_x,\\
1355 < \dot{j_{z}} & = & \tau^b_z(t) +
1356 < \left(\overleftrightarrow{\mathsf{I}}_{xx} - \overleftrightarrow{\mathsf{I}}_{yy} \right) j_x j_y,
1351 > \dot{j_{x}} & = & \tau^b_x(t)  -
1352 > \left(\overleftrightarrow{\mathsf{I}}_{yy}^{-1} - \overleftrightarrow{\mathsf{I}}_{zz}^{-1} \right) j_y j_z, \\
1353 > \dot{j_{y}} & = & \tau^b_y(t) -
1354 > \left(\overleftrightarrow{\mathsf{I}}_{zz}^{-1} - \overleftrightarrow{\mathsf{I}}_{xx}^{-1} \right) j_z j_x,\\
1355 > \dot{j_{z}} & = & \tau^b_z(t) -
1356 > \left(\overleftrightarrow{\mathsf{I}}_{xx}^{-1} - \overleftrightarrow{\mathsf{I}}_{yy}^{-1} \right) j_x j_y,
1357   \end{eqnarray}
1358   which utilize the body-fixed torques, ${\bf \tau}^b$. Torques are
1359   most easily derived in the space-fixed frame,
# Line 1188 | Line 1467 | propagation. With the same time step, a 1000-molecule
1467  
1468   The matrix rotations used in the DLM method end up being more costly
1469   computationally than the simpler arithmetic quaternion
1470 < propagation. With the same time step, a 1000-molecule water simulation
1471 < shows an average 7\% increase in computation time using the DLM method
1472 < in place of quaternions. This cost is more than justified when
1473 < comparing the energy conservation of the two methods as illustrated in
1474 < Fig.~\ref{timestep}.
1470 > propagation. With the same time step, a 1024-molecule water simulation
1471 > shows an 12\% increase in computation time (averaged over several
1472 > different time steps) using the DLM method in place of
1473 > quaternions. This cost is more than justified when comparing the
1474 > energy conservation of the two methods. Figure ~\ref{quatdlm} provides
1475 > a comparative analysis of the {\sc dlm} method versus the simple
1476 > quaternion method that was originally implemented.
1477  
1478   \begin{figure}
1479   \centering
1480 < \includegraphics[width=\linewidth]{timeStep.pdf}
1481 < \caption[Energy conservation for quaternion versus DLM dynamics]{Energy conservation using quaternion based integration versus
1482 < the method proposed by Dullweber \emph{et al.} with increasing time
1483 < step. For each time step, the dotted line is total energy using the
1484 < DLM integrator, and the solid line comes from the quaternion
1485 < integrator. The larger time step plots are shifted up from the true
1486 < energy baseline for clarity.}
1487 < \label{timestep}
1480 > \includegraphics[width=\linewidth]{quatvsdlm.eps}
1481 > \caption[Energy conservation analysis of the {\sc dlm} and quaternion
1482 > integration methods]{The logarithm of absolute value of the slope of
1483 > the energy drift (\delta E$_1$) and the standard deviation of the
1484 > energy fluctuations (\delta E$_0$) as a function of chosen time
1485 > step. All simulations were of a 1024-molecule simulation of SSD water
1486 > at 298 K starting from the same initial configuration. Note that the
1487 > {\sc dlm} method provides a greater-than order-of-magnitude
1488 > improvement in energy conservation and relative energy fluctuations
1489 > over the quaternion method at all the tested time steps. The energy
1490 > drift is quite steep for the larger time steps in both methods, and
1491 > results in discontinuous behavior as the systems compound their
1492 > anomolous energy accumulation.}
1493 > \label{quatdlm}
1494   \end{figure}
1495  
1496 < In Fig.~\ref{timestep}, the resulting energy drift at various time
1497 < steps for both the DLM and quaternion integration schemes is
1498 < compared. All of the 1000 molecule water simulations started with the
1499 < same configuration, and the only difference was the method for
1500 < handling rotational motion. At time steps of 0.1 and 0.5 fs, both
1501 < methods for propagating molecule rotation conserve energy fairly well,
1502 < with the quaternion method showing a slight energy drift over time in
1503 < the 0.5 fs time step simulation. At time steps of 1 and 2 fs, the
1504 < energy conservation benefits of the DLM method are clearly
1505 < demonstrated. Thus, while maintaining the same degree of energy
1506 < conservation, one can take considerably longer time steps, leading to
1507 < an overall reduction in computation time.
1496 > In Fig.~\ref{quatdlm}, \delta E$_1$ is a measure of the linear energy
1497 > drift in units of kcal/mol per particle over a nanosecond of
1498 > simulation time, and \delta E$_0$ is the standard deviation of the
1499 > energy fluctuations in units of kcal/mol per particle. In the top
1500 > plot, it is apparent that the energy drift is reduced by a significant
1501 > amount (2 to 3 orders-of-magnitude improvement at every tested time
1502 > step) by chosing the {\sc dlm} method over the simple non-symplectic
1503 > quaternion integration method. When the energy drift becomes very
1504 > small ($log_{10}[|\delta\text{E}_1|] < -3$), it is more difficult to
1505 > calculate a slope, resulting in the larger displayed error bars. In
1506 > addition to this improvement in energy drift, the fluctuation is the
1507 > total energy are also dampened out by 1 to 2 orders-of-magnitude by
1508 > utilizing the {\sc dlm} integration method.
1509 >
1510 > It was stated previously that the {\sc dlm} method was the more
1511 > computationally expensive of the two implimented integration
1512 > methodologies. In order to incorporate this information into the
1513 > energy analysis a plot of energy drift versus computational cost was
1514 > generated (Fig.~\ref{cpuCost}). This figure provides an estimate of
1515 > the CPU time required under the two integration schemes for 1
1516 > nanosecond of simulation time for the model 1024-molecule system. The
1517 > plot is read by chosing a desired energy drift value and determining
1518 > where both the curves cross. If a \delta E$_1$ of 1E-3 kcal/mol per
1519 > particle is desired, a nanosecond of simulation time will require ~19
1520 > hours of CPU time with the {\sc dlm} integrator, while the same small
1521 > drift value will require ~154 hours of CPU time. This demonstrates the
1522 > computational advantage of the integration scheme utilized in {\sc
1523 > oopse}.
1524 >
1525 > \begin{figure}
1526 > \centering
1527 > \includegraphics[width=\linewidth]{compCost.eps}
1528 > \caption[Energy drift as a function of required simulation run
1529 > time]{The logarithm of absolute value of the slope of the energy drift
1530 > (\delta E$_1$) as a function of simulation run time. Simulations were
1531 > performed on a single 2.5 GHz Pentium IV processor. Simulation time
1532 > comparisons can be made by tracing horizontally from one curve to the
1533 > other. For example, a simulation that takes ~24 hours using the {\sc
1534 > dlm} method will take roughly 210 hours using the simple quaternion
1535 > method if the same degree of energy conservation is desired.}
1536 > \label{cpuCost}
1537 > \end{figure}
1538  
1539   There is only one specific keyword relevant to the default integrator,
1540   and that is the time step for integrating the equations of motion.
1541  
1542   \begin{center}
1543   \begin{tabular}{llll}
1544 < {\bf variable} & {\bf {\tt .bass} keyword} & {\bf units} & {\bf
1544 > {\bf variable} & {\bf Meta-data keyword} & {\bf units} & {\bf
1545   default value} \\  
1546   $h$ & {\tt dt = 2.0;} & fs & none
1547   \end{tabular}
# Line 1234 | Line 1551 | integrator can selected with the {\tt ensemble} keywor
1551  
1552   {\sc oopse} implements a number of extended system integrators for
1553   sampling from other ensembles relevant to chemical physics.  The
1554 < integrator can selected with the {\tt ensemble} keyword in the
1555 < {\tt .bass} file:
1554 > integrator can be selected with the {\tt ensemble} keyword in the
1555 > meta-data file:
1556  
1557   \begin{center}
1558   \begin{tabular}{lll}
1559 < {\bf Integrator} & {\bf Ensemble} & {\bf {\tt .bass} line} \\
1559 > {\bf Integrator} & {\bf Ensemble} & {\bf Meta-data instruction} \\
1560   NVE & microcanonical & {\tt ensemble = NVE; } \\
1561   NVT & canonical & {\tt ensemble = NVT; } \\
1562   NPTi & isobaric-isothermal & {\tt ensemble = NPTi;} \\
# Line 1254 | Line 1571 | system, and has been shown to sample the canonical dis
1571   The relatively well-known Nos\'e-Hoover thermostat\cite{Hoover85} is
1572   implemented in {\sc oopse}'s NVT integrator.  This method couples an
1573   extra degree of freedom (the thermostat) to the kinetic energy of the
1574 < system, and has been shown to sample the canonical distribution in the
1575 < system degrees of freedom while conserving a quantity that is, to
1574 > system and it has been shown to sample the canonical distribution in
1575 > the system degrees of freedom while conserving a quantity that is, to
1576   within a constant, the Helmholtz free energy.\cite{melchionna93}
1577  
1578   NPT algorithms attempt to maintain constant pressure in the system by
# Line 1279 | Line 1596 | variables.
1596  
1597   \begin{center}
1598   \begin{tabular}{llll}
1599 < {\bf variable} & {\bf {\tt .bass} keyword} & {\bf units} & {\bf
1599 > {\bf variable} & {\bf Meta-data instruction} & {\bf units} & {\bf
1600   default value} \\  
1601   $T_{\mathrm{target}}$ & {\tt targetTemperature = 300;} &  K & none \\
1602   $P_{\mathrm{target}}$ & {\tt targetPressure = 1;} & atm & none \\
# Line 1337 | Line 1654 | $\tau_T$ or $T_{\mathrm{target}}$ in a simulation, one
1654   In eq.(\ref{eq:nosehooverext}), $\tau_T$ is the time constant for
1655   relaxation of the temperature to the target value.  To set values for
1656   $\tau_T$ or $T_{\mathrm{target}}$ in a simulation, one would use the
1657 < {\tt tauThermostat} and {\tt targetTemperature} keywords in the {\tt
1658 < .bass} file.  The units for {\tt tauThermostat} are fs, and the units
1659 < for the {\tt targetTemperature} are degrees K.   The integration of
1660 < the equations of motion is carried out in a velocity-Verlet style 2
1657 > {\tt tauThermostat} and {\tt targetTemperature} keywords in the
1658 > meta-data file.  The units for {\tt tauThermostat} are fs, and the
1659 > units for the {\tt targetTemperature} are degrees K.   The integration
1660 > of the equations of motion is carried out in a velocity-Verlet style 2
1661   part algorithm:
1662  
1663   {\tt moveA:}
# Line 1402 | Line 1719 | Since ${\bf v}(t + h)$ and ${\bf j}(t + h)$ are requir
1719          \chi(t + h) \right) .
1720   \end{align*}
1721  
1722 < Since ${\bf v}(t + h)$ and ${\bf j}(t + h)$ are required to caclculate
1722 > Since ${\bf v}(t + h)$ and ${\bf j}(t + h)$ are required to calculate
1723   $T(t + h)$ as well as $\chi(t + h)$, they indirectly depend on their
1724   own values at time $t + h$.  {\tt moveB} is therefore done in an
1725   iterative fashion until $\chi(t + h)$ becomes self-consistent.  The
# Line 1430 | Line 1747 | To carry out isobaric-isothermal ensemble calculations
1747   \subsection{\label{sec:NPTi}Constant-pressure integration with
1748   isotropic box deformations (NPTi)}
1749  
1750 < To carry out isobaric-isothermal ensemble calculations {\sc oopse}
1750 > To carry out isobaric-isothermal ensemble calculations, {\sc oopse}
1751   implements the Melchionna modifications to the Nos\'e-Hoover-Andersen
1752 < equations of motion,\cite{melchionna93}
1752 > equations of motion.\cite{melchionna93} The equations of motion are
1753 > the same as NVT with the following exceptions:
1754  
1755   \begin{eqnarray}
1756   \dot{{\bf r}} & = & {\bf v} + \eta \left( {\bf r} - {\bf R}_0 \right), \\
1757   \dot{{\bf v}} & = & \frac{{\bf f}}{m} - (\eta + \chi) {\bf v}, \\
1440 \dot{\mathsf{A}} & = & \mathsf{A} \cdot
1441 \mbox{ skew}\left(\overleftrightarrow{I}^{-1} \cdot {\bf j}\right),\\
1442 \dot{{\bf j}} & = & {\bf j} \times \left( \overleftrightarrow{I}^{-1}
1443 \cdot {\bf j} \right) - \mbox{ rot}\left(\mathsf{A}^{T} \cdot \frac{\partial
1444 V}{\partial \mathsf{A}} \right) - \chi {\bf j}, \\
1445 \dot{\chi} & = & \frac{1}{\tau_{T}^2} \left(
1446 \frac{T}{T_{\mathrm{target}}} - 1 \right) ,\\
1758   \dot{\eta} & = & \frac{1}{\tau_{B}^2 f k_B T_{\mathrm{target}}} V \left( P -
1759   P_{\mathrm{target}} \right), \\
1760   \dot{\mathcal{V}} & = & 3 \mathcal{V} \eta .
# Line 1470 | Line 1781 | outer} product of the velocities denoted by the $\otim
1781   \overleftrightarrow{\mathsf{W}}(t).
1782   \end{equation}
1783   The kinetic contribution to the pressure tensor utilizes the {\it
1784 < outer} product of the velocities denoted by the $\otimes$ symbol.  The
1784 > outer} product of the velocities, denoted by the $\otimes$ symbol.  The
1785   stress tensor is calculated from another outer product of the
1786   inter-atomic separation vectors (${\bf r}_{ij} = {\bf r}_j - {\bf
1787   r}_i$) with the forces between the same two atoms,
1788   \begin{equation}
1789   \overleftrightarrow{\mathsf{W}}(t) = \sum_{i} \sum_{j>i} {\bf r}_{ij}(t)
1790   \otimes {\bf f}_{ij}(t).
1791 + \end{equation}
1792 + In systems containing cutoff groups, the stress tensor is computed
1793 + between the centers-of-mass of the cutoff groups:
1794 + \begin{equation}
1795 + \overleftrightarrow{\mathsf{W}}(t) = \sum_{a} \sum_{b} {\bf r}_{ab}(t)
1796 + \otimes {\bf f}_{ab}(t).
1797 + \end{equation}
1798 + where ${\bf r}_{ab}$ is the distance between the centers of mass, and
1799 + \begin{equation}
1800 + {\bf f}_{ab} = s(r_{ab}) \sum_{i \in a} \sum_{j \in b} {\bf f}_{ij} +
1801 + s\prime(r_{ab}) \frac{{\bf r}_{ab}}{|r_{ab}|} \sum_{i \in a} \sum_{j
1802 + \in b} V_{ij}({\bf r}_{ij}).
1803   \end{equation}
1804 +
1805   The instantaneous pressure is then simply obtained from the trace of
1806 < the Pressure tensor,
1806 > the pressure tensor,
1807   \begin{equation}
1808   P(t) = \frac{1}{3} \mathrm{Tr} \left( \overleftrightarrow{\mathsf{P}}(t).
1809   \right)
# Line 1488 | Line 1812 | $\tau_B$ or $P_{\mathrm{target}}$ in a simulation, one
1812   In eq.(\ref{eq:melchionna1}), $\tau_B$ is the time constant for
1813   relaxation of the pressure to the target value.  To set values for
1814   $\tau_B$ or $P_{\mathrm{target}}$ in a simulation, one would use the
1815 < {\tt tauBarostat} and {\tt targetPressure} keywords in the {\tt .bass}
1815 > {\tt tauBarostat} and {\tt targetPressure} keywords in the meta-data
1816   file.  The units for {\tt tauBarostat} are fs, and the units for the
1817   {\tt targetPressure} are atmospheres.  Like in the NVT integrator, the
1818   integration of the equations of motion is carried out in a
1819 < velocity-Verlet style 2 part algorithm:
1819 > velocity-Verlet style 2 part algorithm with only the following differences:
1820  
1821   {\tt moveA:}
1822   \begin{align*}
1499 T(t) &\leftarrow \left\{{\bf v}(t)\right\}, \left\{{\bf j}(t)\right\} ,\\
1500 %
1823   P(t) &\leftarrow \left\{{\bf r}(t)\right\}, \left\{{\bf v}(t)\right\} ,\\
1824   %
1825   {\bf v}\left(t + h / 2\right)  &\leftarrow {\bf v}(t)
1826          + \frac{h}{2} \left( \frac{{\bf f}(t)}{m} - {\bf v}(t)
1827          \left(\chi(t) + \eta(t) \right) \right), \\
1828   %
1507 {\bf j}\left(t + h / 2 \right)  &\leftarrow {\bf j}(t)
1508        + \frac{h}{2} \left( {\bf \tau}^b(t) - {\bf j}(t)
1509        \chi(t) \right), \\
1510 %
1511 \mathsf{A}(t + h) &\leftarrow \mathrm{rotate}\left(h *
1512        {\bf j}(t + h / 2) \overleftrightarrow{\mathsf{I}}^{-1}
1513        \right) ,\\
1514 %
1515 \chi\left(t + h / 2 \right) &\leftarrow \chi(t) +
1516        \frac{h}{2 \tau_T^2} \left( \frac{T(t)}{T_{\mathrm{target}}} - 1
1517        \right) ,\\
1518 %
1829   \eta(t + h / 2) &\leftarrow \eta(t) + \frac{h
1830          \mathcal{V}(t)}{2 N k_B T(t) \tau_B^2} \left( P(t)
1831          - P_{\mathrm{target}} \right), \\
# Line 1529 | Line 1839 | Most of these equations are identical to their counter
1839          \mathsf{H}(t).
1840   \end{align*}
1841  
1842 < Most of these equations are identical to their counterparts in the NVT
1533 < integrator, but the propagation of positions to time $t + h$
1842 > The propagation of positions to time $t + h$
1843   depends on the positions at the same time.  {\sc oopse} carries out
1844   this step iteratively (with a limit of 5 passes through the iterative
1845   loop).  Also, the simulation box $\mathsf{H}$ is scaled uniformly for
# Line 1539 | Line 1848 | the box by
1848   h / 2$.  Reshaping the box uniformly also scales the volume of
1849   the box by
1850   \begin{equation}
1851 < \mathcal{V}(t + h) \leftarrow e^{ - 3 h \eta(t + h /2)}.
1851 > \mathcal{V}(t + h) \leftarrow e^{ - 3 h \eta(t + h /2)} \times
1852   \mathcal{V}(t)
1853   \end{equation}
1854  
# Line 1550 | Line 1859 | T(t + h) &\leftarrow \left\{{\bf v}(t + h)\right\},
1859  
1860   {\tt moveB:}
1861   \begin{align*}
1553 T(t + h) &\leftarrow \left\{{\bf v}(t + h)\right\},
1554        \left\{{\bf j}(t + h)\right\} ,\\
1555 %
1862   P(t + h) &\leftarrow  \left\{{\bf r}(t + h)\right\},
1863          \left\{{\bf v}(t + h)\right\}, \\
1864   %
1559 \chi\left(t + h \right) &\leftarrow \chi\left(t + h /
1560        2 \right) + \frac{h}{2 \tau_T^2} \left( \frac{T(t+h)}
1561        {T_{\mathrm{target}}} - 1 \right), \\
1562 %
1865   \eta(t + h) &\leftarrow \eta(t + h / 2) +
1866          \frac{h \mathcal{V}(t + h)}{2 N k_B T(t + h)
1867          \tau_B^2} \left( P(t + h) - P_{\mathrm{target}} \right), \\
# Line 1576 | Line 1878 | to caclculate $T(t + h)$, $P(t + h)$, $\chi(t + h)$, a
1878   \end{align*}
1879  
1880   Once again, since ${\bf v}(t + h)$ and ${\bf j}(t + h)$ are required
1881 < to caclculate $T(t + h)$, $P(t + h)$, $\chi(t + h)$, and $\eta(t +
1881 > to calculate $T(t + h)$, $P(t + h)$, $\chi(t + h)$, and $\eta(t +
1882   h)$, they indirectly depend on their own values at time $t + h$.  {\tt
1883   moveB} is therefore done in an iterative fashion until $\chi(t + h)$
1884   and $\eta(t + h)$ become self-consistent.  The relative tolerance for
# Line 1616 | Line 1918 | the box shape.  The equations of motion for this metho
1918   {\it shape} as well as in the volume of the box.  This method utilizes
1919   the full $3 \times 3$ pressure tensor and introduces a tensor of
1920   extended variables ($\overleftrightarrow{\eta}$) to control changes to
1921 < the box shape.  The equations of motion for this method are
1921 > the box shape.  The equations of motion for this method differ from
1922 > those of NPTi as follows:
1923   \begin{eqnarray}
1924   \dot{{\bf r}} & = & {\bf v} + \overleftrightarrow{\eta} \cdot \left( {\bf r} - {\bf R}_0 \right), \\
1925   \dot{{\bf v}} & = & \frac{{\bf f}}{m} - (\overleftrightarrow{\eta} +
1926   \chi \cdot \mathsf{1}) {\bf v}, \\
1624 \dot{\mathsf{A}} & = & \mathsf{A} \cdot
1625 \mbox{ skew}\left(\overleftrightarrow{I}^{-1} \cdot {\bf j}\right) ,\\
1626 \dot{{\bf j}} & = & {\bf j} \times \left( \overleftrightarrow{I}^{-1}
1627 \cdot {\bf j} \right) - \mbox{ rot}\left(\mathsf{A}^{T} \cdot \frac{\partial
1628 V}{\partial \mathsf{A}} \right) - \chi {\bf j} ,\\
1629 \dot{\chi} & = & \frac{1}{\tau_{T}^2} \left(
1630 \frac{T}{T_{\mathrm{target}}} - 1 \right) ,\\
1927   \dot{\overleftrightarrow{\eta}} & = & \frac{1}{\tau_{B}^2 f k_B
1928   T_{\mathrm{target}}} V \left( \overleftrightarrow{\mathsf{P}} - P_{\mathrm{target}}\mathsf{1} \right) ,\\
1929   \dot{\mathsf{H}} & = &  \overleftrightarrow{\eta} \cdot \mathsf{H} .
# Line 1643 | Line 1939 | T(t) &\leftarrow \left\{{\bf v}(t)\right\}, \left\{{\b
1939  
1940   {\tt moveA:}
1941   \begin{align*}
1646 T(t) &\leftarrow \left\{{\bf v}(t)\right\}, \left\{{\bf j}(t)\right\} ,\\
1647 %
1942   \overleftrightarrow{\mathsf{P}}(t) &\leftarrow \left\{{\bf r}(t)\right\},
1943          \left\{{\bf v}(t)\right\} ,\\
1944   %
# Line 1653 | Line 1947 | T(t) &\leftarrow \left\{{\bf v}(t)\right\}, \left\{{\b
1947          \left(\chi(t)\mathsf{1} + \overleftrightarrow{\eta}(t) \right) \cdot
1948          {\bf v}(t) \right), \\
1949   %
1656 {\bf j}\left(t + h / 2 \right)  &\leftarrow {\bf j}(t)
1657        + \frac{h}{2} \left( {\bf \tau}^b(t) - {\bf j}(t)
1658        \chi(t) \right), \\
1659 %
1660 \mathsf{A}(t + h) &\leftarrow \mathrm{rotate}\left(h *
1661        {\bf j}(t + h / 2) \overleftrightarrow{\mathsf{I}}^{-1}
1662        \right), \\
1663 %
1664 \chi\left(t + h / 2 \right) &\leftarrow \chi(t) +
1665        \frac{h}{2 \tau_T^2} \left( \frac{T(t)}{T_{\mathrm{target}}}
1666        - 1 \right), \\
1667 %
1950   \overleftrightarrow{\eta}(t + h / 2) &\leftarrow
1951          \overleftrightarrow{\eta}(t) + \frac{h \mathcal{V}(t)}{2 N k_B
1952          T(t) \tau_B^2} \left( \overleftrightarrow{\mathsf{P}}(t)
# Line 1686 | Line 1968 | T(t + h) &\leftarrow \left\{{\bf v}(t + h)\right\},
1968  
1969   {\tt moveB:}
1970   \begin{align*}
1689 T(t + h) &\leftarrow \left\{{\bf v}(t + h)\right\},
1690        \left\{{\bf j}(t + h)\right\}, \\
1691 %
1971   \overleftrightarrow{\mathsf{P}}(t + h) &\leftarrow \left\{{\bf r}
1972          (t + h)\right\}, \left\{{\bf v}(t
1973          + h)\right\}, \left\{{\bf f}(t + h)\right\} ,\\
1974   %
1696 \chi\left(t + h \right) &\leftarrow \chi\left(t + h /
1697        2 \right) + \frac{h}{2 \tau_T^2} \left( \frac{T(t+
1698        h)}{T_{\mathrm{target}}} - 1 \right), \\
1699 %
1975   \overleftrightarrow{\eta}(t + h) &\leftarrow
1976          \overleftrightarrow{\eta}(t + h / 2) +
1977          \frac{h \mathcal{V}(t + h)}{2 N k_B T(t + h)
# Line 1708 | Line 1983 | T(t + h) &\leftarrow \left\{{\bf v}(t + h)\right\},
1983          \frac{{\bf f}(t + h)}{m} -
1984          (\chi(t + h)\mathsf{1} + \overleftrightarrow{\eta}(t
1985          + h)) \right) \cdot {\bf v}(t + h), \\
1711 %
1712 {\bf j}\left(t + h \right)  &\leftarrow {\bf j}\left(t
1713        + h / 2 \right) + \frac{h}{2} \left( {\bf \tau}^b(t
1714        + h) - {\bf j}(t + h) \chi(t + h) \right) .
1986   \end{align*}
1987  
1988   The iterative schemes for both {\tt moveA} and {\tt moveB} are
# Line 1729 | Line 2000 | elongated and sheared geometries which become smaller
2000   This integrator must be used with care, particularly in liquid
2001   simulations.  Liquids have very small restoring forces in the
2002   off-diagonal directions, and the simulation box can very quickly form
2003 < elongated and sheared geometries which become smaller than the
2004 < electrostatic or Lennard-Jones cutoff radii.  The NPTf integrator
2005 < finds most use in simulating crystals or liquid crystals which assume
1735 < non-orthorhombic geometries.
2003 > elongated and sheared geometries which become smaller than the cutoff
2004 > radius.  The NPTf integrator finds most use in simulating crystals or
2005 > liquid crystals which assume non-orthorhombic geometries.
2006  
2007   \subsection{\label{nptxyz}Constant pressure in 3 axes (NPTxyz)}
2008  
# Line 1762 | Line 2032 | Andersen.\cite{andersen83} The algorithm is a velocity
2032  
2033   In order to satisfy the constraints of fixed bond lengths within {\sc
2034   oopse}, we have implemented the {\sc rattle} algorithm of
2035 < Andersen.\cite{andersen83} The algorithm is a velocity verlet
2036 < formulation of the {\sc shake} method\cite{ryckaert77} of iteratively
2037 < solving the Lagrange multipliers of constraint.
2035 > Andersen.\cite{andersen83} {\sc rattle} is a velocity-Verlet
2036 > formulation of the {\sc shake} method\cite{ryckaert77} for iteratively
2037 > solving the Lagrange multipliers which maintain the holonomic
2038 > constraints.  Both methods are covered in depth in the
2039 > literature,\cite{leach01:mm,allen87:csl} and a detailed description of
2040 > this method would be redundant.
2041  
2042 < \subsubsection{\label{oopseSec:zcons}Z-Constraint Method}
2042 > \subsubsection{\label{oopseSec:zcons}The Z-Constraint Method}
2043  
2044 < Based on the fluctuation-dissipation theorem, a force auto-correlation
2045 < method was developed by Roux and Karplus to investigate the dynamics
2044 > A force auto-correlation method based on the fluctuation-dissipation
2045 > theorem was developed by Roux and Karplus to investigate the dynamics
2046   of ions inside ion channels.\cite{Roux91} The time-dependent friction
2047   coefficient can be calculated from the deviation of the instantaneous
2048 < force from its mean force.
2048 > force from its mean value:
2049   \begin{equation}
2050   \xi(z,t)=\langle\delta F(z,t)\delta F(z,0)\rangle/k_{B}T,
2051   \end{equation}
# Line 1781 | Line 2054 | where%
2054   \delta F(z,t)=F(z,t)-\langle F(z,t)\rangle.
2055   \end{equation}
2056  
1784
2057   If the time-dependent friction decays rapidly, the static friction
2058   coefficient can be approximated by
2059   \begin{equation}
2060   \xi_{\text{static}}(z)=\int_{0}^{\infty}\langle\delta F(z,t)\delta F(z,0)\rangle dt.
2061   \end{equation}
2062 < Allowing diffusion constant to then be calculated through the
2062 >
2063 > This allows the diffusion constant to then be calculated through the
2064   Einstein relation:\cite{Marrink94}
2065   \begin{equation}
2066   D(z)=\frac{k_{B}T}{\xi_{\text{static}}(z)}=\frac{(k_{B}T)^{2}}{\int_{0}^{\infty
2067   }\langle\delta F(z,t)\delta F(z,0)\rangle dt}.%
2068   \end{equation}
2069  
2070 < The Z-Constraint method, which fixes the z coordinates of the
2071 < molecules with respect to the center of the mass of the system, has
2072 < been a method suggested to obtain the forces required for the force
2073 < auto-correlation calculation.\cite{Marrink94} However, simply resetting the
2074 < coordinate will move the center of the mass of the whole system. To
2075 < avoid this problem, a new method was used in {\sc oopse}. Instead of
2076 < resetting the coordinate, we reset the forces of z-constrained
2077 < molecules as well as subtract the total constraint forces from the
2078 < rest of the system after the force calculation at each time step.
2070 > The Z-Constraint method, which fixes the $z$ coordinates of a few
2071 > ``tagged'' molecules with respect to the center of the mass of the
2072 > system is a technique that was proposed to obtain the forces required
2073 > for the force auto-correlation calculation.\cite{Marrink94} However,
2074 > simply resetting the coordinate will move the center of the mass of
2075 > the whole system. To avoid this problem, we have developed a new
2076 > method that is utilized in {\sc oopse}. Instead of resetting the
2077 > coordinates, we reset the forces of $z$-constrained molecules and
2078 > subtract the total constraint forces from the rest of the system after
2079 > the force calculation at each time step.
2080  
2081 < After the force calculation, define $G_\alpha$ as
2081 > After the force calculation, the total force on molecule $\alpha$,
2082   \begin{equation}
2083   G_{\alpha} = \sum_i F_{\alpha i},
2084   \label{oopseEq:zc1}
2085   \end{equation}
2086 < where $F_{\alpha i}$ is the force in the z direction of atom $i$ in
2087 < z-constrained molecule $\alpha$. The forces of the z constrained
2088 < molecule are then set to:
2086 > where $F_{\alpha i}$ is the force in the $z$ direction on atom $i$ in
2087 > $z$-constrained molecule $\alpha$. The forces on the atoms in the
2088 > $z$-constrained molecule are then adjusted to remove the total force
2089 > on molecule $\alpha$:
2090   \begin{equation}
2091   F_{\alpha i} = F_{\alpha i} -
2092          \frac{m_{\alpha i} G_{\alpha}}{\sum_i m_{\alpha i}}.
2093   \end{equation}
2094 < Here, $m_{\alpha i}$ is the mass of atom $i$ in the z-constrained
2095 < molecule. Having rescaled the forces, the velocities must also be
2096 < rescaled to subtract out any center of mass velocity in the z
2097 < direction.
2094 > Here, $m_{\alpha i}$ is the mass of atom $i$ in the $z$-constrained
2095 > molecule.  After the forces have been adjusted, the velocities must
2096 > also be modified to subtract out molecule $\alpha$'s center-of-mass
2097 > velocity in the $z$ direction.
2098   \begin{equation}
2099   v_{\alpha i} = v_{\alpha i} -
2100          \frac{\sum_i m_{\alpha i} v_{\alpha i}}{\sum_i m_{\alpha i}},
2101   \end{equation}
2102   where $v_{\alpha i}$ is the velocity of atom $i$ in the z direction.
2103 < Lastly, all of the accumulated z constrained forces must be subtracted
2104 < from the system to keep the system center of mass from drifting.
2103 > Lastly, all of the accumulated constraint forces must be subtracted
2104 > from the rest of the unconstrained system to keep the system center of
2105 > mass of the entire system from drifting.
2106   \begin{equation}
2107   F_{\beta i} = F_{\beta i} - \frac{m_{\beta i} \sum_{\alpha} G_{\alpha}}
2108          {\sum_{\beta}\sum_i m_{\beta i}},
2109   \end{equation}
2110 < where $\beta$ are all of the unconstrained molecules in the
2110 > where $\beta$ denotes all {\it unconstrained} molecules in the
2111   system. Similarly, the velocities of the unconstrained molecules must
2112 < also be scaled.
2112 > also be scaled:
2113   \begin{equation}
2114 < v_{\beta i} = v_{\beta i} + \sum_{\alpha}
2115 <        \frac{\sum_i m_{\alpha i} v_{\alpha i}}{\sum_i m_{\alpha i}}.
2114 > v_{\beta i} = v_{\beta i} + \sum_{\alpha} \frac{\sum_i m_{\alpha i}
2115 > v_{\alpha i}}{\sum_i m_{\alpha i}}.
2116   \end{equation}
2117  
2118 < At the very beginning of the simulation, the molecules may not be at their
2119 < constrained positions. To move a z-constrained molecule to its specified
2120 < position, a simple harmonic potential is used
2118 > This method will pin down the centers-of-mass of all of the
2119 > $z$-constrained molecules, and will also keep the entire system fixed
2120 > at the original system center-of-mass location.
2121 >
2122 > At the very beginning of the simulation, the molecules may not be at
2123 > their desired positions. To steer a $z$-constrained molecule to its
2124 > specified position, a simple harmonic potential is used:
2125   \begin{equation}
2126   U(t)=\frac{1}{2}k_{\text{Harmonic}}(z(t)-z_{\text{cons}})^{2},%
2127   \end{equation}
2128 < where $k_{\text{Harmonic}}$ is the harmonic force constant, $z(t)$ is the
2129 < current $z$ coordinate of the center of mass of the constrained molecule, and
2130 < $z_{\text{cons}}$ is the constrained position. The harmonic force operating
2131 < on the z-constrained molecule at time $t$ can be calculated by
2128 > where $k_{\text{Harmonic}}$ is an harmonic force constant, $z(t)$ is
2129 > the current $z$ coordinate of the center of mass of the constrained
2130 > molecule, and $z_{\text{cons}}$ is the desired constraint
2131 > position. The harmonic force operating on the $z$-constrained molecule
2132 > at time $t$ can be calculated by
2133   \begin{equation}
2134   F_{z_{\text{Harmonic}}}(t)=-\frac{\partial U(t)}{\partial z(t)}=
2135          -k_{\text{Harmonic}}(z(t)-z_{\text{cons}}).
2136   \end{equation}
2137  
2138 < \section{\label{oopseSec:design}Program Design}
2138 > The user may also specify the use of a constant velocity method
2139 > (steered molecular dynamics) to move the molecules to their desired
2140 > initial positions.
2141  
2142 < \subsection{\label{sec:architecture} {\sc oopse} Architecture}
2142 > To use of the $z$-constraint method in an {\sc oopse} simulation, the
2143 > molecules must be specified using the {\tt nZconstraints} keyword in
2144 > the meta-data file.  The other parameters for modifying the behavior
2145 > of the $z$-constraint method are listed in table~\ref{table:zconParams}.
2146  
2147 < The core of OOPSE is divided into two main object libraries:
2148 < \texttt{libBASS} and \texttt{libmdtools}. \texttt{libBASS} is the
2149 < library developed around the parsing engine and \texttt{libmdtools}
2150 < is the software library developed around the simulation engine. These
2151 < two libraries are designed to encompass all the basic functions and
2152 < tools that {\sc oopse} provides. Utility programs, such as the
2153 < property analyzers, need only link against the software libraries to
2154 < gain access to parsing, force evaluation, and input / output
2155 < routines.
2147 > \begin{table}
2148 > \caption{The Global Keywords: Z-Constraint Parameters}
2149 > \label{table:zconParams}
2150 > \begin{center}
2151 > % Note when adding or removing columns, the \hsize numbers must add up to the total number
2152 > % of columns.
2153 > \begin{tabularx}{\linewidth}%
2154 >  {>{\setlength{\hsize}{1.00\hsize}}X%
2155 >  >{\setlength{\hsize}{0.4\hsize}}X%
2156 >  >{\setlength{\hsize}{1.2\hsize}}X%
2157 >  >{\setlength{\hsize}{1.4\hsize}}X}
2158  
2159 < Contained in \texttt{libBASS} are all the routines associated with
1872 < reading and parsing the \texttt{.bass} input files. Given a
1873 < \texttt{.bass} file, \texttt{libBASS} will open it and any associated
1874 < \texttt{.mdl} files; then create structures in memory that are
1875 < templates of all the molecules specified in the input files. In
1876 < addition, any simulation parameters set in the \texttt{.bass} file
1877 < will be placed in a structure for later query by the controlling
1878 < program.
2159 > {\bf keyword} & {\bf units} & {\bf use} & {\bf remarks} \\ \hline
2160  
2161 < Located in \texttt{libmdtools} are all other routines necessary to a
2162 < Molecular Dynamics simulation. The library uses the main data
2163 < structures returned by \texttt{libBASS} to initialize the various
2164 < parts of the simulation: the atom structures and positions, the force
2165 < field, the integrator, \emph{et cetera}. After initialization, the
2166 < library can be used to perform a variety of tasks: integrate a
2167 < Molecular Dynamics trajectory, query phase space information from a
2168 < specific frame of a completed trajectory, or even recalculate force or
2169 < energetic information about specific frames from a completed
2170 < trajectory.
2171 <
2172 < With these core libraries in place, several programs have been
2173 < developed to utilize the routines provided by \texttt{libBASS} and
1893 < \texttt{libmdtools}. The main program of the package is \texttt{oopse}
1894 < and the corresponding parallel version \texttt{oopse\_MPI}. These two
1895 < programs will take the \texttt{.bass} file, and create (and integrate)
1896 < the simulation specified in the script. The two analysis programs
1897 < \texttt{staticProps} and \texttt{dynamicProps} utilize the core
1898 < libraries to initialize and read in trajectories from previously
1899 < completed simulations, in addition to the ability to use functionality
1900 < from \texttt{libmdtools} to recalculate forces and energies at key
1901 < frames in the trajectories. Lastly, the family of system building
1902 < programs (Sec.~\ref{oopseSec:initCoords}) also use the libraries to
1903 < store and output the system configurations they create.
1904 <
1905 < \subsection{\label{oopseSec:parallelization} Parallelization of {\sc oopse}}
2161 > {\tt nZconstraints} & integer &  The number of zconstraint molecules& If using zconstraint method, {\tt nZconstraints} must be set \\
2162 > {\tt zconsTime} & fs & Sets the frequency at which the {\tt .fz} file is written &  \\
2163 > {\tt zconsForcePolicy} & string & The strategy of subtracting
2164 > zconstraint force from the unconstrained molecules & Possible
2165 > strategies are {\tt BYMASS} and {\tt BYNUMBER}. Default
2166 > strategy is set to {\tt BYMASS}\\
2167 > {\tt zconsGap} & $\mbox{\AA}$ & Set the distance between two adjacent
2168 > constraint positions& Used mainly in moving molecules through a simulation \\
2169 > {\tt zconsFixtime} & fs & Sets how long the zconstraint molecule is
2170 > fixed & {\tt zconsFixtime} must be set if {\tt zconsGap} is set\\
2171 > {\tt zconsUsingSMD} &logical & Flag for using Steered Molecular
2172 > Dynamics or Harmonic Forces to move the molecule  & Harmonic Forces are
2173 > used by default\\
2174  
2175 < Although processor power is continually growing roughly following
2176 < Moore's Law, it is still unreasonable to simulate systems of more then
2177 < a 1000 atoms on a single processor. To facilitate study of larger
1910 < system sizes or smaller systems on long time scales in a reasonable
1911 < period of time, parallel methods were developed allowing multiple
1912 < CPU's to share the simulation workload. Three general categories of
1913 < parallel decomposition methods have been developed including atomic,
1914 < spatial and force decomposition methods.
2175 > \end{tabularx}
2176 > \end{center}
2177 > \end{table}
2178  
2179 < Algorithmically simplest of the three methods is atomic decomposition
2180 < where N particles in a simulation are split among P processors for the
2181 < duration of the simulation. Computational cost scales as an optimal
2182 < $\mathcal{O}(N/P)$ for atomic decomposition. Unfortunately all
2179 >
2180 > \section{\label{oopseSec:minimizer}Energy Minimization}
2181 >
2182 > As one of the basic procedures of molecular modeling, energy
2183 > minimization is used to identify local configurations that are stable
2184 > points on the potential energy surface. There is a vast literature on
2185 > energy minimization algorithms have been developed to search for the
2186 > global energy minimum as well as to find local structures which are
2187 > stable fixed points on the surface.  We have included two simple
2188 > minimization algorithms: steepest descent, ({\sc sd}) and conjugate
2189 > gradient ({\sc cg}) to help users find reasonable local minima from
2190 > their initial configurations.
2191 >
2192 > Since {\sc oopse} handles atoms and rigid bodies which have
2193 > orientational coordinates as well as translational coordinates, there
2194 > is some subtlety to the choice of parameters for minimization
2195 > algorithms.
2196 >
2197 > Given a coordinate set $x_{k}$ and a search direction $d_{k}$, a line
2198 > search algorithm is performed along $d_{k}$ to produce
2199 > $x_{k+1}=x_{k}+$ $\lambda _{k}d_{k}$.
2200 >
2201 > In the steepest descent ({\sc sd}) algorithm,%
2202 > \begin{equation}
2203 > d_{k}=-\nabla V(x_{k})
2204 > \end{equation}
2205 > The gradient and the direction of next step are always orthogonal.
2206 > This may cause oscillatory behavior in narrow valleys.  To overcome
2207 > this problem, the Fletcher-Reeves variant~\cite{FletcherReeves} of the
2208 > conjugate gradient ({\sc cg}) algorithm is used to generate $d_{k+1}$
2209 > via simple recursion:
2210 > \begin{align}
2211 > d_{k+1}  &  =-\nabla V(x_{k+1})+\gamma_{k}d_{k}\\
2212 > \gamma_{k}  &  =\frac{\nabla V(x_{k+1})^{T}\nabla V(x_{k+1})}{\nabla
2213 > V(x_{k})^{T}\nabla V(x_{k})}%
2214 > \end{align}
2215 >
2216 > The Polak-Ribiere variant~\cite{PolakRibiere} of the conjugate
2217 > gradient ($\gamma_{k}$) is defined as%
2218 > \begin{equation}
2219 > \gamma_{k}=\frac{[\nabla V(x_{k+1})-\nabla V(x)]^{T}\nabla V(x_{k+1})}{\nabla
2220 > V(x_{k})^{T}\nabla V(x_{k})}%
2221 > \end{equation}
2222 >
2223 > The conjugate gradient method assumes that the conformation is close
2224 > enough to a local minimum that the potential energy surface is very
2225 > nearly quadratic.  When the initial structure is far from the minimum,
2226 > the steepest descent method can be superior to the conjugate gradient
2227 > method. Hence, the steepest descent method is often used for the first
2228 > 10-100 steps of minimization. Another useful feature of minimization
2229 > methods in {\sc oopse} is that a modified {\sc shake} algorithm can be
2230 > applied during the minimization to constraint the bond lengths if this
2231 > is required by the force field. Meta-data parameters concerning the
2232 > minimizer are given in Table~\ref{table:minimizeParams}
2233 >
2234 > \begin{table}
2235 > \caption{The Global Keywords: Energy Minimizer Parameters}
2236 > \label{table:minimizeParams}
2237 > \begin{center}
2238 > % Note when adding or removing columns, the \hsize numbers must add up to the total number
2239 > % of columns.
2240 > \begin{tabularx}{\linewidth}%
2241 >  {>{\setlength{\hsize}{1.2\hsize}}X%
2242 >  >{\setlength{\hsize}{0.6\hsize}}X%
2243 >  >{\setlength{\hsize}{1.1\hsize}}X%
2244 >  >{\setlength{\hsize}{1.1\hsize}}X}
2245 >
2246 > {\bf keyword} & {\bf units} & {\bf use} & {\bf remarks} \\ \hline
2247 >
2248 > {\tt minimizer} & string &  selects the minimization method to be used
2249 > & either {\tt CG} (conjugate gradient) or {\tt SD} (steepest
2250 > descent) \\
2251 > {\tt minimizerMaxIter} & steps & Sets the maximum iteration number in the energy minimization & Default value is 200\\
2252 > {\tt minimizerWriteFreq} & steps & Sets the frequency at which the {\tt .dump} and {\tt .stat} files are writtern during energy minimization & \\
2253 > {\tt minimizerStepSize} & $\mbox{\AA}$ &  Set the step size of line search & Default value is 0.01\\
2254 > {\tt minimizerFTol} & $\mbox{kcal mol}^{-1}$  & Sets energy tolerance  & Default value is $10^{-8}$\\
2255 > {\tt minimizerGTol} & $\mbox{kcal mol}^{-1}\mbox{\AA}^{-1}$ & Sets gradient tolerance & Default value is $10^{-8}$\\
2256 > {\tt minimizerLSTol} &  $\mbox{kcal mol}^{-1}$ & Sets line search tolerance & Default value is $10^{-8}$\\
2257 > {\tt minimizerLSMaxIter} & steps &  Sets the maximum iteration of line searching & Default value is 50\\
2258 >
2259 > \end{tabularx}
2260 > \end{center}
2261 > \end{table}
2262 >
2263 > \section{\label{oopseSec:parallelization} Parallel Simulation Implementation}
2264 >
2265 > Although processor power is continually improving, it is still
2266 > unreasonable to simulate systems of more then a 1000 atoms on a single
2267 > processor. To facilitate study of larger system sizes or smaller
2268 > systems for longer time scales, parallel methods were developed to
2269 > allow multiple CPU's to share the simulation workload. Three general
2270 > categories of parallel decomposition methods have been developed:
2271 > these are the atomic,\cite{Fox88} spatial~\cite{plimpton95} and
2272 > force~\cite{Paradyn} decomposition methods.
2273 >
2274 > Algorithmically simplest of the three methods is atomic decomposition,
2275 > where $N$ particles in a simulation are split among $P$ processors for
2276 > the duration of the simulation. Computational cost scales as an
2277 > optimal $\mathcal{O}(N/P)$ for atomic decomposition. Unfortunately all
2278   processors must communicate positions and forces with all other
2279 < processors at every force evaluation, leading communication costs to
2280 < scale as an unfavorable $\mathcal{O}(N)$, \emph{independent of the
2279 > processors at every force evaluation, leading the communication costs
2280 > to scale as an unfavorable $\mathcal{O}(N)$, \emph{independent of the
2281   number of processors}. This communication bottleneck led to the
2282 < development of spatial and force decomposition methods in which
2282 > development of spatial and force decomposition methods, in which
2283   communication among processors scales much more favorably. Spatial or
2284   domain decomposition divides the physical spatial domain into 3D boxes
2285   in which each processor is responsible for calculation of forces and
2286   positions of particles located in its box. Particles are reassigned to
2287   different processors as they move through simulation space. To
2288 < calculate forces on a given particle, a processor must know the
2288 > calculate forces on a given particle, a processor must simply know the
2289   positions of particles within some cutoff radius located on nearby
2290 < processors instead of the positions of particles on all
2290 > processors rather than the positions of particles on all
2291   processors. Both communication between processors and computation
2292   scale as $\mathcal{O}(N/P)$ in the spatial method. However, spatial
2293   decomposition adds algorithmic complexity to the simulation code and
2294 < is not very efficient for small N since the overall communication
2294 > is not very efficient for small $N$, since the overall communication
2295   scales as the surface to volume ratio $\mathcal{O}(N/P)^{2/3}$ in
2296   three dimensions.
2297  
# Line 1942 | Line 2300 | given row by particles located in that processors colu
2300   processors based on a block decomposition of the force
2301   matrix. Processors are split into an optimally square grid forming row
2302   and column processor groups. Forces are calculated on particles in a
2303 < given row by particles located in that processors column
2303 > given row by particles located in that processor's column
2304   assignment. Force decomposition is less complex to implement than the
2305   spatial method but still scales computationally as $\mathcal{O}(N/P)$
2306   and scales as $\mathcal{O}(N/\sqrt{P})$ in communication
# Line 1953 | Line 2311 | We have presented the design and implementation of our
2311  
2312   \section{\label{oopseSec:conclusion}Conclusion}
2313  
2314 < We have presented the design and implementation of our open source
2315 < simulation package {\sc oopse}. The package offers novel capabilities
2316 < to the field of Molecular Dynamics simulation packages in the form of
2317 < dipolar force fields, and symplectic integration of rigid body
2318 < dynamics. It is capable of scaling across multiple processors through
2319 < the use of force based decomposition using MPI. It also implements
2320 < several advanced integrators allowing the end user control over
2321 < temperature and pressure. In addition, it is capable of integrating
2322 < constrained dynamics through both the {\sc rattle} algorithm and the
2323 < z-constraint method.
2314 > We have presented a new open source parallel simulation program {\sc
2315 > oopse}. This program offers some novel capabilities, but mostly makes
2316 > available a library of modern object-oriented code for the scientific
2317 > community to use freely.  Notably, {\sc oopse} can handle symplectic
2318 > integration of objects (atoms and rigid bodies) which have
2319 > orientational degrees of freedom.  It can also work with transition
2320 > metal force fields and point-dipoles. It is capable of scaling across
2321 > multiple processors through the use of force based decomposition. It
2322 > also implements several advanced integrators allowing the end user
2323 > control over temperature and pressure. In addition, it is capable of
2324 > integrating constrained dynamics through both the {\sc rattle}
2325 > algorithm and the $z$-constraint method.
2326  
2327 < These features are all brought together in a single open-source
2328 < program. This allows researchers to not only benefit from
2329 < {\sc oopse}, but also contribute to {\sc oopse}'s development as
2330 < well.
2327 > We encourage other researchers to download and apply this program to
2328 > their own research problems.  By making the code available, we hope to
2329 > encourage other researchers to contribute their own code and make it a
2330 > more powerful package for everyone in the molecular dynamics community
2331 > to use.  All source code for {\sc oopse} is available for download at
2332 > {\tt http://oopse.org}.
2333  
1972
2334   \newpage
2335   \section{Acknowledgments}
1975 The authors would like to thank the Notre Dame BoB computer cluster where much of this project was tested. Additionally, the authors would like to acknowledge their funding from {\LARGE FIX ME}.
2336  
2337 + Development of {\sc oopse} was funded by a New Faculty Award from the
2338 + Camille and Henry Dreyfus Foundation and by the National Science
2339 + Foundation under grant CHE-0134881. Computation time was provided by
2340 + the Notre Dame Bunch-of-Boxes (B.o.B) computer cluster under NSF grant
2341 + DMR-0079647.
2342 +
2343   \bibliographystyle{achemso}
2344   \bibliography{oopsePaper}
2345  

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines