Fixed numerous spelling errors, some grammatical boo-boos, formatting flaws

(inlcuding gratuitous hyphenation and un-dotted 'e.g.' and 'i.e')

Made more consistent use of italics (using \emph and \textit,
which are just better than \it for formatting)
	1) emphasis using \emph
	2) definitions, etc using \textit

Made capitalization more consistent and in-line with common usage
	1) Acronyms: MPI, MPICH, CVS
	2) Languages as proper nouns: Fortran, Perl
	3) Special capitalizations: LaTeX, PostScript
	4) Flesh seems best as a proper name, so capitalize
	5) thorn is a generic term, so capitalize accordingly
	6) 'tags' appears to be generic (TAGS is name of emacs database)

Made use of teletype font more consistent: ONLY for
	1) directory/file names
	2) typed commands and program names
	3) code
	4) URL's


git-svn-id: http://svn.cactuscode.org/flesh/trunk@3485 17b73243-c579-4c4c-a9d2-2d5706c11dac

1 files changed, 333 insertions, 322 deletions

diff --git a/doc/UsersGuide/ThornWriters.tex b/doc/UsersGuide/ThornWriters.tex
index 9bb81075..58ddb4b8 100644
--- a/doc/UsersGuide/ThornWriters.tex
+++ b/doc/UsersGuide/ThornWriters.tex
@@ -11,7 +11,7 @@
 %   @author   Jonathan Thornburg <jthorn@aei.mpg.de>
 %   @desc     Revise section "Interpolation Operators" to cover the
 %             new interpolation API (when we will have multiple APIs
-%             coexisting, eg CCTK_InterpLocalUniform() and
+%             coexisting, e.g. CCTK_InterpLocalUniform() and
 %             CCTK_InterpLocalNonUniform())
 %   @endhistory
 % @@*/
@@ -43,27 +43,27 @@ you may use to gain extra functionality.
 
 \section{Thorns}
 
-A thorn is the basic working module within Cactus.  All user-supplied
+A thorn is the basic working module within Cactus.  All user supplied
 code goes into thorns, which are, by and large, independent of each other.
-Thorns communicate with each other via calls to the flesh API, plus, more
+Thorns communicate with each other via calls to the Flesh API, plus, more
 rarely, custom APIs of other thorns.
 
-The connection from a thorn to the flesh or to other thorns is specified in
+The connection from a thorn to the Flesh or to other thorns is specified in
 configuration files which are parsed at compile time and used to generate
-glue code which encapsulates the external appearence of a thorn.
+glue code which encapsulates the external appearance of a thorn.
 
 Thorn names must be (case independently) unique, must start with a letter,
 can only contain
 letters, numbers or underscores, and must contain 27 characters or less.
 In addition, a thorn cannot have the name {\t doc}, this is reserved
 for arrangement documentation. Arrangement names which start with a
-`\#', or finish with `\~{}' or `.bak' will be ignored.
+`{\t \#}', or finish with `{\t \~{}}' or `{\t .bak}' will be ignored.
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 \section{Arrangements}
 
-Thorns are grouped into {\em arrangements}.  This is a logical grouping of
+Thorns are grouped into \textit{arrangements}.  This is a logical grouping of
 thorns which is purely for organisational purposes. For example,
 you might wish to keep all your initial data thorns in one arrangement,
 and all your evolution thorns in another arrangement, or you may want
@@ -75,7 +75,7 @@ Cactus directory.  Arrangement names must be (case independently) unique,
 must start with a letter,
 and can only contain
 letters, numbers or underscores. Arrangement names which start with a
-`\#', or finish with `\~{}' or `.bak' will be ignored.
+`{\t \#}', or finish with `{\t \~{}}' or `{\t .bak}' will be ignored.
 
 Inside an arrangement directory there are directories for each thorn
 belonging to the arrangement.
@@ -86,25 +86,25 @@ belonging to the arrangement.
 
 \label{sec:im}
 
-One of the key concepts for thorns is the concept of the {\bf implementation}.
+One of the key concepts for thorns is the concept of the \textit{implementation}.
 Relationships among thorns are all based upon relationships among the
-{\bf implementations} they provide.
+implementations they provide.
 In principle it should be possible to swap one thorn providing an
 implementation with another thorn providing that implementation,
 without affecting any other thorn.
 
-An {\bf implementation} defines a group of variables and parameters which
+An implementation defines a group of variables and parameters which
 are used to implement some functionality.  For example the thorn
-{\tt CactusPUGH/PUGH} provides the implementation {\it driver}.  This
+{\tt CactusPUGH/PUGH} provides the implementation {\tt driver}.  This
 implementation is responsible for providing memory for grid variables and
 for communication.  Another thorn can also implement {\tt driver},
-and both thorns can be compiled in {\em at the same time}.
+and both thorns can be compiled in \emph{at the same time}.
 At runtime, the user can decide which thorn providing {\tt driver} is used.
 No other thorn should be affected by this choice.
 
 When a thorn decides it needs access to a variable or a parameter provided by
 another thorn, it defines a relationship between itself and the other thorn's
-{\bf implementation}, not explicitly with the other {\bf thorn}.
+\emph{implementation}, not explicitly with the other \emph{thorn}.
 This allows the transparent replacement, at compile or runtime, of one
 thorn with another thorn providing the same functionality as seen by
 the other thorns.
@@ -124,7 +124,7 @@ A thorn consists of a subdirectory of an arrangement containing four
 administrative files:
 
 \begin{Lentry}
-\item[{\tt interface.ccl}] the cactus interface, which defines the grid
+\item[{\tt interface.ccl}] the Cactus interface, which defines the grid
 functions, variables, etc. See \ref{sec:in}.
 \item[{\tt param.ccl}] the parameters introduced by this thorn, and the
 parameters needed from other thorns. See
@@ -132,7 +132,7 @@ parameters needed from other thorns. See
 \item[{\tt schedule.ccl}] scheduling information for routines called by
 \item[{\tt configuration.ccl}] configuration options for the thorn. See
 \ref{sec:co}.
-the flesh. See \ref{sec:sc}.
+the Flesh. See \ref{sec:sc}.
 \end{Lentry}
 
 Thorns can also contain
@@ -144,7 +144,7 @@ Thorns can also contain
 \item a {\tt doc} directory for documentation
 \item a {\tt par} directory for example parameter files
 \item a {\tt test} subdirectory may also be added, to hold the thorn's
-    testsuite. See \ref{sec:adatesu} for details.
+    test suite. See \ref{sec:adatesu} for details.
 \end{itemize}
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -152,29 +152,29 @@ Thorns can also contain
 \section{Creating a thorn}
 
 
-To simplify the creation of a thorn, a make target {\tt
+To simplify the creation of a thorn, a {\tt make} target {\tt
 gmake newthorn} has been provided. When this is run:
 
 \begin{enumerate}
 \item{} You will be prompted for the name of the new thorn.
-\item{} You will be prompted for the name of the arrangement you would
-like to include your thorn in. Either enter a new arrangement name or pick
-one from the list of available arrangements that are shown.
+\item{} You will be prompted for the name of the arrangement in which you
+would like to include your thorn. Either enter a new arrangement name or
+pick one from the list of available arrangements that are shown.
 \end{enumerate}
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 \section{Configuring your thorn}
 
-The interaction of a thorn with the flesh and other thorns is controlled
-by various configuration files.
+The interaction of a thorn with the Flesh and other thorns is controlled
+by certain configuration files.
 
-These consist of:
+These are:
 
 \begin{Lentry}
 
 \item [{\tt interface.ccl}]
-This defines the {\bf implementation} (Section~\ref{sec:im}) the thorn
+This defines the \textit{implementation} (Section~\ref{sec:im}) the thorn
 provides, and the variables the thorn needs, along with their
 visibility to other implementations.
 
@@ -183,7 +183,7 @@ This defines the parameters that are used to control the thorn, along
 with their visibility to other implementations.
 
 \item [{\tt schedule.ccl}]
-This defines which functions from the thorn are called and when they are
+This defines which functions are called from the thorn and when they are
 called. It also handles memory and communication assignment for grid variables.
 
 \item [{\tt configuration.ccl}]
@@ -193,12 +193,15 @@ This file is optional for a thorn. If it exists it contains configuration option
 
 \subsection{General syntax of CCL files}
 
-{\bf Cactus Configuration Language} (CCL) files are simple text files
+\textit{Cactus Configuration Language} (CCL) files are simple text files
 used to define configuration information for a thorn.  CCL files are
-case independent, and may contain comments introduced by the `\#' character,
-which indicates that the rest of the line is a comment. If the last non-blank character of a line in a CCL file is a backslash {\tt $\backslash$}, the following line is treated as a continuation of the current line.
+case independent, and may contain comments introduced by the hash `{\tt \#}'
+character, which indicates that the rest of the line is a comment. If the last
+non-blank character of a line in a CCL file is a backslash
+`{\tt $\backslash$}', the
+following line is treated as a continuation of the current line.
 
-\subsection{The {\tt interface.ccl}}
+\subsection{The {\tt interface.ccl} file}
 
 The {\tt interface.ccl} file is used to declare
 
@@ -216,6 +219,7 @@ implements: <name>
 \end{verbatim}
 Where {\tt <name>} can be any combination of alphanumeric
 characters and underscores, and is case independent.
+
 There are three different access levels available for variables
 
 \begin{Lentry}
@@ -239,8 +243,8 @@ An implementation may inherit from any number of other implementations.
 \item [{\tt Friend: <name>}]
 This gets all {\tt Protected} variables from implementation {\tt <name>}, but,
 unlike {\tt inherits}, it is symmetric and also defines a transitive relation by
-pushing its own implementations {\tt Protected} variables onto implementation
-{\tt <name>}.  This keyword is used define to a group of implementations which
+pushing its own implementation's {\tt Protected} variables onto implementation
+{\tt <name>}.  This keyword is used to define a group of implementations which
 all end up with the same {\tt Protected} variables.
 \end{Lentry}
 
@@ -250,14 +254,15 @@ implements: wavetoy
 inherits:   grid
 friend:     wave_extract
 \end{verbatim}
-declares that the thorn provides an implementation called `wavetoy', gets
-all the {\tt public} variables declared by an implementation called `grid', and
-shares all {\tt protected} variables with {\tt wave\_extract} and its friends.
+declares that the thorn provides an implementation called {\tt wavetoy}, gets
+all the {\tt public} variables declared by an implementation called {\tt grid},
+and shares all {\tt protected} variables with {\tt wave\_extract} and its
+friends.
 
-Cactus variables, described in Chapter~\ref{chap:cava} are placed
+Cactus variables, described in Chapter~\ref{chap:cava}, are placed
 in groups with homogeneous attributes, where
 the attributes describe properties such as the data type, group type,
-dimenension, ghostsize, number of timelevels, type of staggering and
+dimension, ghostsize, number of timelevels, type of staggering and
 distribution.
 
 For example, a group, called {\tt realfields} of 5 real grid
@@ -288,10 +293,10 @@ changes the access level for any group defined in the file from that point on.
 
 All variables seen by any one thorn must have distinct names.
 
-\subsection{The {\tt param.ccl}}
+\subsection{The {\tt param.ccl} file}
 
 Users control the operation of thorns via parameters given in a file
-at runtime.  The {\tt param.ccl}
+at runtime.  The {\tt param.ccl} file
 is used to specify the parameters used to control an individual thorn, and
 to specify the values these parameters are allowed to take.  When the code
 is run it reads a parameter file and sets the parameters if they fall
@@ -321,8 +326,8 @@ A distinct string with only a few known allowed values.
 \item [{\tt STRING}]
 An arbitrary string, which must conform to a given regular expression.
 \item [{\tt BOOLEAN}]
-A boolean type which can take values 1, `t', `true', `yes' or
-0, `f', `false', `no'.
+A boolean type which can take values {\t 1}, {\t t}, {\t true}, {\t yes} or
+{\t 0}, {\t f}, {\t false}, {\t no}.
 \end{Lentry}
 
 \item the parameter name
@@ -335,13 +340,13 @@ A boolean type which can take values 1, `t', `true', `yes' or
   each element is specified with square brackets and is 0-based.  The
   size must be an integer.
 
-\item a {\tt description} of the parameter
+\item a description of the parameter
 
 \item an allowed value block -- This consists of a brace delimited
-block of lines\footnote{The beginning brace (\{) must sit on a line by
-itself; the ending brace (\}) must be preceded by a carriage return.}
+block of lines\footnote{The beginning brace ({\t \{}) must sit on a line by
+itself; the ending brace ({\t \}}) must be preceded by a carriage return.}
 describing the allowed values of the parameter.  Each range may have a
-description associated with it by placing a :: on the line and putting
+description associated with it by placing a {\t ::} on the line and putting
 the description afterwards.
 
 \item the default value --
@@ -351,8 +356,8 @@ This must be one of the allowed values.
 
 For the numeric types {\tt INT} and {\tt REAL}, a range consists
 of a string of the
-forms lower-bound:upper-bound:step where a missing number or a * denotes
-anything (i.e.\ infinite bounds or an infinitesimal step).
+form lower-bound:upper-bound:step, where a missing number or an asterisk 
+`{\t *}' denotes anything (i.e.\ infinite bounds or an infinitesimal step).
 
 For example
 \begin{verbatim}
@@ -381,10 +386,10 @@ REAL Length[2] "Length in each direction"
 } 1.0
 
 \end{verbatim}
-defines a REAL parameter, a BOOLEAN parameter, a KEYWORD and an array
-of REAL parameters.
+defines a {\tt REAL} parameter, a {\tt BOOLEAN} parameter, a {\tt KEYWORD}
+and an array of {\tt REAL} parameters.
 
-By default all parameters are {\tt private}, to change this an access
+By default all parameters are {\tt private}; to change this, an access
 specification of the form {\tt global:} or {\tt restricted:} (or
 {\tt private:} to change it back) may be placed on a line by itself.  This
 changes the access level for any parameter defined in the file from that point on.
@@ -404,7 +409,7 @@ value must be omitted --- it is impossible to set the default value of any
 parameter not originating in this thorn.
 For example, the following block adds possible values to the keyword
 {\tt initial\_data} originally defined in the implementation {\tt einstein},
-and uses the real parameter {\tt speed}.
+and uses the {\tt REAL} parameter {\tt speed}.
 
 \begin{verbatim}
 shares:einstein
@@ -426,7 +431,7 @@ Note that you must compile at least one thorn which implements {\tt einstein}.
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
-\subsection{The {\tt schedule.ccl}}
+\subsection{The {\tt schedule.ccl} file}
 \label{subsec:schedule_ccl}
 By default no routine of a thorn will be run.  The {\tt schedule.ccl}
 file defines those that should be run and when and under which
@@ -451,7 +456,7 @@ the most useful schedule bins for application thorns is given here, a complete a
 \begin{Lentry}
 
 \item [{\tt CCTK\_STARTUP}]
-For routines run before the grid hierachy is set up, for example function
+For routines run before the grid hierarchy is set up, for example function
 registration.
 
 \item [{\tt CCTK\_PARAMCHECK}]
@@ -513,7 +518,7 @@ the variables from a group in {\tt TRIGGERS} is due for output.
 \item[{\tt SYNC}]
 The keyword {\tt SYNC} specifies groups of variables which should be
 synchronised (that is, their ghostzones should be exchanged between
-processors) on exit from the routine. Specifying synchonisation of
+processors) on exit from the routine. Specifying synchronisation of
 grid variables in {\tt schedule.ccl} is an alternative to calling the
 function {\tt CCTK\_SyncGroup()} from inside a routine. Using the {\tt SYNC}
 keyword in the {\tt schedule.ccl} is the preferred method, since it
@@ -523,16 +528,16 @@ refinement.
 
 \end{Lentry}
 
-As well as schedule blocks it's possible to embed C style {\tt
-if/else} statements in the schedule.ccl.  These can be used to
+Besides schedule blocks it's possible to embed C style {\tt
+if/else} statements in the {\tt schedule.ccl} file.  These can be used to
 schedule things based upon the value of a parameter.
 
 \vskip .5cm
 {\bf Example I:}
 
 If the parameter {\tt evolve\_hydro} is positively set, the Fortran
-routine {\tt hydro\_predictor} is scheduled to run in the {\em
-evolution} loop, after the routine {\tt metric\_predictor} and before
+routine {\tt hydro\_predictor} is scheduled to run in the \textit{evolution}
+loop, after the routine {\tt metric\_predictor} and before
 {\tt metric\_corrector}. The routine names {\tt metric\_predictor} and
 {\tt metric\_corrector} may either be real routine names from the same
 or a different thorn, or they may be {\tt aliased} routine names (see the
@@ -565,7 +570,7 @@ interface is available.
 The thorns {\tt WaveToy77} and {\tt WaveToyC} each provide a
 routine to evolve the 3D wave equation: {\tt WaveToyF77\_Evolution} and
 {\tt WaveToyC\_Evolution}. The routine names have to be different, so
-that both thorns can be compiled at the same time, their functionlity
+that both thorns can be compiled at the same time, their functionality
 is identical though. Either one of them can then be activated at run
 time  in the parameter file via {\tt ActiveThorns}.
 
@@ -594,7 +599,7 @@ schedule WaveToyC_Evolution AS WaveToy_Evolution AT evol
 \end{verbatim}
 
 The thorn {\tt IDScalarWave} schedules the routine {\tt WaveBinary}
-after the alias {\em WaveToy\_Evolution}. It is scheduled independently of
+after the alias {\tt WaveToy\_Evolution}. It is scheduled independently of
 the C or Fortran routine name.
 
 \begin{verbatim}
@@ -648,12 +653,12 @@ to designate coding language. The following extensions can be handled:
 \hline
 Extension & Coding Language \\
 \hline
-{\t .F} & Fortran90 fixed form \\
-{\t .f} & (no preprocessing) Fortran90 fixed form\\
-{\t .F90} & Fortran90 free form\\
-{\t .f90} & (no preprocessing) Fortran90 free form\\
-{\t .F77} & Fortran77 \\
-{\t .f77} & (no preprocessing) Fortran77\\
+{\t .F} & Fortran 90 fixed form \\
+{\t .f} & (no preprocessing) Fortran 90 fixed form\\
+{\t .F90} & Fortran 90 free form\\
+{\t .f90} & (no preprocessing) Fortran 90 free form\\
+{\t .F77} & Fortran 77 \\
+{\t .f77} & (no preprocessing) Fortran 77\\
 {\t .c} & C \\
 {\t .cc} or {\t .C} & C++ \\
 \hline
@@ -665,7 +670,7 @@ The following restrictions apply to file names:
 \item For portability across all operating systems, the base names
         for any particular extension should not depend on the operating
         system being case sensitive (e.g.\ having {\tt MyFile.c} and
-        {\tt MYFILE.f77} is alright, but {\tt MyFile.c} and {\tt MYFILE.c} could cause problems).
+        {\tt MYFILE.f77} is allright, but {\tt MyFile.c} and {\tt MYFILE.c} could cause problems).
 \item Currently all source files in different subroutines within a
 thorn must have distinct names.  We hope
 to relax this in future.  Different thorns can have files with the same names.
@@ -725,7 +730,7 @@ The makefile is passed the following variables
 
 \item [{\tt \$(THORN)}]   the thorn name
 
-\item [{\tt \$(SCRATCH\_BUILD)}]  the scratch directory where Fortran90 module
+\item [{\tt \$(SCRATCH\_BUILD)}]  the scratch directory where Fortran 90 module
 files should end up if they need to be seen by other thorns.
 
 \item [{\tt \$(NAME)}] the name of the library to be built
@@ -737,15 +742,15 @@ and has a working directory of {\tt <config>/build/<thorn\_name>} .
 \subsection{Other makefile variables}
 
 \begin{itemize}
-\item CC
-\item CXX
-\item F90
-\item F77
-\item CFLAGS
-\item CXXFLAGS
-\item F90FLAGS
-\item F77FLAGS
-\item LD
+\item {\tt CC}
+\item {\tt CXX}
+\item {\tt F90}
+\item {\tt F77}
+\item {\tt CFLAGS}
+\item {\tt CXXFLAGS}
+\item {\tt F90FLAGS}
+\item {\tt F77FLAGS}
+\item {\tt LD}
 \end{itemize}
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -754,13 +759,13 @@ and has a working directory of {\tt <config>/build/<thorn\_name>} .
 \chapter{Cactus Variables}
 \label{chap:cava}
 
-Cactus variables are sorted into {\tt groups}.  All variables in a group
+Cactus variables are sorted into \textit{groups}.  All variables in a group
 are of the same type, and have
 the same attributes, and most Cactus operations act on a group as a whole.
 
 Cactus variables are used instead of local variables for a number of reasons:
 \begin{itemize}
-\item Cactus variables can be made visable to other thorns, allowing
+\item Cactus variables can be made visible to other thorns, allowing
 thorns to communicate and share data,
 \item Cactus  variables can be distributed and communicated
         among processors, allowing parallel computation,
@@ -797,42 +802,45 @@ bytes the type takes).
 
 \begin{Lentry}
 \item[INTEGER]
-CCTK\_INT, CCTK\_INT1, CCTK\_INT2, CCTK\_INT4, CCTK\_INT8.
-(CCTK\_INT defaults to being CCTK\_INT4).
+{\tt CCTK\_INT}, {\tt CCTK\_INT1}, {\tt CCTK\_INT2}, {\tt CCTK\_INT4}, {\tt CCTK\_INT8}.
+({\tt CCTK\_INT} defaults to being {\tt CCTK\_INT4}).
 \item[REAL]
-CCTK\_REAL, CCTK\_REAL4, CCTK\_REAL8, CCTK\_REAL16.  (CCTK\_REAL defaults to being CCTK\_REAL8).
+{\tt CCTK\_REAL}, {\tt CCTK\_REAL4}, {\tt CCTK\_REAL8}, {\tt CCTK\_REAL16}.  ({\tt CCTK\_REAL} defaults to being {\tt CCTK\_REAL8}).
 \item[COMPLEX]
-CCTK\_COMPLEX, CCTK\_COMPLEX8, CCTK\_COMPLEX16, CCTK\_COMPLEX32.
-(CCTK\_COMPLEX defaults to being CCTK\_COMPLEX16).
+{\tt CCTK\_COMPLEX}, {\tt CCTK\_COMPLEX8}, {\tt CCTK\_COMPLEX16}, {\tt CCTK\_COMPLEX32}.
+({\tt CCTK\_COMPLEX} defaults to being {\tt CCTK\_COMPLEX16}).
 \item[BYTE]
 This is a 1 byte data type.
 \end{Lentry}
 
 Normally a thorn should use the default types ---
-CCTK\_INT, CCTK\_REAL, CCTK\_COMPLEX --- rather than explicitly setting the size, as this gives maximum
+{\tt CCTK\_INT}, {\tt CCTK\_REAL}, {\tt CCTK\_COMPLEX} --- rather than explicitly setting the size, as this gives maximum
 portability. Also, the defaults can be changed at configuration time (see
 \ref{Compilation-Available_Options}), and this allows people to compile the
-code with different precisions to test for round-off effects, or to run more
+code with different precisions to test for roundoff effects, or to run more
 quickly with a lower accuracy.
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 \section{Group Types}
 
-Groups can be either {\tt scalars}, {\tt grid functions (GFs)}, or {\tt grid arrays}. Different attributes are relevant for the different group types.
+Groups can be either \textit{scalars}, \textit{grid functions} (GFs), or
+\textit{grid arrays}. Different attributes are relevant for the different group
+types.
+
 
 \begin{Lentry}
-\item[SCALAR]
+\item[{\tt SCALAR}]
 This is just a single number, e.g.\ the total energy of some field.  These
 variables aren't communicated between processors --- what would be the
 result of such communication?
-\item[GF]
+\item[{\tt GF}]
 This is the most common group type.  A GF is an array with a
-specific size, set at run-time in the parameter file, which is distributed
+specific size, set at run time in the parameter file, which is distributed
 across processors.  All GFs have the same size, and the same number of
 ghostzones. Groups of GFs can also specify a dimension,
 number of timelevels, and stagger type.
-\item[ARRAY]
+\item[{\tt ARRAY}]
 This is a more general form of the GF.  Each group of arrays can have
 a distinct size and number of ghostzones, in addition to dimension,
 number of timelevels and stagger type.
@@ -891,10 +899,10 @@ loop:
 Timelevel rotation means that, for example,
 {\tt phi\_p} now holds the values of the former {\tt phi},
 and {\tt phi\_p\_p} the values of the former {\tt phi\_p}, etc.
-Note that after rotation {\tt phi} is  undefined, and it's values should
+Note that after rotation {\tt phi} is  undefined, and its values should
 not be used until they have been updated.
 
-All timelevels, except the current level, should be considered {\bf read-only} during evolution, that is their values should not be changed by thorns.
+All timelevels, except the current level, should be considered \emph{read-only} during evolution, that is their values should not be changed by thorns.
 The exception to this rule is for function initialisation, when the
 values at the previous timelevels do need to be explicitly filled out.
 
@@ -906,7 +914,7 @@ A Cactus grid function or array has a size set at runtime by parameters.
 This size can either be the global size of the array across all processors
 ({\tt DISTRIB=DEFAULT}),
 or, if {\tt DISTRIB=CONSTANT} the specified
-size on {\bf each} processor.
+size on \emph{each} processor.
 If the size is split across processors, the driver thorn is
 responsible for assigning the size on each processor.
 
@@ -914,7 +922,7 @@ responsible for assigning the size on each processor.
 
 \section{Ghost Size}
 
-Cactus is based upon a {\tt distributed computing} paradigm.  That is,
+Cactus is based upon a \textit{distributed computing} paradigm.  That is,
 the problem domain is split into blocks, each of which is assigned to
 a processor.  For hyperbolic and parabolic problems the blocks only
 need to communicate at the edges.
@@ -927,7 +935,7 @@ $x$), ($t-\Delta t$, $x$), ($t$, $x+\Delta x$) and ($t$, $x-\Delta x$)
 only.  Ignoring the points at $x$, which are obviously always
 available on a given processor, you can see that the algorithm
 requires a point on either side of the point $x$, i.e.\ this algorithm
-has {\tt stencil size} 1.  Similarly algorithms requiring two points
+has \textit{stencil size} 1.  Similarly algorithms requiring two points
 on either side have stencil size 2, etc.
 
 Now, if you evolve the above scheme, it becomes apparent that at each
@@ -946,17 +954,17 @@ At the outer boundary of the physical domain the data for the boundary
 point can be generated by the boundary conditions, however at internal
 boundaries the data has to be copied from the adjacent processor.  It
 would be inefficient to copy each point individually, so instead, a
-number of {\bf ghostzones} are created at the internal boundaries.  A
+number of \textit{ghostzones} are created at the internal boundaries.  A
 ghostzone consists of a copy of the whole plane (in 3d, line in 2d,
 point in 1d) of the data from the adjacent processor.  That is, the array
 on each processor is augmented with copies of points from the adjacent
-processors, thus allowing the algorithm to proceed {\bf on the points
+processors, thus allowing the algorithm to proceed \textit{on the points
 owned by this processor} without having to worry about copying data.
 Once the data has been evolved one step, the data in the ghostzones
-can be exchanged (or {\bf synchronised}) between processors in one
+can be exchanged (or \textit{synchronised}) between processors in one
 fell swoop before the next evolution step.  (See figure
 \ref{fig:withghost}.)  Note that you should have at least as many
-ghostzones as your stencil-size requires.
+ghostzones as your stencil size requires.
 
 \begin{figure}[ht]
 \begin{center}
@@ -970,7 +978,7 @@ ghostzones as your stencil-size requires.
 
 \section{Staggering}
 
-The staggering of a gridfunction or array describes the {\em physical}
+The staggering of a gridfunction or array describes the \emph{physical}
 placement of that gridfunction relative to the supporting grid
 structure. For example, a gridfunction does not have to
 be placed at the intersection
@@ -978,9 +986,9 @@ of the ``grid lines''. It can be moved by half a grid spacing in
 any or all dimensions. In the latter case, it will be placed in
 the center of a cell.
 
-The staggering of a grid function is a pure {\em physical} property:
+The staggering of a grid function is a pure \emph{physical} property:
 the values will be calculated at a different position in physical
-space. Still the indexing (or bookeeping)  is kept the same for all
+space. Still the indexing (or bookkeeping)  is kept the same for all
 types of staggerings: the indexing of the default unstaggered grids is
 used.
 
@@ -999,17 +1007,16 @@ stagger attribute:
 relative to  the default gridpoint.
 \item[{\tt C}] centre staggering. The physical location is offset by
 half of the grid spacing in the positive direction (or to the right).
-\item[{\tt P}] full staggered. P refers to plus. The physical location
-is offset by a full gridspacing in the positive direction (or the
-right).
+\item[{\tt P}] full staggered. {\tt P} refers to plus. The physical location
+is offset by a full gridspacing in the positive direction (or the right).
 \end{Lentry}
 For multi dimensional gridfunctions you concatenate the code
-characters in xyz order. In Figure \ref{fig:stagger1} we show four different
+characters in $xyz$ order. In Figure \ref{fig:stagger1} we show four different
 staggerings of a two dimensional grid function. The solid black grid
 circles show the default location of the grid function at the
 intersections of the grid lines. In (A) we show an additional grid
-function of type {\tt stagger=MC}: no staggering in x direction,
-center staggered in y direction. In (B) we have  {\tt stagger=CM} and
+function of type {\tt stagger=MC}: no staggering in $x$ direction,
+center staggered in $y$ direction. In (B) we have  {\tt stagger=CM} and
 staggering each direction ({\tt stagger=CC}) is shown in (C). The full
 staggering in (D) ({\tt stagger=PP}) obeys the same rules, but is
 rather unusual; it is included here for completeness.
@@ -1034,7 +1041,7 @@ provides a set of querying APIs.
 
 \subsection{Group Information}
 
-Fundamental information about grid functions (e.g.\ local grid size and location, number of ghostzones) is passed through the argument list of scheduled routines (see~\ref{sec:cava2}). To obtain similar information from non-scheduled routins, or for general grid variables, a set of functions are provided, the last two letters of which specify whether the information is requested using a group name ({\tt GN}) or index ({\tt GI}), or a variable name ({\tt VN}) or index ({\tt VI}). 
+Fundamental information about grid functions (e.g.\ local grid size and location, number of ghostzones) is passed through the argument list of scheduled routines (see~\ref{sec:cava2}). To obtain similar information from non-scheduled routines, or for general grid variables, a set of functions are provided, the last two letters of which specify whether the information is requested using a group name ({\tt GN}) or index ({\tt GI}), or a variable name ({\tt VN}) or index ({\tt VI}). 
 
 \begin{itemize}
 
@@ -1047,12 +1054,11 @@ Fundamental information about grid functions (e.g.\ local grid size and location
 \item {\tt CCTK\_Groupbbox[GN|GI|VN|VI]}      An array of  integers 
       which indicate whether the boundaries are internal boundaries
       (e.g.\ between processors), or physical boundaries. 
-        A value of 1 indicates
+        A value of {\tt 1} indicates
       a physical (outer) boundary at the edge of the computational grid,
-      and 0 indicates an internal boundary.  
+      and {\tt 0} indicates an internal boundary.  
 
-\item {\tt CCTK\_Groupnghostzones[GN|GI|VN|VI]}    
-An array of integers with
+\item {\tt CCTK\_Groupnghostzones[GN|GI|VN|VI]}    An array of integers with
          the number of ghostzones used in each direction.
 
 \item {\tt CCTK\_Grouplbnd[GN|GI|VN|VI]}       An array of integers
@@ -1075,15 +1081,15 @@ An array of integers with
 \chapter{Cactus Parameters}
 \label{chap:capa}
 
-Parameters are the means by which the user specifies the run-time behaviour of
+Parameters are the means by which the user specifies the runtime behaviour of
 the code.  The user specifies values for parameters in the parameter file, and
-then the flesh validates these values against the ranges the thorn writers have
+then the Flesh validates these values against the ranges the thorn writers have
 specified to be valid.  Once validated, parameter values are fixed, and cannot
 be changed (unless the parameter is specified to be steerable, see
 below).  For a detailed discussion of the {\tt param.ccl} syntax see
 Appendix \ref{sec:pa}.
 
-The full specification for a parameter decalaration is
+The full specification for a parameter declaration is
 \begin{verbatim}
 [EXTENDS|USES] <parameter_type>[[<size>]] <parameter name> "<parameter description>"
 {
@@ -1101,7 +1107,8 @@ Parameters can be of several types:
 \item[Integer]  Can take any integral value
 \item[Real] Can take any floating point value
 \item[Keyword] Can have a value consisting of one of a choice of strings
-\item[Boolean] Can be true or false (1, `t', `true', or 0, `f', `false').
+\item[Boolean] Can be true or false ({\t 1}, {\t t}, {\t true}, or
+{\t 0}, {\t f}, {\t false}).
 \item[String] Can have any string value
 \end{Lentry}
 
@@ -1119,15 +1126,15 @@ lower:upper:stride
 
 \end{verbatim}
 
-where {\em lower} and {\em upper} specify the lower and upper allowed
-range, and {\em stride} allows numbers to be be missed out.  e.g.\
+where \textit{lower} and \textit{upper} specify the lower and upper allowed
+range, and \textit{stride} allows numbers to be be missed out.  e.g.\
 \begin{verbatim}
 1:21:2
 \end{verbatim}
 means the value must be an odd number between one and twenty-one
 (inclusive).
 
-A missing end of range (or a `*') implies negative or positive
+A missing end of range (or a `{\t *}') indicates negative or positive
 infinity, and the default stride is one.
 
 \subsection{Real}
@@ -1136,15 +1143,15 @@ The range specification is of the form
 \begin{verbatim}
 lower:upper
 \end{verbatim}
-where {\em lower} and {\em upper} specify the lower and upper allowed
-range.  A missing end of range (or a `*') implies negative or positive
-infinity.  The above is inclusive of the end-points.  A '(' (or ')')
-before (or after) the lower (or upper) range specifies an open
-end-point.
+where \textit{lower} and \textit{upper} specify the lower and upper allowed
+range.  A missing end of range (or a `{\t *}') implies negative or positive
+infinity.  The above is inclusive of the endpoints.  A `{\tt (}'
+(or `{\tt )}') before (or after) the lower (or upper) range specifies an open
+endpoint.
 
-The numbers written in a param.ccl file are interpreted as C code.
+The numbers written in a {\tt param.ccl} file are interpreted as C code.
 To express a number in `scientific notation', use
-e.g.\ ``1e-10'', which is a double precision constant in C.  (If the
+e.g.\ `{\tt 1e-10}', which is a double precision constant in C.  (If the
 floating precision of the variable to which it is assigned is not
 double, then C will typecast appropriately.  If you \emph{really} want to
 specify a single precision floating constant, or a long double
@@ -1153,7 +1160,7 @@ constant, append the number with {\t f} or {\t l} respectively.)
 \subsection{Keyword}
 
 The range specification consists of a string, which will be matched in
-a case-insensitive manner.
+a case insensitive manner.
 
 \subsection{Boolean}
 
@@ -1169,9 +1176,9 @@ to be portable.
 
 \section{Scope}
 
-Parameters can be {\em GLOBAL}, {\em RESTRICTED}, or {\em PRIVATE}.
+Parameters can be {\tt GLOBAL}, {\tt RESTRICTED}, or {\tt PRIVATE}.
 Global parameters are visible to all thorns.  Restricted parameters
-are visible to any thorn which chooses to {\em USE} or {\em EXTEND}
+are visible to any thorn which chooses to {\tt USE} or {\tt EXTEND}
 it.  A private parameter is only visible to the thorn which declares
 it.
 
@@ -1211,11 +1218,11 @@ The full specification for a schedule declaration is
 \end{verbatim}
 
 This full schedule specification consists of a mandatory part, a set
-of options, and the main body limited by braces, referred to as the {\tt schedule
-block}.
+of options, and the main body limited by braces, referred to as the
+\textit{schedule block}.
 
-Each schedule item is scheduled either {\em AT} a particular {\em
-scheduling bin}, or {\em IN} a schedule {\em group}.
+Each schedule item is scheduled either {\tt AT} a particular
+\textit{scheduling bin}, or {\tt IN} a schedule \textit{group}.
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
@@ -1225,14 +1232,14 @@ scheduling bin}, or {\em IN} a schedule {\em group}.
 These are the main times at which scheduled functions are run, from
 fixed points in the Flesh and Driver thorn (schedule bins can easily
 be traversed from any thorn, although this is not usual).  When a
-schedule bin is {\it traversed}, all the functions scheduled in that
+schedule bin is \textit{traversed}, all the functions scheduled in that
 particular are called, in the manner described in
 \ref{scheduling:calling_scheduled_functions} and respecting the
 requested ordering of functions~\ref{scheduling:schedule_options}. In the absence of any ordering, functions in a particular schedule bin will be called in 
 an undetermined order. 
 
 The schedule bins are described in \ref{subsec:schedule_ccl}. Note that
-the preceeding {\tt CCTK\_} is optional for the use of the bin names 
+the preceding {\tt CCTK\_} is optional for the use of the bin names 
 in the {\tt schedule.ccl} file.
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -1243,14 +1250,14 @@ in the {\tt schedule.ccl} file.
 If the optional {\tt GROUP} specifier is used, the item is a schedule
 group rather than a normal function.  Schedule groups are effectively
 new, user-defined, schedule bins.  Functions or groups may be
-scheduled {\em IN} these in the same way as they are scheduled {\em
+scheduled {\tt IN} these in the same way as they are scheduled {\tt
 AT} the main schedule bins.  (That is, groups may be nested.)
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 \section{Schedule Options}
 \label{scheduling:schedule_options}
-The options define various charactertics of the schedule item.
+The options define various characteristics of the schedule item.
 
 \begin{Lentry}
 \item[{\tt BEFORE or AFTER}]
@@ -1258,14 +1265,14 @@ These specify a function or group before or after which this item will
 be scheduled.
 \item[{\tt WHILE}]
 This specifies a {\tt CCTK\_INT} grid scalar which is used to control
-the execution of this item.  If the grid scalar has a non-zero value
+the execution of this item.  If the grid scalar has a nonzero value
 the schedule item will be executed, otherwise the item will be
 ignored.  This allows some dynamic behaviour with scheduling.
 \item[{\tt AS}]
 This assigns a new name to a function for scheduling purposes.  This
 is used, for instance, to allow a thorn to schedule something before
 or after a routine from another implementation;  two thorns providing this
-implementation can schedule a routine {\em AS} the same thing, thus
+implementation can schedule a routine {\tt AS} the same thing, thus
 allowing other thorns to operate independently of which one is active.
 \end{Lentry}
 
@@ -1287,7 +1294,7 @@ which memory should be allocated for the duration of the routine or
 schedule group.  The storage status reverts to its previous status
 after completion of the routine or schedule group.
 \item[\texttt{TRIGGER}]
-This is only used for items scheduled at {\em CCTK\_ANALYSIS}.  The
+This is only used for items scheduled at timebin {\tt CCTK\_ANALYSIS}.  The
 item will only be executed if output is due for at least one
 variable in one of the listed groups.
 \item[\texttt{SYNC}]
@@ -1295,7 +1302,7 @@ On exit from this item the ghost zones of the listed groups will be
 exchanged.
 \item[\texttt{OPTIONS}]
 This is for miscellaneous options.  The only currently supported
-option is {\em GLOBAL} which tells the driver that this routine does
+option is {\tt GLOBAL} which tells the driver that this routine does
 not use a local grid, but instead uses global operations to process
 data;  such a routine should only be called once however many
 sub-grids the driver may have broken the problem into.
@@ -1306,11 +1313,11 @@ sub-grids the driver may have broken the problem into.
 \section{How Cactus Calls Scheduled Functions}
 \label{scheduling:calling_scheduled_functions}
 
-For each scheduled function called, the flesh performs a variety of jobs
+For each scheduled function called, the Flesh performs a variety of jobs
 at entry and exit.
 
 On entry to a scheduled routine, if the routine is being called at the
-ANALYSIS timebin first a check is made to see if the routine should
+{\tt CCTK\_ANALYSIS} timebin first a check is made to see if the routine should
 actually be called on this timestep. For this, all grid variables in the
 trigger groups for the routine are checked with all registered output
 methods to determine if it is time to output any triggers. The routine
@@ -1319,9 +1326,9 @@ a grid variable has been analyzed it gets marked as such and will not
 be analyzed again during this iteration. Thus if more than one analysis
 routine should be triggered on the same trigger variable(s) they must
 be scheduled in a single group.\\
-Routines from all timebins other than ANALYSIS are always called.
+Routines from all timebins other than {\tt ANALYSIS} are always called.
 
-Next storage is assigned for any required variables, remembering the
+Next, storage is assigned for any required variables, remembering the
 original state of storage.
 
 The routine is then called, and on exit, any required grid variables are
@@ -1340,22 +1347,22 @@ returned to the original state.
 
 When you start writing a new thorn, the first decision to make is
 which programming language to use? The source code in Cactus thorns
-can be written in any mixture of {\tt FORTRAN77}, {\tt FORTRAN90},
-{\tt C} or {\tt C++}. The following points should be considered when
+can be written in any mixture of Fortran 77, Fortran 90,
+C or C++. The following points should be considered when
 choosing a language to work in
 \begin{itemize}
 
 \item All functions designed for application thorn writers are available
       in all languages, however some interfaces for infrastructure
-      thorn writing are only available from {\tt C} or {\tt C++}.
+      thorn writing are only available from C or C++.
 
 % This is no longer relevant?
-%\item If you are writing in {\tt FORTRAN}, use {\tt F77} if you want
+%\item If you are writing in Fortran, use {\tt F77} if you want
 %      to distribute your code to people who may not be able to afford
-%      to buy proprietory {\tt F90} compilers.
+%      to buy proprietary Fortran 90 compilers.
 
-\item Stick to {\tt C} rather than {\tt C++}, unless you really need
-      features from {\tt C++}, this will help you with portability.
+\item Stick to C rather than C++, unless you really need
+      features from C++, this will help you with portability.
 
 \end{itemize}
 
@@ -1367,14 +1374,14 @@ use machine dependent extensions.
 
 \section{What the Flesh provides}
 
-The flesh provides for thorns:
+The Flesh provides for thorns:
 \begin{Lentry}
 \item [{\tt Variables}]
 \item [{\tt Parameters}]
 \item [{\tt Cactus Functions}]
 
 \begin{itemize}
-  \item{} driver (parallelisation) utilities
+  \item{} Driver (parallelisation) utilities
   \item{} IO utilities
   \item{} Coordinates utilities
   \item{} Reduction utilities
@@ -1391,8 +1398,8 @@ the header file {\tt cctk.h} using the line
 \begin{verbatim}
 #include "cctk.h"
 \end{verbatim}
-(Fortran programmers should not be put of by this being a C style
-header file, most Cactus files are run through a C preprocessor
+(Fortran programmers should not be put off by this being a C style
+header file --- most Cactus files are run through a C preprocessor
 before compilation).
 
 \subsubsection{Variables}
@@ -1429,11 +1436,12 @@ no grid hierarchy exists.
 \subsubsection{Parameters}
 
 All parameters defined in a thorn's {\tt param.ccl} and all {\tt global}
-parameters appear as local variables of the corresponding CCTK datatype
-in Fortran source code, ie. Booleans and Integers appear as CCTK\_INT types
-(with non-zero/zero values for boolean {\t yes/no}),
-Reals as CCTK\_REAL, and Keywords and String parameters as CCTK\_POINTER (see
-also note below). These variables are {\tt read only} and {\em changes should
+parameters appear as local variables of the corresponding {\tt CCTK} datatype
+in Fortran source code, i.e.. Booleans and Integers appear as {\tt CCTK\_INT}
+types (with nonzero/zero values for boolean {\t yes/no}),
+Reals as {\tt CCTK\_REAL}, and Keywords and String parameters as
+{\tt CCTK\_POINTER} (see
+also note below). These variables are \emph{read only} and \emph{changes should
 not be made to them}. The effect of changing a parameter is undefined (at best).
 
 Any routine using Cactus parameters should include at
@@ -1547,7 +1555,7 @@ $(SYS_OBJD)/MyRoutine.F.o:         $(SYS_OBJD)/MyModule.F.o
 
 The intrinsic function {\tt MOD} in Fortran takes two integer
 arguments, which should both be of the same type. This means
-that it may be necessary to cast the arguements to {\it e.g}
+that it may be necessary to cast the arguments to \textit{e.g.}
 {\tt INT} for some architectures. This can occur in particular
 when a {\tt CCTK\_INT} parameter and the Cactus variable {\tt cctk\_iteration}
 (which is declared to be {\tt INTEGER}) are used,
@@ -1577,7 +1585,7 @@ should include at the top of the file the header
 A Cactus macro {\tt CCTK\_ARGUMENTS} is defined for each thorn
 to contain
 \begin{itemize}
-\item General information about the grid hierachy, for example the
+\item General information about the grid hierarchy, for example the
 number of grid points on the processor. See Section \ref{sec:cava2}
 for a complete list.
 \item All the grid variables defined in the thorn's {\tt interface.ccl}
@@ -1600,11 +1608,11 @@ no grid hierarchy exists.
 \subsubsection{Parameters}
 
 All parameters defined in a thorn's {\tt param.ccl} and all {\tt global}
-parameters appear as local variables of the corresponding CCTK datatype
-in C source code, ie. Integers and Booleans appear as CCTK\_INT types (with
-non-zero/zero values for boolean {\t yes/no)}, Reals as
-CCTK\_REAL, and Keywords and String parameters as CCTK\_STRING.
-These variables are {\tt read only} and {\em changes should not be made to
+parameters appear as local variables of the corresponding {\tt CCTK} datatype
+in C source code, i.e. Integers and Booleans appear as {\tt CCTK\_INT} types
+(with nonzero/zero values for boolean {\t yes/no}), Reals as
+{\tt CCTK\_REAL}, and Keywords and String parameters as {\tt CCTK\_STRING}.
+These variables are \emph{read only} and \emph{changes should not be made to
 them}.  The effect of changing a parameter is undefined (at best).
 
 Any routine using Cactus parameters should include at
@@ -1618,7 +1626,7 @@ of the routine using them with the macro {\tt DECLARE\_CCTK\_PARAMETERS}.
 
 \subsubsection{Example}
 
-The C routine ``MyCRoutine'' is scheduled in the {\tt schedule.ccl} file,
+The C routine {\tt MyCRoutine} is scheduled in the {\tt schedule.ccl} file,
 and uses Cactus parameters. The source file should look like
 \begin{verbatim}
 #include "cctk.h"
@@ -1648,15 +1656,15 @@ functionality available in Fortran. These functions are {\tt CCTK\_Cmplx},
 
 \subsubsection{Specifically for C Programmers}
 
-Grid functions are held in memory as 1D C arrays. These are laid
+Grid functions are held in memory as 1-dimensional C arrays. These are laid
 out in memory as in Fortran. This means that the first index should
 be incremented through most rapidly.  This is illustrated in the example
 below.
 
 Cactus provides
-macros to find the 1D index which is needed from the multidimensional
+macros to find the 1-dimensional index which is needed from the multidimensional
 indices which are usually used. There is a macro for each dimension of
-grid function.  Below is an articifial example to demonstrate this
+grid function.  Below is an artificial example to demonstrate this
 using the 3D macro {\tt CCTK\_GFINDEX3D}:
 \begin{verbatim}
 for (k=0; k<cctk_lsh[2]; k++)
@@ -1682,13 +1690,13 @@ Here, {\tt CCTK\_GFINDEX3D(cctkGH,i,j,k)]} expands to
 The Cactus variables which are passed through the macro
 {\tt CCTK\_ARGUMENTS} are
 \begin{Lentry}
-\item [{\tt cctkGH}] A C pointer identifying the grid hierachy.
+\item [{\tt cctkGH}] A C pointer identifying the grid hierarchy.
 \item [{\tt cctk\_dim}] An integer with the number of dimensions
       used for this grid hierarchy.
 \item [{\tt cctk\_lsh}] An array of {\tt cctk\_dim} integers
       with the local grid size on this processor.
 \item [{\tt cctk\_gsh}] An array of {\tt cctk\_dim} integers
-      with the {\it global} grid size.
+      with the \textit{global} grid size.
 \item [\texttt{cctk\_iteration}] The current iteration number.
 \item [{\tt cctk\_delta\_time}] A {\tt CCTK\_REAL} with the timestep.
 \item [{\tt cctk\_time}] A {\tt CCTK\_REAL} with the current time.
@@ -1728,8 +1736,8 @@ the global grid.
       Fortran thorns.
 \item {\tt cctk\_bbox}
       An array of 2$*${\tt cctk\_dim} integers (in the order
-        $[{\mbox{dim}}_0^{\mbox{min}}, \mbox{dim}_0^{\mbox{max}},
-        {\mbox dim}_1^{\mbox{min}}, {\mbox dim}_1^{\mbox{max}}, \ldots]$),
+        $[\mbox{dim}_0^{\mbox{min}}, \mbox{dim}_0^{\mbox{max}},
+        \mbox{dim}_1^{\mbox{min}}, \mbox{dim}_1^{\mbox{max}}, \ldots]$),
       which indicate whether the boundaries are internal boundaries
       (e.g.\ between processors), or physical boundaries.
       A value of 1 indicates
@@ -1753,15 +1761,17 @@ The following variable is needed for grid refinement methods
         base grid.
 \end{itemize}
 
-The following variable is used for identifing convergence levels. {\tt NOTE:} Convergence is not currently implemented by Cactus, so that {\tt cctk\_convlevel} is currently always 0.
+The following variable is used for identifying convergence levels. \emph{NOTE:}
+Convergence is not currently implemented by Cactus, so that
+{\tt cctk\_convlevel} is currently always 0.
 \begin{itemize}
-\item {\tt cctk\_convlevel} The convergence level of this grid hierachy.
+\item {\tt cctk\_convlevel} The convergence level of this grid hierarchy.
         The base level is 0, and every level above that is currently coarsened         by a factor of 2.
 \end{itemize}
 
 The variables {\tt cctk\_delta\_space}, {\tt cctk\_delta\_time}, and
 {\tt cctk\_origin\_space} denote the grid spacings, time step size,
-and spatial origin on the {\em base} grid.  If you are using a grid
+and spatial origin on the \textit{base} grid.  If you are using a grid
 refinement method, you need to calculate these quantities on the grid
 you are on.  There are Cactus macros provided for this, with the
 syntax {\tt CCTK\_DELTA\_SPACE(dir)}, {\tt CCTK\_ORIGIN\_SPACE(dir)},
@@ -1827,9 +1837,9 @@ location (it's only addressed by indices) why add staggering if the
 indexing is the same?
 
 Indeed, you could roll your own, but there compelling reasons:
-Readabilty and the fact that you are able to query the staggertype of a
+Readability and the fact that you are able to query the staggertype of a
 gridfunction. More important: in the way the grid is laid out, there is one grid
-point {\em less} for {\tt M} and {\tt P} staggered grid functions. This is
+point \emph{less} for {\tt M} and {\tt P} staggered grid functions. This is
 illustrated in picture \ref{fig:stagger2}, which shows 15 gridpoints distributed
 across 3 processors. The solid black circles show the default
 location of the gridfunctions, the grey circles depict the ghostzones.
@@ -1839,13 +1849,13 @@ the last one. (The same is true for full staggered gridpoints).
 
 \subsubsection{Staggertypes}
 The string specifying the staggering is encoded in a number called
-the {\em staggerindex}. With the 3 supported staggerings, the string
-is converted into a base-3 number. Several routines exist, to extract the
-staggering in a specific direction, called {\em directional
-staggerindex}. E.g.\ {\tt stagger = MCM}: {\em staggerindex} = 3, in the
-x-direction: {\em directional staggerindex} = CCTK\_STAGGER\_M (value 0),
+the \textit{staggerindex}. With the 3 supported staggerings, the string
+is converted into a base 3 number. Several routines exist to extract the
+staggering in a specific direction, called \textit{directional
+staggerindex}. E.g.\ {\tt stagger = MCM}: \textit{staggerindex} = 3, in the
+$x$-direction: \textit{directional staggerindex} = {\tt CCTK\_STAGGER\_M} (value 0),
 in the
-y-direction: {\em directional staggerindex} = CCTK\_STAGGER\_C (value 1).
+$y$-direction: \textit{directional staggerindex} = {\tt CCTK\_STAGGER\_C} (value 1).
 
 \begin{Lentry}
 \item[{\tt CCTK\_STAGGER\_M}]  value used for M-type staggering
@@ -1886,7 +1896,7 @@ of processor local gridpoints, including ghostzones.
 \begin{itemize}
 \item{macro has to be in capital letters}
 \item{This macro is C/Fortran indexing aware:
-can specify the dimension in C ranging from $0 \ldots$ and in Fortan
+can specify the dimension in C ranging from $0 \ldots$ and in Fortran
 ranging from $1 \ldots$.}
 \end{itemize}
 \end{Lentry}
@@ -1897,60 +1907,59 @@ Several functions exist to derive the staggertype for a given group
 and for a certain direction.
 \begin{Lentry}
 \item[{\tt int CCTK\_GroupStaggerIndexGI(int group\_index)}] %returns the
-%{\em staggerindex} for a given group index.
+%\textit{staggerindex} for a given group index.
 \item[{\tt call CCTK\_GroupStaggerIndexGI(int staggerindex, int
-group\_index)}]  returns the {\em staggerindex} for a given group index.
+group\_index)}]  returns the \textit{staggerindex} for a given group index.
 \end{Lentry}
 \vskip .45cm
 
 \begin{Lentry}
 \item[{\tt int CCTK\_GroupStaggerIndexGN(char *group\_name)}] %returns the
-%{\em staggerindex} for a given group name.
+%\textit{staggerindex} for a given group name.
 \item[{\tt call CCTK\_GroupStaggerIndexGN(int staggerindex, char *group\_name)}] returns the
-{\em staggerindex} for a given group name. \vskip .25cm
+\textit{staggerindex} for a given group name. \vskip .25cm
 \end{Lentry}
 \vskip .45cm
 
 \begin{Lentry}
 \item[{\tt int CCTK\_GroupStaggerIndexVI(int variable\_index)}] %returns the
-%{\em staggerindex} for a given variable index.
+%\textit{staggerindex} for a given variable index.
 \item[{\tt call CCTK\_GroupStaggerIndexVI(int staggerindex, int variable\_index)}] returns the
-{\em staggerindex} for a given variable index.
+\textit{staggerindex} for a given variable index.
 \end{Lentry}
 \vskip .45cm
 
 \begin{Lentry}
 \item[{\tt int CCTK\_GroupStaggerIndexVN(char *variable\_name)}] %returns the
-%{\em staggerindex} for a given variable name.
+%\textit{staggerindex} for a given variable name.
 \item[{\tt call CCTK\_GroupStaggerIndexVN(int staggerindex, char *variable\_name)}] returns the
-{\em staggerindex} for a given variable name.
+\textit{staggerindex} for a given variable name.
 \end{Lentry}
 \vskip .45cm
 
 \begin{Lentry}
-\item[{\tt int CCTK\_StaggerIndex(char *stagger\_string)}] %return the {\em
+\item[{\tt int CCTK\_StaggerIndex(char *stagger\_string)}] %return the \textit{
 %staggerindex} for a given stagger string.
-\item[{\tt call CCTK\_StaggerIndex(int staggerindex, char *stagger\_string)}] return the {\em
-staggerindex} for a given stagger string.
+\item[{\tt call CCTK\_StaggerIndex(int staggerindex, char *stagger\_string)}] return the \textit{staggerindex} for a given stagger string.
 \end{Lentry}
 \vskip .45cm
 
 \begin{Lentry}
 \item[{\tt int CCTK\_DirStaggerIndex(int direction, char *stagger\_string)}]
-%returns the {\em directional staggerindex} for a given direction and
+%returns the \textit{directional staggerindex} for a given direction and
 %stagger string.
 \item[{\tt call CCTK\_DirStaggerIndex(int dir\_staggerindex, int direction, char *stagger\_string)}]
-returns the {\em directional staggerindex} for a given direction and
+returns the \textit{directional staggerindex} for a given direction and
 stagger string.
 \end{Lentry}
 \vskip .45cm
 
 \begin{Lentry}
 \item[{\tt int CCTK\_DirStaggerIndexI(int direction, char *stagger\_type)}]
-%returns the {\em directional staggerindex} for a given direction and
+%returns the \textit{directional staggerindex} for a given direction and
 %staggerindex.
 \item[{\tt call CCTK\_DirStaggerIndexI(int dir\_direction, char *stagger\_type)}]
-returns the {\em directional staggerindex} for a given direction and
+returns the \textit{directional staggerindex} for a given direction and
 staggerindex.
 
 \end{Lentry}
@@ -1960,14 +1969,14 @@ staggerindex.
 \section{Parallelisation}
 \label{seap}
 
-The flesh itself does not actually set up grid variables. This
-is done by a {\it driver} thorn. To allow the distribution of
+The Flesh itself does not actually set up grid variables. This
+is done by a \textit{driver} thorn. To allow the distribution of
 a grid over a number of processors, the driver thorn must
 also provide the grid decomposition, and routines to enable
 parallelisation. The method used to provide this parallelisation
 (e.g.\ MPI, PVM) is not usually important for the thorn writer since
 the driver thorn provides routines which are called by standard interfaces
-from the flesh. Here we describe briefly the most important of these routines
+from the Flesh. Here we describe briefly the most important of these routines
 for the application thorn writer. A more detailed description
 of these interfaces with their arguments, is given in the Reference Manual.
 A complete description of the
@@ -1997,20 +2006,20 @@ is a parallel unigrid driver.
 \section{Coordinates}
 \label{sec:co}
 
-The flesh provides utility routines for registering and querying
-coordinate information. The flesh does not provide any coordinates
+The Flesh provides utility routines for registering and querying
+coordinate information. The Flesh does not provide any coordinates
 itself, these must be supplied by a thorn. Thorns are not required to
-register coordinates to the flesh, but registering coordinates
+register coordinates to the Flesh, but registering coordinates
 provides a means for infrastructure thorns to make use of coordinate
 information.
 
-Coordinate support is still being developed in the Cactus flesh. At
+Coordinate support is still being developed in the Cactus Flesh. At
 the moment, it is assumed that coordinates will usually be grid
 functions.
 
-Coordinates are grouped into {\it coordinate systems}, which have a
+Coordinates are grouped into \textit{coordinate systems}, which have a
 specified dimension. Any number of coordinate systems can be
-registered with the flesh, and a coordinate system must be registered
+registered with the Flesh, and a coordinate system must be registered
 before any coordinates can be registered, since they must be
 associated with their corresponding system.  Coordinates can be
 registered, with any chosen name, with an existing coordinate system,
@@ -2023,7 +2032,7 @@ Following conventions for coordinate system and coordinate names
 provides a means for other thorns to use the physical properties of
 coordinate systems, without being tied to a particular thorn.
 
-A registered coordinate system can be refered to by both its name and
+A registered coordinate system can be referred to by both its name and
 an associated handle. Passing such an integer handle instead of the
 name string may be necessary for calling C routines from Fortran.
 
@@ -2050,7 +2059,7 @@ ierr = CCTK\_CoordRegisterSystem(dim,"cart3d");
 Defines a coordinate in a given coordinate system, with a given
         direction and name, and optionally associates it to a grid variable.
 The directions of the coordinates range from 1 to the dimension of the
-coordinate system. For example, to register the grid variable {\it grid::y3d}
+coordinate system. For example, to register the grid variable {\tt grid::y3d}
 to have the coordinate name {\tt y} in the {\tt cart3d} system
 
 {\tt
@@ -2062,7 +2071,7 @@ ierr = CCTK\_CoordRegisterData(dir,"grid::y3d","y","cart3d");
 \item[{\tt CCTK\_CoordRegisterRange}]
 
 Assigns the global computational maximum and minimum for a coordinate
-on a grid hierachy, that is in a {\tt cctkGH}. At this time the
+on a grid hierarchy, that is in a {\tt cctkGH}. At this time the
 maximum and minimum values have to be of type {\tt CCTK\_REAL}. For
 example, if the {\tt y} coordinate for the {\tt cart3d} system ranges
 between zero and one
@@ -2087,9 +2096,9 @@ ierr = CCTK\_CoordRegisterRange(cctkGH, lower, upper, 2, NULL, "cart3d");
 \item[{\tt CCTK\_CoordRegisterPhysIndex}]
 
 Implementing such things as symmetry properties for a grid leads to
-the need to know the details of the {\it physical} section of a grid.
+the need to know the details of the \emph{physical} section of a grid.
 Such information is typically needed by IO thorns. The following call
-illustrates how To register the
+illustrates how to register the
 indices 3 and 25 as supplying the physical range of the {\tt y}
 coordinate in the {\tt cart3d} system
 
@@ -2163,7 +2172,7 @@ const char *name = CCTK\_CoordSystemName(handle);
 
 \item[{\tt CCTK\_CoordIndex}]
 
-Provides the grid variable index for a given coordinate. Notethat it is
+Provides the grid variable index for a given coordinate. Note that it is
 not necessary for a registered coordinate to have an associated grid variable,
 and if no such grid variable is found a negative integer will be returned.
 For example, to find the grid variable index associated with the {\tt y}
@@ -2193,11 +2202,11 @@ could not be found.
 
 \item[{\tt CCTK\_CoordRange}]
 
-Provides the global range (that is, the minumum and maximum values across
-the complete grid) of a coordinate on a given grid hierachy. Currently
-the minumum and maximum values must be of type {\tt CCTK\_REAL}. The
+Provides the global range (that is, the minimum and maximum values across
+the complete grid) of a coordinate on a given grid hierarchy. Currently
+the minimum and maximum values must be of type {\tt CCTK\_REAL}. The
 coordinate can be specified either by name or by its direction. Note that
-this call returns the {\tt addresses} or the minumum and maximum values.
+this call returns the {\tt addresses} or the minimum and maximum values.
 For example, the range of the {\tt y} coordinate of the {\tt cart3d}
 coordinate system can be found using
 
@@ -2218,7 +2227,7 @@ ierr = CCTK\_CoordRange(cctkGH, \&lower, \&upper, 2, NULL, "cart3d");
 \item[{\tt CCTK\_CoordLocalRange}]
 
 Provides the local range of a coordinate on a processor for a given
-grid hierachy. WARNING: This utility only currently works for regular
+grid hierarchy. WARNING: This utility only currently works for regular
 cartesian grids. For example, the local processor range of the
 {\tt y} coordinate of the {\tt cart3d} coordinate system can be found using
 
@@ -2236,7 +2245,7 @@ ierr = CCTK\_CoordLocalRange(cctkGH, \&lower, \&upper, 2, NULL, "cart3d");
 
 \item[{\tt CCTK\_CoordRangePhysIndex}]
 
-For a given coordinate, provides the indices describing the {\it physical}
+For a given coordinate, provides the indices describing the \emph{physical}
 range of the coordinate. A negative return value signifies that no such range
 was registered for the coordinate.
 
@@ -2269,7 +2278,7 @@ should usually be the case.
 \section{IO}
 \label{sec:io}
 
-To allow flexible IO, the flesh itself does not provide any output
+To allow flexible IO, the Flesh itself does not provide any output
 routines, however it provides a mechanism for thorns to register
 different routines as IO methods (see chapter \ref{chap:io_methods}).
 Application thorns can interact with the different IO methods through
@@ -2327,13 +2336,13 @@ name of the variable for the purpose of constructing a filename.
 \section{Interpolation Operators}
 \label{sec:inop}
 
-The flesh does not provide interpolation routines by itself. Instead
+The Flesh does not provide interpolation routines by itself. Instead
 it offers a general function API to thorns for the registration and
 invocation of interpolation operators.
 
-There are several different flesh APIs for interpolation, depending
-on whether the data arrays are Cactus grid arrays or processor-local
-``ordinary programming-language'' arrays, and on what assumptions
+There are several different Flesh APIs for interpolation, depending
+on whether the data arrays are Cactus grid arrays or processor-local,
+programming language built-in arrays, and on what assumptions
 are made about the topology and spacing of the grid (these descriptions
 are for 3-D, but the generalizations to other numbers of dimensions
 should be obvious):
@@ -2354,10 +2363,10 @@ should be obvious):
 \item[{\tt CCTK\_InterpLocal()}]
         Interpolate processor-local arrays (old API, will be phased out soon)
 \item[{\tt CCTK\_InterpLocalUniform()}]
-        Interpolates processor-local arrays with {\em uniformly\/}
+        Interpolates processor-local arrays with \emph{uniformly}
         spaced data points, \ie{} where the coordinates~$xyz$
         are related to the integer array subscripts~\verb|ijk| by
-        {\em linear\/} functions
+        \emph{linear} functions
         \begin{flushleft}
         $x = \verb|origin|_x + \verb|delta|_x \verb|i|$ \\
         $y = \verb|origin|_y + \verb|delta|_y \verb|j|$ \\
@@ -2366,10 +2375,10 @@ should be obvious):
         where the caller specifies the \verb|origin| and \verb|delta|
         values.
 %notyet \item[{\tt CCTK\_InterpLocalNonUniform()}]
-%notyet         Interpolates processor-local arrays with {\em nonuniformly\/}
+%notyet         Interpolates processor-local arrays with \emph{non-uniformly}
 %notyet         spaced data points, \ie{} where the coordinates~$xyz$
 %notyet         are related to the integer array subscripts~\verb|ijk| by
-%notyet         {\em nonlinear\/} (but still single-variable) functions
+%notyet         \emph{nonlinear} (but still single-variable) functions
 %notyet         \begin{flushleft}
 %notyet         $x = x(\verb|i|)$       \\
 %notyet         $y = y(\verb|j|)$       \\
@@ -2378,10 +2387,10 @@ should be obvious):
 %notyet         where the caller specifies the functions $x$, $y$, and $z$
 %notyet         by providing 1-D arrays giving their values at the grid points.
 %notyet \item[{\tt CCTK\_InterpLocalWarped()}]
-%notyet         Interpolates processor-local arrays with {\em curvilinearly
-%notyet         warped\/} data points, \ie{} where the coordinates~$xyz$
+%notyet         Interpolates processor-local arrays with \emph{curvilinearly
+%notyet         warped} data points, \ie{} where the coordinates~$xyz$
 %notyet         are related to the integer array subscripts~\verb|ijk| by
-%notyet         generic {\em nonlinear\/} functions
+%notyet         generic \emph{nonlinear} functions
 %notyet         \begin{flushleft}
 %notyet         $x = x(\verb|i|, \verb|j|, \verb|k|)$   \\
 %notyet         $y = y(\verb|i|, \verb|j|, \verb|k|)$   \\
@@ -2391,7 +2400,7 @@ should be obvious):
 %notyet         by providing 3-D arrays giving their values at the grid points.
 \end{Lentry}
 
-There are separate flesh routines to register interpolation operators for
+There are separate Flesh routines to register interpolation operators for
 the APIs (note the calling sequences differ slightly from one registration
 routine to another!):
 \begin{Lentry}
@@ -2410,12 +2419,12 @@ routine to another!):
 \end{Lentry}
 These are described in detail in the Reference Manual.
 
-Each operator is registered under a character-string name; at
+Each operator is registered under a character string name; at
 registration the name is mapped to a unique integer handle which
 may be used to refer to the operator.  \verb|CCTK_InterpHandle()|
-is used to get the handle corresponding to a given character-string
+is used to get the handle corresponding to a given character string
 name.  In general each name/handle is actually associated with a
-{\em set\/} of interpolation operators, one for each of the
+\emph{set} of interpolation operators, one for each of the
 interpolation APIs.%%%
 \footnote{%%%
          If (as is often the case) an operator
@@ -2450,16 +2459,16 @@ truncation error.
 The exchange of
 information across processors needs the functionality of a
 communication layer e.g.\ {\tt CactusPUGH/PUGH}. For this reason, the
-reduction operation itself is not part of the flesh, instead Cactus (again)
+reduction operation itself is not part of the Flesh, instead Cactus (again)
 provides a registration mechanism for thorns to register routines they
 provide as reduction operators. The different operators are
-identified by their name and/or a unique number, called a {\em handle}.
+identified by their name and/or a unique number, called a \textit{handle}.
 The registration mechanism gives the advantage of a common
 interface while hiding the individual communication calls in the
 layer.
 
 In Cactus, reduction operators can in principle be applied to
-grid functions, arrays, and scalars, as well as to local (non CCTK-) arrays. Note that
+grid functions, arrays, and scalars, as well as to local (non-CCTK) arrays. Note that
 different implementations of reduction operators may be limited in
 the types of objects to which they can be applied.
 There is a fundamental difference between a reduction operation on
@@ -2476,7 +2485,7 @@ Reference Manual.
 {\bf Obtaining the reduction handle}
 
 Before calling the routine which performs the reduction operation,
-the handle, which indentifies the operation, must be derived from its
+the handle, which identifies the operation, must be derived from its
 registered name.  To obtain a handle for the reduction of a CCTK variable, use
 %
 \begin{verbatim}
@@ -2487,7 +2496,7 @@ integer       reduction_handle
 character*(*) reduction_name
 \end{verbatim}
 %
-(for C or Fortran respectively), while for a local, non-CCTK-array, use
+(for C or Fortran respectively), while for a local, non-CCTK array, use
 %
 \begin{verbatim}
 int CCTK_ReductionArrayHandle(const char *reduction_name);
@@ -2513,7 +2522,7 @@ Computational Toolkit release which provides reduction operators is
 (Note that although it would appear to be far more convenient to
 pass the name of the reduction operator directly to the following
 function call to {\t CCTK\_Reduce} this causes problems with the
-translation of strings from {\t FORTRAN} to {\t C} with variable
+translation of strings from Fortran to C with variable
 argument lists).
 
 
@@ -2577,9 +2586,9 @@ call CCTK_ReduceArray( integer returnvalue,
 \begin{Lentry}
 \item[{\tt returnvalue}] the return value of the operation.  A
 negative value indicates a failure to perform the reduction.  A zero
-indicates successfull operation.
+indicates successful operation.
 
-\item[{\tt GH} or {\tt cctkGH}] the pointer to the grid hierachy
+\item[{\tt GH} or {\tt cctkGH}] the pointer to the grid hierarchy
 structure.
 
 \item[{\tt processor}] the processor which collects the
@@ -2598,7 +2607,7 @@ number, this would be one.
 \item[{\tt type\_out\_arrays}, {\tt type\_in\_arrays}]
 specifies the type of the data
 you are communicating.  Use the values as specified in
-\ref{sec:datyansi}. Note: Do not {\em mix} datatypes.  For example, in
+\ref{sec:datyansi}. Note: Do not \emph{mix} datatypes.  For example, in
 Fortran do not declare a variable as {\tt integer} and then specify
 the type {\tt CCTK\_VARIABLE\_INT} in the reduction command. These
 types may not be the same on some architectures and will conflict.
@@ -2606,19 +2615,19 @@ types may not be the same on some architectures and will conflict.
 \item[{\tt out\_vals}] a pointer to the buffer which will hold the
 output values. Note that the input and output buffer must be distinct.
 
-\item[{\tt num\_dims}] (CCTK\_ReduceArray only) the number of dimensions of the input and output arrays.
+\item[{\tt num\_dims}] ({\tt CCTK\_ReduceArray} only) the number of dimensions of the input and output arrays.
 
-\item[{\tt num\_in\_fields}] (CCTK\_Reduce only) specifies the number of input CCTK
+\item[{\tt num\_in\_fields}] ({\tt CCTK\_Reduce} only) specifies the number of input CCTK
 variables which will be specified in the variable argument list $<$...$>$.
 
-\item[{\tt num\_in\_arrays}] (CCTK\_ReduceArray only) specifies the
-number of imput \emph{arrays} (not the number of input \emph{fields},
+\item[{\tt num\_in\_arrays}] ({\tt CCTK\_ReduceArray} only) specifies the
+number of input \textit{arrays} (not the number of input \textit{fields},
 which would be $\mathrm{num\_in\_arrays}*(\mathrm{num\_dims}+1)$, see below) which
 will be specified in the variable argument list $<$...$>$.
 
-\item[{\tt ...}] indicates a varible argument list:\\
+\item[{\tt ...}] indicates a variable argument list:\\
 %
-\textbf{for CCTK\_Reduce:} Specify a list of CCTK variable indicies,
+\textbf{for CCTK\_Reduce:} Specify a list of CCTK variable indices,
 one for each variable that is to be reduced.  The number of specified
 variables must be the same as the value of the {\tt num\_in\_fields}
 variable.\\
@@ -2666,8 +2675,8 @@ call CCTK_ReduceLocScalar(integer returnvalue,
 \begin{Lentry}
 \item[{\tt returnvalue}] the return value of the operation.  A
 negative value indicates a failure to perform the reduction.  A zero
-indicates successfull operation.
-\item[{\tt GH} or {\tt cctkGH}] the pointer to the grid hierachy
+indicates successful operation.
+\item[{\tt GH} or {\tt cctkGH}] the pointer to the grid hierarchy
 structure.
 \item[{\tt processor}] the processor which collects the
 information; a negative value will distribute the data to all
@@ -2716,8 +2725,8 @@ call CCTK_ReduceLocArrayToArray1D( integer returnvalue
 \begin{Lentry}
 \item[{\tt returnvalue}] the return value of the operation.  A
 negative value indicates a failure to perform the reduction.  A zero
-indicates successfull operation.
-\item[{\tt GH} or {\tt cctkGH}] the pointer to the grid hierachy
+indicates successful operation.
+\item[{\tt GH} or {\tt cctkGH}] the pointer to the grid hierarchy
 structure.
 \item[{\tt processor}] the processor which collects the
 information; a negative value will distribute the data to all
@@ -2766,8 +2775,8 @@ call CCTK_ReduceLocArrayToArray2D( integer returnvalue
 \begin{Lentry}
 \item[{\tt returnvalue}] the return value of the operation.  A
 negative value indicates a failure to perform the reduction.  A zero
-indicates successfull operation.
-\item[{\tt GH} or {\tt cctkGH}] the pointer to the grid hierachy
+indicates successful operation.
+\item[{\tt GH} or {\tt cctkGH}] the pointer to the grid hierarchy
 structure.
 \item[{\tt processor}] the processor which collects the
 information; a negative value will distribute the data to all
@@ -2780,8 +2789,8 @@ processors.
 processors, element by element.
 \item[{\tt out\_array2d}] two dimensional array to hold the reduction
 result. out\_array2d[i,j]= Reduction(in\_array2d[i,j]).
-\item[{\tt xsize}] the size of the two dimensional array in x direction.
-\item[{\tt ysize}] the size of the two dimensional array in y
+\item[{\tt xsize}] the size of the two dimensional array in $x$ direction.
+\item[{\tt ysize}] the size of the two dimensional array in $y$
 direction. Note that the input and output array must be distinct.
 
 \item[{\tt data\_type}] specifies the type of the gridfunction you are
@@ -2819,8 +2828,8 @@ call CCTK_ReduceLocArrayToArray3D(integer returnvalue
 \begin{Lentry}
 \item[{\tt returnvalue}] the return value of the operation.  A
 negative value indicates a failure to perform the reduction.  A zero
-indicates successfull operation.
-\item[{\tt GH} or {\tt cctkGH}] the pointer to the grid hierachy
+indicates successful operation.
+\item[{\tt GH} or {\tt cctkGH}] the pointer to the grid hierarchy
 structure.
 \item[{\tt processor}] the processor which collects the
 information; a negative value will distribute the data to all
@@ -2833,9 +2842,9 @@ processors.
 processors, element by element.
 \item[{\tt out\_array3d}] three dimensional array holding the reduction
 result. out\_array3d[i,j,k]= Reduction(in\_array3d[i,j,k]).
-\item[{\tt xsize}] the size of the three dimensional array in x direction.
-\item[{\tt ysize}] the size of the three dimensional array in y direction.
-\item[{\tt ysize}] the size of the three dimensional array in z
+\item[{\tt xsize}] the size of the three dimensional array in $x$ direction.
+\item[{\tt ysize}] the size of the three dimensional array in $y$ direction.
+\item[{\tt zsize}] the size of the three dimensional array in $z$
 direction. Note that the input and output array must be distinct.
 
 \item[{\tt data\_type}] specifies the type of the gridfunction you are
@@ -2845,7 +2854,7 @@ communicating. Use the values as specified in \ref{sec:datyansi}.
 \vskip .24cm
 {\bf Some brief examples:}
 
-{\bf Reduction of a scalar:}  A local error is reduced across all
+\textit{Reduction of a scalar:}  A local error is reduced across all
 processors with the maximum operation. The variable {\tt tmp} will
 hold the maximum of the error and  is the same on all
 processors. This quantity can then be reassigned to {\tt normerr}.
@@ -2869,9 +2878,9 @@ processors. This quantity can then be reassigned to {\tt normerr}.
 \end{verbatim}
 
 
-{\bf Reduction of a 2d array:}  A two dimensional $(2x3)$ array is
+\textit{Reduction of a 2d array:}  A two dimensional $(2\times3)$ array is
 reduced; the reduction result (array of same size: {\tt bla\_tmp}) is seen
-on all processors ($-1$ entry as the thid argument).  This example also demonstrates
+on all processors ($-1$ entry as the third argument).  This example also demonstrates
 some simple error checking with the {\tt CCTKi\_EXPECTOK} macro.
 \begin{verbatim}
       CCTK_REAL bla(2,3),bla_tmp(2,3);
@@ -2903,7 +2912,8 @@ the reduction call is made.
 
 Note that since most source files (see Section~\ref{nacofosofi} for
 exceptions) pass through a C preprocessor, C style comments can be
-used in Fortran code. (Note that C++ comments (that is //),
+used in Fortran code. (Note that C++ comments (that is ones starting
+with ``{\tt //}''),
 should only be used in C++ source code).
 
 The Flesh and the Cactus thorns use the {\tt grdoc} Code Documenting
@@ -2915,7 +2925,7 @@ source code.
 \section{Providing Runtime Information}
 \label{sec:prrutiin}
 
-To write from thorns to standard output ({\it i.e.} the screen)
+To write from thorns to standard output (\textit{i.e.} the screen)
 at runtime, use the macro {\tt CCTK\_INFO} or the function {\tt CCTK\_VInfo()}.
 
 For example, from the Fortran thorn {\tt MyThorn},
@@ -3011,10 +3021,10 @@ and from C
 Note that {\tt CCTK\_WARN} is just a macro which expands to a call to the
 internal function {\tt CCTK\_Warn()}. The macro automatically includes the name
 of the thorn, the source file name and line number of the warning in the
-funtion call. (For this reason it is important for Fortran code that capital
+function call. (For this reason it is important for Fortran code that capital
 letters are always used in order to expand the macro).
 
-If the flesh parameter {\tt cctk\_full\_warnings} is set to true, then the
+If the Flesh parameter {\tt cctk\_full\_warnings} is set to true, then the
 source file name and line number will be printed to standard error along with
 the originating processor number, the thorn name and the warning message.
 The default is to omit the source file name and line number.
@@ -3054,7 +3064,7 @@ In Fortran 90, you can also do:
   call CCTK_WARN (1, trim(message))
 \end{verbatim}
 
-The flesh will be implementing standard error return codes
+The Flesh will be implementing standard error return codes
 which can be used by the thorns, although this is not
 yet ready. In general, thorns should attempt to handle errors
 without terminating, and warning messages should be liberally
@@ -3065,7 +3075,7 @@ used.
 \section{Adding documentation}
 \label{sec:addo}
 
-Documentation is a vital part of your thorn, helping to ensure it's
+Documentation is a vital part of your thorn, helping to ensure its
 ease of use and longevity, not only for others but also for the thorn
 authors.  Although any kind of independent documentation can be added
 to a thorn (ideally in the {\tt doc} directory), there are two
@@ -3078,14 +3088,14 @@ The {\tt README}, in the top level of a thorn, should contain brief
 and essential details about the thorn, such as the authors, any
 copyright details, and a synopsis of what the thorn does.
 
-\subsection{Contribution to ThornGuide}
+\subsection{Contribution to Thorn Guide}
 
-The latex file {\tt doc/documentation.tex} is included in Thorn Guides
+The LaTeX file {\tt doc/documentation.tex} is included in Thorn Guides
 built by the Cactus make system. (e.g.\ by {\tt gmake
 $<$config$>$-ThornGuide}). Ideally this file should contain complete
-(and {\it up-to-date}) details about the thorn, exactly what is
-relevent is for the authors to decide, but remember that the Cactus
-make system automically parses the thorn {\tt CCL} files to include
+(and \textit{up-to-date}) details about the thorn, exactly what is
+relevant is for the authors to decide, but remember that the Cactus
+make system automatically parses the thorn CCL files to include
 information about all parameters, variables and scheduling. Suggested
 sections include:
 
@@ -3103,7 +3113,7 @@ sections include:
 
   \item{\bf history} Here is where you should describe why the thorn
     was written, any previous software or experience which was made use of,
-    the authors of the thorn sourcecode and documentation, how to get
+    the authors of the thorn source code and documentation, how to get
     hold of the thorn etc.
 
   \item{\bf references} A bibliography can be included, referencing papers
@@ -3112,17 +3122,16 @@ sections include:
 
 \end{itemize}
 
-A latex template for the Thorn Guide documentation can be found in the
+A LaTeX template for the Thorn Guide documentation can be found in the
 Flesh distribution at
 
 {\tt doc/ThornGuide/template.tex},
 
-this file is
-automatically copied to the correct location in a new thorn which is
-created with {\tt gmake newthorn}.
+this file is automatically copied to the correct location in a new thorn
+which is created with {\tt gmake newthorn}.
 
 Since Cactus scripts need to parse this documentation, and since the
-latex document should be consistent across all thorns included in a
+LaTeX document should be consistent across all thorns included in a
 Thorn Guide, please follow the guidelines below when filling in the
 documentation:
 
@@ -3152,12 +3161,12 @@ and
 
  \item The command {\tt $\backslash$def} can be used to define macros, but all
    such definitions must lie between the {\tt START} and {\tt END}
-   line. Do not redefine any standard latex command
+   line. Do not redefine any standard LaTeX command
 
  \item Do not use the {\t $\backslash$appendix} command, instead include any appendices
         you have as standard sections.
 
- \item Currently we only support postscript ({\tt .eps or .ps}) figures.
+ \item Currently we only support PostScript ({\tt .eps or .ps}) figures.
    Graphics figures should be included using the {\tt includegraphics}
    command (not {\tt epsffig}), with no file extension specified. For example,
 
@@ -3180,7 +3189,7 @@ and
    blackhole.eps, you should rename your image to be {\tt
      CactusWave\_WaveToyC\_blackhole.eps}
 
- \item References should be formatted with the standard latex {\bf
+ \item References should be formatted with the standard LaTeX {\bf
         bibitem} command, for example, a bibliography section should
         look like:
 
@@ -3188,7 +3197,7 @@ and
 \begin{verbatim}
 \begin{thebibliography}{9}
   \bibitem{MyArrangement_MyThorn_Author99}
-  {J. Author, {\em The Title of the Book, Journal, or periodical}, 1 (1999),
+  {J. Author, \textit{The Title of the Book, Journal, or periodical}, 1 (1999),
   1--16. \url{http://www.nowhere.com/}}
 \end{thebibliography}
 \end{verbatim}
@@ -3203,7 +3212,7 @@ and
 
 To add a test suite to your thorn, devise a series of parameter
 files which use as many aspects of your thorn as possible.
-Make sure that the parameter files produce ascii output to files,
+Make sure that the parameter files produce ASCII output to files,
 and that these files are in the directory
 {\tt ./<parameter file base name>}.
 
@@ -3244,10 +3253,10 @@ You can add any number of timers to your thorn source code, providing
 each with a chosen name, for example {\tt TimeMyRoutine}, {\tt TimeNextCalculation}, and then use Cactus functions to switch on the
 timers, stop or reset them, and recover timing information.
 
-Note that we use the word {\it Clock} to describe the timing instrument
+Note that we use the word \textit{clock} to describe the timing instrument
 itself, for example the hardware counters on a machine, and the word
-{\it Timer} to describe the calls in your code which collect results
-from the different {\it Clocks}.
+\textit{timer} to describe the calls in your code which collect results
+from the different clocks.
 
 \subsection{Timing calls}
 
@@ -3283,7 +3292,7 @@ Access the actual timing results, which are passed back as a
 structure, {\t cTimerData} described below, in {\t CCTK\_Timer}.
 Since the timing data is dynamic, before it can be assessed, the structure
 must be allocated with a call to {\t CCTK\_TimerCreateData}. A similar function
-is provided to destroy the stucture
+is provided to destroy the structure
 
 \item[{\t CCTK\_NumTimers}]
 
@@ -3418,7 +3427,7 @@ ierr = CCTK_TimerDestroyData(info);
 Cactus provides a mechanism for thorns to add code to
 include files which can be used by any other thorn.
 Such include files can contain executable source code, or header/declaration
-information. A difference is made between these two cases, since included
+information. A distinction is made between these two cases, since included
 executable code is protected from being run if a thorn is compiled but
 not active by being wrapped by a call to {\tt CCTK\_IsThornActive}.
 
@@ -3502,13 +3511,13 @@ available in C only.
 \label{sec:acmetr}
 
 Memory tracing has to be activated at configure time. The standard
-malloc statements are overriden with macros ({\tt CCTK\_MALLOC}).  To
+{\tt malloc} statements are overridden with macros ({\tt CCTK\_MALLOC}).  To
 activate memory tracing use either
 
 \begin{Lentry}
 \item[{\tt DEBUG=all}]  Enables all debug options (compiler debug
-flags, redefines malloc)
-\item[{\tt DEBUG=memory}] Redefine malloc only.
+flags, redefines {\tt malloc})
+\item[{\tt DEBUG=memory}] Redefine {\tt malloc} only.
 \end{Lentry}
 
 The {\tt CCTK\_MALLOC} statements can also be used directly in the C
@@ -3536,7 +3545,7 @@ allocation some time later.
         Request a ticket: save the current total memory to a database.
         Return an integer (ticket). Use the ticket to calculate the
         difference in memory allocation between the two instances in
-        CCTK\_MemTicketCash.    
+        {\tt CCTK\_MemTicketCash}.    
 
 \item[{\tt long int CCTK\_MemTicketCash(int your\_ticket)}]
         Cash in your ticket: return the memory difference between now and the
@@ -3548,7 +3557,7 @@ allocation some time later.
         allocated either if you compile undebugged.
 
 \item[{\tt int CCTK\_MemTicketDelete(int your\_ticket)}]
-        Delete the memory ticket. The ticket-id will not be reused, since
+        Delete the memory ticket. The ticket ID will not be reused, since
         it's incremented with every ticket request, but the memory of
         the memory datastructure is deallocated.
 
@@ -3561,8 +3570,8 @@ allocation some time later.
         successive calls to this routine, as well as the difference.
 \end{Lentry}
 
-Sample C Code demonstrating the ticket handling. Two tickets are
-requested during malloc operations. The {\tt CCTK\_MALLOC} statement is
+Sample C code demonstrating the ticket handling. Two tickets are
+requested during {\tt malloc} operations. The {\tt CCTK\_MALLOC} statement is
 used directly. They are cashed in and the memory
 difference is printed. Ticket 1 is cashed twice. The tickets are
 deleted at the end.
@@ -3601,7 +3610,7 @@ CCTK_MemTicketDelete(t2);
 \section[Calls to different language]{Calls between different programming languages}
 %\pagestyle{empty}
 
-\subsection{Calling C routines from FORTRAN}
+\subsection{Calling C routines from Fortran}
 \label{sec:cacrofr}
 
 To make the following C routine,
@@ -3622,7 +3631,7 @@ void CCTK\_FCALL CCTK\_FNAME(<routine name>)(int *ierr, <argument list>)\\
 }
 
 The convention used in Cactus is that {\tt <routine name>} be the same as any
-C-callable routine name, and that this is mixed-case.  The macros change
+C routine name, and that this is mixed-case.  The macros change
 the case and number of underscores of the routine name to match that expected
 by Fortran.
 
@@ -3658,7 +3667,7 @@ translation to C strings.
 The macros are defined in {\tt cctk\_FortranString.h} which
 should be included in your C file.
 
-String arguments {\em must always come last} in the argument list for
+String arguments \emph{must always come last} in the argument list for
 these macros to be effective (some Fortran compilers automatically
 migrate the strings to the end so there is no portable workaround).
 
@@ -3689,7 +3698,7 @@ In more detail:
 
 \item[{\tt <ONE|TWO|THREE>\_FORTSTRING\_PTR}]
         These macros, used in the declaration section of the C routine
-        {\em after} the {\tt CREATE} macro,
+        \emph{after} the {\tt CREATE} macro,
         should be used if you need to modify one of the passed-in strings.
         They declare and define pointers to the passed-in strings.
         
@@ -3736,7 +3745,7 @@ from Fortran, they should be treated as read-only.
 To change the data in a string passed from Fortran, you need to use
 the {\tt FORTSTRING\_PTR} macros, which declare and set up pointers
 to the strings passed from C. Note that this macro must be used
-{\em after} the {\tt FORTSTRING\_CREATE} macro. For example, the
+\emph{after} the {\tt FORTSTRING\_CREATE} macro. For example, the
 following routine copies the contents of the second string to the
 first string.
 
@@ -3770,13 +3779,13 @@ int CCTK_FCALL CCTK_FNAME(CopyStrings)(TWO_FORTSTRING_ARG)
 \end{verbatim}
 
 Note that in the example above two new variables, pointers to the
-Fortran strings, were created.  These are just pointers and {\em
-should not be freed}.  The example also illustrates the
+Fortran strings, were created.  These are just pointers and
+\emph{should not be freed}.  The example also illustrates the
 automatically-created variables (e.g.\ {\tt cctk\_strlen1}
 which hold the sizes of original Fortran strings.
 When writing to a string its length should never be exceeded.
 
-\subsection{Calling FORTRAN routines from C}
+\subsection{Calling Fortran routines from C}
 \label{sec:caforofr}
 
 To call a utility Fortran routine from C use
@@ -3798,7 +3807,7 @@ strings from C.
 As well as calling functions in a different language, Cactus offers a
 mechanism for calling a function in a different thorn where you need
 not know which thorn is actually providing the function, nor what
-language the function is provided in. The idea of {\it function
+language the function is provided in. The idea of \textit{function
 aliasing} is similar to that of thorns; the routine that calls a
 function should not need to know anything about it except that the
 function exists.
@@ -3949,10 +3958,12 @@ function reference section.
 
 \item{} Thorn names must not start with the word ``Cactus'' (in
         any case).
-\item{} Arrangements will be ignored if their names start with \# or .
-        or end in \~{} .bak or .BAK.
-\item{} Thorns will be ignored if they are called doc or start with
-        \# or . or end in \~{} .bak or .BAK.
+\item{} Arrangements will be ignored if their names start with a
+        hash mark `{\tt \#}' or dot `{\tt .}'
+        or end in a tilde `{\tt \~{}}', {\tt .bak} or {\tt .BAK}.
+\item{} Thorns will be ignored if they are called doc or start with a
+        hash mark `{\tt \#}' or dot `{\tt .}'
+        or end in a tilde `{\tt \~{}}', {\tt .bak} or {\tt .BAK}.
 \item{} Routine names have to be unique among all thorns.
 
 \end{itemize}
@@ -3961,7 +3972,7 @@ function reference section.
 
 \section{General Naming Conventions}
 
-The following naming conventions are followed by the flesh and the
+The following naming conventions are followed by the Flesh and the
 supported Cactus arrangements. They are not compulsory, but if followed
 allow for a homogeneous code.
 
@@ -4082,7 +4093,7 @@ For example, the variable {\tt cctkGH} is of this type.
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
-\chapter{Telling the makesystem what to do}
+\chapter{Telling the make system what to do}
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%