Polarized SANS metadata: add SavePolarizedNXcanSAS algorithm

[rbauststfc]

Part of #36147. See the design and requirements documents, and the NXcanSAS specification proposal, that are linked on that issue for more details of what needs to be implemented.

We need to add a new algorithm that will handle saving reduced polarized SANS data. The suggestion is to call this SavePolarizedNXcanSAS. It should expose all of the properties that the SaveNXcanSAS algorithm does and then add the following that are specific to polarized experiments:

• Spin state configuration (takes a string such as: +1+1,+1-1,-1+1,-1-1, which tells us which child workspace in the input group corresponds with each spin state so that we can create the separate SASData blocks)
• Polarizer component name
• Flipper component names (as a list)
• Analyzer component name
• Magnetic field strength sample log name (the name of the sample log that holds this value for the run)
• Magnetic field direction (the actual value for the run)
• Pol Transmission workspaces - dictionary of these mapped to the relevant component name
• Pol Efficiency workspaces - dictionary of these mapped to the relevant component name
• Pol Empty cell workspaces - dictionary of these mapped to the relevant component name
• Electric field strength sample log name (the name of the sample log that holds this value for the run)
• Electric field direction (the actual value for the run)
• Initial polarization of He3 cell - dictionary of these mapped to the relevant component name (polarizer and analyzer could have values for this so we support both, even though the SANS instruments will only use this for the analyzer at the moment)
• Error of initial polarization of He3 cell - dictionary of these mapped to the relevant component name (polarizer and analyzer could have values for this so we support both, even though the SANS instruments will only use this for the analyzer at the moment)
• Gas pressure - dictionary of these mapped to the relevant component name (i.e. polarizer and analyzer are possible)

There are some metadata values we will need to save that are not being passed as properties and will instead be retrieved from the instrument that’s on the first workspace in the input workspace group. The polarizer, flipper and analyzer components will be looked up by name. If they have a parameter called “device-name” then this is the name that will be used in the NXcanSAS file. If it does not than the component name will be used. See the design document for full details about what and how relevant metadata is being stored as parameters in the IDF. See the NXcanSAS proposal and the requirements document for details on which metadata items are mandatory and non-mandatory, and how they should be specified in the file.

I would suggest that this issue is completed in (at least) two parts:

• Add an algorithm that can output a file that includes the mandatory polarized metadata plus magnetic field strength and direction (the magnetic field strength and direction across the sample is non-mandatory for a polarized NXcanSAS file, but in practice is required for analysis of the data by the SANS Group). See comment below that gives some information about the magnetic field strength value, as some further discussion may be required regarding some differences in LARMOR sample logs.
• Extend the algorithm to add the remaining non-mandatory metadata.

This issue should not be worked on until #38501, #38503 and #38504 have been completed.

[rbauststfc]

Some examples from Dirk of LARMOR and ZOOM runs with the sample log names that give the magnetic field strength value. In the LARMOR examples the logs don't actually contain the magnetic field strength value so this will require further discussion when we're closer to implementation to confirm what our scientists want to do in these cases:

Here are the parameter names:
For LARMOR 89280 ( 3D magnet), the parameter names are "XField3D", "YField3D", "ZField3D". The reading of orientation and the field magnitude is missing. This would need some investigation how to extract these values from the magnet control software or calculate them again and store the result in the logs.

For LARMOR 88969 (electromagnet), the parameter name is "mag_curr_val". This is actually an electric current and not a magnetic field value. We should make it a habit to measure the electromagnets, create calibration file and display the recorded field value. The current values are carried too far into the analysis stage with the danger of corrupting data (manually entering wrong field, look-up errors etc).

On ZOOM 45129 (HTS magnet) the name is "HTS_Field".
and for 43480 (7T magnet) it is just "Field".

As you see it is a bit of a mix. I was thinking abut producing a magnet class that streamlines how all these different kind of magnets are handled. This would also keep the magnet control out of the user scripts (and having a multitude of versions that may work ever so slightly differently).