-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hello all,

I am trying to recover a checkpoint that was written with the attached parfile and get errors - --8<-- cactus_bns_all: /mnt/data/rhaas/postdoc/gr/Zelmani/arrangements/Carpet/CarpetLib/src/th.hh:79: CCTK_REAL8 th::get_time(int, int, int) const: Assertion `tl>=0 and tl<timelevels' failed. Rank 0 with PID 31684 received signal 6 Writing backtrace to tov-mol/backtrace.0.txt - --8<-- and indeed the checkpoint contains - --8<-- ML_ADMCONSTRAINTS::H\ it=0\ tl=2\ rl=0\ c=0 Dataset {21, 21, 36} - --8<--

Setting carpet::max_timelevels when recovering however does not have the desired effect since the parameter is not steerable.

There was a lengthy discussion as to how best fix this issue of not being able to recover checkpoints when the parameter file was "funny" in https://trac.einsteintoolkit.org/ticket/626 (yes, that one :-) ).

My question now is: why is carpet::max_timelevels not steerable? It seems to me as if the most common use will be exactly to make a checkpoint recoverable. Was this just an oversight?

Ideally no such parameter should be needed. Either CarpetIOHDF5 should ignore (or: fail with a meaningful error when it encounters them) timelevels in checkpoint files that the current simulation cannot handle or Carpet should be able to cope with the maximum possible number of timelevels (determined to be the maximum over all groups of CCTK_MaxTimeLevels()), I think.

Yours, Roland

PS The attached parfile is a proxy for a real world parfile where we attempt to do something similar (but the real world one runs on many cores only), so just disabling ML_ADMCONSTRAINTS is not an option.

- --

My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net.