Feature: Gridding for rotation lists #47
Conversation
|
@EirikOpheim @tinabe - for reference. |
| Between 1 and 230 | ||
|
|
||
| resolution : float | ||
| The 'resolution' of the grid (degrees) |
There was a problem hiding this comment.
Can we specify what this means more precisely? Is it the misorientation between points in the grid?
|
|
||
| Returns | ||
| ------- | ||
| structure_library : StructureLibrary | ||
| Structure library for the given phase names, structures and orientations. | ||
| """ | ||
| return StructureLibrary(self.phase_names, self.structures, orientations) | ||
|
|
||
| def get_orientations_from_stereographic_triangle(self, inplane_rotations, resolution): |
There was a problem hiding this comment.
Why is this function getting fully removed? My impression is that this approach is the one used in the Meng & Zuo paper about improving automated indexation and in Rauch papers - so I doubt it's wrong in principle and in the short term, I'd have a preference for supporting it as a "community standard", but only if it's not a massive time sink.
There was a problem hiding this comment.
I missed this at first pass. I'm happy to keep it, will undo the deletion and make corrections in a different PR
|
This PR is now very big, @dnjohnstone would you be happy to merge it if: a) I undeleted the |
a) I'm happy for you to remove the get_stereographic temporarily and raise an issue/new PR to replace it because I think, from our other discussion, that what was there is actually wrong in current implementation - if it's not actually wrong then undeleted is good. b) yes you can do that, or even just raise a warning saying it only works for the cubic case? And raise an issue/ new PR to fix it. Then yes, happy to merge |
name: Feature: Gridding for rotation lists
about: This PR adds easier user function for providing rotation_list
WIP
Release Notes
What does this PR do? Please describe and/or link to an open issue.
Deletes all streographic triangle related functionality
Adds 3 new gridding functions in the file
rotation_list_generators.pythese are:1) full fundamental zone
2) a small region around a known orientation
3) around the beam for a known orientation
To support this, vectorisation of several transform3d functions is provided, as well as two smallish classes (
EulerandAxangle) inrotation_conversion_utils.pyDescribe alternatives you've considered
Internal work is done using vectorization of the code in transforms3d, see
rotation_conversion_utils.py, these are tested against the appropriate for loops. I could have either (1) used orix."Gridding" could be done in any number of spaces, with various levels of correctness. I've chosen to use euler angles for everything
fundamental zone code (anticipating speed ups that rely on this) and axangles for gridding code (for speed, as generating subsets of the space in euler angles is a challenge)