From bb7c8ef28e73c9d13a4c05e420550d0e01eb237c Mon Sep 17 00:00:00 2001 From: swhite Date: Wed, 28 Jul 2004 14:04:06 +0000 Subject: 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 --- doc/documentation.tex | 42 ++++++++++++++++++++++-------------------- param.ccl | 4 ++++ src/CheckpointRecovery.c | 5 ++++- 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, -- cgit v1.2.3