Although EBSDReader was designed to import EBSD data, it also can be utilized to import complex geometries to set initial conditions that aren't related to EBSD data. It isn't intuitive that this functionality can be used outside of EBSD related situations because of how all the functionality is named. Renaming EBSDReader and its related functionality to be more generic could help users see the potential of it, especially those who are unfamiliar with it.
The goal of this issue is to at least start the discussion on this change and to see opinions on whether this would be a good change to pursue.
Design
This would be up for discussion as it depends on the extent of these changes since there is a decent amount of functionality related to EBSDReader.
At a minimum, we could just update the documentation to explain the alternative ways that EBSDReader can be utilized. Multiple MooseObjects related to EBSDReader are lacking even general documentation, e.g. ReconPhaseVarIC and EBSDReaderPointDataAux. Adding the documentation for these objects could include more information about how they can be used with EBSDReader to accomplish goals outside of strictly EBSD related data.
At the other end of the spectrum, we could change the name of EBSDReader, all the related MooseObject names, documentation, and the terminology of data read into MOOSE to be more generic (such as grain or phase). We could keep documentation on how it specifically applies to EBSD data since that will likely remain the main use case of this functionality, but a user ideally wouldn't need to know about or understand EBSD data to start using this functionality for non-EBSD related purposes.
A middle of the road approach could be taken as well where a line is drawn somewhere on how much is changed. We would just need to make sure this doesn't increase confusion due to a mix of generic and EBSD related language.
Impact
This depends on the extent of the changes desired. If we go the full route of making everything generic, then this could require changing a decent number of existing APIs and code since the EBSDReader functionality has multiple components. If we go the minimum route of just changing documentation, then this could just be the addition of new documentation to explain other use cases to the existing objects.
lindsayad
commented
1 month ago
Motivation
Although EBSDReader was designed to import EBSD data, it also can be utilized to import complex geometries to set initial conditions that aren't related to EBSD data. It isn't intuitive that this functionality can be used outside of EBSD related situations because of how all the functionality is named. Renaming EBSDReader and its related functionality to be more generic could help users see the potential of it, especially those who are unfamiliar with it.
The goal of this issue is to at least start the discussion on this change and to see opinions on whether this would be a good change to pursue.
Design
This would be up for discussion as it depends on the extent of these changes since there is a decent amount of functionality related to EBSDReader.
At a minimum, we could just update the documentation to explain the alternative ways that EBSDReader can be utilized. Multiple MooseObjects related to EBSDReader are lacking even general documentation, e.g. ReconPhaseVarIC and EBSDReaderPointDataAux. Adding the documentation for these objects could include more information about how they can be used with EBSDReader to accomplish goals outside of strictly EBSD related data.
At the other end of the spectrum, we could change the name of EBSDReader, all the related MooseObject names, documentation, and the terminology of data read into MOOSE to be more generic (such as grain or phase). We could keep documentation on how it specifically applies to EBSD data since that will likely remain the main use case of this functionality, but a user ideally wouldn't need to know about or understand EBSD data to start using this functionality for non-EBSD related purposes.
A middle of the road approach could be taken as well where a line is drawn somewhere on how much is changed. We would just need to make sure this doesn't increase confusion due to a mix of generic and EBSD related language.
Impact
This depends on the extent of the changes desired. If we go the full route of making everything generic, then this could require changing a decent number of existing APIs and code since the EBSDReader functionality has multiple components. If we go the minimum route of just changing documentation, then this could just be the addition of new documentation to explain other use cases to the existing objects.