Return XRC locations in physical coordinates rather than boxes

[DominicOram]

From a hyperion point of view it will be a lot cleaner if zocalo returned results in mm/um rather than boxes so that we do not have to do the conversion in the DAQ side. The setpoints of the gridscan should already be written to the nexus file and are already read by the 3D XRC anyway (

python-dlstbx/src/dlstbx/cli/gridscan3d.py

Line 95 in 75915e3

for item in ("sam_x", "sam_y", "sam_z", "omega")

). Additionally, the readback values of the gridscan will soon be in there too DiamondLightSource/mx-bluesky#597.

Notes

• This may require some correction on the hyperion side if we're not correctly writing the positions, see NeXus: record sample position in real motor positions mx-bluesky#414
• We will probably want to keep the box co-ordinates in the result too as they may be useful

Acceptance

• Zocalo additionally returns XRC results in position coordinates

[ndevenish]

One thing here is that I don't know what that CLI script is for. It doesn't seem to be used by the actual XRC service, which doesn't read the files directly, only goes off of information sent to it from other services and data from the database.

This means here, the GridScan object. At the moment, it only pulls the shape, size of boxes, but it looks like absolute offset is in the schema, at least.

If the offset is written, and helpful, would a calculated position from what is written in the database be acceptable, or would you prefer to get the data (or the RBV data) from the actual file? (This latter would.. probably be possible but I'm slightly hesitant because then it is coupling the PIA to XRC such that you get different results depending on if the source has this information available or not e.g. GPU PIA would have to gather this information somehow)

[DominicOram]

This means here, the GridScan object. At the moment, it only pulls the shape, size of boxes, but it looks like absolute offset is in the schema, at least.

Ok, so I guess we can put the grid starting point (in mm) into there and it would be enough to be able to give us something based on setpoints.

If the offset is written, and helpful, would a calculated position from what is written in the database be acceptable, or would you prefer to get the data (or the RBV data) from the actual file?

I think it would be preferable to try and get the RBV into the analysis properly as it would open us up to:

• Being able to correct for misaligned grids (we had a meeting with @graeme-winter and @npat113 a few weeks back discussing that now we have better RBV this could be possible)
• Looking at different geometries for XRC rather than grids

(This latter would.. probably be possible but I'm slightly hesitant because then it is coupling the PIA to XRC such that you get different results depending on if the source has this information available or not e.g. GPU PIA would have to gather this information somehow)

I hadn't appreciated that this would be different in the GPU PIA case. My understanding was that the GPU just replaced the PIA but further downstream processing was the same CPU-run code which had access to database/filesystem.

I realise that this wont be as easy as I thought but I do think it's worth a chat about the cost/benefit of doing it. I will organise a meeting.

[DominicOram]

Discussed in a meeting with @graeme-winter, @ndevenish and Ollie S:

• We agreed that getting RBV values into analysis will be useful
• We agreed that coupling this analysis to the file system will be bad
• Instead hyperion will send the set points for the XRC at the start of the scan and the RBV values at the end of the scan (both via the messaging bus and both in motor co-ordinates e.g. mm/um)
• Zocalo will use the SPs for connected component analysis and the RBVs for giving back centres in motor co-ordinates
• Importantly PIA should not need to wait for the RBV values to start analysing individual images

Actions:

• @ndevenish to write up his immediate ideas on how to do it and schedule the work on the analysis side (no immediate rush)
• @DominicOram to discuss with controls on getting the RBVs without having to read from disk