On May 4, 2010, at 15:10 , Eloisa Bentivegna wrote:
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 don't think MoL_PseudoEvolution is the right schedule bin for Exact, for two reasons:
- when thorn Exact is used to evolve, thorn MoL will not be active, hence the bin won't be there - as someone (Eloisa?) mentioned, other thorns in MoL_PseudoEvolution assume that the main evolution (providing the spacetime and/or hydro) is done, so that they can access the ADM variables there
The first point could be solved by moving PseudoEvolution to a different thorn, e.g. a driver, or to the flesh itself.
The second point could (and maybe should) be solved by having markers in PseudoEvolution that state when the ADM and/or hydro variables are available, and always schedule your analysis routines with respect to these markers. (This would mimic SphericalSurface.)
At the moment, I would schedule Exact in EVOL (or PRESTEP).
-erik