[Users] Evolving grid arrays using MoL

[Ian Hinder]

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?

> 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?

-- 
Ian Hinder
http://numrel.aei.mpg.de/people/hinder

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20131016/3ef7e62d/attachment.html 
-------------- 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/3ef7e62d/attachment.bin