PunctureTracker: add READS to workaround poison for puncture arrrays

[lwJi]

PunctureTracker has array of 10 elements to store punctures by default.
Without READS, those inactive elements will be set to nan by the poison mechanism.

[lwJi]

@rhaas80 I removed the change in schedule.ccl and write those inactive elements instead to workaround CarpetX poison mechanism

[rhaas80]

I took a look at BoxInBox's interface.ccl and it reads:

CCTK_REAL positions[3] TYPE=scalar
{
  position_x position_y position_z
} "Positions of refined regions"

meaning that writing to any position_x[n] with n>2 will cause a SEGFAULT (or at least write to memory it should not write to).

This is a general bug with the code in PunctureTracker.

Since it's not in the ET, I officially don't care. However it cannot be added to the ET in this form yet.

[rhaas80]

it's a horrible workaround and cannot in this form be merged into the official ET code base.

In a private repo though: it will get the job done.

[lwJi]

I took a look at BoxInBox's interface.ccl and it reads:

CCTK_REAL positions[3] TYPE=scalar
{
  position_x position_y position_z
} "Positions of refined regions"

meaning that writing to any position_x[n] with n>2 will cause a SEGFAULT (or at least write to memory it should not write to).

This is a general bug with the code in PunctureTracker.

Since it's not in the ET, I officially don't care. However it cannot be added to the ET in this form yet.

What do you mean by 'a general bug with PunctureTracker'? If it is, I can fix it.

[rhaas80]

What do you mean by 'a general bug with PunctureTracker'? If it is, I can fix it.

PunctureTracker currently does:

    for (int n = 0; n < nPunctures; ++n) {
      CCTK_VINFO("Writing punc coords to box %d.", n);
      position_x[n] = location[0][n];
      position_y[n] = location[1][n];
      position_z[n] = location[2][n];
    }

so if nPunctures > 2 it will write to non-existent position_x elements. As written right now, nPunctures must be at most 3 (and currently it could go up to 10 given PunctureTracker's param.ccl, can it?).

[lwJi]

What do you mean by 'a general bug with PunctureTracker'? If it is, I can fix it.

PunctureTracker currently does:

    for (int n = 0; n < nPunctures; ++n) {
      CCTK_VINFO("Writing punc coords to box %d.", n);
      position_x[n] = location[0][n];
      position_y[n] = location[1][n];
      position_z[n] = location[2][n];
    }

so if nPunctures > 2 it will write to non-existent position_x elements. As written right now, nPunctures must be at most 3 (and currently it could go up to 10 given PunctureTracker's param.ccl, can it?).

Very good. I add assert(nPunctures <= 3) // BoxInBox currently hardcodes position[3] when we are using BoxInBox