[Developers] Warn if grid structure changes upon recovery

[Erik Schnetter]

On Jun 3, 2010, at 15:24 , Erik Schnetter wrote:

> On Jun 3, 2010, at 13:56 , Erik Schnetter wrote:
>
>> On Jun 2, 2010, at 16:36 , Erik Schnetter wrote:
>>
>>> Ian
>>>
>>> Thanks for the discussion in the chat; this was a good  
>>> brainstorming session.  The enclosed patch to CarpetIOHDF5  
>>> introduces two parameters:
>>>
>>> use_process_decomposition_from_checkpoint re-uses the stored  
>>> process decomposition if possible, which should avoid having to  
>>> read data from checkpoint files from other processes.
>>>
>>> warn_if_process_decomposition_differs_from_checkpoint compares the  
>>> stored and the recreated grid structures, and warns if there is a  
>>> difference.
>>>
>>> The patch builds, but is untested otherwise.  Consider it a  
>>> suggestion that may help finding the cause of and/or a remedy for  
>>> the slow recovery.
>>
>> Ian
>>
>> Here is an updated version of the patch that also handles the  
>> regrid_in_level_mode case (which is the more important case).
>
> Ian
>
> I attach another tentative patch to save/load the tree structure  
> that describes the process decomposition.  This patch adds input and  
> output methods for the tree data structure -- the idea is simple,  
> the implementation a bit tedious since the tree structure has to be  
> parsed from a string.
>
> This essentially modifies the checkpoint file format, since the  
> format of the grid hierarchy changes.  Old checkpoint files can't be  
> read in.  (We can make this backward compatible later.)


Ian

Here comes another patch to CarpetLib that also modifies the region_t  
reader/writer routines to actually make use of the tree reader/writer  
routines.

-erik

-- 
Erik Schnetter <schnetter at cct.lsu.edu>   http://www.cct.lsu.edu/~eschnett/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: CarpetLib.diff
Type: application/octet-stream
Size: 5857 bytes
Desc: not available
Url : http://www.cactuscode.org/pipermail/developers/attachments/20100603/3f5c1518/attachment.obj