Document grid scan coordinate systems

[rtuck99]

Rotations after xray centring sometimes are not aligned with the centre of the crystal, see:

Xray centred crystal: https://ispyb.diamond.ac.uk/dc/visit/cm37235-3/id/14661060 Manually centred same crystal: https://ispyb.diamond.ac.uk/dc/visit/cm37235-3/id/14661069

Observations after discussion with Mark, possibly this is multi-factorial:

• In zocalo_results.py we subtract a 0.5 box-width amount from the coordinates we get back from zocalo - it's not clear to me if this is correct or not, not knowing enough about how the analysis interprets its input data or what it outputs

• the number of data points for small crystals is very small (for some it may be a crystal only 2 x 1 x 1 boxes) and this may be affecting the quality of the returned centre-of-mass coordinate depending on the assumptions made in the analysis

• The heatmap superimposed on the grid in ispyb is somewhat misleading as it suggests we have more data than we really do - a discretised flat shading per box would be more representative than smooth shading interpolated from the limited data points

• Suggest that we reduce the grid size to collect more points per crystal, as per DiamondLightSource/mx-bluesky#231

• Investigate if the 0.5 grid size correction is actually the correct thing to do.

[ndg63276]

A reasonably simple example is at https://ispyb.diamond.ac.uk/dc/visit/cm37235-3/dcg/12456108, there is only diffraction on 2 images in each grid. Zocalo returned

[I 240725 10:00:35.145 zocalo_results:221] Received {'results': [{'centre_of_mass': [1.1030927835051547, 10.5, 4.5], 'max_voxel': [1, 10, 4], 'max_count': 234.0, 'n_voxels': 2, 'total_count': 388.0, 'bounding_box': [[0, 10, 4], [2, 11, 5]]}], 'status': 'success', 'type': '3d'}

which suggests an origin of the top left of box 1, but Hyperion removed the 0.5 box-width, as if the origin is the centre of box 1.

[rtuck99]

During investigation of this issue, I have found an issue with our variable naming in hyperion, it's not clear at the moment whether this actually affects the calculations or not, however it does make following the logic a lot harder:

DiamondLightSource/mx-bluesky#220

[rtuck99]

After further analysis, I think the main issue is likely to be the grid scan boxes are too large. The difference in motor position for x,y,z axes between the manually aligned vs XRC aligned collections are 7.5, -10.5, -15.3 um respectively, and this approximately tallies with what the oav crosshair shows when the two images are superimposed (where the orientation is such that x,z axes are used). These amounts are all smaller than 1 grid square.

It seems that the issue described in DiamondLightSource/mx-bluesky#220 doesn't affect the actual calculation as the um/mm mixup is reversed later on.

[DominicOram]

As part of this issue we should also document the co-ordinate system better e.g. is the top left the origin or is the centre of the box? Does the motor program/hyperion/zocalo agree on this origin?

[DominicOram]

Check this for the panda program too

[DominicOram]

We need to go through the whole stack and work out the coordinate systems and write a nice document on it