Allow multiple slicing intervals in reflectometry GUI

[gemmaguest]

Description

In the ISIS Reflectometry interface, it is possible to slice event data by specifying slicing intervals on the Event Handling tab, e.g. in 300ms slices. Currently it is only possible to slice the data once. However, for some experiments, users need to slice the same data in different ways, e.g. in both 300ms slices and 900ms slices.

In order to do this, at the moment users currently have to re-process the whole batch with the different settings. Instead, they would like to be able to set multiple intervals on the Event Handling tab so that they only have to process the batch once. Max has explained that they would ideally like something that provides equivalent functionality to the SANS GUI, which would allow something like the following:

1-2,10:1:20,20:30:500

Entering the above would slice out the period from 1 to 2 seconds. From 10-20 s it would provide a further block of 1s slices. From 20 to 500 s it would give 30s slices.

This isn't an urgent requirement, but would streamline the workflow when processing kinetic data.

Notes

• The slicing options on the GUI are already quite complex, with the ability to slice with custom lists, by log value etc. The screenshots below show an example of each option. We will need to make it clear that the new options are to re-slice the whole input run in different ways.

• We should check how much the current options are used at the moment, e.g. the "Python list" is actually mis-named at the moment and I don't think it is particularly useful; it takes a comma separated list and slices repeatedly alternating between the values, e.g. below it slices 300ms then 200ms then 300ms again till it reaches the end of the run. I think the original intent of this input was to be able to specify more complex slicing via a Python-like slicing string. In this case it could be extended to support multple fully specified ranges e.g. 0:300:5000, 0:900:5000 to slice the full range in 300ms slices and then in 900ms slices. The SANS GUI does something similar so we could perhaps re-use some code from there.

• We should check if it is also required to be able to use e.g. the uniform-number-of-slices option.

• Uniform slicing

• Custom list

• By log value

Implementation

• Slicing is done by the generic filtering algorithms but wrapped in our own custom algorithm ReflectometrySliceEventWorkspace algorithm, which converts the inputs from the reflectometry GUI into appropriate inputs for the filter algorithms. This would be the best place to encapsulate the new logic.
• However, some of the logic is also in ReflectometryISISLoadAndProcess. We should check if this is required or if it could be moved into the slicing algorithm. If so we would need to consider if the inputs to the slicing algorithm need to be changed and if this would need versioning to avoid breaking reproducibility of old results.
• It might be better for the slicing (and also the summing of runs) to be moved into ReflectometryISISPreprocess. We could perhaps consider tidying this up as part of this work but it is not urgent.
• Currently only one call to the filter algorithm is required, resulting in one output workspace group. We would likely need multiple calls to support the new functionality, which could be done from within the slicing algorithm. The outputs can probably still be all grouped together into a single group (but check with scientists). This should be straightforward to do in the slicing algorithm but we need to test carefully, including the case where the initial input workspace is a group.

[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.

[rbauststfc]

Re-open as still of interest.

[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.