Improve detector distance to XY converter parser

[Tom-Willemsen]

It would be useful for the detector distance parser in dodal to be able to load GDA detector distance files without modification.

On VMXm for example, a detector distance file in GDA like:

VMXm det distance file

``` #Table giving position of beam X and Y as a function of detector distance #Take values from autoprocessing results in SynchWeb #Or take values from xds (in pixels) and multiply by pixel size 0.075 # 1. DIALS - detector.slow_fast_beam_centre=1277,1303 # Ybeam = slow * 0.075 # Xbeam = fast * 0.075 #Import data to dials. #Run dials.show imported.expt for currently slow,fast values. #Open imported.expt in dials.image_viewer and use ring tool to find differences to new centre and subtract from current values. #Multiply slow fast pixel values by 0.075 to get mm values. # values updated 03/12/2021 #E2 9M #dety=732mm Units mm mm mm #287 123.15 187.70 #613 123.15 187.70 #dety=718mm Units mm mm mm #282 123.169 168.479 #613 123.169 168.479 #dety=704mm Units mm mm mm #282 123.169 154.386 #613 123.169 154.386 #MX Settings #dety=676 Units mm mm mm 300 123.35 131.77 593 123.35 131.77 #613 123.2 126.2 # ## # To load lookup table go to jython terminal # type reloadLookupTables() ```

failed to parse (due to using multiple spaces as a separator, in this case).

This issue is to adjust dodal's parser to be able to cope with this kind of file, and to write corresponding tests to prove it.

• Suggest gathering a representative sample of these files from MX beamlines and using those as unit-test cases.
• Check the parsing logic used by java to see if there are any other cases we're cot covering properly
• Making Units a "comment" seems wrong, is this going to catch us out if some beamlines start defining different units?
  • I feel we should at least be checking that the units are what we expect.

Once this issue is done, make hyperion_fast_grid_scan in GDA point at DetDistToBeamXYConverter_E9M.txt on VMXm and delete the _hyperion version.

[stan-dot]

what decides whether a file in GDA is xml (human readable, machine readable) and what is txt (human readable, machine-parseable-if-effort-results-still-brittle)? @iain-hall

does this question only apply for MX beamlines @DominicOram ?

[DominicOram]

I'm not sure how it is done on other beamlines. Our long term plan for this is move all the information into a config service, which we pull from using REST. The underlying representation of the data can stay on disk as these files for the medium term and we can move it to a different storage format down the line when everything only depends on the REST service.

[stan-dot]

Our long term plan for this is move all the information into a config service, which we pull from using REST.

I think that'd be a solid default option for any beamline config going forward

[stan-dot]

should we close this then as work on it wouldn't align with the long term goals, @DominicOram ?

[DominicOram]

We will need a parser for the medium term and this issue may end up blocking us moving to other beamlines so I'm inclined to keep it open

[stan-dot]

can we change the distance file to JSON? and update both GDA and the python parser?

sounds easier than dealing with raw txt?