[ET Trac] [Einstein Toolkit] #181: AEILocalInterp should not off-centre the interpolation stencil by default

[Einstein Toolkit]

#181: AEILocalInterp should not off-centre the interpolation stencil by default
---------------------+------------------------------------------------------
  Reporter:  hinder  |       Owner:                
      Type:  defect  |      Status:  confirmed     
  Priority:  major   |   Milestone:                
 Component:  Cactus  |     Version:                
Resolution:          |    Keywords:  AEILocalInterp
---------------------+------------------------------------------------------

Comment (by hinder):

 Erik: This is unigrid, so I think there is no difference between vertex
 and cell centring.  Does your question relate to whether the upper or
 lower boundary is open or closed?  Usually, the boundaries are specified
 as [0, L), so we have an evolved point at 0, and three symmetry points <
 0, and the last evolved point would be L - h, followed by three symmetry
 points. The lower boundary would have a shiftout of 1, and the upper 0.
 As far as I can tell, AEILocalInterp doesn't look at anything other than
 the options you pass in; there is provision for passing a number of
 boundary points, but we don't use it, and it defaults to 0.  So
 AEILocalInterp thinks that all points can be interpolated to and from.

 I think that this is fine, because the symmetry thorn and CarpetInterp
 should only ever be asking for points for which there are enough ghost
 zones, in our case.

 PeriodicCarpet folds the interpolation coordinates using the physical_min
 and physical_max, which it gets from CoordBase's GetDomainSpecification.
 Is this logic implemented correctly?  Are these the first and last evolved
 points?  If PeriodicCarpet is leaving the coordinate "unfolded", so that
 it is actually outside the domain for which we have enough points, then
 this might explain some of what is happening.

 But still, even in that case, if the interpolator was previously having to
 off-centre, then setting the options to tell it not to should result in an
 error, not in the "right" answer.  So I am still confused.

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/181#comment:8>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit