Size of the 2-D Grid

Because of the isometry condition (D13.13), the 2-D grid need only cover the region $\eta \ge 0$; the code just takes the absolute value of $\eta$ before interpolating.

The 2-D grid covers the region $\vert\eta\vert \in [0,\texttt{etamax}]$, $\theta \in [0,\pi]$, where the parameter etamax defaults to 5. If any 3-D grid point's $(\vert\eta\vert,\theta)$ is outside this 2-D grid, this thorn will abort with a fatal error message from the interpolator. In practice, the most common cause of such an out-of-range point is the 3-D grid having a grid point at, or very near to, the origin. For example:

WARNING level 1 in thorn AEILocalInterp processor 0 host ic0087 (line 1007
of /nfs/nethome/pollney/runs/CactusDev/arrangements/AEIThorns/AEILocalInterp/src
/Lagrange-tensor-product/../template.c):
  ->
   CCTK_InterpLocalUniform():
        interpolation point is either outside the grid,
        or inside but too close to the grid boundary!
        0-origin interpolation point number pt=307062 of N_interp_points=614125
        interpolation point (x,y)=(36.1875,0.955317)
        grid x_min(delta_x)x_max = -0.0199336(0.0199336)6.01993
        grid y_min(delta_y)y_max = -0.0290888(0.0581776)3.17068

WARNING level 0 in thorn IDAxiBrillBH processor 0 host ic0087
  (line 484 of IDAxiBrillBH.F):
  -> error in interpolator: ierror=   -1002

Here the 3-D grid had a point right at the origin (which by virtue of (D13.5) would have given $\eta = -\infty$), but some software moved the grid point by $10^{-16}m$ or so (the standard Cactus work-around to try to avoid divisions by zero), giving $\eta \equiv \ln (2 \,{\times}\, 10^{-16}) \approx -36$. The absolute value of this is the ``$x$'' coordinate the interpolator is complaining about.

In an ideal world, someone would enhance IDAxiBrillBH so it could handle a grid point at (or very near to) the origin.^part332 However, so far noone has volunteered to do this.

In the meantime, a staggered grid is the ``standard'' work-around for this problem.