Action to convert RGMB geometries to Shift/Titan MC geometry

[kkiesling]

Reason

This is an extension of #21445

There is an immediate need to be able to convert Reactor Geometry Mesh Base models to Monte Carlo CSG models for SCALE's Shift code in FY23. After discussion with various NEAMS and Griffin developers (@shikhar413 @eshemon + Javi, Yaqi, and Changho), we determined the likely best location for this converter method would be as an RGMB Action in MOOSE since the method is specific to that geometry definition handled by MOOSE.

Design

Implemented would be an action to take the RGMB input definitions (not the mesh directly) and convert it to the new Titan CSG syntax for Shift which would include geometry, material, and source/tally information.

We also discussed methods for going from generally MOOSE meshes to DAGMC mesh geometries (not CSG) that can be used for a variety of MC codes. This particular method is more involved and won't be able to address immediate needs this FY but if these details are of interest, I can share them.

Impact

Better support for reactor modeling workflows. Adds a new action to the reactor module.

[kkiesling]

Looking for input from @GiudGiud on this action

[GiudGiud]

An alternative to parsing all the mesh generator parameters would be to use the mesh meta data.

It depends on how you envision the process I guess:

• following the same construction process step by step as the mesh generation or
• decomposing the final mesh using its metadata to find its parts, then figure out the steps from the natural pin/assembly/core hierarchy

An action would be the way to go for sure. Is Titan CSG open-source ? We could have it as a contrib in the module

[kkiesling]

Thanks @GiudGiud - I just discussed this with @shikhar413 and he suggested using the metadata as well. It sounds like that would be the way to go if done all at the completion of the mesh generation. Whether the action happens alongside the construction process or at the end I think is still up for discussion. It seems like it could be done both ways with pros and cons to each. The Titan input scheme takes on a similar model structure as RGMB so I think doing it alongside the mesh generation process would actually be fairly straightforward. I plan to explore that implementation first and see what is/isn't doable.

Titan/Shift is not open source (it's a part of SCALE). Titan has a C++ API that can be used for constructing the models or one can manually generate the JSON text input files. Because it is closed source I was not going to use that API here. Though it would be useful to use a JSON package for C to generate and write the JSON objects (there seem to be many open-source options for that if MOOSE doesn't already have one as a dependency).

[GiudGiud]

So you would be generating the JSON files that Titan can read? And just to be clear, the CSG is represented as a JSON file. Is Titan both the reader and the generator of those files in Shift ? (full disclosure, I am still in the process for Shift approval)

We use the nlohmann json iirc.

[kkiesling]

Correct, I would be generating JSON files that Titan can read which defines the CSG model. Titan is a frontend interface developed for Shift specific to defining reactor geometries, I am not exactly sure how do define it as a reader or generator as I am not entirely sure what it does under the hood but I know that models are developed using the Titan syntax (either by using the API to make the JSON or just making the JSON by hand) and then the simulation is run with the Titan executable. How exactly it interfaces with Shift I am not full sure (nor sure if I can share if I did know). But Shift can technically use a wide array of geometry definitions and is executed through a frontend. Titan is basically a new frontend developed as a convenient interface/input scheme for reactors.

[eshemon]

Does Shift need the material assignments*? I'm not sure this is in the metadata. it is, however in the RGMB input.

[kkiesling]

Yes Shift would need material information.

[GiudGiud]

This could be retrievable from the Mesh directly too.

Another point to settle is whether we want to hold a general CSG definition of the geometry before outputting. And if so, should it be a new system in MOOSE or should it pull an open-source (openMC?) geometry system to do that

[kkiesling]

Another point to settle is whether we want to hold a general CSG definition of the geometry before outputting. And if so, should it be a new system in MOOSE or should it pull an open-source (openMC?) geometry system to do that

Honestly all great things to think about that we have also been thinking about and discussed. I am not sure how much of the decision making process to get into here but basically this wouldn't be able to be immediately available this FY which is why we settled on trying to get RGMB-to-Shift at least available this FY. This would be worth a conference call with @eshemon to discuss further.

[shikhar413]

Just chiming in re: material definition. The convertor right now would focus on RGMB-based geometries and therefore would also have the region_id extra element id defined on the mesh. As an alternative to parsing the input parameters to extact this information, another way to extract this information after mesh generation is to figure out what type of region each mesh element corresponds to (pin ring, pin background, pin duct, assembly background / duct, or peripheral ring), and then extract the region id (i.e. material id) for each element type. As of right now, not sure if this is simpler than parsing the input parameters directly

[GiudGiud]

The difference may lie in the amount of re-usable capability generated. Reading input parameters from other objects seems more brittle and would likely not be an API that you would share with another object. It goes against modularity to share parameters from one syntax to another

On the other hand, solid mappings between meshes and materials seem highly useful for other problems (depletion maybe?)

[GiudGiud]

What's the call here?

[kkiesling]

Sorry to leave this hanging- I don't know enough at the moment to make a call on which method would make most sense to implement for the material mapping. If you have a preference, I can start by attempting to implement that method first.

[GiudGiud]

I'd like to see a Mesh & mesh meta data based solution, but I understand we'll have to add more metadata for it to work. I think it will work better in several cases useful to the community:

• output the geometry at the end of a simulation rather than at the beginning, for example if the final geometry is the output of an optimization study
• in the same vein, to output material definitions at the end of a regular calculation in a modified configuration; a depletion calculation maybe, with the updated compositions; a multiphysics calculation, with a thermally expanded SFR core configuration; or a cycle calculation where the assemblies would have been shuffled by Griffin from their original position
• go beyond RGMB, using the meta data for pebble bed reactors for example