unexpected "i" index in TSV output

[rhaas80]

A simple parameter file:

ActiveThorns = "
  CarpetX
  IOUtil
  TestSubcycling
"

Cactus::presync_mode = "mixed-error"

CarpetX::poison_undefined_values = yes

CarpetX::ncells_x = 8
CarpetX::ncells_y = 8
CarpetX::ncells_z = 8

CarpetX::periodic_x = yes
CarpetX::periodic_y = yes
CarpetX::periodic_z = yes

Cactus::cctk_itlast = 4

CarpetX::use_subcycling_wip = yes

IO::out_dir = $parfile
IO::out_every = 1
IO::parfile_write = no

CarpetX::out_metadata = no
CarpetX::out_tsv_vars = "
  TestSubcycling::iteration
"

leads to TSV output like this:

# 1:iteration	2:time	3:patch	4:level	5:i	6:j	7:k	8:x	9:y	10:z	11:iteration
0	0.0000000000000000e+00	0	0	-1	4	4	-1.2500000000000000e+00	0.0000000000000000e+00	0.0000000000000000e+00	0.0000000000000000e+00
0	0.0000000000000000e+00	0	0	0	4	4	-1.0000000000000000e+00	0.0000000000000000e+00	0.0000000000000000e+00	0.0000000000000000e+00
0	0.0000000000000000e+00	0	0	1	4	4	-7.5000000000000000e-01	0.0000000000000000e+00	0.0000000000000000e+00	0.0000000000000000e+00
0	0.0000000000000000e+00	0	0	2	4	4	-5.0000000000000000e-01	0.0000000000000000e+00	0.0000000000000000e+00	0.0000000000000000e+00
0

where the "i" index starts at -1, which is unexpected and not usually the case in Cactus where all indices start from 0 (different from AMReX where negative indices indicate ghost/boundary points).

[eschnett]

It seems this output is using AMReX's grid point numbering when it should be using Cactus's numbering scheme.

[rhaas80]

yup, that is my guess.