For recovery, there is one small problem that would be difficult to avoid:
If you start a simulation in a directory that is not empty, but which contains files e.g. from a previous simulation, then Cactus is supposed to delete all files that it is writing before writing them. (That is, Cactus shouldn't append to existing files, unless you recover.) If you steer the parameter upon recovery, this check is omitted, and Cactus appends to existing files.
For example, if you start a simulation from scratch in a directory containing the files lapse.asc and lapse.xg, and if you are using xgraph style, then lapse.xg will be deleted and then written. If you change to gnuplot style upon recovery, Cactus will append to the (existing) lapse.asc without deleting it first. This can be confusing.
What do you think, Luca? What do others think?
-erik
On Tue, Sep 21, 2010 at 5:05 PM, Baiotti Luca baiotti@ile.osaka-u.ac.jp wrote:
Erik,
making it steerable on recovery would be enough.
Luca
On 9/22/10 6:52 AM, Erik Schnetter wrote:
Luca
This parameter determines also the file name that is used to output the data. When you steer the parameter, IOBasic would have to create the new file. If you steer it back, it probably should append to the existing, old file. It would probably also need to indicate that the output has been distributed over several files, so that people are not surprised by "missing" data.
I could be convinced to make it steerable upon recovery, but making it generally steerable seems to create a lot of complications. When would this feature be convenient for you?
-erik
On Tue, Sep 21, 2010 at 4:45 PM, Baiotti Lucabaiotti@ile.osaka-u.ac.jp wrote:
Hello,
could the IOBasic parameter:
KEYWORD outScalar_style "Which style for Scalar output" { "gnuplot" :: "1D output readable by gnuplot" "xgraph" :: "1D output readable by xgraph" } "xgraph"
be made steerable?
Luca _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users