Since is called in LEVEL mode map is -1 and all boundary sizes are set to 0. This is indeed what happens in ML_ADMConstraints when used with a Llama run (eg the multipatch test arrangements/McLachlan/ML_BSSN_Test/test/ML_BSSN_MP_O8_bh.par).
On the MoL side things are somehow even worse. The code in will always ask for 1 boundary point (Tools/CodeGen/MoL.m):
which really only works since the physical boundary condition is usually NewRad which is not called via Boundary but as part of the RHS and b/c the symmetry thorns (which are called via Boundary) use cctk_nghostzones rather than the boundary width (which is ok since they, or at least the Reflection thorn, check that the number of ghost zones agrees with the boundary width). This however would fail is one used eg a scalar boundary condition with an outer boundary width of more than 1 (or flat).
For the non-MoL code it seems to me as if one should collect all boundary widths from all maps and use that, eg code somewhat like this one (which is utterly untested):
if (CCTK_IsFunctionAliased ("MultiPatch_GetBoundarySpecification")) {
int const maps = MultiPatch_GetMaps (cctkGH);
for (int i = 0; i < 6; i++)
nboundaryzones[i] = -1;
// collect all boundary information from all maps, and get
// outer boundary information only
for (int m = 0; m < maps; m++) {
CCTK_INT nbounds[6];
ierr = MultiPatch_GetBoundarySpecification
(m, 6, nboundaryzones, is_internal, is_staggered, shiftout);
if (ierr != 0)
CCTK_WARN(0, "Could not obtain boundary specification");
for(int i = 0; i < 6; i++) {
if(!is_internal[i]) {
if(nboundaryzones[i] == -1) {
nboundaryzones[i] = nbounds[i];
} else {
if(nboundaryzones[i] != nbounds[i]) {
CCTK_WARN(0,
"Inconsistent number of outer boundary points: %d != %d in the %s %c direction between map %d and an earlier map",
nboundaryzones[i], nbounds[i], i % 2 ? "upper" : "lower", "xyz" (i/2), m);
} else {
// identical boundary sizes, all is fine
}
}
}
}
}
}
Kranc's automated boundary code for non-MoL code looks like this
Auxiliary/Cactus/SourceFiles/Kranc.cc
:which is called from routines scheduled in
LEVEL
mode egTools/CodeGen/CalculationBoundaries.m
:and scheduled in
LEVEL
mode (seeTools/CodeGen/Schedule.m
):Since is called in
LEVEL
modemap
is -1 and all boundary sizes are set to 0. This is indeed what happens inML_ADMConstraints
when used with a Llama run (eg the multipatch testarrangements/McLachlan/ML_BSSN_Test/test/ML_BSSN_MP_O8_bh.par
).On the MoL side things are somehow even worse. The code in will always ask for 1 boundary point (
Tools/CodeGen/MoL.m
):which really only works since the physical boundary condition is usually
NewRad
which is not called viaBoundary
but as part of the RHS and b/c the symmetry thorns (which are called via Boundary) usecctk_nghostzones
rather than the boundary width (which is ok since they, or at least the Reflection thorn, check that the number of ghost zones agrees with the boundary width). This however would fail is one used eg ascalar
boundary condition with an outer boundary width of more than 1 (orflat
).For the non-MoL code it seems to me as if one should collect all boundary widths from all maps and use that, eg code somewhat like this one (which is utterly untested):