openmc-dev
Integrate .vtk random ray output with regular OpenMC plotting classes
In addition to the usual geometry plotting capabilities available with openmc --plot, the random ray solver also is capable of outputting result data (e.g., flux, source, etc) at the end of a simulation. The output is currently in the format of a binary .vtk file that has 3D voxel data with a variety of fields (flux for each energy group, total fission source, FSR ID, material) and can be easily opened/viewed in Paraview etc. The data output happens locally in a single function of the random ray solver code base, and does not really utilize the capabilities of the existing OpenMC plotter.
The main issue preventing creation of a random ray plotter class that just inherits from PlottableInterface is that about 80% of the interface is dealing with RGB pixel coloring data, which is not relevant when outputting data directly to a .vtk. Additionally, the current OpenMC plotting capabilities are limited to converting material or Cell ID numbers into colors, and are not yet equipped to handle image generation for continuous variables like flux.
Longer term, it would be nice to bring the .vtk output abilities to OpenMC, such that mesh tally data could perhaps be output in much the same manner as the random ray flux output data. There are a few ways of doing this, but will likely involve a non-trivial reworking of the Plotting hierarchy.
Wondering if this mesh method in openmc is useful for writing flux mesh results to vtk
https://github.com/openmc-dev/openmc/blob/bf33a9e11bf288639df7d6aba9c6b39aeff0afdd/openmc/mesh.py#L278-L348
I was thinking about this morning and was wondering the same, @shimwell. RR has a pretty fixed set of data to write to VTK at this point, so I can see how it makes sense to generate VTK files from C++. When I was looking at supporting a VTK output format for unstructured meshes I realized that the combination of additional tally filters, scores, etc. could quickly add up to a very large VTK file with data that the user might not be interested in and is data that is also present in the statepoint file. So I settled on adding these VTK methods to the Python API where users can down-select data they'd like to apply to the VTK file rather that writing all data in that format by default. But again, w/ RR we have a fairly fixed set of data to write to VTK (for now) so maybe it makes sense to leave it as-is. Idk, just spit-balling here.
