Under issues #35067 and #36981 we amended the PolarizationCorrectionWildes and PolarizationCorrectionFredrikze algorithms to allow different input flipper and output spin state orders. We now need to extend the ISIS Reflectometry GUI to support these new options. This is particularly important for PA experiments on POLREF, as the default input flipper configuration for PolarizationCorrectionWildes and the default input spin state order for PolarizationCorrectionFredrikze do not match the child workspace order for POLREF PA datasets, so we need to be able to specify this via the GUI.

Key assumptions and considerations:

• The flipper configuration of an instrument (relevant for Wildes algorithm) will change very infrequently, usually only as part of an instrument upgrade. As a result, this setting would be suitable to store in the instrument parameter file.
• The input spin state (relevant for Fredrikze algorithm) can change per experiment, and potentially (although less likely) per measurement. This is because POLREF have three types of analyser (transmitting, reflecting and off-specular) and they switch these out fairly regularly. The type of analyser determines whether spin up or spin down neutrons are counted, thus changing the spin state associated with the analysing flipper being on or off.
• Even where spin states have changed per measurement, there will still be batches of runs within an experiment that use the same input spin state. This means GUI users will be able to reduce their experiment in batches when different input spin states have been used, rather than needing to set spin states on a per-run basis.
• Changing the output spin state order can be useful for loading into different analysis software, however we expect that GUI users would only need to be able to do this in edge case scenarios. In addition, the spin state will be identified if the reduced data is saved out using the ORSO format, so hopefully that will help as adoption of that standard grows. As a result, we have agreed with our scientists that we won’t support changing the output spin state order via the GUI - people can instead re-order their workspace group via a script if required. This could be revisited in future if it became clear that there was a need for it.

Suggested solution:

Based on the above, we have agreed the following changes with our scientists:

For Wildes flipper configuration
Add the Wildes flipper configuration to the parameter file as follows:

  <parameter name="wildes_flipper_config" type="string">
    <value val="00,01,10,11" />
  </parameter>

We would then look this up from the relevant place within ReflectometryReductionOneAuto3.

For Fredrikze spin states

Add an additional input on the Experiment Settings tab of the GUI to allow people to provide an input spin state when using the Fredrikze algorithm (see Polarization Correction Fredrikze Input SpinState in screenshot below). The Fredrikze algorithm is expected to be used infrequently. The new input will need to be supported with a sufficiently detailed tooltip to explain what it is for/when it should be used and how to use it. The tooltip is particularly important because the GUI automatically detects which correction algorithm to apply (e.g. from the labels on the efficiency workspace) so a tooltip will be needed to avoid confusion over when this new optional input would be used. We should also ensure that there is enough validation to help users to use the input correctly and under the right circumstances (i.e. only if doing a Fredrikze correction). The input spin state would be applied to all runs that were reduced as part of that batch.

The new input should enable and disable according to the same logic that the existing polarization correction input fields do.

At the algorithm level, we would need to add a new property to ReflectometryISISLoadAndProcess to receive this setting.

Note that there are several different ways you could approach implementing this in the GUI, but we agreed with our scientists to go with this approach first because it should be straight-forward to implement. Depending on feedback once it starts to be used, the GUI layout could always be changed in future to improve usability, if necessary. We also discussed that if any further polarization settings were required in future then it might be worth creating a separate Polarization tab to hold everything, but again that would be something to address at a later time.

This is part of the Polarised Reflectivity epic.