[ET Trac] [Einstein Toolkit] #1797: allow new timelevels to be created at runtime

[Einstein Toolkit]

#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%2FunlimitedTimelevels
 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.

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1797>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit