[Users] Schedule change in Exact.
Erik Schnetter
schnetter at cct.lsu.edu
Tue May 4 17:06:41 CDT 2010
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
--
Erik Schnetter <schnetter at cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/
More information about the Users
mailing list