Generic region-based container for random sphere packing#3759
Generic region-based container for random sphere packing#3759paulromano wants to merge 1 commit intoopenmc-dev:developfrom
Conversation
|
@paulromano I'll try this out and let you know how it goes! Thank you. |
|
I still have the little sample cone I made before - I'll run both versions and report back on the time. |
|
Here is the input file I'm running. I'm only updating the packing fraction between runs, and the only difference between the generic and specific runs is whether or not I supply the volume/bounding box (and the branch my openmc install is on) |
|
Paul, the 30% run is still going - I'm ending it now. I'm guessing that the check for stopping after a certain number of failed attempts isn't working for RSP for some reason. |
I think |

Description
This PR adds a generic region-based container for
openmc.model.pack_spheres, enabling packing in arbitrary closedRegionobjects with a required finite bounding box and explicit volume.pack_spheresnow acceptsbounding_box/volumekwargs and uses a fixed container selection order to preserve existing behavior. The new_RegionContainersupports analytic boundary clearance for simple shapes and uses conservative directional checks otherwise:Analytic fast path: If the region is an
IntersectionofHalfspaceobjects with planes, spheres, cylinders, or cones, we compute exact clearance to each surface and require it to be at least the sphere radius. This gives a precise, fast boundary test.Generic fallback: Otherwise we do a conservative directional probe. We generate ~50 unit vectors on the sphere using a Fibonacci lattice (low-discrepancy, evenly spread points). A candidate center is accepted only if every probe point at
center + safety * radius * directionis inside the region. The 50 points are a practical balance between cost and coverage; the Fibonacci pattern avoids clustering at the poles, so you get better angular uniformity than random or latitude/longitude grids. A small safety factor (1.001) reduces false positives from numerical edge cases near the boundary.This approach is intentionally conservative: it may reject some valid centers but should not accept invalid ones, and it keeps the cost predictable for arbitrary CSG regions.
@ZoeRichter @MendesMichael if either of you want to try this out on your use cases, I would love know how it goes and if you encounter any problems. In particular, I'm curious about the performance of this versus your specialized implementation from #3739.
Marking as draft since this was 99% coded by GPT 5.2 Codex and I haven't really reviewed/optimized to my liking, but I wanted to make it available for others to start playing around with.
Checklist