Impossible overlaps in DAGMC geometry with perfectly conformal mesh

I’ve been struggling to debug an odd issue when using DAGMC geometry where “impossible” overlaps are detected by the DAGMC overlap checker and openmc-plotter. As a minimal example, the attached script generated a series of conformal toroidal shells using cadquery. These shells are then meshed conformally using both @Shimwell 's CAD-to-DAGMC and @ebknudsen’s CAD-to-OpenMC with the STL backend. Regardless of the meshing tool, the overlap checker reports overlaps between volumes which clearly do not overlap in the generated mesh.

These overlaps are clearly impossible as layers 1,2,3,4 for ex. do not share any surfaces.

Running overlap check:
100% |===============================================================>|+
Overlap locations found: 3
Overlap Location: 819.047 -429.869 -129.904
Overlapping volumes: 1 2 3 4 
Overlap Location: 79.8867 -698.799 44.7127
Overlapping volumes: 2 3 4 
Overlap Location: 193.887 -674.945 -337.401
Overlapping volumes: 3 4 

Any help would be greatly appreciated. I’ve brought the issue up with @Shimwell and @ebknudsen, but they weren’t sure what might be going wrong.

Script

Source is included as an attachment.

Please expand this screenshot to view the full script:

Key images

Build123d/Cadquery-generated geometry:

Gmsh conformal mesh:

Vtk file produced with mbconvert:

Example of reported overlaps:


20230825_meshing-debug-followup.ipynb (452.2 KB)

1 Like

I started trying to rework cad-to-dagmc to have surface sense like Erik’s code but I’ve got stuck on the part where a different surface sense needs applying. Working progress if here for your interest. I hope to have another look next weekend.

It is very strange that there are multiple overlapping geometries in the model. Which branch fork of CAD_to_OpenMC did you make use of?

Question about build123d usage in the notebook, does the faces.thicken make the geometry thicker in one direction or both, do we need a boolean cut to make sure the layers don’t overlap?

(Before I embark on making sure my python environment is up to this…) Are you able to make some plots that show each volume separately? I’m curious to see how the different surfaces of each toroidal layer look. I’m also curious to know what the meshing looks like on the inner surface of one torus and the outer surface of the torus it encloses.

Thanks for your help everyone! Here’s a visualization of the layers separated to show there’s no overlap in the geometry:

I’m using the master branches of both CAD-to-OpenMC and CAD-to-DAGMC (the pip install is included in the script in an attempt to make it reproducible).

@gonuke, in both cases, I’m quite sure the mesh is conformal, i.e. the inner and outer surfaces of adjacent volumes are meshed exactly the same.

A non-conformal mesh would look something like this:
CleanShot 2023-08-29 at 09.30.58

In comparison to our nicely meshed torus:
CleanShot 2023-08-29 at 09.31.53

Regardless, even if the volumes were truly overlapping it shouldn’t be possible to have overlaps between all the volumes as reported by overlap_check. It’s possible that it’s a normal vector issue, although CAD-to-OpenMC already includes correction using trimesh unless I’m mistaken.

@Shimwell, do we know if incorrect sense data would lead to this sort of overlap? My understanding is that CAD-to-DAGMC sets all faces to have sense 0.

Beyond that, is there a clear heuristic for what is forward and what is backward? This is the best information I could find from the MOAB documentation, but to me it seems that all faces bounding a volume point both in our out depending on how you look at it.

A geometric face has a natural orientation, indicated by the direction of the normal to the face; similarly, edges have a natural orientation determined by the direction of the tangent. When faces bound regions, or edges bound faces, they do so with a sense; if a region includes a face with forward sense, that means the face’s natural normal direction points out of the volume.
The following sense values are used:
0: forward
1: reverse
-1: unnknown

Last update:

@Shimwell, I know your Gist script is a work in progress, but the overlap checker also found overlapping volumes in the produced h5m file:

Script output:

face_ids_per_solid {796334115: 2, 796335283: 1}
adding moab details for solid id 796333507 and material tag mat1
    adding face 796334115 to moab core
    face 796334115 has not previously been added
adding moab details for solid id 796336515 and material tag mat2
    adding face 796335283 to moab core
    face 796335283 has not previously been added
    adding face 796334115 to moab core
    face 796334115 has already been added, this must be face shared by two solids

Overlap check:

Running overlap check:
100% |===============================================================>|+
Overlap locations found: 1
Overlap Location: 0.695866 -0.0486597 9.97564
Overlapping volumes: 711896867 711897315

With 3 concentric spheres

CleanShot 2023-08-29 at 12.35.54

adding moab details for solid id 709482979 and material tag mat1
    adding face 709474867 to moab core
    face 709474867 has not previously been added
adding moab details for solid id 709475619 and material tag mat2
    adding face 709475107 to moab core
    face 709475107 has not previously been added
    adding face 709474867 to moab core
    face 709474867 has already been added, this must be face shared by two solids
adding moab details for solid id 709483315 and material tag mat3
    adding face 106019078 to moab core
    face 106019078 has not previously been added
    adding face 709475107 to moab core
    face 709475107 has already been added, this must be face shared by two solids
Running overlap check:
100% |===============================================================>|+
Overlap locations found: 2
Overlap Location: 0.695866 -0.0486597 9.97564
Overlapping volumes: 709475619 709482979 709483315 
Overlap Location: 1.0438 -0.0729895 14.9635
Overlapping volumes: 709475619 709483315 

Plotting Geometry

With my toroidal geometry, cell plots show interesting artifacts. I initially reported this here: Weird artifacts on DAGMC geometry plots - #7 by akoen.

CAD-to-DAGMC

CleanShot 2023-08-29 at 12.55.02

CAD-to-OPEMC

CleanShot 2023-08-29 at 12.57.44