[ET Trac] [Einstein Toolkit] #755: Provide better support for implementing boundary conditions

[Einstein Toolkit]

#755: Provide better support for implementing boundary conditions
-------------------------+--------------------------------------------------
 Reporter:  hinder       |       Owner:     
     Type:  enhancement  |      Status:  new
 Priority:  major        |   Milestone:     
Component:  Cactus       |     Version:     
 Keywords:               |  
-------------------------+--------------------------------------------------
 Whenever an application thorn wants to apply a boundary condition (i.e.
 not using the hard-coded boundary conditions from thorn Boundary), it is
 necessary to identify which points on the local component correspond to
 physical (as opposed to symmetry, inter-process or refinement boundaries).
 This functionality is available in KrancNumericalTools/GenericFD. The
 function is GenericFD_GetBoundaryInfo in
 https://github.com/ianhinder/Kranc/blob/master/Auxiliary/Cactus/KrancNumericalTools/GenericFD/src/GenericFD.c

 The function takes various Cactus variables as input and outputs arrays
 indicating the nature of each boundary: bounding box and whether the face
 is a symmetry, physical or interprocessor boundary (including refinement
 boundaries).

 There is also a function GenericFD_LoopOverBoundary which splits the
 domain into the 26 different regions (6 faces, 12 edges and 8 corners) and
 calls a function (passed by pointer) on each region that corresponds to a
 physical boundary.  Input parameters to the function identify the boundary
 normal, face, direction, etc.  This calls GenericFD_GetBoundaryInfo to
 identify this information.  This functionality is obviously core to
 implementing boundary conditions.

 I propose that this functionality be included in Cactus.  Thorn Boundary
 would be a logical place, since GenericFD_GetBoundaryInfo calls aliased
 functions usually provided by CoordBase or multipatch thorns, so I don't
 think this belongs in the flesh.  The function-pointer interface might not
 be the right one - perhaps we could refactor the code so that there was a
 macro similar to the flesh CCTK_LOOP macros.  The user would write

 BEGIN_BOUNDARY_LOOP(args...)
 ...
 END_BOUNDARY_LOOP

 where args gave names for the local variables indicating the normal
 direction, face number etc.  This macro would evaluate whatever was inside
 it on each of the physical boundaries with appropriate values for the
 arguments.

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/755>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit