Meaning of Vector3d results for hexagonal rotation axes / how to convert

[maclariz]

I have some nice hexagonal clustering data now. And the misorientations at least partially make sense. What I need now is to convert the vector3d results for the rotation axis into 4-vector representation. To do so, I need some clarity on the meaning of the 3 indices. The first must be the a-axis, which really isn't controversial. The third must be the c-axis (although is it scaled to a cartesian cubic representation?) and is the second the [01-10] axis and is it scaled? Is there a conversion built in to 4-vectors?

Thanks

Ian

[hakonanes]

Hi Ian,

can you show how you obtained the misorientations? Are they the mean misorientations within each cluster as in the misorientation clustering user guide?

If the above is the case, the cluster_mean.axis (see user guide) should represent directions, as unit vectors (x, y, z), in the unit cell of the reference/initial orientation/grain in the cartesian reference frame (e1, e2, e3). To convert from (x, y, z) to [UVTW] in the crystal reference frame (a, b, c), you should be able to do the following:

>>> from orix.crystal_map import Phase
>>> from orix.vector import Miller
>>> phase = Phase.from_cif("phase_file.cif")
>>> rot_axes = Miller(xyz=cluster_mean.axis.data, phase=phase)
>>> rot_axes.coordinate_format = "UVTW"
>>> rot_axes.round()

How the crystal reference frame (a, b, c) is aligned with the cartesian reference frame (e1, e2, e3) is explained in this user guide.

[maclariz]

@hakonanes Yes, these are results from cluster analysis. Actually slightly more clusters found than really exist (it split some areas of very similar misorientation). And then I get all the misorientations to whatever I choose as the reference. But this looks like it should work. And should be able to use to identify relationships between different areas (there should be standard relationships in beta to alpha titanium transformation products).

[maclariz]

I already have a think in there for the point symmetry for HCP, and this is enough for the lattice vectors. Why do I need to import the full cell? Seems redundant.

[hakonanes]

Why do I need to import the full cell? Seems redundant.

Conversion from (x, y, z) in the cartesian reference frame to [uvw] in the crystal reference frame is done using the structure matrix, which requires the base lattice vectors and angles (see the end of the crystal reference frame user guide). But as you say, you don't need the full cell. Instead, you can create the Phase by hand by only passing the lattice parameters and the point group

>>> from diffpy.structure import Lattice, Structure
>>> from orix.crystal_map import Phase
>>> from orix.quaternion.symmetry import D6h  # 6/mmm
>>> lattice = Lattice(1, 1, 1.5, 90, 90, 120)
>>> phase = Phase(structure=Structure(lattice=lattice), point_group=D6h)
>>> phase
<name: . space group: None. point group: 6/mmm. proper point group: 622. color: tab:blue>
>>> phase.structure.lattice.base
array([[ 1.       ,  0.       ,  0.       ],
       [-0.5      ,  0.8660254,  0.       ],
       [ 0.       ,  0.       ,  1.5      ]])

[maclariz]

I get the following error:

DimensionError: Miller requires data of dimension 3 but received dimension 1.

The matrix I am putting in looks like this:

Vector3d (11,) [[ 0.4437 0.884 0.1473] [ 0.3508 -0.8959 -0.2727] [-0.9999 -0.0148 -0.0022] [ 0.9995 -0.0127 -0.0297] [ 0. 0. 0. ] [-0.3972 -0.9094 0.123 ] [-0.3237 0.9069 -0.2698] [ 0.2648 -0.9614 0.0752] [ 0.5847 -0.8112 -0.0085] [-0.5772 0.8166 0.0065] [ 0.9951 -0.0765 -0.063 ]]

[harripj]

Hi Ian, you will want to pass the Vector3d.data into the Miller class, for example:

>>> v = Vector3d(np.random.randn(11, 3)).unit  # example data
>>> m = Miller(xyz=v.data, phase=phase)
>>> m
Miller (11,), point group 6/mmm, xyz
[[-0.2861  0.8443  0.453 ]
 [ 0.9043 -0.006  -0.4269]
 [ 0.5595  0.7778  0.2863]
 [ 0.1686 -0.9783  0.1201]
 [-0.376   0.0614  0.9246]
 [-0.3882  0.2799 -0.878 ]
 [-0.6573 -0.6788  0.3272]
 [-0.4178 -0.2601 -0.8705]
 [ 0.8064  0.2214 -0.5483]
 [ 0.7576 -0.4204  0.4993]
 [ 0.9866  0.1632 -0.0068]]

The .data attribute returns the data as a NumPy array in most cases in orix.

[hakonanes]

Passing Vector3d should be supported... sorry Ian.

[maclariz]

I also get an error with:

rot_axes.round()

ValueError: The Miller-Bravais indices convention U + V + T = 0 is not satisfied

This suggests that the calculation is having rounding errors that it cannot recover from. I checked the calculation and the t values are being calculated correctly.

[maclariz]

Normalisation is odd on conversion to UVTW format too. All my vectors had length 0.27664721 after doing so (as calculated manually by me using my own knowledge of 4-vector maths).

[hakonanes]

Hm. So these are your Misorientation.axes

Vector3d (11,) [[ 0.4437 0.884 0.1473] [ 0.3508 -0.8959 -0.2727] [-0.9999 -0.0148 -0.0022] [ 0.9995 -0.0127 -0.0297] [ 0. 0. 0. ] [-0.3972 -0.9094 0.123 ] [-0.3237 0.9069 -0.2698] [ 0.2648 -0.9614 0.0752] [ 0.5847 -0.8112 -0.0085] [-0.5772 0.8166 0.0065] [ 0.9951 -0.0765 -0.063 ]]

and your misorientation symmetries are both 6/mmm (D6h)? If so, I'll try to troubleshoot tomorrow.

[maclariz]

@hakonanes I checked in the code, and no normalisation in conversion of uvw to UVTW, so that's why. I am going to check your vector to uvw conversion tomorrow. Just checking exam scripts now.

[hakonanes]

no normalisation in conversion of uvw to UVTW, so that's why

For completeness, our conversion

https://github.com/pyxem/orix/blob/2d18672bd3beccf5b9da78e1f22e944d12870c33/orix/vector/miller.py#L826-L854

follows Marc De Graef's convention in Introduction to conventional transmission electron microscopy (2003).

I am going to check your vector to uvw conversion tomorrow

This conversion assumes the following crystal axes alignment: e1 || a and e3 || c*, and is implemented like so

https://github.com/pyxem/orix/blob/2d18672bd3beccf5b9da78e1f22e944d12870c33/orix/vector/miller.py#L789-L790

[maclariz]

@hakonanes Having checked exhaustively, all the main calculation seems to originate in diffpy (i.e. beyond your control) and the normalisation choices made there mean that your vectors once calculated to uvw or UVTW will always be shorter than one a vector of the lattice. If I get the data out as numpy arrays, I can renormalise them using standard formulae for hexagonal indices. No need to make any code changes, although making an option for a normalised version could be considered in future.

[maclariz]

The results once I fiddled with them start matching expectations from crystallographic theory, such as in Wang, Aindow and Starink