Run section setup and subsequent workflow changes

[SimonHeybrock]

This represents the updated understanding based on yesterday's pair-programming session with @astellhorn.

• We determine run sections (defining time binning) based on a number of logs.
• The reduction workflow (SANS, ...) must be able to return reduced data with time and wavelength bands.
• The direct-beam is computed from the reduced data. This is the major structural change compared to the previous version (where we only passed the sample data through the base (SANS) reduction):
  • We reduce all data (sample or not) using the base reduction workflow.
  • Afterwards we split the reduced result into sections
  • Direct beam functions operate on those reduced run sections.
  • ...

We have started writing some tests but those are still largely incomplete. Here is the new workflow structure:

[SimonHeybrock]

The workflow seems good. Only the test-data created in direct_beam_test should be changed as commented. For this I have created a sub-branch "run-section-setup-all-spinstates-together". Can you please have a look on that? It passes the pytest.

It seems you did not push your new commits to the branch.

[astellhorn]

Sorry I thought I did push it. Is it there now? - I have pushed it to the subbranch run-section-setup-all-spinstates...Does it need to be pushed to run-section-setup?

Also, now there are all four spinstates in one 250s loop, and there are 4 of these (in principle only two consequent runs would be needed).

[SimonHeybrock]

@astellhorn Please check if the latest commit correctly modifies the test as you suggested.

[astellhorn]

@astellhorn Please check if the latest commit correctly modifies the test as you suggested.

Can I somehow see the resulting arrays of polarizer/analyzer spin and positions as function of input-time, i.e., the created test-data? The sample-section is definitely correct, but I I am trying to figure out the resulting analyzer and polarizer positions of the -10-->0 time run and after

[SimonHeybrock]

We should probably extend the test to check this.

[astellhorn]

We should probably extend the test to check this.

That would be nice. I would like to check the final output before answering.

[astellhorn]

About the readout of cell status, spin state, depolarization state, etc, I got following message from Hal:

We must differentiate and record the neutron polarization settings and cell status separately, even if there can be redundant information. Time-stamped neutron spin setting = after polariser (-1,1,0=unpolarized beam), after analyser (-1,1,0=unpolarized beam). Time-stamped cell status = { cell: name, length, fill pressure, fill begin, fill end }, time cell installed, initial cell spin state(=-1,+1,0, correspond to neutron spin state), time cell spin-flipped (each flip a stamp), time cell depolarized , time cell moves into beam, time cell moves out of beam, time cell uninstalled, {FID characterization: time of measurement, settings…, measured FID parameters…}.

[astellhorn]

--> That means, we can read out the polarization state (polarized or depolarized) in the same way as the spin status

[SimonHeybrock]

Yes, that looks good to me! About the "assert_identical": this means if I run pytest, and the above created data would not have this sequence, it would yield an error message?

Yes

Also, do you think now (saying the cells should get a "spin-state"=0 when being depolarized), we should add the DataArray for depolarized data after 1000s of measurement in the same way as you have inserted the cells_out measurement before? I guess that would be a new branch/new pull request? it would need to be one DataArray for each single cell (e.g. pol in, ana out, pol_spin=0)

We will have to think about the general problem of having multiple files first, I think. Handling the depolarized once that is solved should be more straightforward. And yes, we will not do this in this PR.

[SimonHeybrock]

--> That means, we can read out the polarization state (polarized or depolarized) in the same way as the spin status

You are saying this is recorded in the NeXus files somehow?

[astellhorn]

You are saying this is recorded in the NeXus files somehow?

Yes