Hello Eloisa,
But is this actually correct? Roland's example with "BSSNtoADM" being naturally scheduled in PseudoEvolution makes it clear that there are at least two levels of pseudo-evolution: one that translates the gravitational/hydro variables between all the different formulations one may need, and a later one where these variables (cast in whichever formulation) are used to build derived objects. Also from Roland's comments, I understand that the latter class must remain in PseudoEvolution (rather than going in ANALYSIS which I would have found more natural) because derivatives calculated in ANALYSIS will be wrong at the refinement boundaries (did I get this point right?).
Yes this is my understanding. There was some discussion about this wrt to WeylScal4 (between Tanja, Erik, Ian, Peter, myself, around 2009-09-18). Essentially in ANALYSIS you get:
--8<-- What I wanted to say is that if the Psi4 grid function is set during ANALYSIS then the fine and coarse grid levels are not set in the proper order. To test this I wrote a tiny thorn with two functions that are both scheduled in ANALYSIS, one which sets a grid function to cctk_iteration+lvl/10, where lvl is the current refinement level and a second function to write one value from this grid function to stdout (see attachement). The output of those (for a six level system) looks like this:
# iteration i*j*k lvl grid-function debug: 0 0 0 0.000000 debug: 0 0 1 0.100000 debug: 0 0 2 0.200000 debug: 0 0 3 0.300000 debug: 0 0 4 0.400000 debug: 0 0 5 0.500000 debug: 0 0 6 0.600000 debug: 1 0 6 1.600000 <- debug: 2 0 5 2.500000 debug: 2 0 6 2.600000
Those ones with iteration number 0 are just initial data and are fine. If prolongation was to be used in ANALYSIS and it works as in EVOL then in step 1 (marked with an <- above) on level 6 one would need values from step 2 of level 5 which at this point have not yet been calculated, resulting in poison (or old values) being prolongated into the slice. --8<-- Essentially the time interpolation part of prolongation fails during ANALYSIS (so computing only every_coarse is almost fine [no restriction from fine to coarse happens]).
Is there a way to solve this other problem perhaps?
No idea.
Yours, Roland