Polarized SANS metadata: test saving via the SANS command interface

[rbauststfc]

Part of #36147. See the design and requirements documents that are linked on that issue for more context.

It is technically possible to save via the SANS command interface as a final step in the reduction workflow, but this is not functionality that the SANS Group were previously aware of and so is not currently being used. They are keen to start making use of this to streamline their scripted reductions, and it will be particularly important for supporting the Polarized SANS reduction. We should test to ensure that the save functionality is working correctly.

The save is integrated into two workflows in the command interface:

• From the BatchReduce method.
• From the WavRangeReduction method (which is more commonly used). This one in particular looks to me like it may not work/work very easily at the moment. It offers a parameter where you can specify to save to file, however for this to work I think you may also need to set some save parameters first using the set_save method. While this method is technically accessible via the command interface, it looks like it has been set up with the purpose of being used internally in the BatchReduce method. We will need to test this and decide if any changes are required to get this working in a user-friendly way.

I've given a rough time estimate if we assume that some changes will be needed to WavRangeReduction.

[adriazalvarez]

@rbauststfc
It seems the save functionality is integrated with batch reduce functions, tested it yesterday with the LOQ_DEMO data with various save algorithms. This would save the loq example in the default save directory of Mantid:

from sans.command_interface.ISISCommandInterface import *

LOQ()

MaskFile("MaskFile.toml")
BatchReduce("batch_mode_reduction.csv","",saveAlgs={"SaveNXcanSAS":"h5"})

The WavRangeReduction command has an output_mode option which could save the results, but as you mention, it seems to have been prepared to be integrated with batch reduce and saving is not as direct.
My opinion would be to refactor both WavRangeReduction and BatchReduce, adding also the saveAlg keyword argument to the WavRangeReduction command.

[rbauststfc]

@adriazalvarez thanks very much for the investigation! Sounds like a good idea to add a saveAlg argument to WavRangeReduction. You mention that you think it would also be good to refactor BatchReduce - what did you have in mind there?

[adriazalvarez]

@rbauststfc So, there is some code at the beginning of batch reduce that sorts the saveAlgs argument into the right command for the state director as well as prepare the output mode for the WavRangeReduction. It can be extracted out of BatchReduce into a separate internal function that can be called from both command functions.

[rbauststfc]

Ah, great, that sounds like a really good thing to do.