Opened 3 years ago

Last modified 3 years ago

#1793 new defect

activating 3d output at restart results in unexpected behavior

Reported by: physik@… Owned by: Erik Schnetter
Priority: unset Milestone:
Component: Carpet Version: ET_2014_05
Keywords: Cc:



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
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.


Attachments (0)

Change History (3)

comment:1 Changed 3 years ago by Roland Haas

"divisor" is (well should be) supported for out3d_criterion, see lines 281 and 296ff of CarpetIOHDF5/src/ (which handles out3d_vars output, 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

comment:2 Changed 3 years ago by anonymous

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::vel


# ADMBase::lapse
# ADMBase::shift
# ADMBase::metric

The checkpoint iteration was 67270

comment:3 Changed 3 years ago by Roland Haas

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'.

Modify Ticket

Change Properties
Set your email in Preferences
as new The owner will remain Erik Schnetter.
Next status will be 'review'.
as The resolution will be set.
to The owner will be changed from Erik Schnetter to the specified user.
Next status will be 'confirmed'.
The owner will be changed from Erik Schnetter to anonymous.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.