Hi,
You can download the slides and 2 movies for my presentation today from
http://ccrg.rit.edu/~yosef/100to1.html
The 100to1.mov is a simple gnuplot visualization of the horizons. h2o_5.mov is a better visualization. In this animation the small horizon is magnified for visualization purposes.
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
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 Luca baiotti@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
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
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
On Tue, Sep 21, 2010 at 07:00:43PM -0500, Erik Schnetter wrote:
What do you think, Luca? What do others think?
That use-case will not be common, and in that case I would simply restart in a fresh directory, e.g. using simfactory.
Frank
On 9/22/10 12:34 PM, Frank Loeffler wrote:
On Tue, Sep 21, 2010 at 07:00:43PM -0500, Erik Schnetter wrote:
What do you think, Luca? What do others think?
That use-case will not be common, and in that case I would simply restart in a fresh directory, e.g. using simfactory.
Erik,
I also think that it is an unlikely situation. An INFO message about which files are being appended, together with the creation date of the datasets contained in the ASCII files should be enough to disentangle the possible confusion you mentioned. As a further help, the date of last writing of the to-be-appended files could be printed together with the INFO message, but I think it not to be a priority or a necessity.
Luca
On Wed, Sep 22, 2010 at 12:17 AM, Baiotti Luca baiotti@ile.osaka-u.ac.jp wrote:
On 9/22/10 12:34 PM, Frank Loeffler wrote:
On Tue, Sep 21, 2010 at 07:00:43PM -0500, Erik Schnetter wrote:
What do you think, Luca? What do others think?
That use-case will not be common, and in that case I would simply restart in a fresh directory, e.g. using simfactory.
Erik,
I also think that it is an unlikely situation. An INFO message about which files are being appended, together with the creation date of the datasets contained in the ASCII files should be enough to disentangle the possible confusion you mentioned. As a further help, the date of last writing of the to-be-appended files could be printed together with the INFO message, but I think it not to be a priority or a necessity.
In this case, just making the corresponding parameters steerable should be good enough. Luca, did you try this? Did it work?
-erik
On 9/23/10 10:09 AM, Erik Schnetter wrote:
On Wed, Sep 22, 2010 at 12:17 AM, Baiotti Luca baiotti@ile.osaka-u.ac.jp wrote:
On 9/22/10 12:34 PM, Frank Loeffler wrote:
On Tue, Sep 21, 2010 at 07:00:43PM -0500, Erik Schnetter wrote:
What do you think, Luca? What do others think?
That use-case will not be common, and in that case I would simply restart in a fresh directory, e.g. using simfactory.
Erik,
I also think that it is an unlikely situation. An INFO message about which files are being appended, together with the creation date of the datasets contained in the ASCII files should be enough to disentangle the possible confusion you mentioned. As a further help, the date of last writing of the to-be-appended files could be printed together with the INFO message, but I think it not to be a priority or a necessity.
In this case, just making the corresponding parameters steerable should be good enough. Luca, did you try this? Did it work?
Yes, it worked for me.
Luca
I propose, then, to make this parameter steerable. This won't affect current users, as it requires manually changing parameter files before recovery.
-erik
On Sat, Sep 25, 2010 at 6:10 AM, Baiotti Luca baiotti@ile.osaka-u.ac.jp wrote:
On 9/23/10 10:09 AM, Erik Schnetter wrote:
On Wed, Sep 22, 2010 at 12:17 AM, Baiotti Luca baiotti@ile.osaka-u.ac.jp wrote:
On 9/22/10 12:34 PM, Frank Loeffler wrote:
On Tue, Sep 21, 2010 at 07:00:43PM -0500, Erik Schnetter wrote:
What do you think, Luca? What do others think?
That use-case will not be common, and in that case I would simply restart in a fresh directory, e.g. using simfactory.
Erik,
I also think that it is an unlikely situation. An INFO message about which files are being appended, together with the creation date of the datasets contained in the ASCII files should be enough to disentangle the possible confusion you mentioned. As a further help, the date of last writing of the to-be-appended files could be printed together with the INFO message, but I think it not to be a priority or a necessity.
In this case, just making the corresponding parameters steerable should be good enough. Luca, did you try this? Did it work?
Yes, it worked for me.
Luca
users@lists.einsteintoolkit.org
-
Baiotti Luca -
Erik Schnetter -
Frank Loeffler -
Yosef Zlochower