Defense date

At the end of the day yesterday, I walked over to the CS department to bang on Professor Sifakis’ door and finalize my defense date. It will be on June 8th. This morning I sent out an email to the committee to finalize a time.

I have a considerable amount of work to do before this is all done, but it seems I’m well on my way and I’m going to do my best to make sure things go as smoothly as possible on the 8th. Constant vigilance!!

Open-DAGMC

Thanks to Sterling’s work on the C++ implementation of the Cell class, I was able to make quite a bit of progress today on this work. To start, I abstracted the Cell class to a general type with virtual functions for the distance, contains, and to_hdf5 methods. All attributes were ported over to this general class as well. I then changed the previous Cell class into a CSGCell which allowed room for my CADCell class. The polymorphism of C++ should then allow for minimal changes to the Fortran code in OpenMC when working with CAD or CSG geometries.

Next, I implemented calls into DAGMC’s interface for both the distance and contains methods of the CADCell class. (The to_hdf5 method I’ll leave for another time.) Right now, each instance of the CADCell has an attribute a DAGMC pointer, dagmc_ptr. This attribute can provide all the information the cell might need, including calls to point_in_volume, ray_fire, closest_to_location etc. The conversion from id to handle is relatively straight forward (entity_by_id) and allows for easy conversion back and forth to and from indices or ids, whichever OpenMC may require at the time.

bool CADCell::contains(const double xyz[3], const double uvw[3], int32_t
on_surface) const {
  moab::EntityHandle vol = dagmc_ptr->entity_by_id(3, id);

  int result = 0;
    dagmc_ptr->point_in_volume(vol, xyz, result, uvw);

  return bool(result);
}

I then ran into a somewhat expected issue when applying this to a simple simulation of a single fuel pin (xml version of the geometry and materials below). Passing particles from cell to cell (or volume to volume) is very different between CSG and CAD. In CSG, when a particle exits a cell (or crosses a surface) every cell in the problem is checked to determine the particle’s new logical location. In CAD, we know which Cell the particle is entering based on the previous volume and surface crossed (surfaces are adjacent to exactly two volumes). This is a common sticking point for implementing DAGMC in native geometry kernels.

<geometry>

  <!-- Definition of Cells -->
  <cell id="1" universe="0" material="40" region="-1 -4  5" />
  <cell id="2" universe="0" material="40" region=" 1 -2 -4 5" />
  <cell id="4" universe="0" material="40" region=" 2 -3 -4 5" />

  <!-- Defition of Surfaces -->
  <surface id="1" type="z-cylinder" coeffs="0 0 7" />
  <surface id="2" type="z-cylinder" coeffs="0 0 9" />
  <surface id="3" type="z-cylinder" coeffs="0 0 11" boundary="vacuum" />
  <surface id="4" type="z-plane"    coeffs=" 20"    boundary="vacuum" />
  <surface id="5" type="z-plane"    coeffs="-20"    boundary="vacuum" />

</geometry>

<materials>

  <material id="40">
    <density value="4.5" units="g/cc" />
    <nuclide name="U235" ao="1.0" />
  </material>

  <material id="41">
    <density value="1.0" units="g/cc" />
    <nuclide name="H1" ao="2.0" />
    <nuclide name="O16" ao="1.0" />
    <sab name="c_H_in_H2O"/>
  </material>

</materials>

The fastest way to handle this situation was to, sadly, alter the Fortran function cross_surface. A #ifdef block is inserted and checks for a CAD-based simulation. If this is true, then an implementation of DAGMC’s next_vol method is called via an exposed C function which takes in the last cell the particle was in and the surface it is on (or the surface is crossing) and updates OpenMC’s Particle type with the new cell, material, temperature, and all other necessary properties to continue transport.

This allowed me to successfully run the fuel pin sample problem (though with only one material). The other hack I had to introduce was the manual killing of particle histories when they enter the implicit complement. This is done via an exposed function for checking if a cell is the implicit complement and killing the history if it is entering that region. This need to be updated in the future and replaced with code using surface boundary conditions to represent the extent of the problem. Any surfaces on the exterior of the problem should be given a BC_VACUUM boundary condition I might give Andy a call to see what the best way to approach that will be.

Materials, temperatures and so on should also be read in from tagged values in the .h5m geometry. Thankfully, a very useful meta-data interface to DAGMC allows this with little additional implementation. The population of OpenMC materials from the UWUWworkflow can be left to a later date.

Git cleanup

Since the rebase onto Sterling’s c_cell branch, I’ve been using a DagMC branch called dagmc_rb_test. I should really replace my old dagmc branch with this one at some point.