Added new parameter IO::filereader_dir

See bug 1809

doc/documentation.tex:
Ran through spellchecker
Fixed a little grammar
Changed square brackets to curly ones in doc for filereader_ID_vars


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

3 files changed, 30 insertions, 21 deletions

diff --git a/doc/documentation.tex b/doc/documentation.tex
index 72a50c1..1ed312e 100644
--- a/doc/documentation.tex
+++ b/doc/documentation.tex
@@ -3,7 +3,7 @@
 % Use the Cactus ThornGuide style file
 % (Automatically used from Cactus distribution, if you have a 
 %  thorn without the Cactus Flesh download this from the Cactus
-%  homepage at www.cactuscode.org)
+%  home page at www.cactuscode.org)
 \usepackage{../../../../doc/ThornGuide/cactus}
 
 \begin{document}
@@ -107,7 +107,7 @@ and activated in your parameter files before any of these I/O methods
 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
+providing output on each iteration. The default behaviour can be overridden
 by specific parameters for each method.
 For example, you may want scalar and 1D output at every iteration
 but computationally expensive 3D output only every 10th iteration,
@@ -138,7 +138,7 @@ a uniform interface on how to use the I/O methods.
 %
 %\begin{itemize}
 %
-%\item{\tt HDF5} {\bf Hierachical Data Format}\\
+%\item{\tt HDF5} {\bf Hierarchical Data Format}\\
 %{\tt http://hdf.ncsa.uiuc.edu/}
 %
 %\item{\tt IEEEIO} \\
@@ -247,10 +247,10 @@ your particular machine architecture and needs:
 \end{itemize}
 
 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
+mode on machines with a fast I/O subsystem and many I/O nodes (e.g. 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"}, doing output by every so many processors,
+you may 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).
 
@@ -266,10 +266,10 @@ provided by the thorns offering parallel I/O methods.
 
 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
+and {\tt IOASCII\_2D} will output only a subset of the data (e.g. 1D lines or 2D
 planes of 3D grid functions).
 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
+region into the multidimensional dataset, with a start point and a length in any
 direction, and an optional downsampling factor.
 
 Thorn {\bf IOUtil} defines a set of hyperslab parameters for all
@@ -383,7 +383,7 @@ The filenames are listed in the following table.
 
 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
+simulation ({\it i.e.} the contents of all the grid variables and the parameter
 settings) at a chosen timestep. Each checkpoint is saved into a
 {\it checkpoint file} which can be used to restart a new simulation at a later
 time, recreating the exact state at which it was checkpointed.
@@ -448,19 +448,19 @@ a warning message and then continue with the simulation. This mode allows you
 to enable checkpointing and recovery in the same parameter file and use that
 without any changes to restart your simulation. On the other hand, you are
 responsible now for making the checkpoint/recovery directory/file parameters
-match -- a mismatch will not be detected by Cactus in order to terminate it.
+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 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
+checkpoint files if you restart on the same number of processors --- no
 recombination is needed here. That's why you should always use one of the
 parallel I/O modes for checkpointing. If you want to restart on a different
 number of processors, you first need to recombine the data in the checkpoint
 file(s) to create a single file with unchunked data.
-Note that Cactus checkpoint files are platform-independent so you can restart
+Note that Cactus checkpoint files are platform independent so you can restart
 from your checkpoint file on a different machine/architecture.
 
 \vskip .5cm
@@ -480,8 +480,8 @@ The output data should match exactly if recovery was successful.
 
 The very same routines which implement checkpointing/recovery functionality
 in the {\tt IOHDF5} and {\tt IOFlexIO} thorns are also used to provide
-filereader capabilities within Cactus. They enable users to read variables,
-which contents was written to files in HDF5 or IEEEIO data format, back into
+file reader capabilities within Cactus. They enable users to read variables,
+whose contents were written to files in HDF5 or IEEEIO data format, back into
 Cactus at a later time. This is especially useful if compute-intensive
 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
@@ -491,6 +491,8 @@ The following {\bf IOUtil} parameters exist to specify what variables should be
 read from file(s) as initial data:
 
 \begin{itemize}
+  \item {\tt IO::filereader\_dir}\\
+    root directory for files to be read
   \item {\tt IO::filereader\_ID\_files}\\
     list of files to read in as initial data (multiple filenames must be
     separated by spaces)\\
@@ -507,7 +509,7 @@ read from file(s) as initial data:
     the last one is taken by default. This can be changed by adding an option
     string with the key {\tt cctk\_iteration} and an associated integer scalar
     value to the variable name denoting the iteration number to choose, like in
-    {\tt IO::filereader\_ID\_vars = "wavetoy::phi[ cctk\_iteration = 10 ]"}.
+    {\tt IO::filereader\_ID\_vars = "wavetoy::phi\{ cctk\_iteration = 10 \}"}.
 \end{itemize}
 
 Thorn {\bf IOUtil} also provides a filereader API which can be called
@@ -683,7 +685,7 @@ variable, except that
 \begin{enumerate}
   \item the output is done for all grid variables existing in a grid hierarchy
   \item in addition to the contents of all variables, also the current setting
-    of all parameters is saved as well as some other information neccessary for
+    of all parameters is saved as well as some other information necessary for
     recovering from the checkpoint at a later time
 \end{enumerate}
 
@@ -698,7 +700,7 @@ corresponding checkpoint parameters of {\bf IOUtil} (see section
 \ref{cp_recovery}).
 
 Before dumping the contents of a distributed grid array into a checkpoint
-file the variable should be synced in case synchronization was not done before
+file the variable should be synchronized in case synchronization was not done before
 implicitly by the scheduler.
 
 To gather the current parameter values you can use the C routine
@@ -711,7 +713,7 @@ 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
 checkpoint in order to reproduce the same state after recovery.
 
-As additional data neccessary for proper recovery, the following information
+As additional data necessary for proper recovery, the following information
 must be saved in a checkpoint file:
 \begin{itemize}
   \item the current main loop index (used by the driver as the main evolution
@@ -722,13 +724,13 @@ must be saved in a checkpoint file:
 
 Moreover, information about the I/O mode used to create the checkpoint
 (chunked/unchunked, serial versus parallel I/O), the active thorns list, or
-this run's Cactus version ID (for compatibilty checking at recovery time) could
+this run's Cactus version ID (for compatibility checking at recovery time) could
 be relevant to save in a checkpoint.
 
 
 \subsection{Adding a Recovery Method}
 
-Recovering from a checkpoint is a two-step operation:
+Recovering from a checkpoint is a two step operation:
 \begin{enumerate}
   \item Right after reading the parameter file and finding out if recovery was
     requested, all the parameters are restored from the checkpoint file
@@ -813,7 +815,7 @@ routine are
 
 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).
+method for some reason (e.g. if no appropriate recovery file was found).
 The scheduler will then continue with the next recovery method until one
 finally succeeds (a positive value is returned). If none of the available
 recovery methods were successful the flesh would stop the code.
diff --git a/param.ccl b/param.ccl
index 1f5ea4a..20405cb 100644
--- a/param.ccl
+++ b/param.ccl
@@ -163,6 +163,10 @@ STRING recover_dir "Directory to look for recovery files" STEERABLE = RECOVER
 {
   ".+" :: "A valid directory name"
 } "."
+STRING filereader_dir "Directory to look for input files" STEERABLE = RECOVER
+{
+  ".+" :: "A valid directory name"
+} "."
 STRING filereader_ID_files "List of files to read in as initial data" STEERABLE = RECOVER
 {
   ".+" :: "Space-separated list of initial data filenames"
diff --git a/src/CheckpointRecovery.c b/src/CheckpointRecovery.c
index 2040959..e319562 100644
--- a/src/CheckpointRecovery.c
+++ b/src/CheckpointRecovery.c
@@ -212,10 +212,13 @@ char *IOUtil_AssembleFilename (const cGH *GH,
 
     case CP_RECOVER_DATA:
     case CP_RECOVER_PARAMETERS:
-    case FILEREADER_DATA:
       dir = recover_dir;
       basename = basefilename ? basefilename : recover_file;
       break;
+    case FILEREADER_DATA:
+      dir = filereader_dir;
+      basename = basefilename ? basefilename : recover_file;
+      break;
 
     default:
       CCTK_VWarn (0, __LINE__, __FILE__, CCTK_THORNSTRING,