[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