[Developers] New schedule bin PostPostInitial?

[David Rideout]

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.  I feel that we should think carefully before
adding another bin.  Is it really necessary?  If so it should have a
well defined need.  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
>
>