[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:  review             
  Priority:  optional     |   Milestone:                     
 Component:  Cactus       |     Version:  development version
Resolution:               |    Keywords:  Cactus Carpet PUGH 
--------------------------+-------------------------------------------------

Comment (by rhaas):

 Replying to [comment:2 eschnett]:
 > What happens during time level cycling? Currently, grid variables with
 one time level remain unchanged, whereas variables with more than one time
 level become invalid during time level cycling.
 The patches introduce no new behaviour. Maybe I was not clear enough: What
 the proposed patches actually do is make the flesh ignore the TIMELEVELS
 attribute in interface.ccl in the EnableStorage calls.

 The described issue of a variable going from not changing to changing
 already happens currently with eg  a TIMELEVELS=2 variable whose
 schedule.ccl says STORAGE: foo[1] and where the user later calls
 EnableStorage during runtime.

 > I suggest to change this behaviour so that every grid function remains
 defined at its current value during time level cycling. This will then
 avoid the need to copy the past to the current time level, which is the
 first step of every time integrator.
 This would basically amount to moving the InitialCopy routine out of MoL
 and into the driver, just after it cycled timelevels, wouldn't it?  Or are
 you suggesting a more invasive change that couples the time stepper and
 the driver more tightly?

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