You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During the process of implementing cell rotations and translations in PR #225 I realized that the Cells in OpenMOC will contain extra redundant ZCylinders when rings are used to spatially discretize fuel pin cells. Basically, the Cell::ringify() will retain the original Surface(s) in a Cell and simply add new ZCylinders to spatially refine the Cell. This is not a bug for ray tracing per se, but does mean that more Surfaces than necessary must be queried for intersection points which will hurt performance.
I don't see this is a critical issue, however, since at most there will only be two redundant Surfaces per Cell (i.e., when ringifying clad or gap zones which are treated as between two ZCylinders in the original non-discretized Cell). But if anyone n the future is looking for low hanging fruit performance optimizations, this could be one.
The text was updated successfully, but these errors were encountered:
I should also point out that I ran against the same issue when implementing the spatial discretization module in OpenCG many months ago. In this case I wasn't so lucky and had to figure out a way to remove redundant surfaces since OpenMC isn't as forgiving as OpenMOC in this regard. The algorithm to remove redundant surfaces in OpenCG uses bounding boxes and takes advantage of OpenCG's Pythonic design, but could serve as a starting point for anyone who sets out to fix this issue in OpenMOC in the future.
During the process of implementing cell rotations and translations in PR #225 I realized that the
Cells
in OpenMOC will contain extra redundantZCylinders
when rings are used to spatially discretize fuel pin cells. Basically, theCell::ringify()
will retain the originalSurface(s)
in aCell
and simply add newZCylinders
to spatially refine theCell
. This is not a bug for ray tracing per se, but does mean that moreSurfaces
than necessary must be queried for intersection points which will hurt performance.I don't see this is a critical issue, however, since at most there will only be two redundant
Surfaces
perCell
(i.e., when ringifying clad or gap zones which are treated as between twoZCylinders
in the original non-discretizedCell
). But if anyone n the future is looking for low hanging fruit performance optimizations, this could be one.The text was updated successfully, but these errors were encountered: