[ET Trac] [Einstein Toolkit] #620: Simplify timelevel handling for Cactus thorn writers

Einstein Toolkit trac-noreply at einsteintoolkit.org
Mon Dec 12 14:10:38 CST 2011


#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?

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


More information about the Trac mailing list