eschnett
Loop: Check for symmetry boundaries in outermost interior loops
The loop_outermost_int and loop_outermost_int_device routines used in NewRadX should check for symmetry boundaries. This is so that at symmetry boundaries, the radiative boundary conditions are applied if and only if they are also adjacent to physical boundaries.
This pull request also updates TestLoopX with the new loop syntax, so that symmetry information is passed into the loop from the patch data. The test case is also updated with reflection symmetry and periodic boundary conditions enabled.
Ticket is here: https://bitbucket.org/einsteintoolkit/tickets/issues/2820/newradx-boundary-condition-conflicts-with
@rhaas80 To create a separate commit for the change to CarpetX, I reverted to the commit a3b4594 and separated out the commits to CarpetX and TestLoopX.
@eschnett Could you take a moment to review this pull request and let me know your comments? The changes to CarpetX and Loop here are necessary for the NewRadX pull request review (https://github.com/EinsteinToolkit/SpacetimeX/pull/39) to be proceed. Thank you!
Why do you need to know whether a particular boundary is a symmetry boundary? I think what you actually need to know if a particular boundaries is a newrad boundary.
Yes, we are actually checking whether a certain boundary is a NewRad boundary. This would consist of the points that correspond to the physical outer boundary, but belong to the interior from CarpetX's point of view. If a symmetry is applied to a boundary, then that boundary would not be an outer boundary and not a NewRad boundary. We would need to know which boundaries are symmetry boundaries, so that they can be excluded from the "outermost interior" loops.
I am not too worried about this pull request since it only changes C++ code in Loop that so far is only used by NewRadX, though if applying this one also requires the corresponding SpacetiomeX/NewRadX pull request then one needs to be a bit more careful since then the change becomes "user visible".
It is less urgent to include this is in the release now that Z4c has been bumped to the 2025_05 release then it was when Z4c was to be included in 2024_11.
@eschnett @rhaas80 I wanted to hit merge for this but it seems to be waiting on the CI checks and these don't seem to be running for some reason...
@rhaas80 @eschnett Pushes to Cheng-Hsin's fork don't seem to be triggering the workflow checks. We are also unable to manually trigger them via the actions tab because these apply only to branches of this repository and not to forks it seems.
Maybe we are missing something like
on:
pull_request:
types: [review_requested, edited]
in the CI file? Otherwise it seems that the checks won't trigger.
Running for pull requests was disabled in git hash [e20e3232](https://github.com/einsteintoolkit/CarpetX/commits/e20e3232b4d172b638672309d5f87b01b0a616c9) "CI: Don't build for pull request changes" of [CarpetX](https://github.com/einsteintoolkit/CarpetX) which is about 6 months old.
That would explain the issue. @eschnett is it ok to re-enable?
Yes, that's fine.
I disabled it because I noticed that all my pushes to branches ran CI twice, once via the "push to branch" rule, and once via the "PR" rule. Maybe you know a way to avoid this?