Is there an existing plan for this?
Description of the Feature, Filter, or Functionality?
Hello,
I am currently working with experimental data obtained from scanning 3DXRD experiments (DOI: https://doi.org/10.1038/s41598-024-71006-0). Conceptually, the dataset is very similar to a 3D-EBSD dataset: it contains slice-by-slice voxelated microstructure orientation information, but additionally includes per-voxel elastic strain tensors derived from diffraction measurements.
To perform the final post-processing of these datasets, I initially explored DREAM3D-NX through the trial license and later moved to simplnx. My goal was to export the experimental data into an H5EBSD-like format and reuse the existing 3D-EBSD processing workflow already available in simplnx.
The approach I explored was to treat elastic strain fields as additional optional datasets accompanying the standard orientation-related datasets already present in the H5EBSD structure, similar to how fields such as MAD or Error are handled. Since most workflow operations primarily act on the spatial microstructure representation and orientation information, this appeared to be the least intrusive way to extend the workflow while preserving compatibility with the current architecture. In this sense, the elastic strain fields effectively accompany the orientation data in the same way as existing auxiliary datasets such as MAD or Error.
Alternative approaches such as introducing a completely new manufacturer type or implementing a dedicated plugin seemed unnecessarily heavy given the strong structural similarity between scanning 3DXRD data and existing 3D-EBSD datasets.
I forked the repository and implemented a working prototype of this approach, which I have successfully tested against my experimental dataset. During this process, I observed that the currently supported H5EBSD fields (for Cell Data) are largely predefined inside EbsdLib, and the H5EBSD reader only imports explicitly registered datasets. Therefore, supporting additional voxel-wise fields (such as elastic strain or similar diffraction-derived quantities) required modifications not only in simplnx, but also in EbsdLib itself.
At the moment, I have this working locally by extending the EbsdLib handling of H5EBSD datasets to recognize and import these additional elastic strain arrays.
I would be very interested in contributing these changes if this direction is considered sensible for supporting diffraction-derived datasets that are structurally similar to 3D-EBSD data. I would also greatly appreciate feedback on whether this implementation could be made cleaner or more aligned with the intended simplnx/EbsdLib architecture.
Longer term, if this workflow is considered useful, I would also be interested in implementing an H5EBSD exporter in ImageD11 (https://github.com/FABLE-3DXRD/ImageD11) to streamline the subsequent post-processing workflow in simplnx or DREAM3D-NX. I am already in contact with developers working on ImageD11, and I believe such interoperability could become increasingly valuable as diffraction experiments continue moving toward higher spatial resolution. In particular, when experimentally reconstructed microstructures are intended for downstream simulations, the existing simplnx processing filters become especially valuable.
I have not attached a minimum working example yet because the experimental dataset is not currently published. However, if the overall idea seems relevant, I would be happy to prepare and share a synthetic example dataset that reproduces the structure of the real experimental data. From the experimental side, the information is already stored in HDF5 format, so the simplnx-compatible structure can likely remain relatively flexible and be defined in a way that integrates naturally with the current workflow.
Thank you for your time. I would be very interested to hear your thoughts on whether this seems like a sensible direction for extending the existing H5EBSD workflow.
Version
7.x.x+ (DREAM3DNX)
What section did you foresee your suggestion falling in? [Further details may be required during triage process]
External Compatibility
High Level Steps To Implement
No response
Anything else?
No response
Code of Conduct
Is there an existing plan for this?
Description of the Feature, Filter, or Functionality?
Hello,
I am currently working with experimental data obtained from scanning 3DXRD experiments (DOI: https://doi.org/10.1038/s41598-024-71006-0). Conceptually, the dataset is very similar to a 3D-EBSD dataset: it contains slice-by-slice voxelated microstructure orientation information, but additionally includes per-voxel elastic strain tensors derived from diffraction measurements.
To perform the final post-processing of these datasets, I initially explored DREAM3D-NX through the trial license and later moved to simplnx. My goal was to export the experimental data into an H5EBSD-like format and reuse the existing 3D-EBSD processing workflow already available in simplnx.
The approach I explored was to treat elastic strain fields as additional optional datasets accompanying the standard orientation-related datasets already present in the H5EBSD structure, similar to how fields such as MAD or Error are handled. Since most workflow operations primarily act on the spatial microstructure representation and orientation information, this appeared to be the least intrusive way to extend the workflow while preserving compatibility with the current architecture. In this sense, the elastic strain fields effectively accompany the orientation data in the same way as existing auxiliary datasets such as MAD or Error.
Alternative approaches such as introducing a completely new manufacturer type or implementing a dedicated plugin seemed unnecessarily heavy given the strong structural similarity between scanning 3DXRD data and existing 3D-EBSD datasets.
I forked the repository and implemented a working prototype of this approach, which I have successfully tested against my experimental dataset. During this process, I observed that the currently supported H5EBSD fields (for Cell Data) are largely predefined inside EbsdLib, and the H5EBSD reader only imports explicitly registered datasets. Therefore, supporting additional voxel-wise fields (such as elastic strain or similar diffraction-derived quantities) required modifications not only in simplnx, but also in EbsdLib itself.
At the moment, I have this working locally by extending the EbsdLib handling of H5EBSD datasets to recognize and import these additional elastic strain arrays.
I would be very interested in contributing these changes if this direction is considered sensible for supporting diffraction-derived datasets that are structurally similar to 3D-EBSD data. I would also greatly appreciate feedback on whether this implementation could be made cleaner or more aligned with the intended simplnx/EbsdLib architecture.
Longer term, if this workflow is considered useful, I would also be interested in implementing an H5EBSD exporter in ImageD11 (https://github.com/FABLE-3DXRD/ImageD11) to streamline the subsequent post-processing workflow in simplnx or DREAM3D-NX. I am already in contact with developers working on ImageD11, and I believe such interoperability could become increasingly valuable as diffraction experiments continue moving toward higher spatial resolution. In particular, when experimentally reconstructed microstructures are intended for downstream simulations, the existing simplnx processing filters become especially valuable.
I have not attached a minimum working example yet because the experimental dataset is not currently published. However, if the overall idea seems relevant, I would be happy to prepare and share a synthetic example dataset that reproduces the structure of the real experimental data. From the experimental side, the information is already stored in HDF5 format, so the simplnx-compatible structure can likely remain relatively flexible and be defined in a way that integrates naturally with the current workflow.
Thank you for your time. I would be very interested to hear your thoughts on whether this seems like a sensible direction for extending the existing H5EBSD workflow.
Version
7.x.x+ (DREAM3DNX)
What section did you foresee your suggestion falling in? [Further details may be required during triage process]
External Compatibility
High Level Steps To Implement
No response
Anything else?
No response
Code of Conduct