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.
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.
Yours, Roland
Yours, Roland