check_watertight fails with CAD_to_OpenMC h5m output

[sjcrs]

I've used CAD_to_OpenMC to convert a CAD file to h5m format, and the output file can be visualized using the h5m visualization tool at sirepo.com/cloudmc:

However, simulations fail with this geometry, and in debugging I attempted to check the geometry with the DAGMC check_watertight and make_watertight tools. The output is below:

$ check_watertight geometryInput-dagmcFile.nano.h5m 
geometry check
number of surfaces=243
number of volumes=243 
MOAB ERROR: --------------------- Error Message ------------------------------------
MOAB ERROR: could not check model for watertightness!
MOAB ERROR: main() line 122 in check_watertight.cpp


$ make_watertight $PWD/nano.h5m 
Loading input file...
MOAB ERROR: --------------------- Error Message ------------------------------------ 
MOAB ERROR: file set not found! 
MOAB ERROR: get_sealing_mesh_tags() line 1976 in Gen.cpp
MOAB ERROR: --------------------- Error Message ------------------------------------
MOAB ERROR: could not get the mesh tags!
MOAB ERROR: make_mesh_watertight() line 1803 in MakeWatertight.cpp
MOAB ERROR: --------------------- Error Message ------------------------------------
MOAB ERROR: could not make model watertight!
MOAB ERROR: main() line 75 in make_watertight.cpp

Is the h5m output missing some internal metadata that is expected in DAGMC files?

[pshriwise]

To streamline debugging a bit:

I tracked this down to the following in the make_watertight source code:

https://github.com/svalinn/DAGMC/blob/73377602789e484fbbf1249d76761b3cf59b3394/src/make_watertight/Gen.cpp#L1967-L1968

This is an unfortunate error message as the real cause is that the faceting_tolerance tag isn't present in the .h5m file. The algorithm identifies the file set as an EntitySet with the faceting tolerance tag applied. This tag is important as it's used to evaluate proximity and accuracy of the sealing algorithm. Historically, this value comes from what tolerance was provided to the faceting engine in Cubit. The lines for the addition of that tag to the MOAB file in the Cubit plugin is here:

https://github.com/svalinn/Cubit-plugin/blob/7cfebdbe76ded373cef9c4aff1e04ae1b694ad33/export_dagmc_cmd/DAGMCExportCommand.cpp#L225-L226

I'm not sure if there's a similar parameter to add to the DAGMC file in this workflow or not. Another option might be to allow a value to be passed to the algorithm to set the faceting tolerance, but I think this could be more error prone tbh. Thoughts @ebknudsen?

[ebknudsen]

It should definitely be possible/easy to add the property to the h5m-file produced by CAD_to_OpenMC. In case of the stl meshing backend (triangulation by cq/OCCT) the same tolerance parametrization is directly communicated to the mesher. In the case of the gsmh-backend, some kind of translation is necessary.

[pshriwise]

Awesome! Let me know if there's anything I can do to lend a hand w/ that.

[ebknudsen]

A number for the faceting tolerance is now added to the h5m-file by CAD_to_OpenMC. This is for the development branch - which is soon to be released as a new main.

[ebknudsen]

@sjcrs I would be very much interested if you could try if that helped the problem. There are quite a few improvements in the merging routines in the development branch.

[sjcrs]

I pulled the develop branch and ran the same geometry from above. It seemed to fix the root problem I was having initially, and I'm able to generate OpenMC simulations with the geometry, up to the point where there are too many lost particles. However, when I run check_watertight and make_watertight on that same h5m volume, I'm still getting the same MOAB output I shared above.

[ebknudsen]

OK - a step forward at least - but not far enough. This geometry you are running - is that something you'd be allowed/willing to share with me? Then I could give it a go here and see if I can reproduce the problem.
Also - it looks like you are using the "stl" backend, correct?

[sjcrs]

Sure, it's actually just a random CAD model I pulled from GrabCAD (https://grabcad.com/library/arduino-nano-rp2040-connect-1). I chose it because it's 1) fairly complicated, but 2) still mostly flat surfaces and right angles.

Yes, I'm using the 'stl' backend. I'm running in a vanilla fedora virtual box as a testing environment, and i'm not using mmg tools

[ebknudsen]

OK that's cool - I will grab it and experiment. One thing: The development branch includes the (admittedly not very well named) stl2-backend which includes a major improvement if you have shared surfaces in a model. Stay tuned.

[ebknudsen]

@sjcrs I have now run a few tests with the Nano - I am seeing some issues when using the merging routine, and unfortunately also with the experimental imprint routines (which should accomplish pretty much the same thing.
The thing will mesh fine without merging however, both with the gmsh and with the stl, and stl2 backends. This is of course unsatisfactory, since imprinting is important, when objects have [partially] shared surfaces.

[ebknudsen]

I created a couple of testing scripts just to automate runs a bit - you're more than welcome to fiddle with them if you want
testArduino.zip

[ebknudsen]

An update: @sjcrs I've now tinkered quite a bit with the routines, made a new release, found bugs etc. The will be another respin release in a day or two. I can now mesh the arduino quite nicely with the 'stl2' backend. This includes catching surfaces that are shared between parts in the step-file.
Check_watertight crashes however with a moab-related error. So setting closer but no cigar yet perhaps, abeit I am not entirely sure that this error is caused by CAD_to_OpenMC.

[sjcrs]

Great to hear! I'll be on the lookout to test this respin with a few different test geometries. That arduino model is of no real importance, but it seems like it's a pretty good pathological example to use for debugging!