[Users] Evolving grid arrays using MoL

Wed Oct 16 09:22:13 CDT 2013

On 2013-10-16, at 9:09 , Ian Hinder <ian.hinder at aei.mpg.de> wrote:

> On 7 Oct 2013, at 19:34, Erik Schnetter <schnetter at cct.lsu.edu> wrote:
> 
>> On 2013-10-07, at 12:47 , Ian Hinder <ian.hinder at aei.mpg.de> wrote:
>> 
>>> On 28 Sep 2013, at 16:17, Erik Schnetter <schnetter at gmail.com> wrote:
>>> 
>>>> Yes, this (i.e. the work-around of scheduling the RHS in level mode, and then only actually executing the routine if this corresponds to global mode) is how I made things work. I haven't tried this recently, though. Maybe a test case would be in order...
>>>> 
>>>> Rather straightforward changes to MoL should allow scheduling the RHS in global mode as well, which would then work elegantly. This would probably require to duplicate MoL's integration logic, so that grid functions are integrated in level mode while grid arrays are integrated in global mode.
>>> 
>>> Is the problem that the grid arrays are not available in global mode, but they are available in level mode?  Or is there some other reason that global mode cannot be used?  When I try to call the interpolator in MoL_CalcRHS in level mode, I get
>>> 
>>> Assertion failed: (not (not want_global_mode and num_time_derivs.AT(m) == 0 and need_time_interp.AT(m))), function interpolate_components, file /Users/ian/Cactus/arrangements/Carpet/CarpetInterp/src/interp.cc, line 1353.
>>> 
>>> This is with InterpNumTimelevels = 1 in the interpolator parameters.  I dug around in interp.cc, and came across the interpolation parameter want_global_mode.  Setting this to 1 seems to allow the interpolation to succeed, but I don't know if this will break in certain situations.  What does this interpolator parameter do?
>>> 
>>> My problem with registration turned out to be that I was trying to register MoL for grid SCALARs, not grid ARRAYs.  A vector of grid arrays seems to work.
>> 
>> 
>> Grid arrays are available in global mode (and also in level, singlemap, and local mode).
>> 
>> Global mode cannot be used because MoL will still try to evolve them in level mode, i.e. more often. One needs to ensure that grid arrays have a non-zero RHS exactly on the finest grid. Global mode may be equivalent to the coarsest grid, which would then evolve with the wrong step size.
>> 
>> Yes, one cannot interpolate in level mode if this requires data from coarser levels. This is just what level mode means -- access data from the current refinement level only.
> 
> I don't follow this logic.  In global mode, one can call the interpolator, even though there is no access to any data.  CarpetInterp doesn't contain any macros that I can see for changing mode, and yet it calls functions for accessing data and sending it between processes. So it looks like CarpetInterp doesn't care much about the concept of modes.  If I can call it in global mode, naively I don't see why I can't also call it in level mode and access data from the other levels.  What is there that prevents this?

CarpetInterp certainly could interpolate from all levels; the question is what the user most likely wants, and to catch errors.

In level mode, the user most likely wants to operate on (and access) the current level only. Instead of interpolating from multiple levels, CarpetInterp assumes that it should interpolate only from the current refinement level. We later decided that interpolating from a single level wasn't a useful idea, and thus disabled it to catch more errors.

Global mode doesn't mean "cannot access grid functions"; it means "access all refinement levels of grid functions", as in "don't restrict yourself to a single level". As a by-product, one cannot define "pointer to THE grid function" since "THE" doesn't make sense. Thus pointers to individual grid functions are set to null in scheduled routines.

Yes, you probably want to use this interpolator parameter.

>> Is there a mode "global-finest"? This should work. Or maybe "global-late" for evolution, since finest grid are evolved last? Yes, I think this should work.
> 
> In unigrid, level mode appears to work.  I haven't tried with refinement yet.
> 
> I have also tried global-late, but this does not work.  With RK4, MoL_CalcRHS should be called four times, with cctk_time = (t^n, t^{n+1/2}, t^{n+1/2}, t^{n+1}) respectively.  However, the first time it is called, it has cctk_time = 0, which is wrong.  Calls to the interpolator lead to NaNs, which I also don't understand.
> 
> If I call it in level mode instead, then cctk_time is correct and the interpolator returns sensible-looking values.  MoL_SetTime is called in level mode; is this related to the problem?

Likely yes. MoL modifies the current level's cctk_time, and not the global time. (Each level has its own time, and there is also a "global time" that corresponds to cctk_iteration * finest_delta_time.)

If MoL knew about global mode, and used it for grid arrays, then it would also need to modify the global time.

-erik

-- 
Erik Schnetter <schnetter at cct.lsu.edu>
http://www.perimeterinstitute.ca/personal/eschnetter/

My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from http://pgp.mit.edu/.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20131016/d11c394a/attachment.bin 