[Carpet] inefficient recovery from a checkpoint

[Erik Schnetter]

On Oct 18, 2007, at 08:46:53, Thomas Radke wrote:

> Hi Erik,
>
> while debugging a BBH run recovery problem (the run always aborted due
> to excessive memory allocation) I discovered that during recovery each
> processor would iterate through _all_ the checkpoint files to read  
> data
> from, even though the run was restarted on the same number of
> processors. Did something change in the way Carpet (the experimental
> version) sets up the grid structure ?

I am not aware of any changes that should cause this.  However, I did  
recently make changes to the HDF5 I/O routines, and I could have  
introduced an error there.  My changes added timers measuring I/O  
times and bytes transferred.

> The parameter file I used has
>
>    Carpet::regrid_during_recovery             = no
>    IOHDF5::use_grid_structure_from_checkpoint = yes
>
> in it. What's the first parameter setting good for ?

These parameters are for the development version of Carpet, or for  
old versions of the experimental version.  The first parameter  
ensures that Carpet does not use a grid structure as chosen by a  
regridding thorn to regrid.  A regridding thorn right before recovery  
would probably choose a slightly different grid structure.  The old  
regridding mechanism in Carpet would read in the base level, regrid,  
read the next level, regrid, etc., all ignoring the grid structure in  
the checkpoint file.  The new mechanism reads the grid structure from  
the checkpoint file, regrids once, and then never regrids again until  
the evolution has re-started.

-erik

-- 
Erik Schnetter <schnetter at cct.lsu.edu>

My email is as private as my paper mail.  I therefore support encrypting
and signing email messages.  Get my PGP key from www.keyserver.net.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : /archives/developers/attachments/20071018/f8a004ef/attachment.pgp