Hello Eloisa,
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?).
Not really. WeylScal4 is the only I use that schedules in PseudoEvolution. If a routine does only purely pointwise algebraic operations (a lot of our Hydro analysis thorns do) then scheduling in ANALYSIS would be best I think (happens after restriction, regridding etc are done, so only one call is needed). WeylScal is in PseudoEvolution since it takes derivatives and therefor has to be in Evol for prolongation to work properly (b/c of the order in which coarse and fine level routines end up being called in EVOL and ANALYSIS for the same cctk_time).
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?
Anything that does something like BSSNtoADM [if it did not happen in MoL_Poststep] uses the evolved BSSN variables but is still part of the evolution I would think since for routines outside of the BSSN evolution the ADM variables look like the "evolving" variables.
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?
Sorry, I was not clear enough it seems. My point is that routines that are algebraic and pointwise normally (should) do not need boundary/symmetry conditions since they should inherit them from their sources (assuming the routine runs after boundary conditions have been applied to the sources). Eg. BSSNtoADM does not need SYNC's if it runs after the boundaries have been applied to the BSSN variables [please correct me if I have this wrong]. Similarly for a simple Con2Prim routine for a hydro thorn.
Copying in postrestrict is fine (I think). Currently it would not happen since PseudoEvolution is not scheduled in the postrestrict bins.
Yours, Roland