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

Einstein Toolkit trac-noreply at einsteintoolkit.org
Tue Oct 25 04:41:26 CDT 2016

#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):

 This is the problem!  There is no complaint.  When we don't tell it not to
 off-centre (the default), there is some sort of symmetry violation,
 suggesting that it is off-centering.  When we tell it **not** to off-
 centre, this symmetry violation goes away, so it looks like it is no
 longer off-centering.  This doesn't make any sense.  Telling it not to
 off-centre should cause it to give an error if it had been off-centering
 before.  The case we have is the one in comment:5.

 > Let's assume you have 10 points on your grid, and your domain is [0; 1).
 Your points' coordinates are thus [0.0, ..., 0.9]. If you try to
 interpolate at 0.95, then this is fine, as it's inside the domain.
 However, all AEILocalInterp sees is that it has grid points in the range
 [0.0; 0.9], and it will thus complain.

 Are these just the evolved points?  We would also have three symmetry
 points at [-0.3,-0.2,-0.1] and [1.0,1.1,1.2].  Suppose we ask for
 interpolation at 0.95.  This is outside the 'logical' domain, so
 PeriodicCarpet should fold it back.  Aha!  Now I see something odd.  This
 point is equivalent to 0.95 - 1, which is -0.05, which is STILL outside
 the logical domain.  So there is actually no interpolation point we can
 use which would lie inside [0,1).  Is this to do with using vertex
 centring?  What would PeriodicCarpet do in this case?  Even so, I still
 don't understand the problem.  Suppose PeriodicCarpet does fold it back to
 -0.05.  AEILocalInterp will see the points [-0.3, -0.2, -0.1, 0.0, 0.1,
 0.2, 0.3, ...].  It needs 5 points to do the interpolation, so it should
 use -0.3, -0.2, -0.1, 0.0, 0.1 (or shifted to the right by one; I find it
 hard to parse the open/closed diagran in the AEILocalInterp docs.)  So it
 should still work, and should never have to off-centre.  We get away with
 this because we have three ghost zones, and this interpolator only needs
 two (modulo the PeriodicCarpet issue above).

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

More information about the Trac mailing list