CCTK_Interp() -> CCTK_InterpGridArrays(). Fixed a few typos.

git-svn-id: http://svn.cactuscode.org/arrangements/CactusBase/SymBase/trunk@21 906471b6-c639-44d1-9ea0-3e3d6879f074

1 files changed, 11 insertions, 9 deletions

diff --git a/doc/documentation.tex b/doc/documentation.tex
index 7111d5b..956a10e 100644
--- a/doc/documentation.tex
+++ b/doc/documentation.tex
@@ -275,6 +275,8 @@ for (face=0; face<6; ++face) {
 }
 \end{verbatim}
 
+\hrule
+
 \begin{verbatim}
 #include "util_Table.h"
 
@@ -306,15 +308,15 @@ the actual computational grid, but can be mapped into the grid through
 the symmetries.  Thorn SymBase provides a mechanism by which symmetry
 conditions can register routines that handle this mapping when a
 global interpolator is called.  Additionally, the driver has to be
-aware that is calls thorn SymBase's mapping routine before it actually
+aware that it calls thorn SymBase's mapping routine before it actually
 interpolates.  The whole mechanism is transparent for the user.
 
 The mechanism by which the grid points are mapped into the domain
 works as follows:
 \begin{enumerate}
-\item The user calls \texttt{CCTK\_Interp} with a list of coordinates.
+\item The user calls \texttt{CCTK\_InterpGridArrays} with a list of coordinates.
 \item The flesh forwards this call to the driver.
-\item The driver calls SymBase's aliased function.
+\item The driver calls SymBase's aliased function,
   \texttt{SymmetryInterpolate}, passing along all arguments.
 \item SymBase sets a flag for all boundaries that have a symmetry
   condition associated with it, and then calls
@@ -341,7 +343,7 @@ works as follows:
   e.g., after a reflection on the lower $x$-boundary, $x$-components
   of vectors need their sign changed.
 \item The chain of recursive calls unravels until the call to
-  \texttt{CCTK\_Interp} returns.
+  \texttt{CCTK\_InterpGridArrays} returns.
 \end{enumerate}
 
 This mechanism has thus four players:
@@ -354,8 +356,8 @@ This mechanism has thus four players:
   interpolation'' routine that first maps the points into the domain,
   then calls SymBase recursively, and finally corrects the tensor
   types of the interpolated quantities.
-\item Finally, the user calls \texttt{CCTK\_Interp} as before, and
-  everything happens transparently for him.
+\item Finally, the user calls \texttt{CCTK\_InterpGridArrays} as before, and
+  everything happens transparently for her.
 \end{itemize}
 
 
@@ -365,7 +367,7 @@ This mechanism has thus four players:
 The driver has to call SymBase's aliased function
 \texttt{SymmetryInterpolate}, and has to provide an aliased function
 \texttt{DriverInterpolate}.  Both functions have essentially the same
-prototype as \texttt{CCTK\_Interp}, which are:
+prototype as \texttt{CCTK\_InterpGridArrays}, which are:
 
 \begin{verbatim}
 CCTK_INT FUNCTION
@@ -431,8 +433,8 @@ CCTK_INT symmetry_interpolate
 \end{verbatim}
 
 These arguments are essentially the same as those for
-\texttt{CCTK\_Interp}, except that the bit field \texttt{faces} flags
-those faces that still their symmetry boundary condition applied to
+\texttt{CCTK\_InterpGridArrays}, except that the bit field \texttt{faces} flags
+those faces that still need their symmetry boundary condition applied to
 the interpolation points.  The aliased function
 \texttt{SymmetryRegisterGridInterpolator} has the prototype