Recently I was trying to find the bounding planes for a problem (i.e., the openmc.Zplane with the max and min values, or boundary_type == 'vacuum'). After some discussion with @paulromano I think the idiomatic way would be to update openmc.Region.get_surfaces and openmc.Geometry.get_all_surfaces to have a signature more like:
enforcement for valid filters will need to fail fast.
The stringified versions of the class names should be pythonic. The question is should be they be treated as classes or instances? i.e., 'z_plane' vs. 'ZPlane'.
It may or may not be worthwhile to add an SurfaceType enum.
AFAIK openmc.Universe does not have a get_all_surfaces
None options for the filter default to no filtering at all.
Tasks:
[ ] Add filter by surface type
[ ] Add filter by boundary type
[ ] Add universe.get_all_surfaces
Alternatives
The currently work around is for the user to do this manually. This method given would take O(2n) versus a possible O(n) implementation. Obviously these are the same order of scaling but still not ideal:
actual_surfaces = {}
for id, surf in model.geometry.get_all_surfaces().items():
if isinstance(surf, openmc.ZPlane):
actual_surfaces[id] = surf
Compatibility
This should not break backwards compatibility as all arguments will be optional and without them the status quo is maintained.
I can tackle this ... at some point. Probably after this spring semester.
Description
Recently I was trying to find the bounding planes for a problem (i.e., the
openmc.Zplane
with the max and min values, orboundary_type == 'vacuum'
). After some discussion with @paulromano I think the idiomatic way would be to updateopenmc.Region.get_surfaces
andopenmc.Geometry.get_all_surfaces
to have a signature more like:Note: type annotations just added for clarity.
Notes:
'z_plane'
vs.'ZPlane'
.SurfaceType
enum.openmc.Universe
does not have aget_all_surfaces
Tasks:
universe.get_all_surfaces
Alternatives
The currently work around is for the user to do this manually. This method given would take O(2n) versus a possible O(n) implementation. Obviously these are the same order of scaling but still not ideal:
Compatibility
This should not break backwards compatibility as all arguments will be optional and without them the status quo is maintained.
I can tackle this ... at some point. Probably after this spring semester.