#620: Simplify timelevel handling for Cactus thorn writers --------------------------+------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by eschnett):
I believe this could be implemented in the following way:
1. In addition to the flesh function MaxTimelevels that returns the maximum number of timelevels, we add a SetMaxTimelevels that allows increasing the maximum number of timelevels for a group. We probably don't want to allow decreasing this number, because some code may cache this number (maybe implicitly in the CCTK_ARGUMENTS bindings). This would not actually allocate memory, it only increases the maximum. The flesh provides a data structure cGH->data which contains pointers to all timelevels of all grid variables; this data structure needs to be resized (and the new elements initialised) in this function.
2. The driver functions that modify the number of active timelevels call SetMaxTimelevels if necessary before they allocate storage. If a driver does not do this, the behaviour remains as is at the moment.
3. The drivers that allow increasing this number will also have to checkpoint and restore this value while checkpointing. It seems that the checkpointing data format does not need to be changed; increasing the maximum to the number of timelevels found in the checkpoint file seems fine.
This data structure is set up in CactusDefaultSetupGH (file Comm/CactusDefaultComm.c).
The maximum number of timelevels per group is stored in the field n_timelevels of struct cGroupDefinition, which is declared privately in main/Groups.c, and can be read via MaxTimelevels.
Does this sound reasonable?