Some context: I've been playing around with creating robust bounding boxes for surfaces, cells, and universes in our C++ code to make this information accessible in the CAPI. While surfaces and universes are straightforward, cell bounding boxes require more consideration in accounting for the CSG operations defining their regions. In particular, cells with complement regions are problematic. A bounding box complement is difficult to define without knowledge of the specific halfspaces that make up that region, requiring what I'll claim is messy and complicated parsing of the RPN to isolate these regions.
As an alternative, I found it fairly straightforward to avoid the use of complement operators altogether in OpenMC's internal RPN representation by applying De Morgan's laws in the generate_rpn function. These laws are also applied in the Python API to get bounding boxes, but it is significantly more clear there thanks to the openmc.Region class and subclasses.
The removal of complement operators from the C++-side RPN allows us to simplify the CSGCell::contains_complex slightly as well.
Is there any major downside to this? I suppose it could be a little confusing if users re-create a geometry.xml from a summary.h5 file. The RPN will have changed at that point, I think...
Another option would be to implement a Region class in C++ similar to the one in the Python API, though I worry that this wouldn't be as efficient during simulation.
Some context: I've been playing around with creating robust bounding boxes for surfaces, cells, and universes in our C++ code to make this information accessible in the CAPI. While surfaces and universes are straightforward, cell bounding boxes require more consideration in accounting for the CSG operations defining their regions. In particular, cells with complement regions are problematic. A bounding box complement is difficult to define without knowledge of the specific halfspaces that make up that region, requiring what I'll claim is messy and complicated parsing of the RPN to isolate these regions.
As an alternative, I found it fairly straightforward to avoid the use of complement operators altogether in OpenMC's internal RPN representation by applying De Morgan's laws in the
generate_rpnfunction. These laws are also applied in the Python API to get bounding boxes, but it is significantly more clear there thanks to theopenmc.Regionclass and subclasses.The removal of complement operators from the C++-side RPN allows us to simplify the
CSGCell::contains_complexslightly as well.Is there any major downside to this? I suppose it could be a little confusing if users re-create a
geometry.xmlfrom asummary.h5file. The RPN will have changed at that point, I think...Another option would be to implement a
Regionclass in C++ similar to the one in the Python API, though I worry that this wouldn't be as efficient during simulation.