I am having an issue with my DAGMC geometry. In the image below is defining my OpenMC geometry to just the DAGMC Universe where it is creating this shadow cell (white). When I create a bounding box cell using CSG and fill it with the DAGMC Universe and run the simulation I get missing particles. When I run the DAGMC check_overlaps and check_watertight everything is perfect. However, when i run openmc --geometry-debug I get an error about an overlap being detected between cell 152 and cell 153. When I plot this is openmc-plotter Cell 152 is a cell in the DAGMC geometry and Cell 153 is the CSG cell, so I shouldn’t have overlaps. Again the plot below is when I just plot the DAGMC geometry and the shadow part (white) is Cell 152. This tells me this is causing a problem. Does anyone know how to fix this?
The OpenMC geometry debug mode unfortunately isn’t super reliable for DAGMC universes because particles right on the boundary can result in ambiguous results. In transport this is handled for particles on a surface by maintaining the previously hit triangle to mask it out of the next query, but for point containment calls we don’t an equivalent mechanism at this time.
The two DAGMC diagnostics you ran are the best way to check the model integrity.
Thanks for the response. The warning I’m getting is that there is no intersect between dagmc cells. Is it possible that using double-down and a fine mesh with millions of triangles produces a particle ray-on-edge effect where a ray produced in the ray tracing intersects an edge of 2 triangles causing this problem? I’m only losing about 0.03% of particles when I run 2 billion particles, so fine for good stats.
The state that we keep during transport of particles in DAGMC geometries should account for a particle intersecting exactly with the triangle edge as far as I am aware. The lost particles you’re seeing may be due to some other factor in the geometry, such as coincident triangles on the surfaces of different volume. Is that a possibility in your model?
At any rate, I’m glad to hear that you’re getting good enough statistics for your purpose!
Something I find strange is that when I run the surface overlap check in Cubit, no overlaps are detected — this is after performing imprint and merge on the volumes. I’ve also run overlap_check from DAGMC with 100 points per edge, and still no overlaps are found. Wouldn’t this indicate that there are no coincident triangles?
For context, my workflow starts with a hex mesh in Cubit, then uses the htet function to decompose the hexes into tets, giving me a mesh for tallies (hexes) and a mesh for tracking (tets/tris). I don’t think htet is the source of the problem, since overlap_check should catch any triangle-level overlaps.
Could this be a tolerance issue? Specifically, is it possible that two triangles are nearly parallel and so close to each other that they fall below the overlap detection threshold, yet close enough to cause issues during particle tracking?
