Parameter names changes as announced in today's mail to users@cactuscode.org.

You must update all other I/O thorns now.


git-svn-id: http://svn.cactuscode.org/arrangements/CactusBase/IOUtil/trunk@163 b32723a9-ab3a-4a60-88e2-2e5d99d7c17a

1 files changed, 134 insertions, 128 deletions

diff --git a/doc/documentation.tex b/doc/documentation.tex
index c7d6c8a..d3c9b4c 100644
--- a/doc/documentation.tex
+++ b/doc/documentation.tex
@@ -18,11 +18,11 @@ Input and output of data (I/O) in Cactus is provided by infrastructure thorns,
 which interact with the flesh via a fixed interface, which is described in the
 Users' Guide. The standard release of Cactus contains a number of thorns which
 provide so-called I/O methods implementing the actual I/O in a variety of data
-formats and styles. All these provided I/O methods use thorn {\tt
-CactusBase/IOUtil} which provides general utilities for I/O (such as parsing
+formats and styles. All these provided I/O methods use thorn {\bf IOUtil} which
+provides general utilities for I/O (such as parsing
 parameter strings to decide which variables to output), and a general set of
 parameters which are inherited by the different I/O methods (such as the output
-directory). Thorn {\tt IOUtil} by itself provides no I/O methods.
+directory). Thorn {\bf IOUtil} by itself provides no I/O methods.
 
 More information about I/O and visualisation of Cactus data can be found in the
 individual I/O thorns, and in the {\tt Visualization-HOWTO} available on the
@@ -62,12 +62,17 @@ registered names are the labels we now use to describe the various methods.
   {\tt CactusBase/IOASCII}
 \\
   {\tt IOASCII\_3D} &
-  full 3D output of grid arrays in gnuplot format &
+  full output of 3D grid arrays in gnuplot format &
   {\tt CactusBase/IOASCII}
 \\
 &&\\
-  {\tt IOHDF5\_3D} &
-  full 3D output of grid arrays in HDF5 format &
+  {\tt IOJpeg} &
+  2D slice output of grid arrays in jpeg image format &
+  {\tt CactusIO/IOJpeg}
+\\
+&&\\
+  {\tt IOHDF5} &
+  full output of arbitrary grid variables in HDF5 format &
   {\tt CactusPUGHIO/IOHDF5}
 \\
 &&\\
@@ -75,8 +80,8 @@ registered names are the labels we now use to describe the various methods.
   2D slice output of grid arrays in FlexIO format &
   {\tt CactusPUGHIO/IOFlexIO}
 \\
-  {\tt IOFlexIO\_3D} &
-  full 3D output of grid arrays in FlexIO format &
+  {\tt IOFlexIO} &
+  full output of arbitrary grid variables in FlexIO format &
   {\tt CactusPUGHIO/IOFlexIO}
 \\
   \hline
@@ -88,9 +93,9 @@ registered names are the labels we now use to describe the various methods.
 
 The standard provided Cactus I/O methods are shown in Table~\ref{one}.
 As described above, each of these I/O thorns inherit parameters from thorn
-{\tt CactusBase/IOUtil}, which must be included in your ThornList
+{\bf IOUtil}, which must be included in your ThornList
 and activated in your parameter files before any of these I/O methods
-can be used. {\tt CactusBase/IOUtil} allows you to set the default
+can be used. {\bf IOUtil} allows you to set the default
 behaviour for all the I/O methods described above, for example, setting
 the parameter {\tt IO::out\_every = 1} will result in any chosen I/O method
 providing output on each iteration. The default behaviour can be overriden
@@ -100,7 +105,7 @@ but computationally expensive 3D output only every 10th iteration,
 with these files going into another directory on a scratch partition.
 
 
-\section{Providing Your own I/O Method}
+\section{Providing Your Own I/O Method}
 
 If you as a Cactus developer have your own input/output routines and want to
 share this functionality with other people you should do this by putting them
@@ -109,7 +114,7 @@ A description on how to register a new I/O method with the flesh's I/O subsystem
 can be found in the {\it Infrastructure Thorn Writer's Guide} (as part of the
 {\it Cactus User's Guide}).
 
-New I/O thorns should always inherit from thorn {\tt CactusBase/IOUtil} in order
+New I/O thorns should always inherit from thorn {\bf IOUtil} in order
 to reuse as much of the existing I/O infrastructure as possible, and to maintain
 a uniform interface on how to use the I/O methods.
 
@@ -134,11 +139,11 @@ a uniform interface on how to use the I/O methods.
 
 \section{Standard Parameters}
 
-Here we describe a few of the standard parameters used by {\tt IOUtil} to
+Here we describe a few of the standard parameters used by {\bf IOUtil} to
 control output.
 \begin{itemize}
 
-  \item{\tt IO::outdir}\\
+  \item{\tt IO::out\_dir}\\
     The name of the directory to be used for output. All the I/O methods
     described here will write by default to this directory (which itself
     defaults to the current working directory). Individual methods have
@@ -153,7 +158,7 @@ control output.
 
 \section{Saving/Generating Parameter Files}
 
-Thorn {\tt IOUtil} can save a copy of the parameter file of a run, or can also
+Thorn {\bf IOUtil} can save a copy of the parameter file of a run, or can also
 automatically generate a parameter file from all current parameter settings.
 This is controlled by the {\tt IO::parfile\_write} parameter:
 
@@ -186,43 +191,43 @@ with the chosen name it will not be overwritten.
 \label{iomodes}
 For a run on multiple processors, scalar, 1D, and 2D output will always be
 written from only processor zero (that is, required data from all other
-processors will be sent to processor zero, who then outputs all the gathered
-data). For 3D output this may become a quite expensive operation since output
-by only a single processor will probably result in an I/O bottleneck and delay
-further computation. For this reason Cactus offers different I/O modes for 3D
-output which can be controlled by the {\tt IO::out\_3Dmode} parameter, in
-combination with {\tt IO::out\_unchunked} and {\tt IO::out3D\_np}. These
-parameters allow I/O to be optimised for your particular machine architecture
-and needs:
+processors will be sent to processor zero, which then outputs all the gathered
+data). For full-dimensional output of grid arrays this may become a quite expensive
+operation since output by only a single processor will probably result in an
+I/O bottleneck and delay further computation. For this reason Cactus offers
+different I/O modes for such output which can be controlled by the
+{\tt IO::out\_mode} parameter, in combination with {\tt IO::out\_unchunked}
+and {\tt IO::out\_proc\_every}. These parameters allow I/O to be optimised for
+your particular machine architecture and needs:
 
 \begin{itemize}
-  \item {\tt IO::out3D\_mode = "onefile"}\\
+  \item {\tt IO::out\_mode = "onefile"}\\
     As for the 1D and 2D I/O methods, writing to file is performed only
     by processor zero.
     This processor gathers all the output data from the other processors
     and then writes to a single file. The gathered grid array data from each
-    processor can be either written in chunks ({\tt IO::out3D\_unchunked =
+    processor can be either written in chunks ({\tt IO::out\_unchunked =
     "no"}) with each chunk containing the data from a single processor, or
     collected into a single global array before writing ({\tt
-    IO::out3D\_unchunked = "yes"}). The default is to write the data in chunks.
+    IO::out\_unchunked = "yes"}). The default is to write the data in chunks.
 
-  \item {\tt IO::out3D\_mode = "np"}\\
-    3D output is written in parallel for groups of processors. Each group
-    consists of {\tt IO::out3D\_procs} processors which have assigned one I/O
+  \item {\tt IO::out\_mode = "np"}\\
+    Output is written in parallel for groups of processors. Each group
+    consists of {\tt IO::out\_proc\_every} processors which have assigned one I/O
     processor which gathers data from the group and writes it to file. The
-    chunked output will go into {\tt IO::out3D\_procs} files.
+    chunked output will go into {\tt IO::out\_proc\_every} files.
     The default number of processors in a group is eight.
 
-  \item {\tt IO::out3D\_mode = "proc"}\\
-    This is the default method for 3D output.
+  \item {\tt IO::out\_mode = "proc"}\\
+    This is the default output mode.
     Every processor writes its own chunk of data into a separate output file.
 \end{itemize}
 
-Probably the single processor {\tt "proc"} mode is the most efficient 3D output
+Probably the single-processor {\tt "proc"} mode is the most efficient output
 mode on machines with a fast I/O subsystem and many I/O nodes (eg. a Linux
 cluster with local disks attached to each node) because it provides the highest
 parallelity for outputting data. Note that on very large numbers of processors
-you mave have to fall back to {\tt "np"}, output from groups of processors,
+you mave have to fall back to {\tt "np"}, doing output by every so many processors,
 mode if the system limit of maximum open file descriptors is exceeded (this is
 true for large jobs on a T3E).
 
@@ -236,7 +241,7 @@ provided by the thorns offering parallel I/O methods.
 
 \section{Output of Hyperslab Data}
 
-While some I/O methods ({\tt IOHDF5\_3D, IOFlexIO\_3D}) can dump the full
+While some I/O methods ({\tt IOHDF5, IOFlexIO}) can dump the full
 contents of a multidimensional CCTK variable, others such as {\tt IOASCII\_1D}
 and {\tt IOASCII\_2D} will output only a subset of the data (eg. 1D lines or 2D
 planes of 3D grid functions).
@@ -244,10 +249,10 @@ Such a subset (called a {\it hyperslab}) is generally defined as an orthogonal
 region into the multidimensional dataset, with a startpoint and a length in any
 direction, and an optional downsampling factor.
 
-Thorn {\tt IOUtil} defines a set of hyperslab parameters for all
+Thorn {\bf IOUtil} defines a set of hyperslab parameters for all
 I/O methods which determine the default positions of 1D line or 2D slice output
 along the axes. I/O thorns can also define their own hyperslab parameters
-which then will overwrite the defaults provided by {\tt IOUtil}.
+which then will overwrite the defaults provided by {\bf IOUtil}.
 
 \begin{itemize}
   \item {\tt IO::out\_[xyz]line\_[xyz]}\\
@@ -262,8 +267,8 @@ which then will overwrite the defaults provided by {\tt IOUtil}.
   \item {\tt IO::out\_[\{xy\}\{xz\}\{yz\}]plane\_[xyz]}i\\
     specifies the slice center of 2D xy,xz,yz-plane output by index points
     of the underlying computational grid
-  \item {\tt IO::out3D\_downsample\_[xyz]}\\
-    specifies the downsampling factor for 3D output in every direction
+  \item {\tt IO::out\_downsample\_[xyz]}\\
+    specifies the downsampling factor for output in every direction
 \end{itemize}
 
 Setting the index points for the slice centers in a parameter file has
@@ -300,11 +305,11 @@ computational grid}
 \end{figure}
 
 
-\section{Data Filenames and Filename Extensions}
+\section{Data Filenames}
 
 The standard I/O thorns in Cactus make use of a consistent set of filenames
 and extensions, which identify the variables and data format used in the file.
-The filenames are listed in the following tables.
+The filenames are listed in the following table.
 %The filenames are listed in Table~\ref{filename_table},
 %and the extensions in Table~\ref{filename_extensions_table}
 
@@ -313,45 +318,47 @@ The filenames are listed in the following tables.
 \label{filename_table}
 \begin{tabular}{|l|l|}
   \hline
-  {\bf I/O method}   & {\bf Filename for output of variable {\tt phi}}\\
+  {\bf I/O method}   & {\bf Filename for output of variable {\tt var}}\\
   \hline
-  {\tt Scalar}       & phi\_nm1.tl, phi\_nm2.tl phi\_max.tl phi\_min.tl\\
-  {\tt Info}         & Provides no output file (the same data is available with {\tt Scalar} output)\\
-  {\tt IOASCII\_1D}  & phi.xl, phi.yl, phi.zl, phi.dl\\
-  {\tt IOASCII\_2D}  & phi\_2d\_xy.gnuplot, phi\_2d\_xz.gnuplot, phi\_2d\_yz.gnuplot\\
-  {\tt IOASCII\_3D}  & phi\_3d.gnuplot\\
-  {\tt IOHDF5\_3D}   & phi\_3d.h5\\
-  {\tt IOFlexIO\_2D} & phi\_2d.ieee\\
-  {\tt IOFlexIO\_3D} & phi\_3d.ieee\\
+  {\tt Info}         & only outputs to screen\\
+  {\tt Scalar}       & {\tt <var>.\{asc|xg\}} for scalar variables\\
+                     & {\tt <var>\_<reduction>.\{asc|xg\}} for reduction values from grid arrays\\
+  {\tt IOASCII\_1D}  & {\tt <var>\_<slice>\_[<center\_i>][center\_j>].\{asc|xg\}}\\
+  {\tt IOASCII\_2D}  & {\tt <var>\_<plane>\_[<center>].asc}\\
+  {\tt IOASCII\_3D}  & {\tt <var>\_3D.asc}\\
+  {\tt IOJpeg}       & {\tt <var>\_<plane>\_[<center>].jpeg}\\
+  {\tt IOHDF5}       & {\tt <var>\_3D.h5}\\
+  {\tt IOFlexIO\_2D} & {\tt <var>\_2D.ieee}\\
+  {\tt IOFlexIO}     & {\tt <var>\_3D.ieee}\\
   \hline
 \end{tabular}
 \caption{Filenames used by standard I/O thorns}
 \end{center}
 \end{table}
 
-\begin{table}[htb]
-\begin{center}
-\label{filename_extensions_table}
-\begin{tabular}{|c|l|l|}
-\hline
-{\bf Extension} & {\bf Description} & {\bf Thorn} \\
-  \hline
- {\tt .xl} & 1D line plots in {\it x}-direction & {\tt CactusBase/IOASCII}\\
- {\tt .yl} & 1D line plots in {\it y}-direction & {\tt CactusBase/IOASCII}\\
- {\tt .zl} & 1D line plots in {\it z}-direction & {\tt CactusBase/IOASCII}\\
- {\tt .dl} & 1D diagonal line plots             & {\tt CactusBase/IOASCII}\\
- {\tt .tl} & traceline plots over time          & {\tt CactusBase/IOBasic}\\
-  \hline
-\end{tabular}
-\caption{File extensions used by the standard I/O thorns}
-\end{center}
-\end{table}
+%\begin{table}[htb]
+%\begin{center}
+%\label{filename_extensions_table}
+%\begin{tabular}{|c|l|l|}
+%\hline
+%{\bf Extension} & {\bf Description} & {\bf Thorn} \\
+%  \hline
+% {\tt .xl} & 1D line plots in {\it x}-direction & {\tt CactusBase/IOASCII}\\
+% {\tt .yl} & 1D line plots in {\it y}-direction & {\tt CactusBase/IOASCII}\\
+% {\tt .zl} & 1D line plots in {\it z}-direction & {\tt CactusBase/IOASCII}\\
+% {\tt .dl} & 1D diagonal line plots             & {\tt CactusBase/IOASCII}\\
+% {\tt .tl} & traceline plots over time          & {\tt CactusBase/IOBasic}\\
+%  \hline
+%\end{tabular}
+%\caption{File extensions used by the standard I/O thorns}
+%\end{center}
+%\end{table}
 
 
 \section{Checkpointing and Recovery in Cactus}
 \label{cp_recovery}
 
-The I/O methods for 3D output also provide functionality for {\it checkpointing}
+The I/O methods for arbitrary output of CCTK variables also provide functionality for {\it checkpointing}
 and {\it recovery}. A checkpoint is a snapshot of the current state of the
 simulation ({\it ie} the contents of all the grid variables and the parameter
 settings) at a chosen timestep. Each checkpoint is saved into a
@@ -366,7 +373,7 @@ Additionally, for performing parameter studies,  compute-intensive
 initial data can be calculated just once and saved in a checkpoint file
 from which each job can be started.
 
-Again, thorn {\tt CactusBase/IOUtil} provides general checkpoint \& recovery
+Again, thorn {\bf IOUtil} provides general checkpoint \& recovery
 parameters. The most important ones are:
 \begin{itemize}
   \item {\tt IO::checkpoint\_every}\\
@@ -391,17 +398,17 @@ parameters. The most important ones are:
     basename of the recovery file\\
     Iteration number and file extension are appended by the individual I/O
     method used to recover from the recovery file.
-  \item {\tt IO::recovery\_dir}\\
+  \item {\tt IO::recover\_dir}\\
     directory where the recovery file is located
 \end{itemize}
 
 To checkpoint your simulation, you need to enable checkpointing by setting
-the boolean parameter {\tt checkpoint}, for one of the 3D I/O methods to
+the boolean parameter {\tt checkpoint}, for one of the appropriate I/O methods to
 {\tt yes}.
 Checkpoint filenames consist of a basename (as specified in {\tt
 IO::checkpoint\_file}) followed by {\tt ".chkpt.it\_$<$iteration\_number$>$"}
-plus the file extension indicating the file format ({\tt ".ieee"} for IEEEIO
-data from {\tt CactusPUGHIO/IOFlexIO}, or {\tt ".h5} for HDF5 data from
+plus the file extension indicating the file format ({\tt "*.ieee"} for IEEEIO
+data from {\tt CactusPUGHIO/IOFlexIO}, or {\tt "*.h5"} for HDF5 data from
 {\tt CactusPUGHIO/IOHDF5}).
 
 Use the {\tt "manual"} mode to recover from a specific checkpoint file by adding
@@ -422,7 +429,7 @@ match -- a mismatch will not be detected by Cactus in order to terminate it.
 Instead the simulation would always start from initial data without any
 recovery.
 
-Because the same I/O methods implement both output of 3D data and checkpoint
+Because the same I/O methods implement both output of arbitrary data and checkpoint
 files, the same I/O modes are used (see Section~\ref{iomodes}).
 Note that the recovery routines in Cactus can process both chunked and unchunked
 checkpoint files if you restart on the same number of processors -- no
@@ -457,16 +464,16 @@ initial data is calculated only once and stored in a file. Such data
 can then be read back in at startup and immediately used by following evolution
 runs.
 
-The following {\tt IOUtil} parameters exist to specify what variables should be
+The following {\bf IOUtil} parameters exist to specify what variables should be
 read from file(s) as initial data:
 
 \begin{itemize}
-  \item {\tt IO::recover\_ID\_files}\\
+  \item {\tt IO::filereader\_ID\_files}\\
     list of files to read in as initial data (multiple filenames must be
     separated by spaces)\\
     The same file naming conventions (what I/O mode used, which iteration
     number) apply as for checkpoint files.
-  \item {\tt IO::recover\_ID\_vars}\\
+  \item {\tt IO::filereader\_ID\_vars}\\
     list of CCTK variables to read in from the given initial data files
     (variables are identified by their full name, multiple variable names must
     be separated by spaces)\\
@@ -476,7 +483,7 @@ read from file(s) as initial data:
     timesteps of the same variable only the last one is taken.
 \end{itemize}
 
-Thorn {\tt IOUtil} also provides a filereader API which can be called
+Thorn {\bf IOUtil} also provides a filereader API which can be called
 by any application thorn at any time. It gets passed the equivalent information
 to the filereader parameters, plus a pointer to the underlying CCTK grid
 hierarchy:
@@ -534,61 +541,60 @@ Here we give examples of the parameters for the different I/O methods.
   IOASCII::out2D_every = 50
 \end{verbatim}
 
-\item{\bf HDF5 Output with {\tt IOHDF5's "IOHDF5\_3D"} I/O method}
+\item{\bf HDF5 Output with {\tt IOHDF5's "IOHDF5"} I/O method}
 \begin{verbatim}
   ActiveThorns = "IOHDF5 IOUtil PUGHSlab ..."
 
   # Output vars in HDF5 format on iteration 0, 5, 10, ...
-  IOHDF5::out3D_every = 5
+  IOHDF5::out_every = 5
 
   # Group of variables to output
-  IOHDF5::out3D_vars = "evolve::vars"
+  IOHDF5::out_vars = "evolve::vars"
 
   # Special I/O directory for HDF5 output
-  IOHDF5::outdir3D = "/scratch/tmp"
+  IOHDF5::out_dir = "/scratch/tmp"
 
-  # 3D Output unchunked to one file
+  # Full output unchunked to one file
   # (Only using a small number of processors)
-  IO::out3D_mode      = "onefile"
-  IO::out3D_unchunked = "yes"
+  IO::out_mode      = "onefile"
+  IO::out_unchunked = "yes"
 
-  # Downsample 3D data by a factor of 3 in each direction
-  IO::out3D_downsample_x = 3
-  IO::out3D_downsample_y = 3
-  IO::out3D_downsample_z = 3
+  # Downsample full data by a factor of 3 in each direction
+  IO::out_downsample_x = 3
+  IO::out_downsample_y = 3
+  IO::out_downsample_z = 3
 \end{verbatim}
 
-\item{\bf IEEEIO 2D and 3D output using {\tt IOFlexIO's "IOFlexIO\_2D"} and
-{\tt "IOFlexIO\_3D"} I/O methods}
+\item{\bf IEEEIO 2D hyperslab and full output using {\tt IOFlexIO's "IOFlexIO\_2D"} and {\tt "IOFlexIO"} I/O methods}
 \begin{verbatim}
   ActiveThorns = "IOFlexIO FlexIO IOUtil PUGHSlab ..."
 
   # Output vars in 2D IEEEIO format on iteration 0, 100, 200, ...
   IOFlexIO::out2D_every = 100
 
-  # Output vars in 3D IEEEIO format on iteration 0, 5, 10, ...
-  IOFlexIO::out3D_every = 5
+  # Output vars in IEEEIO format on iteration 0, 5, 10, ...
+  IOFlexIO::out_every = 5
 
   # Group of variables to output to file for each method
   IOFlexIO::out2D_vars = "evolve::vars"
-  IOFlexIO::out3D_vars = "evolve::vars"
+  IOFlexIO::out_vars   = "evolve::vars"
 
   # 2D output goes into standard I/O directory
-  IO::outdir = "test"
+  IO::out_dir = "test"
 
-  # Special I/O directory for 3D output
-  IOFlexIO::outdir3D = "/scratch/tmp"
+  # Special I/O directory for full output
+  IOFlexIO::out_dir = "/scratch/tmp"
 
-  # 3D Output chunked to one file for every eight processors
+  # Full output chunked to one file for every eight processors
   # (Run on large number of processors)
-  IO::out3D_mode      = "np"
-  IO::out3D_nproc     = 8
-  IO::out3D_unchunked = "no"
-
-  # Downsample 3D data by a factor of 3 in each direction
-  IO::out3D_downsample_x = 3
-  IO::out3D_downsample_y = 3
-  IO::out3D_downsample_z = 3
+  IO::out_mode       = "np"
+  IO::out_proc_every = 8
+  IO::out_unchunked  = "no"
+
+  # Downsample full data by a factor of 3 in each direction
+  IO::out_downsample_x = 3
+  IO::out_downsample_y = 3
+  IO::out_downsample_z = 3
 \end{verbatim}
 
 \item{\bf Checkpointing using thorn {\tt IOFlexIO}}
@@ -625,8 +631,8 @@ Here we give examples of the parameters for the different I/O methods.
 
 This section is for Cactus developers to describe how they can add a new method
 for checkpointing/recovery using the existing I/O parameters and the function
-API of thorn {\tt CactusBase/IOUtil}.
-Inheriting this functionality from thorn {\tt IOUtil} helps you to reuse
+API of thorn {\bf IOUtil}.
+Inheriting this functionality from thorn {\bf IOUtil} helps you to reuse
 existing code and maintain a uniform user interface on how to invoke different
 checkpointing/recovery methods.
 
@@ -643,13 +649,13 @@ variable, except that
 \end{enumerate}
 
 A thorn routine providing this checkpointing capability should register itself
-with the flesh's scheduler at the {\tt CCTK\_CPINITIAL} (for initial data
-checkpoints), {\tt CCTK\_CHECKPOINT} (for periodic checkpoints of evolution
-data), and {\tt CCTK\_TERMINATE} time bins (for checkpointing the last timestep
+with the flesh's scheduler at the {\tt CPINITIAL} (for initial data
+checkpoints), {\tt CHECKPOINT} (for periodic checkpoints of evolution
+data), and {\tt TERMINATE} time bins (for checkpointing the last timestep
 of a simulation).
 
 It should also decide whether checkpointing is needed by evaluating the
-corresponding checkpoint parameters of {\tt IOUtil} (see section
+corresponding checkpoint parameters of {\bf IOUtil} (see section
 \ref{cp_recovery}).
 
 Before dumping the contents of a distributed grid array into a checkpoint
@@ -660,7 +666,7 @@ To gather the current parameter values you can use the C routine
 \begin{verbatim}
   char *IOUtil_GetAllParameters (const cGH *GH, int all);
 \end{verbatim}
-from thorn {\tt IOUtil}. This routine returns the parameter settings in an
+from thorn {\bf IOUtil}. This routine returns the parameter settings in an
 allocated single large string. Its second argument {\tt all} flags whether all
 parameter settings should be gathered ($!= 0$) or just the ones which have been
 set before ($== 0$). Note that you should always save all parameters in a
@@ -694,12 +700,12 @@ Recovering from a checkpoint is a two-step operation:
     contents).
 \end{enumerate}
 
-The flesh provides the special time bins {\tt CCTK\_RECOVER\_PARAMETERS} and
-{\tt CCTK\_RECOVER\_VARIABLES} for these two steps (see also the chapter on
+The flesh provides the special time bins {\tt RECOVER\_PARAMETERS} and
+{\tt RECOVER\_VARIABLES} for these two steps (see also the chapter on
 {\it Adding a Checkpointing/Recovery Method} in the {\it Infrastructure Thorn
 Writer's Guide} as part of the {\it Cactus User's Guide}).\\
 
-Thorn {\tt IOUtil} evaluates the recovery parameters (determines the recovery
+Thorn {\bf IOUtil} evaluates the recovery parameters (determines the recovery
 mode to use, construct the name(s) of the recovery file(s) etc.).
 It also controls the recovery process by invoking the recovery methods of
 other I/O thorns, one after another until one method succeeded.\\
@@ -710,7 +716,7 @@ A recovery method must provide a routine with the following prototype:
   int Recover (cGH *GH, const char *basefilename, int called_from);
 \end{verbatim}
 
-This routine will be invoked by {\tt IOUtil} with the following arguments:
+This routine will be invoked by {\bf IOUtil} with the following arguments:
 
 \begin{itemize}
   \item a GH pointer refer to the grid hierarchy and its grid variables\\
@@ -718,7 +724,7 @@ This routine will be invoked by {\tt IOUtil} with the following arguments:
     at {\tt CP\_RECOVER\_PARAMETERS} when no grid hierarchy exists yet.
 
   \item the basename of the checkpoint file to recover from\\
-    This name is constructed by {\tt IOUtil} from the settings of {\tt
+    This name is constructed by {\bf IOUtil} from the settings of {\tt
     IO::recovery\_dir} and {\tt IO::recover\_file}. It will also include an
     iteration number if one of the {\tt auto} recovery modes is used.
     The filename extension by which checkpoint files of different recovery
@@ -728,15 +734,15 @@ This routine will be invoked by {\tt IOUtil} with the following arguments:
     This can be one of the keywords {\tt CP\_INITIAL\_DATA, CP\_EVOLUTION\_DATA,
     CP\_RECOVER\_PARAMETERS, CP\_RECOVER\_DATA}, or {\tt FILEREADER\_DATA}).
     This flag tells the routine what it should do when it is being called by
-    {\tt IOUtil}. Note that {\tt IOUtil} assumes that the recovery method can
+    {\bf IOUtil}. Note that {\bf IOUtil} assumes that the recovery method can
     also be used as a filereader routine here which is essentially the same
     as recovering (individual) grid variables from (data) files.
 \end{itemize}
 
 
 To perform the first step of recovery process, a recovery method must register
-a routine with the flesh's scheduler at the {\tt CCTK\_RECOVER\_PARAMETERS}
-time bin. This routine itself should call the {\tt IOUtil} API
+a routine with the flesh's scheduler at the {\tt RECOVER\_PARAMETERS}
+time bin. This routine itself should call the {\bf IOUtil} API
 
 \begin{verbatim}
   int IOUtil_RecoverParameters (int (*recover_fn) (cGH *GH,
@@ -756,7 +762,7 @@ routine are
 
   \item {\tt file\_extension} -- the filename extension for recovery files
     which are accepted by this recovery method\\
-    When {\tt IOUtil} constructs the recovery filename and searches for
+    When {\bf IOUtil} constructs the recovery filename and searches for
     potential recovery files (in the {\tt auto} recovery modes) it will only
     match filenames with the basename as given in the {\tt IO::recovery\_file}
     parameter, appended by {\tt file\_extension}.
@@ -766,7 +772,7 @@ routine are
     This is just a descriptive string to print some info output during recovery.
 \end{itemize}
 
-The routine registered at {\tt CCTK\_RECOVER\_PARAMETERS} should return to
+The routine registered at {\tt RECOVER\_PARAMETERS} should return to
 the scheduler a negative value if parameter recovery failed for this recovery
 method for some reason (eg. if no appropriate recovery file was found).
 The scheduler will then continue with the next recovery method until one
@@ -777,9 +783,9 @@ A value of zero should be returned to the scheduler to indicate that no
 recovery was requested.\\
 
 The second step during recovery --- restoring the contents of grid variables
-from the recovery file --- is invoked by thorn {\tt IOUtil} which registers
-a routine at {\tt CCTK\_RECOVER\_VARIABLES}. This routine calls all recovery
-methods which were registered before with {\tt IOUtil} via the API
+from the recovery file --- is invoked by thorn {\bf IOUtil} which registers
+a routine at {\tt RECOVER\_VARIABLES}. This routine calls all recovery
+methods which were registered before with {\bf IOUtil} via the API
 
 \begin{verbatim}
   int IOUtil_RegisterRecover (const char *name,
@@ -789,10 +795,10 @@ methods which were registered before with {\tt IOUtil} via the API
 \end{verbatim}
 
 With this registration, all recovery method's actual recovery routines are made
-known to {\tt IOUtil}, along with a descriptive name under which they are
+known to {\bf IOUtil}, along with a descriptive name under which they are
 registered.
 
-At {\tt CCTK\_RECOVER\_VARIABLES} thorn {\tt IOUtil} will loop over all 
+At {\tt RECOVER\_VARIABLES} thorn {\bf IOUtil} will loop over all 
 available recovery routines (passing the same arguments as for parameter
 recovery) until one succeeds (returns a positive value).