- changed status to open
- removed comment
allow zero timelevels in STORAGE when timelevels are specified via parameter
Issue #675
closed
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)
-
reporter
-
- 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.
-
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).
-
- changed status to resolved
- removed comment
I committed the second patch.
-
reporter
- edited description
- changed status to closed
- Log in to comment
