Feature improvements for SANSTubeCalibration

[rbauststfc]

The following improvements have been requested by our scientists for the SANSTubeCalibration algorithm, which is used for calibrating the Sans2d instrument at ISIS:

• [x] The cvalue printed output should give the tube number expressed as module and tube number, i.e. instead of saying tube 87 was above the cvalue threshold we should say module (or mod) 4, tube 15. We can find the module and tube number based on fact that there are 5 modules of 24 tubes, with tubes numbered 0 to 23: module = math.floor(tube_num / 24) + 1 and tube = tube_num % 24 (note these calculations are already in the script). - 1 day for this and item below

• [x] Save the cvalue printed output as a file, as this needs to be referred back to for deciding which tubes to mask. This must be output with the correct detector suffix to avoid overwriting. It would also be good for the cvalue workspace in the ADS to have the correct detector suffix to avoid overwriting from successive calibrations.

• [x] At the moment the SaveIntegratedWorkspaces parameter saves to the user's default save location. However, the instrument scientists would like to be able to specify a save location, so this should be changed to a parameter that takes a filepath rather than a boolean value. If this parameter is left empty then it would indicate that no save should be performed (this is important behaviour to prevent anything saving out from our system tests). - 1 day

• [ ] At the moment the strip positions are passed as a parameter to the algorithm and the order needs to correspond with the order of the input run numbers. There is an obvious risk that the order of the positions will be passed in out of sync with the order of the runs. Additionally, in the code we include extra parameter validation and take care about maintaining the strip position-to-workspace order, which adds extra complexity. It turns out that the strip position can be retrieved from the workspace sample logs instead under values Front_Strip and Rear_Strip. The strip position is the same for both, so in reality either can be used, although we may want to look up Front_Strip for a front detector calibration and Rear_Strip for a rear detector calibration. These are float time series properties - the correct value to use is the last value in the series and it should be rounded to an integer. 1 day

• [ ] When supplying the DataFiles parameter, it would be much easier if users could supply just the relevant run numbers. At the moment they need to supply them in the format SANS2D0001234.nxs, but they would like to be able to supply just 1234 and have the algorithm create the full name (assuming the default instrument is set correctly in Mantid, this may already work, in which case we could just add an informative error message to prompt users to check their default instrument in the event of a run not being found or automatically append the SANS2D instrument prefix to the run number). - 0.5 day

The below have been mentioned, but we should confirm if they are still required before making any changes:

• [ ] The calibration algorithm has to be run twice for SANS2D (once for rear detector and once for front) and because output workspace names are not unique they are overwritten on the second run. A lot of diagnostic workspaces are currently output, so we should identify which of these need to be retained and therefore shouldn't be overwritten. The rest should probably be cleared to avoid confusion over which have come from which run. - 1 day

• [ ] The algorithm loads the data files, then rebins and saves the output of this stage to a Nexus file in the user's default save location. The reason for saving at this stage is because data loading and rebinning is very slow, so if the user runs the algorithm a second time then the saved workspaces can be retrieved and this step can be skipped. The algorithm may need to be run multiple times during a calibration as it can be necessary to tweak parameter values to get the best result. The saved files are not cleared from the user's machine at the end of processing, though. We've been asked to provide an option to clear memory to force the algorithm to start with a fresh run. - 3 days