#1797: allow new timelevels to be created at runtime --------------------------+------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: review Priority: optional | Milestone: Component: Cactus | Version: development version Resolution: | Keywords: Cactus Carpet PUGH --------------------------+-------------------------------------------------
Comment (by rhaas):
Replying to [comment:2 eschnett]:
What happens during time level cycling? Currently, grid variables with
one time level remain unchanged, whereas variables with more than one time level become invalid during time level cycling. The patches introduce no new behaviour. Maybe I was not clear enough: What the proposed patches actually do is make the flesh ignore the TIMELEVELS attribute in interface.ccl in the EnableStorage calls.
The described issue of a variable going from not changing to changing already happens currently with eg a TIMELEVELS=2 variable whose schedule.ccl says STORAGE: foo[1] and where the user later calls EnableStorage during runtime.
I suggest to change this behaviour so that every grid function remains
defined at its current value during time level cycling. This will then avoid the need to copy the past to the current time level, which is the first step of every time integrator. This would basically amount to moving the InitialCopy routine out of MoL and into the driver, just after it cycled timelevels, wouldn't it? Or are you suggesting a more invasive change that couples the time stepper and the driver more tightly?