Fix rotation omega to match GDA behavior

[rtuck99]

These changes address #247

• This introduces a new omega_flip feature flag that can be set. The default is True. omega_flip should be specified according to whether the goniometer omega rotation axis is consistent with the nexus file specification or not https://journals.iucr.org/m/issues/2020/05/00/ti5018/ti5018.pdf

• The omega_flip determines the /entry/sample/transformations/omega vector in the nexus file and sets it to (-1, 0, 0) if True (in line with GDA) or (+1, 0, 0) if False. It also inverts the motor motions for rotation scans. When omega_flip is False, the smargon omega and the omega values in the request have the same sign.

• The rotation_direction request parameter now indicates the direction of rotation with respect to the omega sweep specified in the Hyperion request (whereas before, rotation_direction was always set to Negative by GDA, and this changed the physical motor direction but not the start of the rotation. Everything else was reported as positive in the nexus files and ispyb.

• The intention of these changes is that this makes Hyperion behave identically with GDA, under the following conditions:

  • omega_flip is True
  • rotation_direction is Positive

• As currently, rotation_direction is hard-coded in GDA, an alternative setting that would arguably produce "nicer" output in nexus files would be omega_flip = False, rotation_direction = Positive, however the motion would be in the opposite sense and nexus output would have have different (positive) transformation omega vector, so this would need to be tested to make sure downstream analysis tools are happy with the output.

• This change doesn't affect gridscans or rotation snapshots - we may want to also make changes for rotation snapshots if we want the reported snapshot angles to be congruent with the rotation sweep.

• I'm not sure whether a FeatureFlag is the best way of presenting this setting, perhaps it may be better as a soft (or maybe even hard) signal that's exposed by the smargon. I am open to discussion on this.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 86.96%. Comparing base (79d8aac) to head (db33f04).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #720      +/-   ##
==========================================
+ Coverage   86.94%   86.96%   +0.02%     
==========================================
  Files         101      101              
  Lines        6918     6929      +11     
==========================================
+ Hits         6015     6026      +11     
  Misses        903      903              

Components	Coverage Δ
i24 SSX	72.69% <ø> (ø)
hyperion	96.53% <100.00%> (+0.01%)	⬆️
other	96.58% <100.00%> (+<0.01%)	⬆️

[olliesilvester]

Looks like this fixes the issue, but it's annoying that we have to do lots of weird logic just to replicate a bug in GDA. Once we are no longer using GDA at all, maybe we can remove all this additional complexity. We could make another issue for that, although it would probably be years before we got around to it 🥲

[olliesilvester]

Did you mean to leave these in?

[olliesilvester]

Can we add a docstring to RotationDirection to explain that this now means the direction of rotation relative to the omega sweep in the Hyperion request

[rtuck99]

This is not the correct interpretation of RotationDirection, RotationDirection is used both in Zebra PositionCompare and in the RotationScan parameter class. A positive rotation in both these represent opposite rotation directions in the real world, if omega_flip is true.

RotationDirection represents the direction of the rotation in the context of the coordinate space of the interface that requires it as a parameter. It has only the meaning, that the sweep / rotation increment should be added or subtracted from the initial position, in whatever class is using it.