Some updates with the recent methods.

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

1 files changed, 28 insertions, 22 deletions

diff --git a/doc/documentation.tex b/doc/documentation.tex
index 3558990..9e61b6c 100644
--- a/doc/documentation.tex
+++ b/doc/documentation.tex
@@ -186,10 +186,9 @@ For more information on the Method of Lines the most comprehensive
 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
+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.
+Choptuik~\cite{AlphaThorns_MoL_Neilsen00} is also quite good.
 
 \section{How to use}
 \label{AlphaThorns_MoL_sec:use}
@@ -205,14 +204,15 @@ 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
 method. The keyword {\tt MoL\_ODE\_Method} chooses between the
-different methods. Currently supported are {\tt RK2}, {\tt ICN} and
-{\tt Generic}. These are second order Runge-Kutta, Iterative Crank
-Nicholson, and the generic Shu-Osher type Runge-Kutta methods. To
-switch between the different types of generic methods there is also
-the keyword {\tt Generic\_Type} which is currently restricted to {\tt
-  RK} for the standard TVD Runge-Kutta methods (first to fourth order)
-and {\tt ICN} for the implementation of the Iterative Crank Nicholson
-method in generic form.
+different methods. Currently supported are {\tt RK2}, {\tt RK3}, {\tt
+  ICN}, {\tt ICN-Avg} and {\tt Generic}. These are second order
+Runge-Kutta, third order Runge-Kutta, Iterative Crank Nicholson,
+Iterative Crank Nicholson with averaging, and the generic Shu-Osher
+type Runge-Kutta methods. To switch between the different types of
+generic methods there is also the keyword {\tt Generic\_Type} which is
+currently restricted to {\tt RK} for the standard TVD Runge-Kutta
+methods (first to fourth order) and {\tt ICN} for the implementation
+of the Iterative Crank Nicholson method in generic form.
 
 The parameter {\tt MoL\_Intermediate\_Steps} controls the number of
 intermediate steps for the ODE solver. For the generic Runge-Kutta
@@ -225,8 +225,8 @@ The parameter {\tt MoL\_Num\_Scratch\_Levels} controls the amount of
 scratch space used. If this is insufficient for the method selected
 there will be an error at parameter checking time. This parameter
 defaults to 0, as no scratch space is required for the efficient ICN
-and Runge-Kutta 2 solvers. For the generic solvers this must be at
-least {\tt MoL\_Intermediate\_Steps - 1}.
+and Runge-Kutta 2 and 3 solvers. For the generic solvers this must be
+at least {\tt MoL\_Intermediate\_Steps - 1}.
 
 A final parameter is {\tt MoL\_Memory\_Always\_On} which switches on
 memory for the scratch space always if true and only during evolution
@@ -266,6 +266,11 @@ cateogories.
   MoL. These would include temporary variables for analysis or setting
   up the initial data. These can safely be ignored.
 \end{enumerate}
+As a generic rule of thumb, variables for which you have a time
+evolution equation are {\it evolved} (obviously), variables which your
+thorn sets but does not evolve are {\it constrained}, and any other
+variables which your thorn reads during evolution is a {\it Save and
+  Restore} variable.
 
 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 constrained variable
@@ -323,9 +328,9 @@ 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{AlphaThorns_MoL_eq:mol2})) should be
-registered at the same time. The appropriate functions are given in
-section~\ref{AlphaThorns_MoL_sec:molfns}.
+term (${\bf L}({\bf q})$ in equation~(\ref{AlphaThorns_MoL_eq:mol2}))
+should be registered at the same time. The appropriate functions are
+given in section~\ref{AlphaThorns_MoL_sec:molfns}.
 
 These functions are provided using function aliasing. For details on
 using function aliasing, see sections B10.5 and F2.2.3 of the
@@ -366,10 +371,10 @@ USES FUNCTION MoLChangeToNone
 
 Note that the list of paramters not complete; see the section on
 parameters for the use of arrays or complex variables. However, the
-list of functions is, and is expanded on in section~\ref{AlphaThorns_MoL_sec:molfns}.
-MoL will check whether a group or variable is a GF or an array and
-whether it is real or complex. Note that currently complex variable
-support is disabled.
+list of functions is, and is expanded on in
+section~\ref{AlphaThorns_MoL_sec:molfns}.  MoL will check whether a
+group or variable is a GF or an array and whether it is real or
+complex. Note that currently complex variable support is disabled.
 
 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
@@ -411,14 +416,15 @@ return the RHS ${\bf L}({\bf q})$. All the book-keeping to ensure that
 it is passed the correct intermediate state at that the GFs contain
 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.
+separate processors will be dealt with by the MoL thorn, the driver
+the flesh.
 
 \section{Example}
 \label{AlphaThorns_MoL_sec:example}
 
 As a fairly extended example of how to use MoL I'll outline how
 ADM\_BSSN works in this context. The actual implementation of this is
-given in the thorn {\tt AEIDevelopment/BSSN\_MoL}. 
+given in the thorn {\tt AEIThorns/BSSN\_MoL}.
 
 As normal the required variables are defined in the {\tt
   interface.ccl} file, together with the associated source terms. For