[ET Trac] [Einstein Toolkit] #797: N13CarpetRegrid211snap_coarseE does not hold after being enforced in cell centering

[Einstein Toolkit]

#797: N13CarpetRegrid211snap_coarseE does not hold after being enforced in cell
centering
---------------------+------------------------------------------------------
  Reporter:  rhaas   |       Owner:  eschnett
      Type:  defect  |      Status:  new     
  Priority:  major   |   Milestone:          
 Component:  Carpet  |     Version:          
Resolution:          |    Keywords:          
---------------------+------------------------------------------------------

Comment (by rhaas):

 Some carefully place printfs in property.cc show that for the regriddin in
 question CarpetRegrid2 has put a small (2 cells high) strip of cells
 between two boxes, ie. the two boxes for the NS are touching in one
 corner:

 {{{
       +---------+
       |   1     |
       |_________|
 +-----+         |
 |       2       |
 |__________+----+
 |          |
 |    3     |
 +----------+
 }}}

 Region "2" is the small one. In numbers from the code:
 {{{
 ([22112,28896,23904]:[35744,28960,33952]:[64,64,64]/[345,451,373]:[558,452,530]/[214,2,158]/67624)
 }}}

 Snaptocoarse uses a
 contracted_for(coarse_base).expand_for(fine_base).expand(buffer_with %
 reffact) scheme to align the active (non-buffer) regions. Outputting the
 strip, then after contraction and then after expand_for and finally the
 expand (by 1 as it turns out) I get:
 {{{
 aa:
 ([22112,28896,23904]:[35744,28960,33952]:[64,64,64]/[345,451,373]:[558,452,530]/[214,2,158]/67624)
 aa.expand():
 ([22112,28896,23904]:[35744,28960,33952]:[64,64,64]/[345,451,373]:[558,452,530]/[214,2,158]/67624)
 aa.expand().contracted_for():
 ([22208,28992,24000]:[35648,28864,33856]:[128,128,128]/[173,226,187]:[278,225,264]/[106,0,78]/0)
 aa.expand().contracted_for().expanded_for():
 ([2464,2464,2464]:[2400,2400,2400]:[64,64,64]/[38,38,38]:[37,37,37]/[0,0,0]/0)
 aa.expand().contracted_for().expanded_for().expand():
 ([2400,2400,2400]:[2464,2464,2464]:[64,64,64]/[37,37,37]:[38,38,38]/[2,2,2]/8)
 }}}

 Notice that after expanded_for() the box is (a) empty and (b) has suddenly
 moved (to what is the lower corner of baseextent(0,rl) for this level
 [2464]). The final expand then turns it into a non-empty box in the wrong
 spot. This is what eventually triggers the property-does-not-hold assert
 (the test checks a difference between snapped and current grid to be empty
 when &'ed with baseextent).

 I'll try and understand why expanded_for() moves the box and if the logic
 for alignment should also work with very small strips.

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