#1053: CarpetIOHDF5: it doesn't honor out3D_every parameter ----------------------+----------------------------------------------------- Reporter: bmundim | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Resolution: | Keywords: CarpetIOHDF5 out3D_every ----------------------+-----------------------------------------------------
Comment (by bmundim):
I see. I understand the problem better now but I have to say that I find the so stated behavior of out_every extremely misleading. Take for example the definition at IOUtil of out_every:
{{{ INT out_every "How often to do output by default" STEERABLE = ALWAYS { 1:* :: "Every so many iterations" -1:0 :: "Disable output" } -1 }}}
that was what I took for granted! Every 128 iterations starting from 0 an output was supposed to be dumped in the example above! If we are using Carpet then we need to understand a bit of AMR and how Carpet deals with time index. Once we understand that then it is easy to choose the number of iterations such that every other coarse (or half coarse, as I have chosen in this example) time step is dumped. The way it seems to be implemented is very misleading, unfortunately.
To remedy this, Carpet now keeps track of when the last output occurred,
and outputs anew if at least out_every iterations passed since then. In the above case, output would occur every 128 iterations, since 128 is the smallest multiple of 32 that is larger than or equal to 100. This is safe, but of course, people now don't like this because output may occur at unpredictable times...
I don't think Carpet is tracking correctly when the last 3D output occurred from the checkpoint file (unless it is considering the checkpoint iteration as the last 3D output, what doesn't look right to me). In the example above Carpet should know that the last 3D output was at it=256, before the checkpoint iteration. However Carpet doesn't seem to recover that information from the checkpoint file correctly. It seems to consider it=262 instead as the last output and then pick up the new series of output from that iteration number. That doesn't seem correct to me at all. Also the 2D slice does work correctly as posted above, ie it does pick it=256 as the last output iteration number.
In any case, adding the following to the par file avoids this problem:
{{{ IOHDF5::out3D_criterion = "divisor" }}}
thanks!