[Developers] New schedule bin PostPostInitial?

[Baiotti Luca]

Hallo David,

David Rideout wrote:
> Adding a new schedule bin will solve this problem in the short term,
> however I have some reservations.
> The Cactus 4 scheduler was designed to prevent this very problem -- a
> proliferation of schedule bins.  In Cactus 3, I understand, the number
> of schedule bins increased without bound, with names not so unlike
> this one.  In principle, in Cactus 4, we should be able to get by with
> a single schedule bin, and use before and after to order our routines.
>  In practice schedule bins are useful in simplifying the task of
> ordering routines.  

what you state is true for PUGH, but not for Carpet. In Carpet imposing 
the wanted scheduling of local-level-global routines is sometimes tricky 
and, even if it is possible to achieve the wanted result with some extra 
code (which explicitly switches from local to global mode and viceversa) 
in the user routines, it is much easier and much more straightforward 
and much more user-friendly to determine the schedule with cactus bins.

I feel that we should think carefully before
> adding another bin.  Is it really necessary?  If so it should have a
> well defined need.  

I would make the opposite proposal (I don't know about Cactus 5): the 
user should be able to use as many bins as she/he finds useful to 
her/him, i.e. there could be a mechanism to allow the user to create 
her/his own additional bins.


Luca


Is your alternate suggestion to do the recursive
> initialization before POSTINITIAL?  This makes more sense to me.  Or,
> if the new bin is really necessary, at least use a name which somehow
> describes the need, as you suggest.
> 
> I understand that with Cactus 5 we will have a script based scheduler,
> which will eliminate the need for agreement of the entire developers
> list for such design decisions...
> 
> -David
> 
> On Wed, May 21, 2008 at 3:24 PM, Erik Schnetter <schnetter at cct.lsu.edu> wrote:
>> Cactus knows two schedule bins for setting up initial data, Initial and
>> PostInitial.  With mesh refinement, both bins are currently executed on each
>> level before finer levels are initialised recursively.  There is no
>> initialisation bin that is executed after the recursive initialisation.
>>  Such a bin is necessary for certain operations, e.g. for initialising
>> Whisky's atmosphere treatment.
>>
>> I suggest to introduce a new bin PostPostInitial for this (maybe with a more
>> clever name).
>>
>> Alternatively, we can change how the existing PostInitial behaves, which
>> would then also require changes to existing thorns.  Most notably, MoL
>> schedules certain events at PostInitial, and moving these to Initial
>> requires that all thorns be checked whether they require explicit "BEFORE"
>> statements in the Initial bin to ensure that they still behave correctly
>> with respect to MoL.
>>
>> Personally, I prefer the first option since it is less invasive.  Do you
>> have better suggestions for a name for the new bin?
>>
>> -erik
>>
>> --
>> Erik Schnetter <schnetter at cct.lsu.edu>   http://www.cct.lsu.edu/~eschnett/
>>
>> My email is as private as my paper mail.  I therefore support encrypting
>> and signing email messages.  Get my PGP key from www.keyserver.net.
>>
>>
>>
>>
>> _______________________________________________
>> Developers mailing list
>> Developers at cactuscode.org
>> http://www.cactuscode.org/mailman/listinfo/developers
>>
>>
> _______________________________________________
> Developers mailing list
> Developers at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/developers
>