[ET Trac] [Einstein Toolkit] #350: Autogenerating cctk_Loop.h

[Einstein Toolkit]

#350: Autogenerating cctk_Loop.h
--------------------------+-------------------------------------------------
  Reporter:  eschnett     |       Owner:        
      Type:  enhancement  |      Status:  review
  Priority:  minor        |   Milestone:        
 Component:  Cactus       |     Version:        
Resolution:               |    Keywords:        
--------------------------+-------------------------------------------------

Comment (by hinder):

 Replying to [comment:13 eschnett]:

 > 3. If we use CCTK_NORMAL for the normal, then we should also use
 CCTK_INDEX for the loop index...

 Yes.  Why not?  Is the reason only due to brevity? Or is there another
 reason?

 > Joke aside, we can store the distance from the outer boundary in the
 normal. (The "number of points less than the boundary size which are
 available" would be less useful -- it would be large at the boundary, and
 small in the interior, thus it wouldn't indicate what stencil you can
 use.)

 By "distance from the outer boundary", I assume you mean the distance from
 the outermost point in the boundary.  But which one? Lower or upper?  I
 thought about both options, and the most symmetric seemed to be the one I
 proposed.  This would be of the form [-2, -1, 0, 0, ..., 0, 1, 2],
 assuming a boundary size of 2.  You are correct that this array does not
 contain exactly the information about the stencil that you can use, but if
 you assume that the interior corresponds to a stencil of the same size as
 the boundary, then this is the missing information.  Maybe this is too
 complicated.  For your suggestion, I believe we would need two variables,
 one for the lower boundary and one for the upper boundary.  This would
 then look like this: nx_lo = [0, 1, 2, ...]; nx_hi = [,,,. 2, 1, 0], then
 we could do
 {{{
 if (nx_lo[0] >= 2 && nx_hi[0] >= 2) {
   dfdx = D4(f);
 } else if (nx_lo[0] == 1 || nx_hi[0] == 1) {
   dfdx = D2(f);
 } else if (nx_lo[0] == 0) {
   dfdx = D2Plus(f);
 } else if (nx_hi[0] == 0) {
   dfdx = D2Minus(f);
 } else assert(0);
 }}}

 > 4. The issue isn't looping over physics vs. looping over symmetry zones.
 The issue is that there are three boundary specifiers (physical, symmetry,
 ghost), and in three dimension, and boundary can have up to three
 specifies attach to it (corners!). Yes, a boundary can be all of a
 physical, a symmetry, and a ghost boundary. The issue is in handling
 these. BOUNDARIES loops over all boundaries that are physical boundaries
 (irrespective of whether they are also a symmetry or a ghost boundary),
 INTBOUNDARIES loops over all boundaries that are only physical boundaries.
 The former does not require applying symmetry conditions and
 synchronisation afterwards, the latter allows taking tangential
 derivatives.

 So BOUNDARIES would be useful if you were only taking derivatives normal
 to the boundary, as it would allow you to skip expensive interprocessor
 synchronisation and symmetry boundary conditions, and INTBOUNDARIES would
 be useful if you also needed to take tangential derivatives?  This seems
 OK, but I wonder if we can come up with clearer names?

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