[Carpet] Regridding & Recomposing

[Erik Schnetter]

On Jan 16, 2007, at 12:38:51, Bela Szilagyi wrote:

> Erik,
>
> it seems that your definitions for Regridding & Recomposing, in  
> combination
> with Carpet::CallRegrid() give no scheduling of the POSTREGRID bin  
> in certain
> cases where maybe it should.
>
> From what I see, the return value of the Regrid function is set to  
> "true" when
> requesting a decrease in the number of refinement levels.

There are two functions, Regrid and Recompose.  Regrid is a global  
function which determines the new grid structure.  It does not  
actually change the grid structure, it only decides how the new grid  
structure should look like.  This function returns true if the grid  
structure should be changed, not if the number of levels should  
decrease.  This return value is not actually needed -- Carpet could  
instead compare the old and the new grid structures, but the return  
values simplifies life.

The function Recompose is called for a certain refinement level.  It  
actually changes this refinement level according to a pre-determined  
new grid structure.  The Recompose function should be called from  
coarsest to finest level, so that newly created fine regions can be  
filled by prolongation from coarser levels.  (The proper nesting  
property guarantees that this is always possible.)  Recompose returns  
whether this level was actually changed.  Thus the postregrid bin can  
be skipped if the grid did not actually change, which is an important  
optimisation.

>   Also, the
> Recompose() routine appears to return "true" only if the grid  
> definition on a
> particular level has changed.

Correct.

>   You only schedule POSTREGRID if both
> "did_regrid" and "did_recompose" is set to "true".  Which means  
> that when I
> request a change (decrease) in the levels, but no change within any  
> of the
> levels themselves, there will be no scheduling of POSTREGRID.

After writing my explanation above I understand what you mean with  
"decrease".  You want to deactivate a level.  In this case, the  
regridding routine should return a grid structure with fewer levels  
in it, in addition to returning "true".  Deactivating a grid should  
certainly be treated as any other change to the grid hierarchy, and  
the postregrid bin should be called.

What mechanism are you using to deactivate levels?  It could be that  
this mechanism doesn't work properly.  Can you check the grid  
structure that is set up by the regridding routine?

> I would suggest that we treat the case
>
> did_regrid = (not did_recompose) = true
>
> slightly differently.
>
> We could schedule POSTREGRID either on all grids or on the new  
> finest grid
> after having changed the nr of levels.
>
> Also, if did_recompose is true on level L < max_reflevels, wouldn't  
> it be
> safer (and reasonable) to call POSTREGRID on all finer levels as  
> well, rather
> than only on level L?  (Perhaps the logic within Recompose() will  
> ensure this
> already.)

The postregrid bin should always be called on all levels.

-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/20070122/bba0e087/attachment.pgp