Provide better support for implementing boundary conditions

Issue #755 closed
Ian Hinder created an issue

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.

Keyword:

Comments (9)

  1. Erik Schnetter
    • removed comment

    This is related to the macro CCTK_LOOP3_BOUNDARIES offered by cctk_Loop.h. However, this macro splits the boundary into only up to 6 blocks, and does not provide a boundary normal.

  2. Ian Hinder reporter
    • removed comment

    Thanks - I didn't know about that macro. What is the intention of the input parameters iblo,jblo,kblo, ibhi,jbhi,kbhi? From their names they seem to be low and high indices of the three directions. Or are they the boundary widths? Could you explain roughly how to use the macro?

  3. Erik Schnetter
    • removed comment

    This macro loops over all physical boundaries. The blo/bhi parameters are the 6 boundary widths. What is missing is code to determine the boundary widths, and to distinguish between physical/symmetry/inter-process boundaries. (This information should be provided by CoordBase.)

    We could augment this macro with flags specifying over which boundaries to loop. We could also augment the macro to loop in 26 steps instead of in 6 steps, and to provide normal information.

    There are some ambiguities because a boundary can be an inter-process, a physical, and a symmetry boundary at the same time (if it is a corner). In this case the caller needs to specify what should happen, e.g. "loop over all outer boundaries but exclude all ghost zones"; this allows taking tangential derivatives. Or "... but include ghost zones"; this does not require synchronisation afterwards. Depending on whether symmetry points are skipped, one may have to schedule the boundary condition after the symmetry condition. And so on.

  4. Erik Schnetter
    • changed status to open
    • removed comment

    The macro looping over boundaries currently looks like

    CCTK_LOOP3_BOUNDARIES(name, cctkGH, i,j,k, iblo,jblo,kblo, ibhi,jbhi,kbhi) I suggest to remove the explicit specification of the *lo and *hi arguments, and instead obtain these from thorn CoordBase. A second, "internal" macro would continue to provide the current functionality. This would be done for loops over the interior as well.

    The new macros would then look like

    CCTK_LOOP3_INTERIOR(name, cctkGH, i,j,k) CCTK_LOOP3_BOUNDARIES(name, cctkGH, i,j,k) and

    CCTK_LOOP3_BOUNDARIES_DIRECT(name, cctkGH, i,j,k, iblo,jblo,kblo, ibhi,jbhi,kbhi) and equivalently for the interior.

  5. Erik Schnetter
    • removed comment

    I applied #350. Is this patch still relevant? It seems the same functionality is now available by

    CCTK_LOOP3_BND(name, cctkGH, i,j,k, ni,nj,nk) and, at a lower level,

    CCTK_LOOP3_BOUNDARIES(name, cctkGH, i,j,k, ni,nj,nk, iblo,jblo,kblo, ibhi,jbji,kbhi, ibboxlo,jbboxlo,kbboxlo, ibboxhi,jbboxhi,kbboxhi)

  6. Ian Hinder reporter
    • removed comment

    If it is possible to replace the boundary functionality in Kranc with the implementation of #350, then this ticket can be closed.

  7. Erik Schnetter
    • changed status to resolved
    • removed comment

    Yes, the GenericFD_LoopOver* routines should not be necessary any more. Instead, it should be possible to replace the LC_LOOP3VEC with the respective macros from cctk_Loop.h.

  8. Log in to comment