#1797: allow new timelevels to be created at runtime --------------------------------+------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Keywords: Cactus Carpet PUGH | --------------------------------+------------------------------------------- The set of patches in
https://bitbucket.org/cactuscode/cactus/branch/rhaas%2FunlimitedTimelevels https://bitbucket.org/cactuscode/cactuspugh/branch/rhaas%2FunlimitedTimeleve... https://bitbucket.org/eschnett/carpet/branch/rhaas%2FunlimitedTimelevels
extend the flesh and the PUGH and Carpet drivers such that user thorns can enable more timelevels than the TIMELEVELS attribute in interface.ccl specifies.
This separates the number of {{{_p}}} and {{{_p_p}}} etc. variables, which continues to be controlled by interface.ccl's TIMELEVELS attribute, from the number of timelevels that are accessible via {{{CCTK_VarDataPtr()}}}.
This means that evolution thorns can ask for only ask many timelevels as they need for their own evolution algorithm (so 2 of MoL based thorns) and don't have to worry about how many timelevels Carpet may require for time interpolation. Similarly some MoL evolution methods (for example AB type methods) require multiple past timelevels of the RHS variables which MoL can enable by its own when using this functionality.
Their should be very little user visible changes, mostly since few thorns actually needed to know the number of timelevels. The exisiting flesh functions {{{CCTK_MaxTimeLevels}}} continue to return the value set in TIMELEVELS while new functions {{{CCTK_MaxActiveTimeLevels}}} return the maximum number of timelevels that were ever activated or {{{CCTK_MaxTimeLevels}}}, whichever is larger.
A possible improvement would be to make the existing {{{CCTK_MaxTimeLevels}}} return what {{{CCTK_MaxActiveTimeLevels}}}, yet no user code should ever need knowledge of {{{CCTK_MaxTimeLevels}}} anyway since it only ever returned the value set in {{{interface.ccl}}} so only drivers etc. should have used it to check for invalid timelevel parameters.
The downside of that approach is that it changes the meaning of an existing flesh function rather than introducing a new one and deprecating the old one. This is fine if the meaning of {{{CCTK_MaxTimeLevels}}} really is "upper bound on {{{CCTK_ActiveTimeLevels}}} that could have been seen" rather than "the value of TIMELEVELS from interface.ccl".
The patches pass all tests.