Description
Description
Prior to support for unstructured mesh in the Mesh.write_data_to_vtk the only way to apply data generated in OpenMC to unstructured meshes was to write the files from C++ and populating fields with the library's native data API. This occurs right after a statepoint is written in openmc_statepoint_write. Some pretty opaque limitations are placed on this as well due to the logic required for labeling data based on arbitrary sets of filters, nuclides, etc. for tallies where the mesh is used.
Now that we support writing datasets and unstructured meshes to VTK from the Python API, it seems more natural for users to post-process data (normalization, volume-adjustment, etc.) using the Python API and write the mesh and data to the file with a user specified label.
In light of all this, I'll propose that we remove this capability and ask that users post process data directly from the statepoint file and write it to VTK using the existing methods on our Mesh classes.
Alternatives
Leave this in place alongside the Python capability. Given that I'd personally be guiding people away from using the C++ writing for creating unstructured mesh files with data, I consider it to be code bloat of sorts.
Compatibility
The removal of this capability _would_make addition of data to libMesh meshes of higher-order elements more difficult. We do currently support collision estimators on these types of meshes with libMesh. However, with the data selection and normalization issues that remain in this scenario I'd instead recommend that we add support for post processing of meshes with these element types in the same manner we do the rest of meshes instead. TBH I'd be highly surprised if anyone using higher-order elements with libMesh is relying on the C++ output capability.