[Carpet] Changes to regridding

[Bela Szilagyi]

Yet another related issue --

I find it slightly inconvenient that Carpet schedules "PostRegrid" at recovery 
the same way as when a true (during-evolution) regridding was done.

Not mentioning that it is possible to get core dumps by trying to change the 
grid-structure at recovery, the major issue I have is:  could we call the 
recovery group some other name, say "PostRegridAtRecovery".  The same would 
hold for "PreRegrid"...


On Sunday 30 April 2006 15:41, Christian David Ott wrote:
> Hi Bela,
>
> regridding via parameter steering is certainly possible,
> but does lead to problems like the ones you describe.
>
> For progressive mesh refinement (PMR) in hydro simulations I use the
> built-in capability of CarpetRegrid to call an outside function to inquire
> the number of refinement levels that should be active. This is the safest
> way if you just want to switch levels on and/or off. You can use this
> feature by saying
>
> CarpetRegrid::activate_levels_on_regrid = "function"
>
> and writing a Thorn that implements the function "RegridLevel" and
> provides it via function aliasing to CarpetRegrid (see CarpetRegrid's
> interface.ccl for the function prototype). You are free to implement
> RegridLevel in any way and in any thorn you want.
>
>   - Christian
>
> On Fri, 28 Apr 2006, Bela Szilagyi wrote:
> > I have a few questions.
>
> I assume that regridding is requested by setting certain Carpet parameters.
> Given that I am interested in changing the number of refinement levels
> (e.g., drop the finest level once I've got one big black-hole), in a
> global-mode scheduled routine in PreRegrid I set, via CCTK_ParameterSet,
> the following:
>
> CarpetRegrid::regrid_every = 1
> CarpetRegrid::num_new_levels = -1
> CarpetRegrid::activate_levels_on_regrid = fixed
> CarpetRegrid::activate_next =  cctk_iteration-10
>
> then wait for the next postregrid event, where I set the first three of
> these to whatever they were before (in my case their default value).
>
> The scheme works sometimes, but in a number of occasions carpet schedules
> the bin PostRegrid without having changed the number of levels.
>
> The questions are:
>
> 1) I am doing thins "correctly" (have set the right params, should be
> indeed done in global mode as regridding is done in BHTracker, etc.)
>
> 2) how can one know whether Carpet has indeed honored the request or that I
> should wait for the next pregrid event for resetting those three parameters
> to their original values.
>
> Note, knowing the finest level structure is important for me, for, with my
> excisionalgorithm, I cannot create one big excision region while I have a
> finest grid that does not contain it.
>
> Bela.
>
> On Monday 17 April 2006 16:40, Erik Schnetter wrote:
> > We are currently working on making regridding in Carpet more
> > flexible.  Christian Ott and myself have just pushed a patch that
> > introduces a new schedule group "PreRegrid".  This one is similar to
> > "PostRegrid", except that it is execute before Carpet regrids, so
> > that thorns can choose the new grid structure there.
> >
> > Obviously, this change can potentially introduce some instability
> > into Carpet.  You should be safe if you do not use dynamic
> > regridding.  If you do use dynamic regridding, please report any
> > problems.
> >
> > Note "PreRegrid" is a schedule group, not a schedule bin.  This is
> > necessary since introducing new bins requires changes to the flesh,
> > whereas introducing new groups can be done by each thorn.
> >
> > -erik

-- 
Bela Szilagyi
----------------------------------------------------
Max-Planck-Institut für Gravitationsphysik
Albert-Einstein-Institut
Tel: +49 331 567 7632
Fax: +49 331 567 7649
----------------------------------------------------