shogas / sped_processing_playground Goto Github PK

Testing the rotations in the interactive plot in pattern_gen_visualizer gives some strange results for non-cubic crystal systems.

For a cubic structure, the last Euler angle seems to be the in-plane rotation, and no intensities or reflections are changed when adjusting this angle, which is as expected. However, with an orthorhombic or monoclinic crystal structure, the intensities and visible spots change siginificantly when adjusting this value.

In addition, there are some discrepancies when I check the Euler angles obtained for an input hkl. For instance, for a monoclinic crystal [1] input hkl=110 gives:

• this code (297.48, 105.67, 62.52) - here none of the angles seems to give in-plane rotation when I try adjusting them.
• Recipro (171.61, 105.67, 61.37) - I cannot find documentation on the used convention, but the first angle seems to be the in-plane rotation.
• VESTA (180. 90. 62.52) - obtained by converting the orientation matrix to Euler with transforms3d using 'rzxz' convention. Here the first angle seems to be the in-plane rotation.

By the way, just a small comment: I understand the input h k l as the zone axis, but hkl is by convention used for a reflection in the DP and for a plane in real space. If so, it might be better to rename these parameters to uvw, which is common notation for a vector or zone axis.

I might have misunderstood the conventions, and if so, please correct me :)

[1] https://materials.springer.com/isp/crystallographic/docs/sd_0261951

Diffpy, or at least my current version of it, has a terrible "fix" for windows paths. Relative paths work fine, but absolute paths do not if they are on the format 'C:/path/to/file.txt'. My temporary fix was to prepend a file protocol: 'file:///C:/path/to/file.txt', but that is confusing for local paths.

Suggested fix: Move the manual filename patching to the variable declaration so that the code further down is easier to follow.

The affine transform used to correct image distortion currently has to be found manually. It should in principle only depend on experimental factors like camera positioning relative to the screen and microscope settings, but in practice it is probably easier to find it by fitting on a known are of the pattern.

I will look into (partially) automating this, or at least separate the transform into translation/stretch/rotation/skew and create a way of visualizing it.

generate_complete_rotation_list needs a figure to explain the different angles.