Hi Ian,

thanks for the quick reply.

SCHEDULE WorldTubeExtract_TEST AT CCTK_INITIAL AFTER WorldTubeExtract_RegisterSlices {   LANG: C   OPTIONS: LEVEL } "TEST"

Also the output of Carpet::is_global_mode() is 0 so definitely not in global mode.

Cheers,

Chris

On 11/03/2017 10:12 AM, Ian Hinder wrote:

On 3 Nov 2017, at 09:06, Chris Stevens <c.stevens@ru.ac.za mailto:c.stevens@ru.ac.za> wrote:

...

Hi all,

this hopefully is a dumb question, but I cannot for the life of me get access to the x,y,z,r coordinates defined in CartGrid3D.

Suppose I have a thorn X that wants to access these coordinates from test.cc http://test.cc, then the thorn should inherit: grid, the .cc should #include "cctk_Arguments.h" and the line that accesses, say x[0], should be called after DECLARE_CCTK_ARGUMENTS.

Unfortunately doing this results in an error:

[maths02:86267] *** Process received signal *** [maths02:86267] Signal: Segmentation fault (11) [maths02:86267] Signal code: Address not mapped (1) [maths02:86267] Failing at address: (nil)

Which is analogous to the error message you get by defining a grid variable in interface.ccl without the accompanying STORAGE: in schedule.ccl, i.e. the memory is not allocated.

I am using Llama as my coordinate system, but I know this basically is a wrapper for CartGrid3D and these coordinates are still set. I see the printout from CartGrid3D.

I try to access these coordinates at, for example, CCTK_INITIAL, when the grid structure is already setup. I have also tried later time bins such as CCTK_POSTSTEP.

Example files that access these coordinates are:

CTGBase::debug.cc http://debug.cc

ADMDerivatives::calc_derivs.cc

Coordinates::cylinderinbox.cc http://cylinderinbox.cc

However I am not having any luck reverse-engineering these.

Any ideas would be appreciated.

Hi,

Thanks for the detailed report!

What mode are you calling your function in?  i.e. can you show us the block in schedule.ccl that schedules your function?  If it is not local mode (the default), then you won't be able to access any grid data, and you will get a segfault.

-- Ian Hinder http://members.aei.mpg.de/ianhin

Yes that has done the trick!

And you have also made me feel better as well, knowing it wasn't just me....

Chris

On 11/03/2017 11:27 AM, Ian Hinder wrote:

On 3 Nov 2017, at 09:22, Chris Stevens <c.stevens@ru.ac.za mailto:c.stevens@ru.ac.za> wrote:

...

Hi Ian,

thanks for the quick reply.

SCHEDULE WorldTubeExtract_TEST AT CCTK_INITIAL AFTER WorldTubeExtract_RegisterSlices {   LANG: C   OPTIONS: LEVEL } "TEST"

Also the output of Carpet::is_global_mode() is 0 so definitely not in global mode.

Hi,

The problem is that it is in level mode ("OPTIONS: LEVEL").  Level mode is called once per refinement level, and on each refinement level, there may be multiple components (rectangular blocks of grid points).  A function scheduled in level mode can access quantities which are defined on a given refinement level (or, for example, call interpolation or reduction functions for that level), but not those that are defined on a given component, for example accessing grid data like gridfunctions.  When you schedule a function in local mode ("OPTIONS: LOCAL"), it is called once per component, and then you can access grid data.

I spent hours recently trying to track down exactly this problem!

-- Ian Hinder http://members.aei.mpg.de/ianhin