Convert Quaternions into exponential map (FF-HEDM)

[minety]

I'm using hexomap (IceNine) for the NF-HEDM reconstruction. I found much more grains in NF-HEDM than FF-HEDM (find-orientations), which was about 1.5-2 times including some grains even less than 10 um. I'm trying to use these orientations obtained from NF-HEDM as seeding for the fit-grains process in hexrd, but found that there is no function available in rotations.py for converting quaternions (got from NF) into the exponential map which is in the grains.out file. Could you give me some suggestions or comments?

Thanks, Tian @joelvbernier

[joelvbernier]

@minety

You're are correct, this precise function doesn't exist, however, the pieces you need are in hexrd.rotations.

Observe:

import numpy as np

from hexrd import rotations as rot

piby2 = 0.5*np.pi

Xl = np.c_[1., 0., 0.].T
Yl = np.c_[0., 1., 0.].T
Zl = np.c_[0., 0., 1.].T

# change-of-basis taking components in fable/IceNine sample frame to hexrd
fable_to_hexrd = np.dot(rot.rotMatOfExpMap(piby2*Zl), rot.rotMatOfExpMap(piby2*Yl))

# Convert input quaternions to angle/axis via rotation matrix.  Some notes:
#
# *) `q_in` must be arranged column-wise (4, n)
#
# *) The outputs will have shapes (n, ) and (3, n), respectively
# 
# *) Hexomap/IceNine and hexrd have different sample frames,
#    so you will need to apply the proper change-of-basis
#
# *) IceNine and hexrd share the same crystal frame; verify Hexomap
#
# *) The convention for orientation in hexrd is that they take
#    components in the crystal frame to the sample frame.

# convert to rotation matrices
rmats_hexomap = rot.rotMatOfQuat(q_in)  # result is (n, 3, 3)

# perform change-of-basis
rmats_hexrd = np.dot(fable_to_hexrd, rmats_hexomap)

# get matrix invariants
phis, ns = rot.angleAxisOfRotMat(rmats_hexrd)

# now arrange as exponential map params
exp_maps = phis*ns

I agree that we should wrap this into a utility function ASAP; I'll work on that. Please verify that Hexomap uses the same crystal and sample frame definitions as IceNine. Let me know if you have any trouble!

[joelvbernier]

Also, regarding the number of grains... there are 2 major factors that can lead to the nearfield finding more grains than the farfield:

1. when a line-focus beam is used in the near-field vs. a box in the far-field
2. when grains of similar orientation exist at different spatial locations in the illuminated volume

The former is a simple consequence of the limitations imposed by dynamic range on the detectors; when you only use a line beam, the scaling between large and small grains is proportional to the cross-sectional area and not the full grain volume, generally leading to a more uniform intensity distribution. In the far field, the results are generally biased against small grains, since the exposure is chose to not overly saturate the largest grains.

Then latter is just a consequence of the resolution limitation for far-field. Orientation is the only real mechanism of contrast, so that the signals from similarly oriented (say <=1º) grains overlap significantly and can't be decoupled (easily...). Since NF is much more sensitive to spatial origin of the diffracted beams, you can separately identify these grains.

Lastly, there is always room for parameter optimization in terms of finding the most grains in FF.

Hope that helps :-)

[minety]

Thank you, it helps a lot. I was able to use the nf-hedm dataset to seed the ff-hedm fit-grains. I understand your point.   In my case, I can only find additional small grains that have been filtered out by a high threshold (I used 50, which is probably dbscan's limitation?) If I set a threshold of less than 50 on our HPC, it will take forever to find a solution for find-orientations. It normally takes around half an hour or so to get a result if it is over 50. (I can find roughly 1400 grains per layer) I know there should be some space to optimize parameters, I did this by trial and error by submitting hundreds of jobs to our HPC. But I haven't tried other algorithms other than dbscan.

[joelvbernier]

Yeah, you have to be a bit careful not to give too many points to dbscan, because it'll really bog down. The indexing algorithm really works well for what I'd call "intermediate" size volumes; if there are many, many separated reflections, then it makes more sense to switch to searching a grid on orientation space. There is a lot of experiential knowledge that comes into processing these data sets, as you are no doubt finding out :-)

[joelvbernier]

I think I will still add a utility function to convert quaternions to exponential maps in hexrd. Should be merged today.