[Users] Schedule change in Exact.

[Roland Haas]

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

-- 
My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from http://keys.gnupg.net.