Angle lookup fails for reflectometry live data reduction

[gemmaguest]

Original reporter: Max at ISIS

Description

Is your feature request related to a problem? Please describe.

When using the live data monitor from the ISIS Reflectometry interface, lookup of settings on the Experiment Settings tab fails if an angle is specified in the lookup criteria

To Reproduce

Live data needs to be running on an instrument at ISIS and you need access to the ISIS network to test this.

• Run this to check that live data is running and note the output angle GetLiveInstrumentValue(Instrument='INTER', PropertyType='Block', PropertyName='THETA')
• Open the ISIS Reflectometry interface
• On the Experiment Settings tab, enter the angle in the table and set the ROI to 70-90
• In the AnalysisMode drop-down, select MultiDetectorAnalysis
• In SummationType set SumInQ and in ReductionType set DivergentBeam
• On the Runs tab, click Start Monitor.
• The expected behaviour is that the angle will be found in the table and the specified ROI used for the reduction which should succeed. However, the angle lookup fails and falls back to the default settings from the IPF. Due to issue #33640 this causes the reduction to fail with a confusing error message Angle correction using ThetaIn can only be done for a single group in ProcessingInstructions, but the number of groups specified was 255

Expected behaviour

Live data has an angle associated with it and it should use the experiment settings associated with that angle if a match can be found; otherwise it defaults to the wildcard row if there is one, or the IPF defaults.

Note that we need to consider what to do with the additional lookup criteria added in #31795 as well. I think we will need to use GetLiveInstrumentValue to get the run Title from the instrument in order to do the lookup in a similar way Theta is found in ReflectometryReductionOneLiveData, e.g.

GetLiveInstrumentValue(Instrument='INTER', PropertyType='Run', PropertyName='TITLE')

Platform/Version (please complete the following information):

• OS: all
• Mantid Version 6.3.0 and earlier

Implementation notes

This is quite tricky to fix because table lookup is currently handled in the GUI but at this point we do not have the angle available; this is only found when the live data postprocessing algorithm ReflectometryReductionOneLiveData is run on each new chunk of live data. The angle may change so we cannot do the lookup in the GUI because it is a fire-and-forget operation that just starts live data monitoring.

We therefore need to pass the whole lookup table through to ReflectometryReductionOneLiveData so that the lookup can be done at the algorithm level. It has been proposed to pass all of the settings through to the workflow algorithms in a batch file rather than as individual properties, which would have additional benefits as well as solving this problem, although will be quite involved. See #33642

Alternatively we could pass just the lookuptable, perhaps also by json string and use the existing json parser, although that will need updating to support std types rather than Qt types, and the parsing functionality (at least for the lookuptable) should probably still be moved out of the GUI so we don't repeat large chunks of code. Hence I would prefer the full solution of supporting a batch file to run the reduction on. I've made #33642 a child of this issue to include that in the estimate.

[gemmaguest]

Removed milestone because this looks like too much work for this release

[gemmaguest]

Increased the estimate because this requires the lookup mechanism to be implemented at the algorithm level too, which will require robust testing, and ideally should be consolidated with the code currently used by the GUI. Removed the bug label because this is extending the scope of the original feature.

[stale[bot]]

This issue has been automatically marked as stale because it has not had activity in 6 months. It will be closed in 7 days if no further activity occurs. Allowing issues to close as stale helps us filter out issues which can wait for future development time. All issues closed by stale bot act like normal issues; they can be searched for, commented on or reopened at any point. If you'd like a closed stale issue to be considered, feel free to either re-open the issue directly or contact a developer. To extend the lifetime of an issue please comment below, it helps us see that this is still affecting you and you want it fixed in the near-future. Extending the lifetime of an issue may cause the development team to prioritise it over other issues, which may be closed as stale instead.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had activity in 6 months. It will be closed in 7 days if no further activity occurs. Allowing issues to close as stale helps us filter out issues which can wait for future development time. All issues closed by stale bot act like normal issues; they can be searched for, commented on or reopened at any point. If you'd like a closed stale issue to be considered, feel free to either re-open the issue directly or contact a developer. To extend the lifetime of an issue please comment below, it helps us see that this is still affecting you and you want it fixed in the near-future. Extending the lifetime of an issue may cause the development team to prioritise it over other issues, which may be closed as stale instead.

[github-actions[bot]]

This issue has been closed automatically. If this still affects you please re-open this issue with a comment or contact us so we can look into resolving it.