[ET Trac] [Einstein Toolkit] #1797: allow new timelevels to be created at runtime

[Einstein Toolkit]

#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?

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1797#comment:6>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit