You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
pshriwise
changed the title
Remove output of unstructured mesh files from executable
Remove output of unstructured mesh files w/ data from statepoint write.
Jan 30, 2025
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 inopenmc_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.
The text was updated successfully, but these errors were encountered: