Possible issue in TmunuBase with support_old_CalcTmunu_mechanism=no

Create issue
Issue #1106 closed
Wolfgang Kastaun created an issue

I think the schedule of the AddToTmunu should be changed from

SCHEDULE GROUP AddToTmunu IN SetTmunu AFTER TmunuBase_SetTmunu


SCHEDULE GROUP AddToTmunu IN SetTmunu AFTER (TmunuBase_SetTmunu TmunuBase_ZeroTmunu)

since with support_old_CalcTmunu_mechanism=no, Tmunu is initialised by TmunuBase_ZeroTmunu and not by TmunuBase_SetTmunu. Otherwise, it could happen that thorns add to undefined value and afterwards Tmunu is set to zero. This did not happen to me yet, but probably only by luck.


Comments (6)

  1. Roland Haas
    • changed status to open
    • removed comment

    yes it should be changed. Right now you are safe since Cactus implictely schedules items in the order in which they appear in schedule files unless instructed otherwise.

  2. Erik Schnetter
    • removed comment

    I believe Cactus happens to schedule items in alphabetical order, not in the order in which they are listed in schedule.ccl.

  3. Roland Haas
    • removed comment

    Nono. I had to check this recently, remember. The scheduling is such that the flesh processes the schedule.ccl files for each thorn in alphabetical order (since this is the order in which thorns are initialized) of the thorn names (hence the alphabetical) but within each schedule.ccl file (and hence within each thorn), the order is (initially, before BEFORE/AFTER are enforced) given by the order in which the statements appear (see discussion in http://cactuscode.org/pipermail/users/2012-July/003163.html and eg the schedule that results from TmunuBase where TmunuBase_Zero is not the last item appearing in Cactus' schedule output even though it is alphabetically after TmunuBase_AddTmunu).

    schedule.ccl are translated almost verbatim (or at least one could treat SCHEDULE and STORAGE as some funny macros) into C code in Cactus/configs/configname/bindings/ScheduleThornName.c and the schedule sorter itself never looks at routine names.

    If you want alphabetical ordering, try Cactus::schedule_sort_mode = "ascending" (or "descending" for reverse alphabetical ordering).

  4. Roland Haas
    • removed comment

    Oh I apparently never committed my previous comment: In the development version (trunk) this has been fixed in rev 16 of TmunuBase. Should we push this into the release version as well (as said, it currently, magically works and I believe it is also save since the current sorting algorithm is stable so will not change the order of schedule elements unless there are BEFORE/AFTER statements)?

  5. Frank Löffler
    • changed status to resolved
    • removed comment

    We don't need to touch a previous release if it works as is. It might break if another default order is requested, but then all hell might probably break loose anyway; currently this is asking for trouble, unfortunately. Plus, the next release isn't that far into the future. I am closing this ticket.

  6. Log in to comment