[Users] Schedule change in Exact.

[Eloisa Bentivegna]

Roland Haas ha scritto:
> Hello all,
> 
>> Would this function be a good candidate for the MoL_PseudoEvolution 
>> group?  That group is intended for routines which "fake" an 
>> evolution, or more generally set grid functions which require the 
>> ghost and refinement boundary points to be filled correctly on 
>> regridding etc.
> I have used Exact in a couple of the testsuites and I think moving Exact
> to Pseudoevolution (I think it fits the description) would require
> changes to all of these parameter files. Currently anything that runs in
> PostStep or PseudoEvolution itself runs after Exact, which is what we
> want, since Exact should behave just like an evolution thorn. While
> scheduling in PreStep is not perfectly equivalent to a real evolution,
> it would seem to cause fewer problems since only routines in MoL_PreStep
> and the ones inside of MoL's substep loop see anything different (namely
> the updated variables).
> If Exact itself moves to PseudoEvolution then one needs extra schedue
> statements to enforce the proper ordering.

Ian, Roland,

thanks for all the suggestions. I'm looking at the use of 
PseudoEvolution in my source tree and I see that some "analysis" 
functions are also scheduled in it (I looking, for instance, at 
ML_ADMConstraints). That, I guess, is one of the cases where scheduling 
Exact__initialize in this bin, without adding further constraints in the 
other functions scheduled here, would lead to incorrect behavior 
(Roland, do you have other examples?).

I would have thought, however, that any function that assumes that the 
evolution step has completed (such as one calculating the constraints) 
should be held until after pseudoevolution has completed. So 
PseudoEvolution does seem like the right place to schedule 
Exact__initialize, and if it breaks the tests it's only because of 
functions which shouldn't belong to this bin anyway. Any comments?

> I would also like to propose to schedule PseudoEvolution in PostRestrict
> after mol poststep so that it picks up any changes in variables that
> come from restriction (only important in the outer boundaries I think).
> Eg. a thorn copying say gxx into a second grid function GXX would either
> have to schedule boundary routines in Postrestrict (even though the copy
> operation itself is purely algebraic and pointwise) or would need to run
> after gxx has been restricted and the newly restricted values used to
> populate the outer and symmetry boundaries. WeylScal4 (which computes
> derivatives so needs boundary conditions anyway) had to do something
> like this.

I'm not sure I understand this point. In your example, what's wrong with 
having the copy happen at postrestrict, like you say?

Eloisa