-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conventions in orix #249
Comments
@pc494 great idea to make a separate thread for this.
I would throw my hat in for
[1] and [3] both seem to suggest the same orthonormal reference frame, namely: |
q1) As long as we're consistent, I think both are OK. The benefit of MTEX' approach is that the two reference frames are always aligned. I'm slightly in favour of a1 for this reason. q2) Agree with @harripj. I think we should write down the current conventions in a notebook and add it to the user guide, stating that these can change in the future. Then, when we decide to change something, we can run the notebook to see that we get the expected result, and change it accordingly. I can propose such a notebook based on the snippets and plots in #234 (comment) after that PR is merged. I suggest to include this notebook and the PR in v0.8, and wait for v0.9 with any changes following the discussion here. |
Could you expand on what this means? Where is the second reference frame coming from? |
I was a bit unclear here. In MTEX, the sample and Euler reference frames are the same (doc). I realise that (q1) didn't include discussions of the latter. That the axes in MTEX' stereographic projection (PF, IPF etc.) point in the same direction as the sample reference frame further simplifies thinking about reference frames, in my opinion. |
Yeah, I think this is a mark for later point. I'm trying to go as slowly as possible so that I don't get jumbled. |
Happy with this, but I think it's only half of what we need. In #236 we found that:
eg:
Then the case above becomes something like: Monoclinic, where beta > 90 (this is the convention in the data book I looked at, and in MTEX, but not in orix right now)
I think this might be just involve going through the International Tables and clearing things up. |
Okay, going to go away and have a think before trying to start the next phase. |
My two cents:
|
I think this is the approach we will go for, convert everything internally to Cartesians using a known arrangement that limits the choices of a,b and c. eg - A monoclinic cell must be defined to have |
Worth noting that this is not the case for EBSD and off-axis TKD (Transmission Kikuchi Diffraction).
This is done in the Miller class, which was demonstrated in #236. |
I have added a phase 2 to the OP. |
I agree. No functionality is lost, since the user can just invert the rotation instance if necessary.
I'm most familiar with Euler angles, thus I always use this, but I agree that definition from an axis/angle pair is more elegant and less error prone. If we implement #250, I'd be happy to change most or all the uses of |
I have now added a phase 3 to the OP |
I believe this is the opposite of the Bunge convention, which describes a passive rotation of the lab reference frame into the crystal reference frame. This is what is laid out in [1], convention 3. It was my understanding so far that we were going for the latter? |
I'm more than happy with multiplying by the inverse orientation g^-1 to translate crystal coordinates h into sample coordinates r: r = g^-1 * h. This follows the Bunge convention, but is the opposite of MTEX and Eq. (1) in the clustering paper. This is what we do when we plot a pole figure: select a crystal direction, and rotate it into the sample reference frame by multiplying with the inverse orientation. |
To clarify, according to [1] the passive/Bunge convention is a transformation from the sample reference frame to the crystal reference frame, is it not?
An example of exactly this is seen in #234 (comment). |
Bunge (in Texture and Analysis in Material Science) says: "We describe the orientations ... by specifying the rotation |
Similarly Rowenhorst et al. "the orientation of the crystal will be described as a passive rotation of the sample reference frame to coincide with the crystal’s standard reference frame" |
Which, I think means we've narrowed down a point of inclarity. MTEX, the orix manuscript (and almost certainly all current orix code) treats an orientation as Refinding https://www.ctcms.nist.gov/~langer/oof2man/RegisteredClass-Bunge.html has reminded me one of the reasons we do this, when working with Euler Angles (bad, don't do this etc.) it is way more natural to use the Rowenhorst/Bunge version as each angle corresponds to a rotation about a crystallographically known axis. Basically, I think we have the choice now, but it might be good to spend a little while about which operations are easier to keep track of in which conventions. For example:
for rotations UPD: or similarly:
should be the misorientation that takes Orientation A to Orientation B |
Hm, the references you're giving above to Bunge and Rowenhorst et al. are in line with #234 (comment), right? Code in that comment use existing orix functionality (and the current status of the unit cell plot PR with inverted rotations).
The last example of combining rotations in that comment assumes A rotates B, which is in line with Bunge, right?
The examples in the comment (and direct comparison of rotation conversions and quaternion/vector multiplication to the 3Drotations supplementary material to the Rowenhorst paper) tells me the crystal2lab and lab2crystal parameter arguments in |
I agree with the comment above. I think [2] might be wrong in it's explanation. The convention would then be that of Rowenhorst/Bunge/#234 (comment) For the documentation we can write something like:
My only final thought is what we say about passive/active, I (personally) find the terminology needlessly involved for working with two sets of axes (lab and crystal) but am open to thoughts. |
I think this means that |
Not a problem, I understood you once I engaged my brain! If you mean a minimal example of the conventions, I would prefer not too until we're sure all the code behaves, if you mean the notebooks, that might be a good idea, although I would lean towards getting something out at this point and maybe patching in the new year if needs be. |
I agree, let's do it in the new year. |
Computing a misorientation in orix@harripj and @pc494 brought this up in #276 (see #276 (comment) and newer comments). A misorientation @pc494 suggested to deprecate this syntax, in favor of obtaining the misorientation via a multiplication. @harripj suggested the following syntax MTEX can have a similar syntax |
I don't think that this is the misorientation from >>> m21 = ~o2 * o1
>>> (m21 * o2) * ~o1
Orientation (1,) 1
[[-0.0881 0.0051 0.3049 -0.9483]] I think the correct calculation should be: >>> m21 = o1 * ~o2
>>> (m21 * o2) * ~o1
Orientation (1,) 1
[[ 1. -0. 0. 0.]] So whichever direction, |
So we should simply raise a warning when doing |
I'm not sure whether there is a use case for it, I haven't come across one yet anyway. Perhaps others have some input on this? On a separate note regarding the implementation of this if we decide on it, as |
I checked MTEX, which returns a rotation when doing the opposite (to * ~from) of their misorientation definition (~to * from), so not even returning an orientation >> ori = orientation.rand(2);
>> inv(ori(1)) * ori(2)
ans = misorientation (1 -> 1)
Bunge Euler angles in degree
phi1 Phi phi2 Inv.
307.55 106.756 291.778 0
>> ori(1) * inv(ori2))
ans = rotation (show methods, plot)
Bunge Euler angles in degree
phi1 Phi phi2 Inv.
69.6646 77.0875 65.9812 0 We could do this, i.e. allow multiplication, but the new instance having no crystal symmetry.
Yes, inverting has to return an orientation specifying a rotation from the crystal to the sample reference frame for the definition |
I just want to bring a topic up again here which we touched on before but I think needs some clarity. In orix/orix/quaternion/rotation.py Lines 416 to 420 in d474f24
But from the MTEX docs and also in this thread #249 (comment) it is written that MTEX should actually be I think this was mentioned before by @hakonanes that these two ( |
Yes, they should be swapped. I think I first mentioned this in #234 (comment), and the following comments expands upon this a bit. I suggest we remove the EDIT: Showing a deprecation warning every time these methods are called is perhaps too much... We can at least warn about this change in the docstrings in a patch release. |
Add a keyword argument with More broadly, my feeling is that |
I agree that we should get rid of I must admit that this is confusing me somewhat still, by default By default I think that the direction should be
@pc494 I agree, so does having the two directions fulfils this or are there other cases we should also address? Also in the code the direction currently is handled here: orix/orix/quaternion/rotation.py Lines 450 to 451 in d474f24
This reads to me that currently only one direction is processed internally and then the direction is corrected after processing. |
I am pretty sure there are only two "directions" (I think I used "direction" as "active/passive" always felt like a can of worms). If orix tells you that the rotations is: 0.2 radians about (0,0,1) The "direction" tells you if that rotations takes your lab axes to the crystal axes or visa versa. The two conventions are related by a simple inversion. If users are working with data correctly imported to |
That's a solution for direct users of orix, yes. It's not a solution for packages, like kikuchipy, which then will emit many warnings. EDIT: Seems like
I agree. I prefer
No, default orix returns the opposite of MTEX. What is wrong in orix at the moment is that |
I've updated Phase 1 in the top comment with the chosen crystal axes alignment now documented. |
The only thing I see remaining here is a (notebook) user guide explaining the conventions for operating on vectors and orientations with orientations and misorientations. This guide could be added under the "Orientations" topic. |
Following on from: #234 (comment)
There are lots of conventions needed to work with orientations. We (the developers) are starting to learn that anything other than extremely well documented conventions will lead to problems. This thread aims to spell these conventions out, agree upon them, and also design a strategy for documenting them. I have decided to design it into "Phases" so as not to lead to information overload. Each new phase will be added to the top line to make life easier.
Phase 0 - Setting Terms
[1] D Rowenhorst et al 2015 Modelling Simul. Mater. Sci. Eng. 23 083501
[2] Johnstone et al. J. Appl. Cryst. (2020). 53, 1293–1298
[3] Krakow R et al.. 2017 On three-dimensional misorientation spaces. Proc. R. Soc. A 473: 20170274.
And the computer package MTEX (which we will refer to as [4]).
Phase 1
Two options jump out:
a1. Follow [4], x east, y south, z into page.
a2. Stick with what we have, x east, y north, z out of page.
Having decided this we should then decided how the crystal axes for each crystal system 'align' with this basis when no rotation has been applied. This basically involves completing the following table, ideally from a single authoritative source (perhaps noting disagreements with other source as and when needed). Appendix B of [3] suggests this might be a bit tricky. Adjacently, I think this is the cause of #236
So questions.
q1) a1 or a2?
q2) Do we have an authoritative source to complete this table, if not, which ones do we think are obvious and can be agreed upon (eg. cubic is a bit trivial)?
Phase 2
This is more of a code design element. I think we should make almost all
from_euler
code (and similar) private so that we can maintain a single internal set of conventions that are consistently applied. As an example, I believe the"lab2crystal"
and"crystal2lab"
arguments set whether imported data is "active" (static if your transform3d) or "passive" (rotating in transform3d) - this can get extremely confusing very quickly. Basically I don't think we want this exposed to users.In a later phase we will discuss whether we should use "passive" or "active", but this only makes sense if (under the hood) every import is converted into the same form. At present a reasonably careful user can run
from_euler
and be off by an inversion without anybody really noticing.(also as a mild addendum to this, I would be much happier if we used axangles in our examples over Eulers, but that's a much more minor point)
Phase 3
It seems we are broadly in agreement on the "passive" convention, in which a rotation R describes the transformation that brings the crystal coordinates into coincidence with the lab coordinates [2]. This has the slightly unwelcome side effect that
R * crystal_vector
is not the correct way to bring some crystal direction from it's "neutral" positions to that described by orientation
R
instead an inversion is needed.Would be good to check that everyone is happy with this.
The text was updated successfully, but these errors were encountered: