[Users] Schedule change in Exact.

Roland Haas roland.haas at physics.gatech.edu
Tue May 4 15:36:10 CDT 2010


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

-- 
My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from http://keys.gnupg.net.


More information about the Users mailing list