Hello Allen,
Not as a checkpoint in Carpet itself since it would have to also interpolate in time the previous time-levels (even if the current time-levels align).
You *could* try and use the checkpoint as initial data with the file reader and use Carpet's init_3_levels or so option to evolve this data backwards and forwards to get valid data for all three levels. Yosef may recall more information if / how that functionality works.
Other than that: the ReadInterpolate thorn (though maybe only in a branch and not in master) had the ability to change timestep size. If I recall correctly then it can only make smaller since otherwise it would have to extrapolate in time, which I wanted to avoid.
Though looking at the ET repository I have a commit
git hash [d49d9095](https://bitbucket.org/einsteintoolkit/einsteininitialdata/commits/d49d9095bf...) "ReadInterpolate: remove broken time interpolation code" of [einsteininitialdata](https://bitbucket.org/einsteintoolkit/einsteininitialdata)
so maybe that one should not really be used either :-)
I have a branch 'rhaas/timeinterp' in the original git repo
https://github.com/rhaas80/ReadInterpolate.git
with a commit that claims to work towards fixing this. However it's commit message says:
still broken since checkpoints record the simulation time in the "time" attribute, not the time of the slice
This however ought to be fixable if that is the issue (but just computing the correct time for the timelevel based on Delta_time, the global simulation time and the timelevel).
So: maybe :-)
Yours, Roland
[CAUTION: Non-UBC Email]
Hello,
Is there a clean way to change the timestep size in a Carpet simulation on recovery (eg. effectively making Time::dtfac steerable)? I am running into numerical instabilities late in a simulation and was wondering if reducing the dtfac would help. While I am using multiple refinement levels with subcycling, I can ensure all levels are aligned in time at this checkpoint if it helps.
Thanks, Allen Wen