#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):
(Answering only Erik so far).
I see, so I can see that currently a thorn can protect against this type of thing if it marks a grid function as TIMELEVELS=1.
I am not sure though if I can construct a situation where this would make copying forward just after cycling the right thing to do: I feel that if time cycling happens because multiple timelevels exist, then the grid function is now time dependent (since all reasons for having time levels means that something changes with time). In this case the copied forward data is actually wrong since it is not the data that belongs to {{{cctk_time}}} but instead that that belongs to {{{cctk_time - cctk_delta_time}}} (since tl=0 is the invalid level and tl=1 is the valid one that was just cycled out). This is fine in MoL's evolution loop since MoL basically says "compute f(y, t) for the y and t that you find in tl=0 and cctk_time" and itself modifies cctk_time so that for eg the first RK step cctk_time is reduced by cctk_delta_time compared to what the driver supplied (in MoL/src/SetTime.c). However the data in tl=0 is genuinely invalid between the time Carpet cycled it in and the time MoL finishes (so in particular the PRESTEP and the PREREGRID bins).
Note that the copied data is correct (in that is is what you'd expect) for something like the ADM variables if they are copied forward at the same time as the BSSN variables only in the sense in that the ADM variables are what would be computed by a BSSN2ADM routine given the values of the BSSN variables in tl=0. I would however maintain that those values (of BSSN in tl=0) are incorrect in between time cycling and the end of EVOL.
Well actually, I can think of a situation, namely say the RHS grid functions which usually have only a single timelevel. A thorn could currently rely on RHS not changing between the last RK step and the first one of the next iteration and use this to compute the new RHS. My proposed solution to this would be for MoL to handle RHS grid functions the same way it does constrained ones: copy forward in time if they have more than one timelevel. Was that the situation you had in mind?