Add helpers to associate "periods" of ISIS files with spin channels

[SimonHeybrock]

The current workflow draft assumes that all spin channels are part of a single long run in event mode. For the ISIS test data this is not the case, instead each spin channel is in a different "period". Relevant part of workflow is

• Add helpers to associate "periods" of ISIS files with spin channels, which can then be used instead of the extract_sample_data_* functions.
• Note that the function inputs will be the results of passing each period through a regular ESSsans workflow.

[jokasimr]

How do we load ReducedDirectBeamData[Polarizer, Polarized] and ReducedDirectBeamData[Analyzer, Polarized] and ReducedDirectBeamDataNoCell from the ISIS data?

It seems sensible they should each belong to a separate period/workspace in the WorkspaceGroup, but from what I understand only four workspaces are present in the workspace group, and those represent ReducedSampleDataBySpinChannel[Down/Up, Down/Up]. Maybe this is a question for @astellhorn ?

[SimonHeybrock]

@jokasimr Is your comment in the correct issue? It seems unrelated to the 4 sample spin channels.

[astellhorn]

I think its connected to here cause of testing the polarization workflow on the ZOOM test data with the 4 periods for each spin channel?

Anyhow, the functions ReducedDirectBeamData[Polarizer, Polarized] and ReducedDirectBeamData[Analyzer, Polarized] and ReducedDirectBeamDataNoCellwere written assuming the ESS workflow where each spin channel should have its own .nxs file (If I remember correctly), and then each .nxs file has to be read out for which cell has been used and with which spin orientation.

For the ISIS test data, I am just having a look on it - but it would actually be really nice if we could sit together on testing the functions of the polarization workflow partially together (in-person) if you may have time one day next week?

[astellhorn]

In the polarization workflow, we use direct beam data to... (i) readout which polarizer and spin the measurement has by time-log (determine_run_section) which returns the RunSectionLog(sc.Dataset(logs)) (ii) reduce the input data by RunSection and Wavelength with the function run_reduction_workflow which returns ReducedDataByRunSectionAndWavelength(data) (iii) extract from this data e.g. the direct beam using extract_direct_beam which returnsReducedDirectBeamDataNoCell(data[is_direct_beam]) (and the others you mentioned accordingly)

--> Hence, we first of all should get the correct RunSectionLog(sc.Dataset(logs)) which has all information on if polarizer is used, analyzer is used, and their spin on a direct beam data set. in the test ZOOM files, the information on polarizer, analyzer, and spin can be found in the .nxs metadata at: (i) Polarizer: /raw_data_1/selog/Spin_flipper/value (--> If value <0 : Up, if value > 0: Down) (ii) Analyzer: /raw_data_1/selog/He_state/value (--> value = 1: Up, value = 2: Down) Unfortunately, in these scans both analyzer and polarizer always have been in, and the position is constantly "both in". TO test if the reference to a direct beam without the cell in works, we will have to take the "empty_cell" reference from the unpolarized SANS workflow.

(Note: the file I used so far - ZOOM00022717.nxs - is actually not a direct beam dataset as it was in transmission through a glassy test sample, but that is irrelevant as it all has the same structure with 4 periods. However, I will send a list of files for all workflow parts in slack).

[astellhorn]

Coming back to your question: Yes, each period of the ZOOM files has one spin state, but we actually need all of them together for the reduction. We additionally need the "NoCell" information (for which we have to use the empty_cell data from the unpolarized workflow).

[jokasimr]

Is this issue still relevant, or has it been fixed in the recent changes in esspolarization?

[SimonHeybrock]

Not relevant anymore / for now.