[ET Trac] [Einstein Toolkit] #1473: Carpet segfaults in Shutdown

Einstein Toolkit trac-noreply at einsteintoolkit.org
Thu May 1 15:16:44 CDT 2014


#1473: Carpet segfaults in Shutdown
---------------------+------------------------------------------------------
  Reporter:  knarf   |       Owner:  eschnett           
      Type:  defect  |      Status:  new                
  Priority:  minor   |   Milestone:                     
 Component:  Carpet  |     Version:  development version
Resolution:          |    Keywords:                     
---------------------+------------------------------------------------------

Comment (by rhaas):

 I just ran a quick test with PUGH with a parfile like this:
 {{{
 ActiveThorns = "PUGH IOUtil IOHDF5 Debug IOASCII PUGHSlab"

 Cactus::cctk_itlast = 1

 IO::checkpoint_id = yes
 IOHDF5::checkpoint = yes

 IO::checkpoint_dir = "cppugh"
 IO::out_dir = $parfile

 debug::gasize = 12

 IOASCII::out1d_every = 1
 IOASCII::out1d_vars = "Debug::array"
 }}}
 where the Debug thorn provides a 1d array whose size is controlled by
 gasize. I then comment out
 {{{
 debug::gasize = 12
 }}}
 for recovery (the default is 3). PUGH behaves the same way that Carpet
 does. After recover the grid array has size 3 while the parameter gasize
 is recovered as size 12.

 If we want to allow the possibility to change an array size during
 recovery, then we need to make sure that CP_RECOVER_PARAMETERS happens
 before the groups are created (which is very early I think). In particular
 this means that the recovery code (and any thorns that it depends on) may
 not assume that their grid functions exist (or at least they are not yet
 fully created) until after CP_RECOVER_PARAMETERS.

 Carpet cannot just resize the grid arrays after recovery since it no
 longer knows which sizes are affected by parameter changes.

 The alternative is what Erik mentioned: to checkpoint the size of (all,
 not just the checkpoint=yes) arrays and re-instantiate them with this size
 in which case Carpet can resize them (since the information is part of
 GroupDynamicData which the driver controls) but which does not allow them
 to change at recovery time.

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


More information about the Trac mailing list