Implicit Complement in OpenMC

I’ve updated the CAD setup code in my “Open-DAGMC” branch to set materials using volume properties. This all seems to work just fine, but it isn’t clear to me how to define the implicit complement. Concepually, it is a closed region with a void (or vacuum) material.

When I assign OpenMC’s equivalent of void to the implicit complement, however, the geometry initialization fails on a step involving adjustting indices between the C++ and Fortran representations of the object arrays.

Update

Turns out this was a problem caused by a move of some constants to C++. It is being resolved in an open PR now. This doesn’t necessarily fix the crux of the problem however. To form an implicit complement, the exterior of the problem needs to be bounded. This is typically done in Trelis using a hollow box to minimize the number of triangles added to the problem. But I also had the thought that this could easily be automated in DAGMC, especially after Chelsea’s PR into MOAB for deleting volume (but not surface) OBB trees. This method would simply expand a bounding box to encompass all the volumes in the model (using the root boxes of their OBB trees) and then construct a box shell and the corresponding geometric topology. This shell would probably be created from two surfaces (rather than 12 as it would be in Trelis), but it should make no difference to the tracking algorithm. Boundary conditions, importances, etc. can then be applied to the boundary volume as necessary to kill particles.

Adding a “Graveyard”

So after adding a bounding box shell around my simple pin cell problems in the CAD OpenMC model, I then applied a Vacuum boundary condition to the interior surfaces to kill any particles crossing into the shell. In the load_cad_geometry_c function, it now searches for the ‘boundary’ property and sets a Vaccum boundary on appropriate surfaces (other BC’s to come later). After adding this capability, both a normal pin cell simulation and void pin cell simulation ran successfully… but I’m now getting very different eigenvalues than OpenMC.

The crux of the problem here is that I’ve hacked the tracking algorithm pretty badly and should be looking for a much cleaner way to integrate CAD tracking into the current alg. I’ll need to take a look tomorrow, though.