activating 3d output at restart results in unexpected behavior

Create issue
Issue #1793 new
Wolfgang Kastaun created an issue

Hi,

I've recently switched on 3D carpetIOHDF5 output when restarting from a checkpoint which was not a multiple of carpetiohdf5::out_every, which in turn corresponds to a multiple of the coarsest timestep. In the resulting files, all but the finest levels where missing. I realized that instead of Carpetiohdf5::out_criterion = divisor I have used Carpetiohdf5::out3D_criterion = divisor A quick grep in the source code resulted in no match for the latter parameter, it seems completely unused. Thus, Carpet was probably using the default for out_criterion, which is "default", which means use IO:out3D_criterion, which was not set, defaulting to "iteration". Now, according to this closed issue https://trac.einsteintoolkit.org/ticket/1053 that should still work as intended. I suppose the problem here is that the 3d output was not activated in previous restarts, so there was no last output time when restarting, and it outputs every so many iterations after the checkpoint.

This occurred with the Wheeler release, I have not checked the newest release yet.

Cheers, Wolfgang.

Keyword:

Comments (3)

  1. Roland Haas
    • removed comment

    "divisor" is (well should be) supported for out3d_criterion, see lines 281 and 296ff of CarpetIOHDF5/src/OutputSlice.cc (which handles out3d_vars output, Output.cc only handles out_vars output). Would you mind attaching the parfile that failed as well as the name of the checkpoint file (to know the iteration of the checkpoint), please?

    A grep for ou3d_criterion will indeed fail since the code uses some preprocessor magic to get the parameter name (the GetParameter macro in OutputSlice.cc).

  2. anonymous
    • removed comment

    I was using out_vars, not out3D_vars. Could this be the issue? Does that mean there are two different code path for variables in out_vars and out3d_vars? Which is the recommended one?

    In any case, the relevant section of the parfile is

    carpetiohdf5::out_dir = "hdf5_3D" Carpetiohdf5::out3D_criterion = divisor carpetiohdf5::out_every = 512 carpetiohdf5::out_vars = " hydrobase::rho

    hydrobase::vel

    hydrobase::temperature hydrobase::entropy hydrobase::Y_e

    ADMBase::lapse

    ADMBase::shift

    ADMBase::metric

    "

    The checkpoint iteration was 67270

  3. Roland Haas
    • removed comment

    Yes, the code paths for 'out_vars' and 'out3d_vars' are completely different. Basically 'out_vars' is the older implementation and the one required for checkpointing/recovery so will always write the full amount of data in a grid function/grid array. 'out3d_vars' uses the same code as the other 'outXD_vars' options and can only write 3d data.

    Both should be functional and both are supported right now, however -- at least personally -- I would recommend using 'out3d_vars' for output and also tend to add more complex new features (such as being able to remove buffer points for output, and use less than one file per process) only to 'out3d_vars'.

    Yes, according to your parfile you are not setting 'out3d_vars' so will use the default value for that parameter which is empty and for 'out3d_every' you'd use its default which means 'no output'.

  4. Log in to comment