Allow UI to set wavelength for characterisation strategy, and detector distance for both

[pkeller]

For discussion with @rhfogh and @phathaway

[pkeller]

At the moment, the detector distance and wavelength for the characterisation strategy cannot be changed from what they are specified to be in the characterisation strategy definition. In practice, the user would expect to be able to set these two parameters in the UI (except for detector distance on the DLS-I23 beamline).

There are three sources of values for these settings:

• Specified in the strategy definition read by the workflow
• Specified by the user in the UI
• The current settings of the beamline when the workflow is invoked.

We need to decide where in the message sequence the definitive values should be specified, and how this fits in with the existing BCS UIs.

[pkeller]

This issue was discussed between @pkeller, @rhfogh and @phathaway today.

Selecting the wavelength is fairly straightforward, since the specification of all the wavelengths needed for an experiment can be done right at the start. If only one wavelength is specified, it should be used throughout (including for the characterisation strategy). In this case, there could be the option to just use the current beamline wavelength. If more than one wavelength is specified, one of them must be selected as the characterisation wavelength. This needs a new enumeration literal in WavelengthRole. The class PhasingWavelength should also be renamed.

The detector distance is more complex. Repositioning the detector after the characterisation data collection, but before a strategy is calculated could be done as follows: add an optional field for detector distance to SelectedLattice and rename it to reflect its new role as providing information for the strategy calculation rather than being related exclusively to indexing.

Specifying the initial detector distance for a conventional beamline could be done in one of two ways:

1. No detector distance is specified by the workflow: it is completely up to the UI/BCS to specify a value (either keeping the current setting, or asking the user).
2. The workflow specifies a default detector distance in the ObtainPriorInformation message (which comes in practice from the current diffractometer calibration), and the UI/BCS can modify it by either reading the current detector distance, or by the user entering a new value.

Both of these possibilities have problems catering both for conventional beamlines, and DLS-I23's detector (which as far as the user is concerned, is fixed). (More detail needed....)

[pkeller]

The conundrum referred to in the previous comment is as follows: for a fixed detector, there is no point in the BCS returning a detector distance. The distance from an up-to-date calibration will probably be more accurate than the nominal distance that is accessible to the BCS from the instrumentation. This suggests that a property such as PriorInformation::requestedDetectorDistance should be optional. But, this makes it possible for the workflow to receive a null value from a conventional beamline: a constraint to avoid this for a particular beamline type cannot be specified either in the Abstract Beamline Interface data model, nor (easily) in the implementing class so as to force the BCS code to do the right thing. What can the workflow do for the two possibilities above?

1. The workflow must abort (or in the future, ask again, if a mechanism for doing this is implemented).
2. The workflow could assume that the default value has been accepted, however this relies on the UI forcing the user to "approve" it.

OTOH, making the detector distance property mandatory means that a fixed-detector beamline has to return a value which the workflow ignores, which isn't very satisfactory either.

[pkeller]

Another solution to this problem would be to provide a factory method for the ObtainPriorInformation message (declared in the interface of course) that allows the BCS to create the PriorInformation object to return to the workflow. The factory method would contain the checks that the detector distance had or had not been specified as appropriate for that beamline. Alternatively, define/provide two factory methods (one with, and one without a detector distance parameter) and ensure that only one is allowed to be called in any particular context.

If the conditions for calling the factory method are violated, an exception could be thrown or null returned.