The ApplyFloodWorkspace algorithm can take a flood workspace that does not contain values for all the spectra that are in the input workspace. In this case, the algorithm identifies which spectra are missing (by matching based on detector ID) and then creates a new flood workspace that adds them in with Y values all set to 1. The flood correction is then performed by dividing the input workspace by the new flood workspace, and this preserves values in the input workspace that we did not have flood data for. The rationale for this approach is described in this PR comment.
For the case where the flood workspace has a single bin, this works correctly. However, when the flood workspace has more than one bin then there is a step before the divide where we rebin the flood workspace to match the input workspace. If there are some spectra in the flood workspace that we have deliberately set to a Y value of 1 then these may be changed after the rebin. The divide that follows will then change the input workspace spectra that we were trying to preserve.
To Reproduce
The following script can be used to demonstrate the issue:
flood_ws = LoadEmptyInstrument(InstrumentName="POLREF", DetectorValue=80)
# Create 20 bins for the flood workspace
flood_ws = Rebin(flood_ws,0.025)
# Remove some of the spectra
flood_ws = CropWorkspace(flood_ws, StartWorkspaceIndex=245, EndWorkspaceIndex=883)
input_ws = LoadEmptyInstrument(InstrumentName="POLREF", DetectorValue=80)
# Create 10 bins for the input workspace
input_ws = Rebin(input_ws,0.05)
corrected_ws = ApplyFloodWorkspace(input_ws, flood_ws)
If you look at the data in corrected_ws you will see that all spectra have been changed when compared with the input workspace.
Expected behavior
Input workspace spectra that we do not have data for in the flood workspace should be unchanged after the correction, regardless of the number of bins in the flood workspace.
In the example above, you would expect corrected_ws to have different values in spectra 246-884, but all other spectra should have been left unchanged compared with input_ws.
Platform/Version (please complete the following information):
Mantid Version: since 4.0
Additional context
We have not seen this bug before because if you use CreateFloodWorkspace to create the flood workspace then it will have a single bin, and this is what INTER and OFFSPEC seem to do. The POLREF flood files have multiple bins, though, and this would prevent them performing flood corrections via the NR GUI (which uses ApplyFloodWorkspace).
For further context, following discussion with POLREF, it seems that they have a step in their flood correction code that integrates the multi-bin flood file to give a single bin workspace. There was apparently a vision to correct the flood in time as well as pixel, which would improve things in some cases, but they have yet to do this. When they use the GUI for soft matter users they use the Mantid flood creation algorithm so that it is consistent with ApplyFloodWorkspace.
Describe the bug
The
ApplyFloodWorkspacealgorithm can take a flood workspace that does not contain values for all the spectra that are in the input workspace. In this case, the algorithm identifies which spectra are missing (by matching based on detector ID) and then creates a new flood workspace that adds them in with Y values all set to 1. The flood correction is then performed by dividing the input workspace by the new flood workspace, and this preserves values in the input workspace that we did not have flood data for. The rationale for this approach is described in this PR comment.For the case where the flood workspace has a single bin, this works correctly. However, when the flood workspace has more than one bin then there is a step before the divide where we rebin the flood workspace to match the input workspace. If there are some spectra in the flood workspace that we have deliberately set to a Y value of 1 then these may be changed after the rebin. The divide that follows will then change the input workspace spectra that we were trying to preserve.
To Reproduce
The following script can be used to demonstrate the issue:
If you look at the data in
corrected_wsyou will see that all spectra have been changed when compared with the input workspace.Expected behavior
Input workspace spectra that we do not have data for in the flood workspace should be unchanged after the correction, regardless of the number of bins in the flood workspace.
In the example above, you would expect
corrected_wsto have different values in spectra 246-884, but all other spectra should have been left unchanged compared withinput_ws.Platform/Version (please complete the following information):
Additional context
We have not seen this bug before because if you use
CreateFloodWorkspaceto create the flood workspace then it will have a single bin, and this is what INTER and OFFSPEC seem to do. The POLREF flood files have multiple bins, though, and this would prevent them performing flood corrections via the NR GUI (which usesApplyFloodWorkspace).For further context, following discussion with POLREF, it seems that they have a step in their flood correction code that integrates the multi-bin flood file to give a single bin workspace. There was apparently a vision to correct the flood in time as well as pixel, which would improve things in some cases, but they have yet to do this. When they use the GUI for soft matter users they use the Mantid flood creation algorithm so that it is consistent with
ApplyFloodWorkspace.