Change the documentation to use the template files.

Massive rewrite for the new version. However it's removed the "gory details" section, so I should write this section again (possibly in a separate file).


git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@5 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b

1 files changed, 1388 insertions, 605 deletions

diff --git a/doc/documentation.tex b/doc/documentation.tex
index 5785dcf..8744143 100644
--- a/doc/documentation.tex
+++ b/doc/documentation.tex
@@ -1,18 +1,363 @@
+% *======================================================================*
+%  Cactus Thorn template for ThornGuide documentation
+%  Author: Ian Kelley
+%  Date: Sun Jun 02, 2002
+%  $Header$                                                             
+%
+%  Thorn documentation in the latex file doc/documentation.tex 
+%  will be included in ThornGuides built with the Cactus make system.
+%  The scripts employed by the make system automatically include 
+%  pages about variables, parameters and scheduling parsed from the 
+%  relevent thorn CCL files.
+%  
+%  This template contains guidelines which help to assure that your     
+%  documentation will be correctly added to ThornGuides. More 
+%  information is available in the Cactus UsersGuide.
+%                                                    
+%  Guidelines:
+%   - Do not change anything before the line
+%       % START CACTUS THORNGUIDE",
+%     except for filling in the title, author, date etc. fields.
+%        - Each of these fields should only be on ONE line.
+%        - Author names should be sparated with a \\ or a comma
+%   - You can define your own macros, but they must appear after
+%     the START CACTUS THORNGUIDE line, and must not redefine standard 
+%     latex commands.
+%   - To avoid name clashes with other thorns, 'labels', 'citations', 
+%     'references', and 'image' names should conform to the following 
+%     convention:          
+%       ARRANGEMENT_THORN_LABEL
+%     For example, an image wave.eps in the arrangement CactusWave and 
+%     thorn WaveToyC should be renamed to CactusWave_WaveToyC_wave.eps
+%   - Graphics should only be included using the graphix package. 
+%     More specifically, with the "includegraphics" command. Do
+%     not specify any graphic file extensions in your .tex file. This 
+%     will allow us (later) to create a PDF version of the ThornGuide
+%     via pdflatex. |
+%   - References should be included with the latex "bibitem" command. 
+%   - Use \begin{abstract}...\end{abstract} instead of \abstract{...}
+%   - Do not use \appendix, instead include any appendices you need as 
+%     standard sections. 
+%   - For the benefit of our Perl scripts, and for future extensions, 
+%     please use simple latex.     
+%
+% *======================================================================* 
+% 
+% Example of including a graphic image:
+%    \begin{figure}[ht]
+%       \begin{center}
+%          \includegraphics[width=6cm]{MyArrangement_MyThorn_MyFigure}
+%       \end{center}
+%       \caption{Illustration of this and that}
+%       \label{MyArrangement_MyThorn_MyLabel}
+%    \end{figure}
+%
+% Example of using a label:
+%   \label{MyArrangement_MyThorn_MyLabel}
+%
+% Example of a citation:
+%    \cite{MyArrangement_MyThorn_Author99}
+%
+% Example of including a reference
+%   \bibitem{MyArrangement_MyThorn_Author99}
+%   {J. Author, {\em The Title of the Book, Journal, or periodical}, 1 (1999), 
+%   1--16. {\tt http://www.nowhere.com/}}
+%
+% *======================================================================* 
+
+% If you are using CVS use this line to give version information
+% $Header$
+
 \documentclass{article}
-\usepackage{graphicx}
+
+% Use the Cactus ThornGuide style file
+% (Automatically used from Cactus distribution, if you have a 
+%  thorn without the Cactus Flesh download this from the Cactus
+%  homepage at www.cactuscode.org)
+\usepackage{../../../../doc/ThornGuide/cactus}
 
 \begin{document}
 
+% The author of the documentation
+\author{Ian Hawke} 
+
+% The title of the document (not necessarily the name of the Thorn)
 \title{Method of Lines}
-\author{Ian Hawke}
-\date{$ $Id$ $}
+
+% the date your document was last changed, if your document is in CVS, 
+% please use:
+\date{$ $Date$ $}
+
 \maketitle
 
-\abstract{The Method of Lines is a way of separating the time
-  integration from the rest of an evolution scheme. This thorn is
-  intended to take care of all the bookwork and provide some basic
-  time integration methods, allowing for easy coupling of different
-  thorns.} 
+% Do not delete next line
+% START CACTUS THORNGUIDE
+
+% Add all definitions used in this documentation here 
+%   \def\mydef etc
+
+%
+% The following is taken from cactusdevcvs/Cactus/doc/cactus.sty v
+% 1.3. Note that the included package doesn't contain this (it's
+% doc/ThornGuide/cactus.sty).
+%
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+%
+% Alternate environments/macros to define function descriptions
+% (can/should be used to replace CCTKFunc environment)
+% Jonathan Thornburg, 10 Nov 2001, revised 26 Mar 2002 & 3 Apr 2002
+%
+% Usage:
+%       \begin{FunctionDescription}{name}
+%       \label{label}
+%       Synopsis for this function                      (running text rules)
+%
+%       \begin{SynopsisSection}
+%       \begin{Synopsis}{C}
+%       text of C function synopsis                     (running text rules)
+%       \end{Synopsis}
+%       \begin{Synopsis}{Fortran}
+%       text of Fortran function synopsis               (running text rules)
+%       \end{Synopsis}
+%       \end{SynopsisSection}
+%
+%       \begin{ResultSection}
+%       \begin{ResultNote}
+%       optional note to go at the beginning of all results
+%                                                       (running text rules)
+%       \end{ResultNote}
+%       \begin{Result}{name or value (automatically in \tt font)}
+%       desription of what the result means in general,
+%       or of what this particular result value means   (running text rules)
+%       \end{Result}
+%       \end{ResultSection}
+%
+%       \begin{ParameterSection}
+%       \begin{Parameter}{name (automatically in \tt font)}
+%       desription of parameter                         (running text rules)
+%       \end{Parameter}
+%       \begin{Parameter}{name2 (automatically in \tt font)}
+%       desription of another parameter                 (running text rules)
+%       \end{Parameter}
+%       \end{ParameterSection}
+%
+%       \begin{Discussion}
+%       (note that there is no "DiscussionSection" environment!)
+%       discussion                                      (running text rules)
+%
+%       another paragraph of discussion                 (running text rules)
+%
+%       yet another paragraph of discussion             (running text rules)
+%       \end{Discussion}
+%
+%       \begin{SeeAlsoSection}
+%       \begin{SeeAlso}{name (automatically in \tt font)
+%       cross-references to other function of that name (running text rules)
+%       \end{SeeAlso}
+%       \begin{SeeAlso}{name2 (automatically in \tt font)
+%       cross-references to another function            (running text rules)
+%       \end{SeeAlso}
+%       \end{SeeAlsoSection}
+%
+%       \begin{ErrorSection}
+%       \begin{Error}{error\_code (automatically in \tt font)}
+%       description of what this error code means       (running text rules)
+%       \end{Error}
+%       \begin{Error}{error\_code2 (automatically in \tt font)}
+%       description of what next error code means       (running text rules)
+%       \end{Error}
+%       \end{ErrorSection}
+%
+%       \begin{ExampleSection}
+%       \begin{Example}{C}
+%       example C code                                  (running text rules)
+%       \end{Example}
+%       \begin{Example}{Fortran}
+%       example Fortran code                            (running text rules)
+%       \end{Example}
+%       \end{ExampleSection}
+%
+% For arguments which are automatically in \tt font, \tt may be used
+% to switch back to normal Roman font (eg for a numerical value), and
+% $...$ may be used for math mode (eg  ($\ge 0$)  to mark a result
+% which is always non-negative).
+%
+% Each "running text rules" item is the body of a latex environment,
+% so it may include multiple lines or even paragraphs.  Normally
+% underscore must be escaped (\_), but  \verb|...|  and/or
+%       \begin{verbatim}
+%       ...
+%       \end{verbatim}
+% or similar constructs (which can't be used inside a macro argument)
+% may also be used (in which case _ { } \ etc need not be escaped).
+%
+% All the subsections are optional.
+%
+% Bugs:
+% - It would be nice if we could avoid having to escape underscore
+%   within arguments.
+% - Error checking: if you have to ask, there isn't enough for you! :)
+% - There are no controls to prevent a page break falling between the
+%   line "C" or "Fortran", and an immediately following example generated
+%   by the Example subenvironment.  In fact, LaTeX seems to like doing
+%   this. :(
+% - It would be nice to have a "...continued" legend at the bottom of
+%   all but the last page of a multi-page description.
+% - The running header giving the function name, only appears for the
+%   first page of a multi-page description.
+% - In some ideal world, "See Also" would generate pdf hotlinks.
+% - The horizontal spacing is ugly in a ResultNote environment, and it's
+%   really *really* ugly if the note spans multiple lines of text. :(
+% - There are often unwanted one-horizontal-space indentations at
+%   the start of items; I don't know how to get rid of these. :(
+%   
+\newenvironment{FunctionDescription}[1]
+{
+\newpage
+\noindent{\t #1}
+\vskip1mm
+\hrule 
+\vskip3mm
+%
+% We define all the subenvironments inside the main one, so they won't
+% interfere with any conflicting global definitions.
+%
+\newenvironment{FunctionDescriptionEntry}
+               {%%%
+               \begin{list}%%%
+                     {}%%%
+                     {%%%
+                     \renewcommand{\makelabel}{\Lentrylabel}%%%
+                     \setlength{\topsep}{0ex}%%%
+                     \setlength{\partopsep}{0ex}%%%
+                     \setlength{\itemsep}{0ex}%%%
+                     \setlength{\labelwidth}{8em}%%%
+                     \setlength{\leftmargin}{\labelwidth+\labelsep}%%%
+                     \setlength{\itemindent}{0em}%%%
+                     \setlength{\listparindent}{0em}%%%
+                     }%%%
+               }%%%
+               {\end{list}}%%%
+\newenvironment{FunctionDescriptionWideEntry}
+               {%%%
+               \begin{list}%%%
+                     {}%%%
+                     {%%%
+                     \renewcommand{\makelabel}{\Lentrylabel}%%%
+                     \setlength{\topsep}{0ex}%%%
+                     \setlength{\partopsep}{0ex}%%%
+                     \setlength{\itemsep}{0ex}%%%
+                     \setlength{\labelwidth}{16em}%%%
+                     \setlength{\leftmargin}{\labelwidth+\labelsep}%%%
+                     \setlength{\itemindent}{0em}%%%
+                     \setlength{\listparindent}{0em}%%%
+                     }%%%
+               }%%%
+               {\end{list}}%%%
+%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%
+\newenvironment{SynopsisSection}
+               {%%%
+               \par\noindent{\bf Synopsis}
+               \begin{FunctionDescriptionEntry}
+               }%%%
+               {\end{FunctionDescriptionEntry}}
+\newenvironment{Synopsis}[1]{\item[\bf ##1]}{}
+%
+\newenvironment{ResultSection}
+               {%%%
+               \par\noindent{\bf Result}
+               \begin{FunctionDescriptionEntry}
+               }%%%
+               {\end{FunctionDescriptionEntry}}
+\newenvironment{ResultNote}{\item[]\hskip-\leftmargin{}}{}
+\newenvironment{Result}[1]{\item[\tt ##1]}{}
+%
+\newenvironment{ParameterSection}
+               {%%%
+               \par\noindent{\bf Parameters}
+               \begin{FunctionDescriptionEntry}
+               }%%%
+               {\end{FunctionDescriptionEntry}}
+\newenvironment{Parameter}[1]{\item[\tt ##1]}{}
+%
+\newenvironment{Discussion}%%%
+               {%%%
+               \par\noindent{\bf Discussion}
+               \begin{FunctionDescriptionEntry}
+               \item[]
+               }%%%
+               {\end{FunctionDescriptionEntry}}
+%
+\newenvironment{SeeAlsoSection}
+               {%%%
+               \par\noindent{\bf See Also}
+               \begin{FunctionDescriptionWideEntry}
+               }%%%
+               {\end{FunctionDescriptionWideEntry}}
+\newenvironment{SeeAlso}[1]{\item[\tt ##1]}{}
+%
+\newenvironment{ErrorSection}
+               {%%%
+               \par\noindent{\bf Errors}
+               \begin{FunctionDescriptionWideEntry}
+               }%%%
+               {\end{FunctionDescriptionWideEntry}}
+\newenvironment{Error}[1]{\item[\tt ##1]}{}
+%
+\newenvironment{ExampleSection}
+               {%%%
+               \par\noindent{\bf Examples}
+               \begin{FunctionDescriptionEntry}
+               }%%%
+               {\end{FunctionDescriptionEntry}}
+\newenvironment{Example}[1]{\item[\bf ##1]}{}
+%
+}%%%    % end of \begin{FunctionDescription} expansion
+{%%%
+}%%%    % \end{FunctionDescription} expansion is empty
+
+% Add an abstract for this thorn's documentation
+\begin{abstract}
+  The Method of Lines is a way of separating the time integration from
+  the rest of an evolution scheme. This thorn is intended to take care
+  of all the bookwork and provide some basic time integration methods,
+  allowing for easy coupling of different thorns.
+\end{abstract}
+
+% The following sections are suggestive only.
+% Remove them or add your own.
+
+% \section{Introduction}
+
+% \section{Physical System}
+
+% \section{Numerical Implementation}
+
+% \section{Using This Thorn}
+
+% \subsection{Obtaining This Thorn}
+
+% \subsection{Basic Usage}
+
+% \subsection{Special Behaviour}
+
+% \subsection{Interaction With Other Thorns}
+
+% \subsection{Examples}
+
+% \subsection{Support and Feedback}
+
+% \section{History}
+
+% \subsection{Thorn Source Code}
+
+% \subsection{Thorn Documentation}
+
+% \subsection{Acknowledgements}
 
 \section{Purpose}
 \label{sec:purpose}
@@ -39,7 +384,7 @@ time integration. This is more modular (allowing for simple extensions
 to higher order methods), more stable (as instabilities can now only
 arise from the spatial discretization or the equations themselves) and
 also avoids the problems of retaining high orders of convergence when
-coupling different matter models.
+coupling different physical models.
 
 MoL can be used for hyperbolic, parabolic and even elliptic problems
 (although I definitely don't recommend the latter). As it currently
@@ -57,15 +402,18 @@ implement only the optimal Runge-Kutta time integrators (which are TVD
 up to RK3, so suitable for hydro) up to fourth order and iterated
 Crank Nicholson. All of the interaction with the MoL thorn should
 occur directly through the scheduler. For example, all synchronization
-steps should now be possible at the scheduler level.
+steps should now be possible at the schedule level. This is essential
+for interacting cleanly with different drivers, especially to make
+Mesh Refinement work.
 
 For more information on the Method of Lines the most comprehensive
-references are the works of Jonathan Thornburg~\cite{jt1,jt2} - see
-especially section 7.3 of the thesis. From the CFD viewpoint the
-review of ENO methods by Shu,~\cite{shu} has some information. For
-relativistic fluids the paper of Neilsen and Choptuik~\cite{nc} is
-also quite good. For Ian Hawke's viewpoint either see below or contact
-by email.
+references are the works of Jonathan
+Thornburg~\cite{AlphaThorns_MoL_Thornburg93,AlphaThorns_MoL_Thornburg99}
+- see especially section 7.3 of the thesis. From the CFD viewpoint the
+review of ENO methods by Shu,~\cite{AlphaThorns_MoL_Shu99} has some
+information. For relativistic fluids the paper of Neilsen and
+Choptuik~\cite{AlphaThorns_MoL_Neilsen00} is also quite good. For Ian
+Hawke's viewpoint either see below or contact by email.
 
 \section{How to use}
 \label{sec:use}
@@ -76,8 +424,7 @@ by email.
 
 For those who used the old version of MoL, this version is
 unfortunately slightly more effort to use. That is, for most methods
-you'll now have to set 4 parameters instead of just one. This
-documentation is still in the process of conversion...
+you'll now have to set 4 parameters instead of just one. 
 
 If you already have a thorn that uses the method of lines, then there
 are four main parameters that are relevant to change the integration
@@ -133,58 +480,113 @@ cateogories.
   these were set by constraints at every intermediate step (which is
   slightly artificial; the usual example would be the use of maximal
   slicing, which is only applied once every $N$ complete steps). These
-  are known as {\it primitive} variables in analogy with the hydro
-  code.
+  are known as {\it constrained} variables.
 \item The third category are those variables that a thorn depends on
   but does not set or evolve. An example would include the metric
-  terms considered from a thorn evolving matter. These are known as
-  {\it dependent} variables.
+  terms considered from a thorn evolving matter. Due to the way that
+  MoL deals with these, they are known as {\it Save and Restore}
+  variables.
 \item The final category are those variables that do not interact with
   MoL. These would include temporary variables for analysis or setting
   up the initial data. These can safely be ignored.
 \end{enumerate}
 
 MoL needs to know every GF that falls in one of the first three
-groups. If a GF is evolved by one thorn but is a dependent variable in
-another (for example, the metric in full GR Hydro) then each thorn
+groups. If a GF is evolved by one thorn but is a constrained variable
+in another (for example, the metric in full GR Hydro) then each thorn
 should register the function as they see it. For example, the hydro
-thorn will register the metric as a dependent variable and the
+thorn will register the metric as a Save and Restore variable and the
 spacetime thorn will register the metric as an evolved variable. The
 different variable categories are given the priority evolved,
-primitive, dependent. So if a variable is registered as belonging in
-two different categories, it is always considered by MoL to belong to
-the category with the highest priority. 
+constrained, Save and Restore. So if a variable is registered as
+belonging in two different categories, it is always considered by MoL
+to belong to the category with the highest priority.
+
+MoL needs to know the total number of GFs in each category \textit{at
+  parameter time}. To do this, your thorn needs to use some
+accumulator parameters from MoL. As an example, here are the paramters
+from WaveMoL:
+\begin{verbatim}
+shares: MethodOfLines
+
+USES CCTK_INT MoL_Num_Evolved_Vars
+USES CCTK_INT MoL_Num_Constrained_Vars
+USES CCTK_INT MoL_Num_SaveAndRestore_Vars
+
+restricted:
+
+CCTK_INT WaveMoL_MaxNumEvolvedVars \
+    "The maximum number of evolved variables used by WaveMoL" \
+    ACCUMULATOR-BASE=MethodofLines::MoL_Num_Evolved_Vars
+{
+  5:5           :: "Just 5: phi and the four derivatives"
+} 5
+
+CCTK_INT WaveMoL_MaxNumConstrainedVars \
+    "The maximum number of constrained variables used by WaveMoL" \
+    ACCUMULATOR-BASE=MethodofLines::MoL_Num_Constrained_Vars
+{
+  0:1           :: "A small range, depending on testing or not"
+} 1
+
+CCTK_INT WaveMoL_MaxNumSandRVars \
+    "The maximum number of save and restore variables used by WaveMoL" \
+    ACCUMULATOR-BASE=MethodofLines::MoL_Num_SaveAndRestore_Vars
+{
+  0:1           :: "A small range, depending on testing or not"
+} 1
+\end{verbatim}
+This should give the \textit{maximum} number of variables that your
+thorn will register.
 
 Every thorn should register every grid function that it uses even if
 you expect it to be registered again by a different thorn. For
-example, a hydro thorn would register the metric variables as
-dependent, whilst the spacetime evolution thorn would register them as
-evolved (in ADM) or primitive (in ADM\_BSSN), both of which have
+example, a hydro thorn would register the metric variables as Save and
+Restore, whilst the spacetime evolution thorn would register them as
+evolved (in ADM) or constrained (in ADM\_BSSN), both of which have
 precedence. To register your GFs with MoL schedule a routine in the
 bin {\tt MoL\_Register} which just contains the relevant function
 calls.  For an evolved variable the GF corresponding to the update
 term (${\bf L}({\bf q})$ in equation~(\ref{eq:mol2})) should be
-registered at the same time, using the call {\tt MoL\_RegisterVar($q,
-  L(q)$)}. For the primitive and dependent variables the function
-calls are {\tt MoL\_RegisterPrimitive($q$)} and {\tt
-  MoL\_RegisterDepends($q$)} respectively. Here $q$ is the {\it
-  variable index} of the GF you wish to register, and $L(q)$ the
-variable index of the associated right hand side GF. These are found
-using the {\tt CCTK\_VarIndex*} functions.
-
-There are both C and Fortran versions of these functions; see the
-reference in section~\ref{sec:molfns}. For the C calls the prototypes
-are given in the file {\tt MoL.h} which can be included without hard
-paths by adding the line
-
-{\tt USES INCLUDE: MoL.h}
+registered at the same time. The appropriate functions are given in
+section~\ref{sec:molfns}.
 
-\noindent to the {\tt interface.ccl} file of your thorn.
-
-{\bf UPDATE} This has now been switched to using function
-aliasing. The include file still exists, but is commented out in the
-{\tt interface.ccl}. For an example of how to use the aliased
-functions, see thorn WaveMoL.
+These functions are provided using function aliasing. For details on
+using function aliasing, see sections B10.5 and F2.2.3 of the
+UsersGuide. In this specific case, you simply add the following lines
+to your \texttt{interface.ccl}:
+\begin{verbatim}
+##########################################
+### PROTOTYPES - DELETE AS APPLICABLE! ###
+##########################################
+
+CCTK_INT FUNCTION MoLRegisterEvolved(CCTK_INT EvolvedIndex, CCTK_INT RHSIndex)
+CCTK_INT FUNCTION MoLRegisterConstrained(CCTK_INT ConstrainedIndex)
+CCTK_INT FUNCTION MoLRegisterSaveAndRestore(CCTK_INT SandRIndex)
+CCTK_INT FUNCTION MoLRegisterEvolvedGroup(CCTK_INT EvolvedIndex, \
+                                          CCTK_INT RHSIndex)
+CCTK_INT FUNCTION MoLRegisterConstrainedGroup(CCTK_INT ConstrainedIndex)
+CCTK_INT FUNCTION MoLRegisterSaveAndRestoreGroup(CCTK_INT SandRIndex)
+CCTK_INT FUNCTION MoLChangeToEvolved(CCTK_INT EvolvedIndex, CCTK_INT RHSIndex)
+CCTK_INT FUNCTION MoLChangeToConstrained(CCTK_INT ConstrainedIndex)
+CCTK_INT FUNCTION MoLChangeToSaveAndRestore(CCTK_INT SandRIndex)
+CCTK_INT FUNCTION MoLChangeToNone(CCTK_INT RemoveIndex)
+
+#############################################
+### USE STATEMENT - DELETE AS APPLICABLE! ###
+#############################################
+
+USES FUNCTION MoLRegisterEvolved
+USES FUNCTION MoLRegisterConstrained
+USES FUNCTION MoLRegisterSaveAndRestore
+USES FUNCTION MoLRegisterEvolvedGroup
+USES FUNCTION MoLRegisterConstrainedGroup
+USES FUNCTION MoLRegisterSaveAndRestoreGroup
+USES FUNCTION MoLChangeToEvolved
+USES FUNCTION MoLChangeToConstrained
+USES FUNCTION MoLChangeToSaveAndRestore
+USES FUNCTION MoLChangeToNone
+\end{verbatim}
 
 Having done that, one routine (or group of routines) which we'll here
 call {\tt Thorn\_CalcRHS} must be defined. This does all the finite
@@ -208,14 +610,15 @@ of boundary conditions\footnote{It is possible to alter the
   updated and do not need setting. This is slightly tricksy. For an
   example of how this would work see the new radiative boundary
   condition in ADM\_BSSN. For more on this see section 7.3.4
-  of~\cite{jt1}.}, the solution of elliptic equations (although this
-would be a very expensive place to solve them, some sets of equations
-might require the updating of some variables by constraints in this
-fashion). When applying boundary conditions the cleanest thing to do
-is to write a routine applying the symmetries to the appropriate GFs
-and, when calling it from the scheduler, adding the {\tt SYNC}
-statement to the appropriate groups. An example is given by the
-routine {\tt WaveToyMoL\_Boundaries} in thorn WaveMoL.
+  of~\cite{AlphaThorns_MoL_Thornburg93}.}, the solution of elliptic
+equations (although this would be a very expensive place to solve
+them, some sets of equations might require the updating of some
+variables by constraints in this fashion). When applying boundary
+conditions the cleanest thing to do is to write a routine applying the
+symmetries to the appropriate GFs and, when calling it from the
+scheduler, adding the {\tt SYNC} statement to the appropriate groups.
+An example is given by the routine {\tt WaveToyMoL\_Boundaries} in
+thorn WaveMoL.
 
 Points to note. The thorn routine {\tt Thorn\_CalcRHS} does not need
 to know and in fact should definitely not know where precisely in the
@@ -227,28 +630,6 @@ the correct data at the end of the MoL step will be dealt with by the
 MoL thorn and the flesh. Also the synchronization of grids across
 separate processors will be dealt with by the MoL thorn and the flesh.
 
-Final point. Currently this MoL thorn is not guaranteed to work with
-mesh refinement codes. Aside from a number of little details that need
-to be worked out, currently MoL does not ensure that {\tt
-  cctk\_delta\_time} is correctly set in the intermediate stages of
-the calculation. This will hopefully change, but for the immediate
-future don't expect this to work with any mesh refinement code.
-
-Update. It is now possible to change the category of a GF in the
-middle of a run. This was added solely to allow for mixed slicing for
-Einstein. In this case the lapse is an evolved function if using
-$1+\log$ slicing, a primitive variable if using maximal or static
-slicing, and a dependent variable if evolved in some unknown
-manner. Currently there exist functions for changing to any of the
-four categories listed above.
-
-{\bf I strongly suggest that these functions are not used}. They are
-almost completely untested, and even those that are tested are far
-from stable. Also, when moving to the version of this thorn that
-supports Mesh Refinement it is quite possible that these functions may
-be dropped.
-
-
 \section{Example}
 \label{sec:example}
 
@@ -273,21 +654,20 @@ real ADM_BSSN_sources type=GF
 ...
 }
 \end{verbatim}
-Also in this file we write {\tt USES INCLUDE: MoL.h}.
+Also in this file we write the function aliasing prototypes.
 
 Once the sources are defined the registration with MoL is required,
-for which the essential file is {\tt MoLRegister.c}. As we're
-registering from C we ensure that we {\tt \#include "MoL.h"}. In the
-ADM\_BSSN system the standard metric coefficients $g_{ij}$ are not
-evolved, and neither are the standard extrinsic curvature components
-$K_{ij}$.  However these are used by ADM\_BSSN in a number of places,
-and are calculated from evolved quantities at the appropriate points.
-In the MoL terminology these variables are {\it primitive}. As the
-appropriate storage is defined in thorn Einstein, the actual calls
-have the form
+for which the essential file is {\tt MoLRegister.c}. In the ADM\_BSSN
+system the standard metric coefficients $g_{ij}$ are not evolved, and
+neither are the standard extrinsic curvature components $K_{ij}$.
+However these are used by ADM\_BSSN in a number of places, and are
+calculated from evolved quantities at the appropriate points.  In the
+MoL terminology these variables are {\it constrained}. As the
+appropriate storage is defined in thorn ADMBase, the actual calls have
+the form
 
 \begin{verbatim}
- ierr += MoL_RegisterPrimitive(CCTK_VarIndex("einstein::kxx"));
+ ierr += MoLRegisterConstrained(CCTK_VarIndex("ADMBase::kxx"));
 \end{verbatim}
 
 \noindent The actual evolved variables include things such as the
@@ -295,8 +675,8 @@ conformal factor. This, and the appropriate source term, is defined in
 thorn ADM\_BSSN, and so the call has the form
 
 \begin{verbatim} 
- ierr += MoL_RegisterVar(CCTK_VarIndex("adm_bssn::ADM_BS_phi"),
-                         CCTK_VarIndex("adm_bssn::adm_bs_sphi")); 
+ ierr += MoLRegisterEvolved(CCTK_VarIndex("adm_bssn::ADM_BS_phi"),
+                            CCTK_VarIndex("adm_bssn::adm_bs_sphi")); 
 \end{verbatim}
 
 
@@ -306,27 +686,27 @@ these have depends on how they are set. If harmonic or 1+log slicing
 is used then the lapse is evolved:
 
 \begin{verbatim}
- ierr += MoL_RegisterVar(CCTK_VarIndex("einstein::alp"),
-                         CCTK_VarIndex("adm_bssn::adm_bs_salp")); 
+ ierr += MoLRegisterEvolved(CCTK_VarIndex("ADMBase::alp"),
+                            CCTK_VarIndex("adm_bssn::adm_bs_salp")); 
 \end{verbatim}
 
 \noindent If maximal or static slicing is used then the lapse is a
-primitive variable\footnote{Note that this is actually a bit of a
-  hack. The rational for {\it dependent} variables was to deal with
-  maximal slicing. However it turned out that I hadn't thought it
-  through correctly and that the treatment for primitive variables was
-  required.}:
+constrained variable\footnote{Note that this is actually a bit of a
+  hack. The rational for {\it Save and Restore} variables was to deal
+  with maximal slicing. However it turned out that I hadn't thought it
+  through correctly and that the treatment for constrained variables
+  was required.}:
 
 \begin{verbatim}
- ierr += MoL_RegisterPrimitive(CCTK_VarIndex("einstein::alp"));
+ ierr += MoLRegisterConstrained(CCTK_VarIndex("ADMBase::alp"));
 \end{verbatim}
 
 \noindent Finally, if none of the above apply we assume that the lapse
 is evolved in some unknown fashion, and so it must be registered as a
-dependent variable:
+Save and Restore variable:
 
 \begin{verbatim}
- ierr += MoL_RegisterDepends(CCTK_VarIndex("einstein::alp"));
+ ierr += MoLRegisterSaveAndRestore(CCTK_VarIndex("ADMBase::alp"));
 \end{verbatim}
 
 However, it is perfectly possible that we may wish to change how we
@@ -336,9 +716,9 @@ routine is called. For example, if we want to use 1+log evolution then
 we call 
 
 \begin{verbatim}
- call CCTK_VarIndex(lapseindex,"einstein::alp")
+ call CCTK_VarIndex(lapseindex,"ADMBase::alp")
  call CCTK_VarIndex(lapserhsindex,"adm_bssn::adm_bs_salp")
- call MoL_ChangeVarToEvolved(ierr, lapseindex, lapserhsindex)
+ call MoLChangeToEvolved(ierr, lapseindex, lapserhsindex)
 \end{verbatim}
 
 \noindent It is not required to tell MoL what the lapse is changing
@@ -356,509 +736,913 @@ variables back to the standard ADM variables in {\tt
   ADM\_BSSN\_StandardVariables}, and also update the time derivative
 of the lapse in {\tt ADM\_BSSN\_LapseChange}.
 
-\section{The gory details}
-\label{sec:gory}
-
-This section is more for people wishing to maintain and extend the
-code. {\bf NEEDS TOTAL REWRITE FOR MOL2}
-
-There are three essential parts to the MoL thorn. The first is the
-registration process where the MoL thorn is told just how many GFs it
-should be looking to integrate, and where they and their RHSs
-are. This is split into three separate routines.
-\begin{itemize}
-\item {\tt MoL\_Init\_Register} Called by the MoL thorn at {\tt
-    postinitial}.  Initializes the number of variables to the maximum
-  possible number (given by {\tt CCTK\_NumVars()}). Sets up two arrays
-  of pointers to GFs (CCTK\_Real**), one for the data ({\tt qindex})
-  and one for the RHSs ({\tt qrhsindex}). It also sets up index arrays
-  for the primitive and dependent variables.
-\item {\tt MoL\_Register} This group lets MoL knows where all the data
-  is and should contain all the user thorn calls to {\tt
-    MoL\_RegisterVar()}. This just associates the index of the
-  GFs to be evolved with their RHSs, and increments the number of
-  variables to be evolved. Also contains the routines to register the
-  primitive and dependent variables.
-\item {\tt MoL\_End\_Register} This could be used to reallocate the
-  index arrays to the correct size. For the moment I've decided that
-  the tiny memory gain is outweighed by the possiblity of problems
-  using realloc.
-\end{itemize}
-
-The second part of the MoL thorn sets up all the scratch space and the
-parameters for the generalized RK routines. This is also scheduled at
-postinitial. This contains the routines
-
-\begin{itemize}
-\item {\tt MoL\_SetupScratch} Sets up the scratch space. Sets the
-  scalar {\tt mol\_num\_scratch} which is the size of the required
-  scratch space from the defaults, then allocates the scratch arrays. 
-\item {\tt MoL\_RKSetup} Sets up the $\alpha$ and $\beta$ arrays for
-  the generalized Runge Kutta step. Note that as we're currently only
-  storing the most recent RHS arrays the $\beta$ arrays are single
-  index only.
-\end{itemize}
-
-The final part of the MoL thorn is the evolution step. This is again
-split into a number of separate routines and groups. Firstly we
-describe a single evolution step, and what MoL expects.
-
-By a single evolution step we here mean the execution of everything
-inside the schedule bin {\tt EVOL}. MoL expects that every GF that it
-knows about is allocated, initialized and lives at the same instant of
-computational time. MoL also expects the ghost zones and boundaries to
-be set correctly. Wherever possible the first two are checked. MoL
-expects that the driver has rotated the timelevels so that the last
-set of complete, consistent data is stored in ${\bf q}\_p$. MoL also
-knows that the dependent variables may or may not have been evolved by
-the time the MoL evolution group is executed.
-
-\begin{figure}[ht]
-\begin{center}
-\includegraphics[width=3cm]{MoLdia1}
-\includegraphics[width=3cm]{MoLdia2}
-\includegraphics[width=3cm]{MoLdia3}
-\end{center}
-\caption{How MoL treats the three different types of variables. The
-  MoL step is performed at evolution after the driver has rotated the
-  timelevels, which occurs right at the start of every {\tt
-    CCTK\_EVOL} step. The physics thorns expect the most recent data
-  to be at the current time level (the top solid line). So the first
-  step for most types of variable is to copy or pointer switch the
-  data from the previous time level (bottom solid line) where the most
-  recent data exists after rotation. Figure (a) shows the {\it
-    evolved} variables.  At each intermediate step the data is updated
-  into the current time level and, if necessary, stored in scratch
-  space.  Figure (b) shows the {\it primitive} variables. As these are
-  set by the physics thorns into the current time level all that is
-  required is the initial copy. Figure (c) shows the {\it dependent}
-  variables for which we cannot know whether these variables are
-  evolved before or after MoL at evolution, and hence whether the
-  current data is already filled before MoL starts, we must store the
-  current data in scratch space first, then do the copy from the
-  previous level, and then at the end of the MoL step return the data
-  to the initial state.}
-\label{MoLvariables}
-\end{figure}
-
-MoL plays around with the timelevels during the intermediate
-steps. This is required so that the latest level in the MoL evolution
-is always stored in the same place so that the user thorns can easily
-access them. This place is the current time level ${\bf q}$. This
-ensures that MoL works correctly with all the standard boundary
-condition routines and minimizes the effort of porting non timelevel
-aware thorns (I hope!).
-
-An outline of the schedule is as follows:
-\begin{equation}
-  \label{eq:schedoutline}
-  \begin{array}[l]{l}
-    \texttt{MoL\_StartStep} \\
-    \texttt{MoL\_Step WHILE counter \{} \\
-    \begin{array}[l]{l}
-      \texttt{MoL\_CalcRHS \{ \}} \\
-      \texttt{MoL\_Add} \\
-      \texttt{MoL\_PostStep \{ \}} \\
-    \end{array} \\
-    \texttt{\}} \\
-    \texttt{MoL\_EndStep \{ \}}
-  \end{array}
-\end{equation}
-
-Each different type of variable is treated slightly differently by
-MoL. Each is assumed to have at least 2 timelevels (although this is
-checked, a fatal error occurs otherwise). Before entering the loop
-over the intermediate steps MoL will first copy (pointer switch?) the
-data into the current time levels. Before doing this the current
-timelevel of any {\it dependent} variables is copied to scratch space,
-as it may have already been updated. During the loop over the
-intermediate steps only the {\it evolved} variables are directly
-altered by MoL. When all user thorns have given their right hand side
-GFs the evolved variables are updated into the current time level.
-This data may also be copied to scratch space if required for later.
-The primitive variables are assumed to be set by the user thorn,
-either in the calculation of the RHS or during {\tt MoL\_PostStep} at
-the end of each intermediate step. The dependent variables are assumed
-to remain completely unchanged. After all the intermediate steps the
-data in the current and previous timelevels is ``correct'' and
-consistent for the evolved and the temporary variables. The data for
-the current timelevel for the dependent variables is recovered from
-scratch space. Precisely how the different variables are
-treated is shown in figure~\ref{MoLvariables}.
-
-\begin{itemize}
-\item {\tt MoL\_StartStep} This ensures that the integer keeping
-    track of where we are in the MoL step is set to the correct
-    value. It also copies the previous data ${\bf q}_p$ into the
-    current position ${\bf q}$ ready for the first step.
-\item {\tt MoL\_Step} This is the main part of the thorn. The scheduler
-  allows us to loop over this group the correct number of times to
-  complete a single Cactus evolution step. Contained within this group
-  are:
-  \begin{itemize}
-  \item {\tt MoL\_CalcRHS} The schedule group within which the user
-    thorns will schedule their routines. These routines should
-    calculate the GFs ${\bf L}({\bf q})$. The order these routines are
-    scheduled within this group should not matter.
-  \item {\tt MoL\_Add} This step performs the time integration
-    depending on where in the MoL step we are. Updates directly into
-    the current GF and copies to the scratch space if required.
-  \item {\tt MoL\_PostStep} Another schedule group within which the
-    user thorns can schedule such things as primitive variable
-    recovery, boundary conditions, etc.
-  \item {\tt MoL\_End} Just alters the scalar tracking the position in
-    the MoL loop.
-  \end{itemize}
-\end{itemize}
-
-Finally, there are the routines {\tt MoL\_FreeScratch} and {\tt
-  MoL\_RKFree} which free up the memory that was explicitly taken. For
-the moment these routines are scheduled at postevol.
-
-
-\section{Adding new numerical integrators}
-\label{sec:newmeth}
-
-There are two obvious ways of adding new ODE integrators into MoL. The
-first is to follow the route used in the efficient RK2 and ICN
-methods. That is, you let the underlying infrastructure define the
-scratch space but you do all the addition yourself. It's probably best
-if you model your integrator on one of the efficient routines to start
-with. 
-
-The alternative is to use the generic integrator. To use this you just
-need to add the correct set of $\alpha$ and $\beta$ coefficients so
-that the generic routine can perform the additions. You'll also have
-to set up the keyword parameters and so on.
-
-\section{To do list}
-\label{sec:todo}
-
-\begin{itemize}
-\item The documentation must be improved, especially inside the code
-  itself. 
-\item Errors are currently not handled well (if at all). This must be
-  fixed.
-\item A test suite is required. I'm not sure how to do this without
-  using WaveMoL, but we could try.
-\item In order to make the code work with a Mesh Refinement driver,
-  the scratch spaces must be changed to be grid functions. This is
-  currently impossible, but Tom Goodale will add the appropriate bits
-  to the flesh to make it possible to do. At that point the entire
-  code will probably be rewritten.
-\end{itemize}
+% \section{The gory details}
+% \label{sec:gory}
+
+% This section is more for people wishing to maintain and extend the
+% code. {\bf NEEDS TOTAL REWRITE FOR MOL2}
+
+% There are three essential parts to the MoL thorn. The first is the
+% registration process where the MoL thorn is told just how many GFs it
+% should be looking to integrate, and where they and their RHSs
+% are. This is split into three separate routines.
+% \begin{itemize}
+% \item {\tt MoL\_Init\_Register} Called by the MoL thorn at {\tt
+%     postinitial}.  Initializes the number of variables to the maximum
+%   possible number (given by {\tt CCTK\_NumVars()}). Sets up two arrays
+%   of pointers to GFs (CCTK\_Real**), one for the data ({\tt qindex})
+%   and one for the RHSs ({\tt qrhsindex}). It also sets up index arrays
+%   for the primitive and dependent variables.
+% \item {\tt MoL\_Register} This group lets MoL knows where all the data
+%   is and should contain all the user thorn calls to {\tt
+%     MoL\_RegisterVar()}. This just associates the index of the
+%   GFs to be evolved with their RHSs, and increments the number of
+%   variables to be evolved. Also contains the routines to register the
+%   primitive and dependent variables.
+% \item {\tt MoL\_End\_Register} This could be used to reallocate the
+%   index arrays to the correct size. For the moment I've decided that
+%   the tiny memory gain is outweighed by the possiblity of problems
+%   using realloc.
+% \end{itemize}
+
+% The second part of the MoL thorn sets up all the scratch space and the
+% parameters for the generalized RK routines. This is also scheduled at
+% postinitial. This contains the routines
+
+% \begin{itemize}
+% \item {\tt MoL\_SetupScratch} Sets up the scratch space. Sets the
+%   scalar {\tt mol\_num\_scratch} which is the size of the required
+%   scratch space from the defaults, then allocates the scratch arrays. 
+% \item {\tt MoL\_RKSetup} Sets up the $\alpha$ and $\beta$ arrays for
+%   the generalized Runge Kutta step. Note that as we're currently only
+%   storing the most recent RHS arrays the $\beta$ arrays are single
+%   index only.
+% \end{itemize}
+
+% The final part of the MoL thorn is the evolution step. This is again
+% split into a number of separate routines and groups. Firstly we
+% describe a single evolution step, and what MoL expects.
+
+% By a single evolution step we here mean the execution of everything
+% inside the schedule bin {\tt EVOL}. MoL expects that every GF that it
+% knows about is allocated, initialized and lives at the same instant of
+% computational time. MoL also expects the ghost zones and boundaries to
+% be set correctly. Wherever possible the first two are checked. MoL
+% expects that the driver has rotated the timelevels so that the last
+% set of complete, consistent data is stored in ${\bf q}\_p$. MoL also
+% knows that the dependent variables may or may not have been evolved by
+% the time the MoL evolution group is executed.
+
+% \begin{figure}[ht]
+% \begin{center}
+% \includegraphics[width=3cm]{MoLdia1}
+% \includegraphics[width=3cm]{MoLdia2}
+% \includegraphics[width=3cm]{MoLdia3}
+% \end{center}
+% \caption{How MoL treats the three different types of variables. The
+%   MoL step is performed at evolution after the driver has rotated the
+%   timelevels, which occurs right at the start of every {\tt
+%     CCTK\_EVOL} step. The physics thorns expect the most recent data
+%   to be at the current time level (the top solid line). So the first
+%   step for most types of variable is to copy or pointer switch the
+%   data from the previous time level (bottom solid line) where the most
+%   recent data exists after rotation. Figure (a) shows the {\it
+%     evolved} variables.  At each intermediate step the data is updated
+%   into the current time level and, if necessary, stored in scratch
+%   space.  Figure (b) shows the {\it primitive} variables. As these are
+%   set by the physics thorns into the current time level all that is
+%   required is the initial copy. Figure (c) shows the {\it dependent}
+%   variables for which we cannot know whether these variables are
+%   evolved before or after MoL at evolution, and hence whether the
+%   current data is already filled before MoL starts, we must store the
+%   current data in scratch space first, then do the copy from the
+%   previous level, and then at the end of the MoL step return the data
+%   to the initial state.}
+% \label{MoLvariables}
+% \end{figure}
+
+% MoL plays around with the timelevels during the intermediate
+% steps. This is required so that the latest level in the MoL evolution
+% is always stored in the same place so that the user thorns can easily
+% access them. This place is the current time level ${\bf q}$. This
+% ensures that MoL works correctly with all the standard boundary
+% condition routines and minimizes the effort of porting non timelevel
+% aware thorns (I hope!).
+
+% An outline of the schedule is as follows:
+% \begin{equation}
+%   \label{eq:schedoutline}
+%   \begin{array}[l]{l}
+%     \texttt{MoL\_StartStep} \\
+%     \texttt{MoL\_Step WHILE counter \{} \\
+%     \begin{array}[l]{l}
+%       \texttt{MoL\_CalcRHS \{ \}} \\
+%       \texttt{MoL\_Add} \\
+%       \texttt{MoL\_PostStep \{ \}} \\
+%     \end{array} \\
+%     \texttt{\}} \\
+%     \texttt{MoL\_EndStep \{ \}}
+%   \end{array}
+% \end{equation}
+
+% Each different type of variable is treated slightly differently by
+% MoL. Each is assumed to have at least 2 timelevels (although this is
+% checked, a fatal error occurs otherwise). Before entering the loop
+% over the intermediate steps MoL will first copy (pointer switch?) the
+% data into the current time levels. Before doing this the current
+% timelevel of any {\it dependent} variables is copied to scratch space,
+% as it may have already been updated. During the loop over the
+% intermediate steps only the {\it evolved} variables are directly
+% altered by MoL. When all user thorns have given their right hand side
+% GFs the evolved variables are updated into the current time level.
+% This data may also be copied to scratch space if required for later.
+% The primitive variables are assumed to be set by the user thorn,
+% either in the calculation of the RHS or during {\tt MoL\_PostStep} at
+% the end of each intermediate step. The dependent variables are assumed
+% to remain completely unchanged. After all the intermediate steps the
+% data in the current and previous timelevels is ``correct'' and
+% consistent for the evolved and the temporary variables. The data for
+% the current timelevel for the dependent variables is recovered from
+% scratch space. Precisely how the different variables are
+% treated is shown in figure~\ref{MoLvariables}.
+
+% \begin{itemize}
+% \item {\tt MoL\_StartStep} This ensures that the integer keeping
+%     track of where we are in the MoL step is set to the correct
+%     value. It also copies the previous data ${\bf q}_p$ into the
+%     current position ${\bf q}$ ready for the first step.
+% \item {\tt MoL\_Step} This is the main part of the thorn. The scheduler
+%   allows us to loop over this group the correct number of times to
+%   complete a single Cactus evolution step. Contained within this group
+%   are:
+%   \begin{itemize}
+%   \item {\tt MoL\_CalcRHS} The schedule group within which the user
+%     thorns will schedule their routines. These routines should
+%     calculate the GFs ${\bf L}({\bf q})$. The order these routines are
+%     scheduled within this group should not matter.
+%   \item {\tt MoL\_Add} This step performs the time integration
+%     depending on where in the MoL step we are. Updates directly into
+%     the current GF and copies to the scratch space if required.
+%   \item {\tt MoL\_PostStep} Another schedule group within which the
+%     user thorns can schedule such things as primitive variable
+%     recovery, boundary conditions, etc.
+%   \item {\tt MoL\_End} Just alters the scalar tracking the position in
+%     the MoL loop.
+%   \end{itemize}
+% \end{itemize}
+
+% Finally, there are the routines {\tt MoL\_FreeScratch} and {\tt
+%   MoL\_RKFree} which free up the memory that was explicitly taken. For
+% the moment these routines are scheduled at postevol.
+
+
+% \section{Adding new numerical integrators}
+% \label{sec:newmeth}
+
+% There are two obvious ways of adding new ODE integrators into MoL. The
+% first is to follow the route used in the efficient RK2 and ICN
+% methods. That is, you let the underlying infrastructure define the
+% scratch space but you do all the addition yourself. It's probably best
+% if you model your integrator on one of the efficient routines to start
+% with. 
+
+% The alternative is to use the generic integrator. To use this you just
+% need to add the correct set of $\alpha$ and $\beta$ coefficients so
+% that the generic routine can perform the additions. You'll also have
+% to set up the keyword parameters and so on.
+
+% \section{To do list}
+% \label{sec:todo}
+
+% \begin{itemize}
+% \item The documentation must be improved, especially inside the code
+%   itself. 
+% \item Errors are currently not handled well (if at all). This must be
+%   fixed.
+% \item A test suite is required. I'm not sure how to do this without
+%   using WaveMoL, but we could try.
+% \item In order to make the code work with a Mesh Refinement driver,
+%   the scratch spaces must be changed to be grid functions. This is
+%   currently impossible, but Tom Goodale will add the appropriate bits
+%   to the flesh to make it possible to do. At that point the entire
+%   code will probably be rewritten.
+% \end{itemize}
 
 \section{Functions provided by MoL}
 \label{sec:molfns}
 
-{\bf Note for Cactus people: I'd really like there to be a generic
-  style file so that I could use the same function environments as in
-  the User's Guide. It would also be nice if the parsing of the
-  interface files recognized function aliasing when that appears, but
-  that's a long distant wish}.
-
 All the functions listed below return error codes in theory. However
 at this current point in time they always return 0 (success). Any
 failure to register or change a GF is assumed fatal and MoL will
 issue a level 0 warning stopping the code. This may change in future,
 in which case negative return values will indicate errors.
 
-\subsection*{MoL\_RegisterVar}
-
-Tells MoL that the given GF is in the evolved category with the
-associated update GF. 
-
-\vskip 3mm
-
-\begin{tabular}[l]{l l l}
-  {\bf Synopsis} && \\
-  & {\bf C} & CCTK\_INT ierr = MoL\_RegisterVar(CCTK\_INT varindex,
-  CCTK\_INT rhsindex) \\
-  & {\bf Fortran} & MoL\_RegisterVar(CCTK\_INT ierr, CCTK\_INT varindex,
-  CCTK\_INT rhsindex) 
-\end{tabular}
-
-\begin{tabular}[l]{l l c l}
-  {\bf Arguments} &&& \\
-  & {\bf varindex} & - & Index of the GF to be evolved \\
-  & {\bf rhsindex} & - & Index of the associated update GF.
-\end{tabular}
-
-\begin{tabular}[l]{l l}
-  {\bf Discussion} & \\
-  & Should be called in a function scheduled in {\tt MoL\_Register}.
-\end{tabular}
-
-\begin{tabular}[l]{l l l}
-  {\bf Examples} && \\
-  & {\bf C} & ierr =
-  MoL\_RegisterVar(CCTK\_VarIndex("wavetoymol::phi"), \\
-  && \qquad CCTK\_VarIndex("wavetoymol::phirhs")); \\ 
-  & {\bf Fortran} & call CCTK\_VarIndex(varindex, ``wavetoymol::phi'')
-  \\
-  && call CCTK\_VarIndex(rhsindex, ``wavetoymol::phirhs'') \\
-  && call MoL\_RegisterVar(ierr, varindex, rhsindex)
-\end{tabular}
-
-\begin{tabular}[l]{l l }
-  {\bf See Also} & \\
-  & CCTK\_VarIndex, MoL\_RegisterDepends, MoL\_RegisterPrimitive, \\
-  & MoL\_ChangeVarToEvolved.
-\end{tabular}
-
-
-\subsection*{MoL\_RegisterDepends}
-
-Tells MoL that the given GF is in the dependent category.
-
-\vskip 3mm
-
-\begin{tabular}[l]{l l l}
-  {\bf Synopsis} && \\
-  & {\bf C} & CCTK\_INT ierr = MoL\_RegisterDepends(CCTK\_INT varindex) \\
-  & {\bf Fortran} & MoL\_RegisterDepends(CCTK\_INT ierr, CCTK\_INT varindex) 
-\end{tabular}
-
-\begin{tabular}[l]{l l c l}
-  {\bf Arguments} &&& \\
-  & {\bf varindex} & - & Index of the dependent GF.
-\end{tabular}
-
-\begin{tabular}[l]{l l}
-  {\bf Discussion} & \\
-  & Should be called in a function scheduled in {\tt MoL\_Register}.
-\end{tabular}
-
-\begin{tabular}[l]{l l l}
-  {\bf Examples} && \\
-  & {\bf C} & ierr =
-  MoL\_RegisterDepends(CCTK\_VarIndex("einstein::alp")); \\ 
-  & {\bf Fortran} & call CCTK\_VarIndex(varindex, ``einstein::alp'')
-  \\
-  && call MoL\_RegisterDepends(ierr, varindex)
-\end{tabular}
-
-\begin{tabular}[l]{l l }
-  {\bf See Also} & \\
-  & CCTK\_VarIndex, MoL\_RegisterVar, MoL\_RegisterPrimitive, \\
-  & MoL\_ChangeVarToDependent.
-\end{tabular}
-
-
-\subsection*{MoL\_RegisterPrimitive}
-
-Tells MoL that the given GF is in the primitive category.
-
-\vskip 3mm
-
-\begin{tabular}[l]{l l l}
-  {\bf Synopsis} && \\
-  & {\bf C} & CCTK\_INT ierr = MoL\_RegisterPrimitive(CCTK\_INT varindex) \\
-  & {\bf Fortran} & MoL\_RegisterPrimitive(CCTK\_INT ierr, CCTK\_INT varindex) 
-\end{tabular}
-
-\begin{tabular}[l]{l l c l}
-  {\bf Arguments} &&& \\
-  & {\bf varindex} & - & Index of the primitive GF.
-\end{tabular}
-
-\begin{tabular}[l]{l l}
-  {\bf Discussion} & \\
-  & Should be called in a function scheduled in {\tt MoL\_Register}.
-\end{tabular}
-
-\begin{tabular}[l]{l l l}
-  {\bf Examples} && \\
-  & {\bf C} & ierr =
-  MoL\_RegisterPrimitive(CCTK\_VarIndex("einstein::alp")); \\ 
-  & {\bf Fortran} & call CCTK\_VarIndex(varindex, ``einstein::alp'')
-  \\
-  && call MoL\_RegisterPrimitive(ierr, varindex)
-\end{tabular}
-
-\begin{tabular}[l]{l l }
-  {\bf See Also} & \\
-  & CCTK\_VarIndex, MoL\_RegisterVar, MoL\_RegisterDepends, \\
-  & MoL\_ChangeVarToPrimitive.
-\end{tabular}
-
-
-\subsection*{MoL\_ChangeVarToEvolved}
-
-Sets a GF to belong to the evolved category, with the associated
-update GF. Not used for the initial setting.
-
-\vskip 3mm
-
-\begin{tabular}[l]{l l l}
-  {\bf Synopsis} && \\
-  & {\bf C} & CCTK\_INT ierr = MoL\_ChangeVarToEvolved(CCTK\_INT varindex, CCTK\_INT
-  rhsindex) \\ 
-  & {\bf Fortran} & MoL\_ChangeVarToEvolved(CCTK\_INT ierr, CCTK\_INT varindex,
-  CCTK\_INT rhsindex)  
-\end{tabular}
-
-\begin{tabular}[l]{l l c l}
-  {\bf Arguments} &&& \\
-  & {\bf varindex} & - & Index of the GF to be evolved. \\
-  & {\bf rhsindex} & - & Index of the associated update GF.
-\end{tabular}
-
-\begin{tabular}[l]{l l}
-  {\bf Discussion} & \\
-  & Should be called in a function scheduled in {\tt MoL\_PreStep}. \\
-  & Note that this function was designed to allow mixed slicings for
-  thorn Einstein. \\
-  & This set of functions is largely untested and should be used with
-  great care.
-\end{tabular}
-
-\begin{tabular}[l]{l l l}
-  {\bf Examples} && \\
-  & {\bf C} & ierr =
-  MoL\_ChangeVarToEvolved(CCTK\_VarIndex("einstein::alp"),\\
-  && \qquad CCTK\_VarIndex(``adm\_bssn::adm\_bs\_salp'')); \\
-  & {\bf Fortran} & call CCTK\_VarIndex(varindex, ``einstein::alp'') \\
-  && call CCTK\_VarIndex(rhsindex, ``adm\_bssn::adm\_bs\_salp'') \\
-  && call MoL\_ChangeVarToEvolved(ierr, varindex, rhsindex)
-\end{tabular}
-
-\begin{tabular}[l]{l l }
-  {\bf See Also} & \\
-  & CCTK\_VarIndex, MoL\_RegisterVar, MoL\_ChangeVarToDependent, \\
-  & MoL\_ChangeVarToPrimitive, MoL\_ChangeVarToNone.
-\end{tabular}
-
-
-\subsection*{MoL\_ChangeVarToDependent}
-
-Sets a GF to belong to the dependent category. Not used for the
-initial setting. 
-
-\vskip 3mm
-
-\begin{tabular}[l]{l l l}
-  {\bf Synopsis} && \\
-  & {\bf C} & CCTK\_INT ierr = MoL\_ChangeVarToDependent(CCTK\_INT varindex) \\ 
-  & {\bf Fortran} & MoL\_ChangeVarToDependent(CCTK\_INT ierr, CCTK\_INT varindex)  
-\end{tabular}
-
-\begin{tabular}[l]{l l c l}
-  {\bf Arguments} &&& \\
-  & {\bf varindex} & - & Index of the dependent GF.
-\end{tabular}
-
-\begin{tabular}[l]{l l}
-  {\bf Discussion} & \\
-  & Should be called in a function scheduled in {\tt MoL\_PreStep}. \\
-  & Note that this function was designed to allow mixed slicings for
-  thorn Einstein. \\
-  & This set of functions is largely untested and should be used with
-  great care.
-\end{tabular}
-
-\begin{tabular}[l]{l l l}
-  {\bf Examples} && \\
-  & {\bf C} & ierr =
-  MoL\_ChangeVarToDependent(CCTK\_VarIndex("einstein::alp")); \\
-  & {\bf Fortran} & call CCTK\_VarIndex(varindex, ``einstein::alp'') \\
-  && call MoL\_ChangeVarToDependent(ierr, varindex)
-\end{tabular}
-
-\begin{tabular}[l]{l l }
-  {\bf See Also} & \\
-  & CCTK\_VarIndex, MoL\_RegisterDepends, MoL\_ChangeVarToEvolved, \\
-  & MoL\_ChangeVarToPrimitive, MoL\_ChangeVarToNone.
-\end{tabular}
-
-\subsection*{MoL\_ChangeVarToPrimitive}
-
-Sets a GF to belong to the primitive category. Not used for the
-initial setting. 
-
-\vskip 3mm
-
-\begin{tabular}[l]{l l l}
-  {\bf Synopsis} && \\
-  & {\bf C} & CCTK\_INT ierr = MoL\_ChangeVarToPrimitive(CCTK\_INT varindex) \\ 
-  & {\bf Fortran} & MoL\_ChangeVarToPrimitive(CCTK\_INT ierr, CCTK\_INT varindex)  
-\end{tabular}
-
-\begin{tabular}[l]{l l c l}
-  {\bf Arguments} &&& \\
-  & {\bf varindex} & - & Index of the primitive GF.
-\end{tabular}
-
-\begin{tabular}[l]{l l}
-  {\bf Discussion} & \\
-  & Should be called in a function scheduled in {\tt MoL\_PreStep}. \\
-  & Note that this function was designed to allow mixed slicings for
-  thorn Einstein. \\
-  & This set of functions is largely untested and should be used with
-  great care.
-\end{tabular}
-
-\begin{tabular}[l]{l l l}
-  {\bf Examples} && \\
-  & {\bf C} & ierr =
-  MoL\_ChangeVarToPrimitive(CCTK\_VarIndex("einstein::alp")); \\
-  & {\bf Fortran} & call CCTK\_VarIndex(varindex, ``einstein::alp'') \\
-  && call MoL\_ChangeVarToPrimitive(ierr, varindex)
-\end{tabular}
-
-\begin{tabular}[l]{l l }
-  {\bf See Also} & \\
-  & CCTK\_VarIndex, MoL\_RegisterPrimitive, MoL\_ChangeVarToEvolved, \\
-  & MoL\_ChangeVarToDependent, MoL\_ChangeVarToNone.
-\end{tabular}
-
-\subsection*{MoL\_ChangeVarToNone}
-
-Sets a GF to belong to the ``unknown'' category. Not used for the
-initial setting. 
-
-\vskip 3mm
-
-\begin{tabular}[l]{l l l}
-  {\bf Synopsis} && \\
-  & {\bf C} & CCTK\_INT ierr = MoL\_ChangeVarToNone(CCTK\_INT varindex) \\ 
-  & {\bf Fortran} & MoL\_ChangeVarToNone(CCTK\_INT ierr, CCTK\_INT varindex)  
-\end{tabular}
-
-\begin{tabular}[l]{l l c l}
-  {\bf Arguments} &&& \\
-  & {\bf varindex} & - & Index of the GF to be unset. 
-\end{tabular}
-
-\begin{tabular}[l]{l l}
-  {\bf Discussion} & \\
-  & Should be called in a function scheduled in {\tt MoL\_PreStep}. \\
-  & Note that this function was designed to allow mixed slicings for
-  thorn Einstein. \\
-  & This set of functions is largely untested and should be used with
-  great care.
-\end{tabular}
-
-\begin{tabular}[l]{l l l}
-  {\bf Examples} && \\
-  & {\bf C} & ierr =
-  MoL\_ChangeVarToNone(CCTK\_VarIndex("einstein::alp")); \\
-  & {\bf Fortran} & call CCTK\_VarIndex(varindex, ``einstein::alp'') \\
-  && call MoL\_RegisterNone(ierr, varindex)
-\end{tabular}
-
-\begin{tabular}[l]{l l }
-  {\bf See Also} & \\
-  & CCTK\_VarIndex, MoL\_ChangeVarToEvolved, MoL\_ChangeVarToDependent, \\
-  & MoL\_ChangeVarToPrimitive.
-\end{tabular}
-
-
-
-
-\begin{thebibliography}{1}
-
-\bibitem{jt1}
+These are all \textit{aliased} functions. You can get the functions
+directly through header files, but this feature may be phased
+out. Using function aliasing is the recommended method.
+
+\begin{FunctionDescription}{MoLRegisterEvolved}
+  \label{MoLRegisterEvolved}
+  
+  Tells MoL that the given GF is in the evolved category with the
+  associated update GF.
+
+  \begin{SynopsisSection}
+    \begin{Synopsis}{C}
+      CCTK\_INT ierr = MoLRegisterEvolved(CCTK\_INT EvolvedIndex, CCTK\_INT
+      RHSIndex)
+    \end{Synopsis}
+    \begin{Synopsis}{Fortran}
+      CCTK\_INT ierr = MoLRegisterEvolved(CCTK\_INT EvolvedIndex, CCTK\_INT
+      RHSIndex)
+    \end{Synopsis}
+  \end{SynopsisSection}
+
+  \begin{ResultSection}
+    \begin{ResultNote}
+      Currently if there is an error, MoL will issue a level 0
+      warning. No sensible return codes exist.
+    \end{ResultNote}
+    \begin{Result}{\rm 0}
+      success
+    \end{Result}
+  \end{ResultSection}
+
+  \begin{ParameterSection}
+    \begin{Parameter}{EvolvedIndex}
+      Index of the GF to be evolved.
+    \end{Parameter}
+    \begin{Parameter}{RHSIndex}
+      Index of the associated update GF.
+    \end{Parameter}
+  \end{ParameterSection}
+
+  \begin{Discussion}
+    Should be called in a function scheduled in {\tt MoL\_Register}.
+  \end{Discussion}
+
+  \begin{SeeAlsoSection}
+    \begin{SeeAlso}{CCTK\_VarIndex()}
+      Get the GF index.
+    \end{SeeAlso}
+    \begin{SeeAlso}{MoLRegisterSaveAndRestore()}
+      Register Save and Restore variables.
+    \end{SeeAlso}
+    \begin{SeeAlso}{MoLRegisterConstrained()}
+      Register constrained variables.
+    \end{SeeAlso}
+    \begin{SeeAlso}{MoLChangeToEvolved()}
+      Change a variable at runtime to be evolved.
+    \end{SeeAlso}
+  \end{SeeAlsoSection}
+
+  \begin{ExampleSection}
+    \begin{Example}{C}
+\begin{verbatim}
+ierr = MoLRegisterEvolved(CCTK_VarIndex("wavetoymol::phi"),
+                          CCTK_VarIndex("wavetoymol::phirhs"));
+\end{verbatim}
+    \end{Example}
+    \begin{Example}{Fortran}
+\begin{verbatim}
+call CCTK_VarIndex(EvolvedIndex, "wavetoymol::phi")
+call CCTK_VarIndex(RHSIndex, "wavetoymol::phirhs")
+ierr = MoLRegisterEvolved(EvolvedIndex, RHSIndex)
+\end{verbatim}
+    \end{Example}
+  \end{ExampleSection}
+
+\end{FunctionDescription}
+
+
+
+\begin{FunctionDescription}{MoLRegisterConstrained}
+  \label{MoLRegisterConstrained}
+  
+  Tells MoL that the given GF is in the constrained category.
+
+  \begin{SynopsisSection}
+    \begin{Synopsis}{C}
+      CCTK\_INT ierr = MoLRegisterConstrained(CCTK\_INT ConstrainedIndex)
+    \end{Synopsis}
+    \begin{Synopsis}{Fortran}
+      CCTK\_INT ierr = MoLRegisterConstrained(CCTK\_INT ConstrainedIndex)
+    \end{Synopsis}
+  \end{SynopsisSection}
+
+  \begin{ResultSection}
+    \begin{ResultNote}
+      Currently if there is an error, MoL will issue a level 0
+      warning. No sensible return codes exist.
+    \end{ResultNote}
+    \begin{Result}{\rm 0}
+      success
+    \end{Result}
+  \end{ResultSection}
+
+  \begin{ParameterSection}
+    \begin{Parameter}{ConstrainedIndex}
+      Index of the constrained GF.
+    \end{Parameter}
+  \end{ParameterSection}
+
+  \begin{Discussion}
+    Should be called in a function scheduled in {\tt MoL\_Register}.
+  \end{Discussion}
+
+  \begin{SeeAlsoSection}
+    \begin{SeeAlso}{CCTK\_VarIndex()}
+      Get the GF index.
+    \end{SeeAlso}
+    \begin{SeeAlso}{MoLRegisterEvolved()}
+      Register evolved variables.
+    \end{SeeAlso}
+    \begin{SeeAlso}{MoLRegisterSaveAndRestore()}
+      Register Save and Restore variables.
+    \end{SeeAlso}
+    \begin{SeeAlso}{MoLChangeToConstrained()}
+      Change a variable at runtime to be constrained.
+    \end{SeeAlso}
+  \end{SeeAlsoSection}
+
+  \begin{ExampleSection}
+    \begin{Example}{C}
+\begin{verbatim}
+ierr = MoLRegisterConstrained(CCTK_VarIndex("ADMBase::alp"));
+\end{verbatim}
+    \end{Example}
+    \begin{Example}{Fortran}
+\begin{verbatim}
+call CCTK_VarIndex(ConstrainedIndex, "ADMBase::alp")
+ierr = MoLRegisterConstrained(ConstrainedIndex)
+\end{verbatim}
+    \end{Example}
+  \end{ExampleSection}
+
+\end{FunctionDescription}
+
+
+
+\begin{FunctionDescription}{MoLRegisterSaveAndRestore}
+  \label{MoLRegisterSaveAndRestore}
+  
+  Tells MoL that the given GF is in the Save and Restore category.
+
+  \begin{SynopsisSection}
+    \begin{Synopsis}{C}
+      CCTK\_INT ierr = MoLRegisterSaveAndRestore(CCTK\_INT SandRIndex)
+    \end{Synopsis}
+    \begin{Synopsis}{Fortran}
+      CCTK\_INT ierr = MoLRegisterSaveAndRestore(CCTK\_INT SandRIndex)
+    \end{Synopsis}
+  \end{SynopsisSection}
+
+  \begin{ResultSection}
+    \begin{ResultNote}
+      Currently if there is an error, MoL will issue a level 0
+      warning. No sensible return codes exist.
+    \end{ResultNote}
+    \begin{Result}{\rm 0}
+      success
+    \end{Result}
+  \end{ResultSection}
+
+  \begin{ParameterSection}
+    \begin{Parameter}{SandRIndex}
+      Index of the Save and Restore GF.
+    \end{Parameter}
+  \end{ParameterSection}
+
+  \begin{Discussion}
+    Should be called in a function scheduled in {\tt MoL\_Register}.
+  \end{Discussion}
+
+  \begin{SeeAlsoSection}
+    \begin{SeeAlso}{CCTK\_VarIndex()}
+      Get the GF index.
+    \end{SeeAlso}
+    \begin{SeeAlso}{MoLRegisterEvolved()}
+      Register evolved variables.
+    \end{SeeAlso}
+    \begin{SeeAlso}{MoLRegisterConstrained()}
+      Register constrained variables.
+    \end{SeeAlso}
+    \begin{SeeAlso}{MoLChangeToSaveAndRestore()}
+      Change a variable at runtime to be Save and Restore.
+    \end{SeeAlso}
+  \end{SeeAlsoSection}
+
+  \begin{ExampleSection}
+    \begin{Example}{C}
+\begin{verbatim}
+ierr = MoLRegisterSaveAndRestore(CCTK_VarIndex("ADMBase::alp"));
+\end{verbatim}
+    \end{Example}
+    \begin{Example}{Fortran}
+\begin{verbatim}
+call CCTK_VarIndex(SandRIndex, "ADMBase::alp")
+ierr = MoLRegisterSaveAndRestore(SandRIndex)
+\end{verbatim}
+    \end{Example}
+  \end{ExampleSection}
+
+\end{FunctionDescription}
+
+
+
+\begin{FunctionDescription}{MoLRegisterEvolvedGroup}
+  \label{MoLRegisterEvolvedGroup}
+  
+  Tells MoL that the given group is in the evolved category with the
+  associated update group.
+
+  \begin{SynopsisSection}
+    \begin{Synopsis}{C}
+      CCTK\_INT ierr = MoLRegisterEvolvedGroup(CCTK\_INT EvolvedIndex, CCTK\_INT
+      RHSIndex)
+    \end{Synopsis}
+    \begin{Synopsis}{Fortran}
+      CCTK\_INT ierr = MoLRegisterEvolvedGroup(CCTK\_INT EvolvedIndex, CCTK\_INT
+      RHSIndex)
+    \end{Synopsis}
+  \end{SynopsisSection}
+
+  \begin{ResultSection}
+    \begin{ResultNote}
+      Currently if there is an error, MoL will issue a level 0
+      warning. No sensible return codes exist.
+    \end{ResultNote}
+    \begin{Result}{\rm 0}
+      success
+    \end{Result}
+  \end{ResultSection}
+
+  \begin{ParameterSection}
+    \begin{Parameter}{EvolvedIndex}
+      Index of the group to be evolved.
+    \end{Parameter}
+    \begin{Parameter}{RHSIndex}
+      Index of the associated update group.
+    \end{Parameter}
+  \end{ParameterSection}
+
+  \begin{Discussion}
+    Should be called in a function scheduled in {\tt MoL\_Register}.
+  \end{Discussion}
+
+  \begin{SeeAlsoSection}
+    \begin{SeeAlso}{CCTK\_GroupIndex()}
+      Get the group index.
+    \end{SeeAlso}
+    \begin{SeeAlso}{MoLRegisterSaveAndRestoreGroup()}
+      Register Save and Restore variables.
+    \end{SeeAlso}
+    \begin{SeeAlso}{MoLRegisterConstrainedGroup()}
+      Register constrained variables.
+    \end{SeeAlso}
+  \end{SeeAlsoSection}
+
+  \begin{ExampleSection}
+    \begin{Example}{C}
+\begin{verbatim}
+ierr = MoLRegisterEvolvedGroup(CCTK_GroupIndex("wavetoymol::scalarevolvemol"),
+                               CCTK_GroupIndex("wavetoymol::scalarevolvemolrhs"));
+\end{verbatim}
+    \end{Example}
+    \begin{Example}{Fortran}
+\begin{verbatim}
+call CCTK_GroupIndex(EvolvedIndex, "wavetoymol::scalarevolvemol")
+call CCTK_GroupIndex(RHSIndex, "wavetoymol::scalarevolvemolrhs")
+ierr = MoLRegisterEvolvedGroup(EvolvedIndex, RHSIndex)
+\end{verbatim}
+    \end{Example}
+  \end{ExampleSection}
+
+\end{FunctionDescription}
+
+
+
+\begin{FunctionDescription}{MoLRegisterConstrainedGroup}
+  \label{MoL-RegisterConstrainedGroup}
+  
+  Tells MoL that the given group is in the constrained category.
+
+  \begin{SynopsisSection}
+    \begin{Synopsis}{C}
+      CCTK\_INT ierr = MoLRegisterConstrainedGroup(CCTK\_INT ConstrainedIndex)
+    \end{Synopsis}
+    \begin{Synopsis}{Fortran}
+      CCTK\_INT ierr = MoLRegisterConstrainedGroup(CCTK\_INT ConstrainedIndex)
+    \end{Synopsis}
+  \end{SynopsisSection}
+
+  \begin{ResultSection}
+    \begin{ResultNote}
+      Currently if there is an error, MoL will issue a level 0
+      warning. No sensible return codes exist.
+    \end{ResultNote}
+    \begin{Result}{\rm 0}
+      success
+    \end{Result}
+  \end{ResultSection}
+
+  \begin{ParameterSection}
+    \begin{Parameter}{ConstrainedIndex}
+      Index of the constrained group.
+    \end{Parameter}
+  \end{ParameterSection}
+
+  \begin{Discussion}
+    Should be called in a function scheduled in {\tt MoL\_Register}.
+  \end{Discussion}
+
+  \begin{SeeAlsoSection}
+    \begin{SeeAlso}{CCTK\_GroupIndex()}
+      Get the group index.
+    \end{SeeAlso}
+    \begin{SeeAlso}{MoLRegisterEvolvedGroup()}
+      Register evolved variables.
+    \end{SeeAlso}
+    \begin{SeeAlso}{MoLRegisterSaveAndRestoreGroup()}
+      Register Save and Restore variables.
+    \end{SeeAlso}
+    \begin{SeeAlso}{MoLChangeToConstrained()}
+      Change a variable at runtime to be constrained.
+    \end{SeeAlso}
+  \end{SeeAlsoSection}
+
+  \begin{ExampleSection}
+    \begin{Example}{C}
+\begin{verbatim}
+ierr = MoLRegisterConstrainedGroup(CCTK_VarIndex("ADMBase::alp"));
+\end{verbatim}
+    \end{Example}
+    \begin{Example}{Fortran}
+\begin{verbatim}
+call CCTK_GroupIndex(ConstrainedIndex, "ADMBase::alp")
+ierr = MoLRegisterConstrainedGroup(ConstrainedIndex)
+\end{verbatim}
+    \end{Example}
+  \end{ExampleSection}
+
+\end{FunctionDescription}
+
+
+
+\begin{FunctionDescription}{MoLRegisterSaveAndRestoreGroup}
+  \label{MoL-RegisterSaveAndRestoreGroup}
+  
+  Tells MoL that the given group is in the Save and Restore category.
+
+  \begin{SynopsisSection}
+    \begin{Synopsis}{C}
+      CCTK\_INT ierr = MoLRegisterSaveAndRestoreGroup(CCTK\_INT SandRIndex)
+    \end{Synopsis}
+    \begin{Synopsis}{Fortran}
+      CCTK\_INT ierr = MoLRegisterSaveAndRestoreGroup(CCTK\_INT SandRIndex)
+    \end{Synopsis}
+  \end{SynopsisSection}
+
+  \begin{ResultSection}
+    \begin{ResultNote}
+      Currently if there is an error, MoL will issue a level 0
+      warning. No sensible return codes exist.
+    \end{ResultNote}
+    \begin{Result}{\rm 0}
+      success
+    \end{Result}
+  \end{ResultSection}
+
+  \begin{ParameterSection}
+    \begin{Parameter}{SandRIndex}
+      Index of the save and restore group.
+    \end{Parameter}
+  \end{ParameterSection}
+
+  \begin{Discussion}
+    Should be called in a function scheduled in {\tt MoL\_Register}.
+  \end{Discussion}
+
+  \begin{SeeAlsoSection}
+    \begin{SeeAlso}{CCTK\_GroupIndex()}
+      Get the group index.
+    \end{SeeAlso}
+    \begin{SeeAlso}{MoLRegisterEvolvedGroup()}
+      Register evolved variables.
+    \end{SeeAlso}
+    \begin{SeeAlso}{MoLRegisterConstrainedGroup()}
+      Register constrained variables.
+    \end{SeeAlso}
+  \end{SeeAlsoSection}
+
+  \begin{ExampleSection}
+    \begin{Example}{C}
+\begin{verbatim}
+ierr = MoLRegisterSaveAndRestoreGroup(CCTK_GroupIndex("ADMBase::shift"));
+\end{verbatim}
+    \end{Example}
+    \begin{Example}{Fortran}
+\begin{verbatim}
+call CCTK_GroupIndex(SandRIndex, "ADMBase::shift")
+ierr = MoLRegisterSaveAndRestoreGroup(SandRIndex)
+\end{verbatim}
+    \end{Example}
+  \end{ExampleSection}
+
+\end{FunctionDescription}
+
+
+
+\begin{FunctionDescription}{MoLChangeToEvolved}
+  \label{MoL-ChangeToEvolved}
+
+  Sets a GF to belong to the evolved category, with the associated
+  update GF. Not used for the initial setting.
+
+  \begin{SynopsisSection}
+    \begin{Synopsis}{C}
+      CCTK\_INT ierr = MoLChangeToEvolved(CCTK\_INT EvolvedIndex, CCTK\_INT RHSIndex)
+    \end{Synopsis}
+    \begin{Synopsis}{Fortran}
+      CCTK\_INT ierr = MoLChangeToEvolved(CCTK\_INT EvolvedIndex, CCTK\_INT RHSIndex)
+    \end{Synopsis}
+  \end{SynopsisSection}
+
+  \begin{ResultSection}
+    \begin{ResultNote}
+      Currently if there is an error, MoL will issue a level 0
+      warning. No sensible return codes exist.
+    \end{ResultNote}
+    \begin{Result}{\rm 0}
+      success
+    \end{Result}
+  \end{ResultSection}
+
+  \begin{ParameterSection}
+    \begin{Parameter}{EvolvedIndex}
+      Index of the evolved GF.
+    \end{Parameter}
+    \begin{Parameter}{RHSIndex}
+      Index of the associated update GF.
+    \end{Parameter}
+  \end{ParameterSection}
+
+  \begin{Discussion}
+    Should be called in a function scheduled in {\tt MoL\_PreStep}.
+    Note that this function was designed to allow mixed slicings for
+    thorn ADMBase. This set of functions is largely untested and
+    should be used with great care.
+  \end{Discussion}
+
+  \begin{SeeAlsoSection}
+    \begin{SeeAlso}{CCTK\_VarIndex()}
+      Get the GF index.
+    \end{SeeAlso}
+    \begin{SeeAlso}{MoLRegisterEvolved()}
+      Register evolved variables.
+    \end{SeeAlso}
+    \begin{SeeAlso}{MoLChangeToSaveAndRestore()}
+      Change a variable at runtime to be Save and Restore.
+    \end{SeeAlso}
+    \begin{SeeAlso}{MoLChangeToConstrained()}
+      Change a variable at runtime to be constrained.
+    \end{SeeAlso}
+  \end{SeeAlsoSection}
+
+  \begin{ExampleSection}
+    \begin{Example}{C}
+\begin{verbatim}
+ierr = MoLChangeToEvolved(CCTK_VarIndex("ADMBase::alp"),
+                          CCTK_VarIndex("adm_bssn::adm_bs_salp"));
+\end{verbatim}
+    \end{Example}
+    \begin{Example}{Fortran}
+\begin{verbatim}
+call CCTK_VarIndex(EvolvedIndex, "ADMBase::alp")
+call CCTK_VarIndex(RHSIndex,"adm_bssn::adm_bs_salp")
+ierr = MoLChangeToEvolved(EvolvedIndex, RHSIndex)
+\end{verbatim}
+    \end{Example}
+  \end{ExampleSection}
+
+\end{FunctionDescription}
+
+
+
+\begin{FunctionDescription}{MoLChangeToConstrained}
+  \label{MoLChangeToConstrained}
+  
+  Sets a GF to belong to the constrained category. Not used for the
+  initial setting.
+
+  \begin{SynopsisSection}
+    \begin{Synopsis}{C}
+      CCTK\_INT ierr = MoLChangeToConstrained(CCTK\_INT EvolvedIndex)
+    \end{Synopsis}
+    \begin{Synopsis}{Fortran}
+      CCTK\_INT ierr = MoLChangeToConstrained(CCTK\_INT EvolvedIndex)
+    \end{Synopsis}
+  \end{SynopsisSection}
+
+  \begin{ResultSection}
+    \begin{ResultNote}
+      Currently if there is an error, MoL will issue a level 0
+      warning. No sensible return codes exist.
+    \end{ResultNote}
+    \begin{Result}{\rm 0}
+      success
+    \end{Result}
+  \end{ResultSection}
+
+  \begin{ParameterSection}
+    \begin{Parameter}{ConstrainedIndex}
+      Index of the constrained GF.
+    \end{Parameter}
+  \end{ParameterSection}
+
+  \begin{Discussion}
+    Should be called in a function scheduled in {\tt MoL\_PreStep}.
+    Note that this function was designed to allow mixed slicings for
+    thorn ADMBase. This set of functions is largely untested and
+    should be used with great care.
+  \end{Discussion}
+
+  \begin{SeeAlsoSection}
+    \begin{SeeAlso}{CCTK\_VarIndex()}
+      Get the GF index.
+    \end{SeeAlso}
+    \begin{SeeAlso}{MoLRegisterConstrained()}
+      Register constrained variables.
+    \end{SeeAlso}
+    \begin{SeeAlso}{MoLChangeToSaveAndRestore()}
+      Change a variable at runtime to be Save and Restore.
+    \end{SeeAlso}
+    \begin{SeeAlso}{MoLChangeToEvolved()}
+      Change a variable at runtime to be evolved.
+    \end{SeeAlso}
+  \end{SeeAlsoSection}
+
+  \begin{ExampleSection}
+    \begin{Example}{C}
+\begin{verbatim}
+ierr = MoLChangeToConstrained(CCTK_VarIndex("ADMBase::alp"));
+\end{verbatim}
+    \end{Example}
+    \begin{Example}{Fortran}
+\begin{verbatim}
+call CCTK_VarIndex(EvolvedIndex, "ADMBase::alp")
+ierr = MoLChangeToConstrained(EvolvedIndex)
+\end{verbatim}
+    \end{Example}
+  \end{ExampleSection}
+
+\end{FunctionDescription}
+
+
+
+\begin{FunctionDescription}{MoLChangeToSaveAndRestore}
+  \label{MoLChangeToSaveAndRestore}
+  
+  Sets a GF to belong to the Save and Restore category. Not used for the
+  initial setting.
+
+  \begin{SynopsisSection}
+    \begin{Synopsis}{C}
+      CCTK\_INT ierr = MoLChangeToSaveAndRestore(CCTK\_INT SandRIndex)
+    \end{Synopsis}
+    \begin{Synopsis}{Fortran}
+      CCTK\_INT ierr = MoLChangeToSaveAndRestore(CCTK\_INT SandRIndex)
+    \end{Synopsis}
+  \end{SynopsisSection}
+
+  \begin{ResultSection}
+    \begin{ResultNote}
+      Currently if there is an error, MoL will issue a level 0
+      warning. No sensible return codes exist.
+    \end{ResultNote}
+    \begin{Result}{\rm 0}
+      success
+    \end{Result}
+  \end{ResultSection}
+
+  \begin{ParameterSection}
+    \begin{Parameter}{SandRIndex}
+      Index of the Save and Restore GF.
+    \end{Parameter}
+  \end{ParameterSection}
+
+  \begin{Discussion}
+    Should be called in a function scheduled in {\tt MoL\_PreStep}.
+    Note that this function was designed to allow mixed slicings for
+    thorn ADMBase. This set of functions is largely untested and
+    should be used with great care.
+  \end{Discussion}
+
+  \begin{SeeAlsoSection}
+    \begin{SeeAlso}{CCTK\_VarIndex()}
+      Get the GF index.
+    \end{SeeAlso}
+    \begin{SeeAlso}{MoLRegisterSaveAndRestore()}
+      Register Save and Restore variables.
+    \end{SeeAlso}
+    \begin{SeeAlso}{MoLChangeToEvolved()}
+      Change a variable at runtime to be evolved.
+    \end{SeeAlso}
+    \begin{SeeAlso}{MoLChangeToConstrained()}
+      Change a variable at runtime to be constrained.
+    \end{SeeAlso}
+  \end{SeeAlsoSection}
+
+  \begin{ExampleSection}
+    \begin{Example}{C}
+\begin{verbatim}
+ierr = MoLChangeToSaveAndRestore(CCTK_VarIndex("ADMBase::alp"));
+\end{verbatim}
+    \end{Example}
+    \begin{Example}{Fortran}
+\begin{verbatim}
+call CCTK_VarIndex(SandRIndex, "ADMBase::alp")
+ierr = MoLChangeToSaveAndRestore(SandRIndex)
+\end{verbatim}
+    \end{Example}
+  \end{ExampleSection}
+
+\end{FunctionDescription}
+
+
+
+\begin{FunctionDescription}{MoLChangeToNone}
+  \label{MoLChangeToNone}
+  
+  Sets a GF to belong to the ``unknown'' category. Not used for the
+  initial setting.
+
+  \begin{SynopsisSection}
+    \begin{Synopsis}{C}
+      CCTK\_INT ierr = MoLChangeToNone(CCTK\_INT RemoveIndex)
+    \end{Synopsis}
+    \begin{Synopsis}{Fortran}
+      CCTK\_INT ierr = MoLChangeToNone(CCTK\_INT RemoveIndex)
+    \end{Synopsis}
+  \end{SynopsisSection}
+
+  \begin{ResultSection}
+    \begin{ResultNote}
+      Currently if there is an error, MoL will issue a level 0
+      warning. No sensible return codes exist.
+    \end{ResultNote}
+    \begin{Result}{\rm 0}
+      success
+    \end{Result}
+  \end{ResultSection}
+
+  \begin{ParameterSection}
+    \begin{Parameter}{RemoveIndex}
+      Index of the ``unknown'' GF.
+    \end{Parameter}
+  \end{ParameterSection}
+
+  \begin{Discussion}
+    Should be called in a function scheduled in {\tt MoL\_PreStep}.
+    Note that this function was designed to allow mixed slicings for
+    thorn ADMBase. This set of functions is largely untested and
+    should be used with great care.
+  \end{Discussion}
+
+  \begin{SeeAlsoSection}
+    \begin{SeeAlso}{CCTK\_VarIndex()}
+      Get the GF index.
+    \end{SeeAlso}
+    \begin{SeeAlso}{MoLChangeToEvolved()}
+      Change a variable at runtime to be evolved.
+    \end{SeeAlso}
+    \begin{SeeAlso}{MoLChangeToSaveAndRestore()}
+      Change a variable at runtime to be Save and Restore.
+    \end{SeeAlso}
+    \begin{SeeAlso}{MoLChangeToConstrained()}
+      Change a variable at runtime to be constrained.
+    \end{SeeAlso}
+  \end{SeeAlsoSection}
+
+  \begin{ExampleSection}
+    \begin{Example}{C}
+\begin{verbatim}
+ierr = MoLChangeToNone(CCTK_VarIndex("ADMBase::alp"));
+\end{verbatim}
+    \end{Example}
+    \begin{Example}{Fortran}
+\begin{verbatim}
+call CCTK_VarIndex(RemoveIndex, "ADMBase::alp")
+ierr = MoLChangeToNone(RemoveIndex)
+\end{verbatim}
+    \end{Example}
+  \end{ExampleSection}
+
+\end{FunctionDescription}
+
+\begin{thebibliography}{9}
+
+\bibitem{AlphaThorns_MoL_Thornburg93}
 J. Thornburg.
 \newblock {N}umerical {R}elativity in {B}lack {H}ole {S}pacetimes. 
 \newblock Unpublished thesis, University of British Columbia.
@@ -866,14 +1650,14 @@ J. Thornburg.
 \newblock Available from \mbox{\tt
   http://www.aei.mpg.de/\~{}jthorn/phd/html/phd.html}. 
 
-\bibitem{jt2}
+\bibitem{AlphaThorns_MoL_Thornburg99}
 J. Thornburg.
 \newblock A {3+1} {C}omputational {S}cheme for {D}ynamic {S}pherically
 {S}ymmetric {B}lack {H}ole {S}pacetimes -- {II}: {T}ime {E}volution.
 \newblock Preprint {\tt gr-qc/9906022}, submitted to {\em Phys. Rev.}
 {\bf D}. 
 
-\bibitem{shu}
+\bibitem{AlphaThorns_MoL_Shu99}
 C. Shu.
 \newblock {H}igh {O}rder {ENO} and {WENO} {S}chemes for
 {C}omputational {F}luid {D}ynamics.
@@ -884,15 +1668,14 @@ C. Shu.
   {S}chemes for {H}yperbolic {C}onservation {L}aws} at {\tt
   http://www.icase.edu/library/reports/rdp/97/97-65RDP.tex.refer.html}. 
 
-\bibitem{nc}
+\bibitem{AlphaThorns_MoL_Neilsen00}
 D.~W. Neilsen and M.~W. Choptuik.
 \newblock Ultrarelativistic fluid dynamics.
 \newblock {\em Class. Quantum Grav.}, {\bf 17}:\penalty0 733--759, 2000.
 
 \end{thebibliography}
 
-\include{interface}
-\include{param}
-\include{schedule}
+% Do not delete next line
+% END CACTUS THORNGUIDE
 
 \end{document}