allow zero timelevels in STORAGE when timelevels are specified via parameter

Create issue
Issue #675 closed
Roland Haas created an issue

this allows to simply set timelevels=0 to turn off storage without having to put an "if(do_something || timelevels > 0)" into schedule.ccl files. It is also the only way to turn off storage inside of a GROUP of SCHEDULE statement based on a condition (other than scheduling the item twice, once with STORAGE, once without).

More complicated conditions require either (I believe): a. the (ab)use of accumulors the way that GRHydro::GRHydro_hydro_excision works (only all "and" or all "or" supported I think) a. using undocumented behaviour and putting C code into schedule.ccl

const int compound_condition = condition_a || condition_b ? 3 : 2
SCHEDULE
{
  STORAGE foo[compound_condition]
...

c. allow more than just identifiers within the '[]" brackets of STORAGE (most likely one has to allow almost everything "[^]]+") then use C's "?" operator to build up the complicated expression

Having 0 timelevels works trivially since eventually these STORAGE statements end up in CCTK_GroupStorageIncrease which allows 0 timelevels.

Keyword:

Comments (5)

  1. Erik Schnetter
    • removed comment

    One issue you didn't mention is that the storage declarations in schedule.ccl do not SET the storage, they only ever INCREASE storage. That is, if storage would be decreased, the statements do nothing instead.

    With this in mind, are your ideas still applicable? (I think so.)

    If so, please apply. Please check also whether the documentation needs to be updated.

  2. Roland Haas reporter
    • removed comment

    True. This is what I need actually. I expect to have a global STORAGE foo[persistent_timelevels] and a SCHEDULE local STORAGE foo[temporary_timelevels] in a compute-grid-frunction-then-reduce-to-get-a-volume-integral setup (specifically variations of Tanja's TotalMass routines). Each of these calculations is wrapped inside of a GROUP with STORAGE statements attached to the group. One group contains a routine that can potentially compute two grid functions so the only way I see to not allocate storage for both grid functions when only one is needed are these zero-timelevels parameters (combined with option b. above. I am not sure if I find b. or c. less horrible).

    It would still be applicable I think.

    I cannot apply it myself since it affects the flesh for which I don't have write permissions. I will update the patch to include some documenation updates mentioning where parameters and explicit timelevel specification differ (a STORAGE[number] is still restricted to 1 <= number <= max_timelevels, by design).

  3. Log in to comment