Add manual checks/infer OpenMC geometry in surrogate

[aprilnovak]

Both the surrogate T/H model and the OpenMC model specify a radial discretization in the rods. If the surrogate discretization is coarser than the OpenMC model, two bugs arise that could lead to a failure to conserve power (I think). To illustrate this by example, consider just the pellet region, with an OpenMC model with four radial cells but a surrogate model with only three radial cells:

OpenMC: x ------- x ------- x ------- x ------- x
Surrogate: x ----------- x ---------- x ---------- x

1. The ring_to_cell_inst_ member will not include all OpenMC cell instances in the pellet - only three of the cells would be included because we assemble ring_to_cell_inst_ by sweeping through center coordinates of the surrogate model. So for the above, the third OpenMC cell would not contribute a heat source to the surrogate model (and we would never even establish a tally for it).

2. The cell_inst_to_ring_ member will not include the third OpenMC cell, so it's temperature would never be updated.

Basically, if the surrogate model is coarser than the OpenMC model, some OpenMC cells will I think never be updated in temperature and never contribute a heat source to the T/H model.

---

I propose adding an input file parameter to say how many rings to expect in the OpenMC model and throw an error if the surrogate is too coarse. We could make this an optional field (and perform no check if absent). I foresee the case where an original model was set up correctly, but maybe the user wants to run a mesh refinement study and varies the discretization(s) without realizing they're introducing a bad mapping.

A more elegant way would be to use the pin_centers and search over the OpenMC surfaces to find the number of SurfaceZCylinders with those center coordinates to back out how many rings are in the OpenMC model, but that sort of goes against the philosophy so-far of "user needs to be careful."

Does anyone have opinions on how to ensure a good mapping here?

[paulromano]

Yeah, I'm basically still relying on the "user needs to be careful" argument. Correct me if I'm wrong, but I think hypothetically the same issue would exist in the OpenMC-Nek coupling. If the mesh in Nek were coarser that the OpenMC discretization, we'd also miss out on some of the heat deposition. That being said, I agree it would be nice to check this. A better way to do this might be to loop over all OpenMC materials/cell instances that are fissionable and make sure that they are included in the mapping.

[aprilnovak]

Yes, the same issue would exist for OpenMC-Nek. I like the idea of checking that all fissionable cells are accounted for, that's more general than what I was thinking.

[aprilnovak]

Actually that would work for the fuel, but not for the coolant or cladding...