Handle incoming polarized beam for analyzer transmission computation #64

SimonHeybrock · 2024-06-24T14:19:43Z

Fixes #58.

I need a detailed review here @astellhorn, since I am not at all confident that this is correct.

src/ess/polarization/he3.py

astellhorn · 2024-06-24T14:47:54Z

src/ess/polarization/he3.py

+class He3AnalyzerTransmissionFraction(
+    sl.ScopeTwoParams[PolarizerSpin, PolarizationState, sc.DataArray], sc.DataArray
+):
+    """Transmission fraction of the analyzer with polarized incoming beam"""


Hm, for me, the namings are unlogical. Do I see it correctly that you define He3CellTransmissionFraction as the transmission fraction for a 3He cell with an unpolarized incoming beam, vs. He3AnalyzerTransmissionFraction for an analyzer with polarized incoming beam?

Yes. Which names would you suggest?

I would call it He3TransmissionFractionIncomingPolarized and He3TransmissionFractionIncomingUnpolarized.
I know the names are long, but precise

SimonHeybrock · 2024-06-25T04:11:13Z

src/ess/polarization/he3.py

+    # The two transmission fractions do not share a common time coordinate. Therefore,
+    # we cannot concat along a third dimension for the fit, but concat along time,
+    # with an additional coordinate for the incoming polarization.
+    up = transmission_fraction_up.assign_coords(incoming_polarization=sc.scalar(1))
+    down = transmission_fraction_down.assign_coords(incoming_polarization=sc.scalar(-1))
+    transmission_fraction = sc.concat([up, down], 'time')


Another question: Can it happen that we have only one of the two?

No. For the polarized incoming beam, we need to compute this for both Up and Down, and then get the same fitparameters from both fits (combined fitting), for the output of T1 and C. We will define for the users to always measure both.

Actually its even more complicated. Because we assume that this is an analyzer 3He cell, its polarized for itself, so we do not only have incoming Up and Down, but also the polarization of the cell itself with Up and Down. But in the end, the transmission through the cell (and hence its parameters after this fit) only depend on two channels: if the incoming beam is parallel or antiparallel to the cell spin.

We could do that in 2 ways: (i) we combine the 2 spin channels (UU+DD, and UD+DU, as "parallel" and "antiparallel", respectively) or (ii) we only take one measured channel of each, i.e., in the workflow we could say take only UU OR DD for "parallel" and DU OR UD for "antiparallel. I am tending towards (ii). Because if the polarizer is not good then UU will be only = DD after the corrections, but not before.

Then we only have two fitting functions.

See update please!

For now I am assuming we have all four channels. It should be easy to adapt this later if we do not, but I wanted to avoid complicating this further. If it is ok with you then we postpone the (ii) case for later (could be soon, if needed).

So this is not something the software can decide/figure out, but the (instrument?) scientist needs to know, somehow?

If e.g. a supermirror is used, and the Flipper after the Supermirror polarizer is not perfect, then for the analyzer the incoming beam Up is not the same anymore as incoming Down, and hence T+ (for the "parallel" state, i.e., to get UU or DD) would "look different" for incoming Up and Down.

Similarly, if a 3He cell is used as polarizer, also T+ and T- for this cell can be slightly different and the same as above can arise.

But I would assume here that this can be a general case, and we have to differ it always for an incoming polarized beam.

... but if there are two different T+, wouldn't we also need to distinguish those two for performing the polarization correction, instead of using only the T+ obtained from UU?

T+ SHOULD be the same for incoming Up and incoming Down. I mean, if the incoming polarized beam (without sample) would be "perfect", then U should be the same as D, which it would be if we would have performed the correction already just for the polarizer/flipper, i.e., for the analyzer they would look the same. Then they have the same T+ of the analyzer, which should be the case. But if we do not perform the correction of intensities for the polarizer/flipper alone before we even compute T+ of the analyzer, I think it would look as if T+ would not be the same.

I split it off, see update please (or wait for our call).

astellhorn · 2024-06-24T14:55:31Z

src/ess/polarization/he3.py

@@ -187,6 +194,8 @@ def __call__(
        polarization = self.polarization_function(time)
        if plus_minus == 'plus':
            polarization *= -1.0
+        elif isinstance(plus_minus, sc.Variable):
+            polarization *= -plus_minus


Why -plus_minus? Is that basically giving the "down"-channel with leaving the computation to "polarization *= +1.0"?

Compared to the lines above, where we heaver either plus or minus, when plus_minus is a Variable we can handle different sections at once, some plus, some minus.

My question was rather a different one - what happens here for (i) plus_minus = plus or (ii) plus_minus = minus? If plus_minus = plus, then as beforepolarization *= -1.0, and if plus_minus = minus then polarization *= +1.0 ?

plus_minus is a scipp.Variable, containing values of +1 and/or -1. +1 means "plus", -1 means "minus". So plus_minus could be something like

[1,1,1,1,-1,-1,-1]

if we first measure the, say, UU channel, then UD.

And for the transmission function that means for 'plus': self.transmission_empty_glass * sc.exp(-opacity * (1.0 - polarization) and for 'minus':
self.transmission_empty_glass * sc.exp(-opacity * (1.0 + polarization) ? I actually just wanted to make sure I understand the calculation of transmission for different values of polus_minus

Yes, correct.

astellhorn · 2024-06-24T15:18:19Z

src/ess/polarization/he3.py

+    the fitted T(t, lambda).
+
+    DB_pol/DB = T_E * cosh(O(lambda)*P(t))*exp(-O(lambda))
+    """


This comment needs to be either changed or deleted here for the incoming polarized beam. Because its not the cosh(O(lambda)*P(t))*exp(-O(lambda)) function anymore, but the self.transmission_empty_glass * sc.exp(-opacity * (1.0 + polarization)) as written in class He3TransmissionFunction(TransmissionFunction[PolarizingElement]): in line 199

astellhorn · 2024-06-27T12:30:44Z

src/ess/polarization/he3.py

+    # The two transmission fractions do not share a common time coordinate. Therefore,
+    # we cannot concat along a third dimension for the fit, but concat along time,
+    # with an additional coordinate for the incoming polarization.
+    up = transmission_fraction_up.assign_coords(incoming_polarization=sc.scalar(1))
+    down = transmission_fraction_down.assign_coords(incoming_polarization=sc.scalar(-1))
+    transmission_fraction = sc.concat([up, down], 'time')


No. For the polarized incoming beam, we need to compute this for both Up and Down, and then get the same fitparameters from both fits (combined fitting), for the output of T1 and C. We will define for the users to always measure both.

astellhorn · 2024-06-27T12:33:38Z

src/ess/polarization/he3.py

+    # The two transmission fractions do not share a common time coordinate. Therefore,
+    # we cannot concat along a third dimension for the fit, but concat along time,
+    # with an additional coordinate for the incoming polarization.
+    up = transmission_fraction_up.assign_coords(incoming_polarization=sc.scalar(1))
+    down = transmission_fraction_down.assign_coords(incoming_polarization=sc.scalar(-1))
+    transmission_fraction = sc.concat([up, down], 'time')


Actually its even more complicated. Because we assume that this is an analyzer 3He cell, its polarized for itself, so we do not only have incoming Up and Down, but also the polarization of the cell itself with Up and Down. But in the end, the transmission through the cell (and hence its parameters after this fit) only depend on two channels: if the incoming beam is parallel or antiparallel to the cell spin.

We could do that in 2 ways: (i) we combine the 2 spin channels (UU+DD, and UD+DU, as "parallel" and "antiparallel", respectively) or (ii) we only take one measured channel of each, i.e., in the workflow we could say take only UU OR DD for "parallel" and DU OR UD for "antiparallel. I am tending towards (ii). Because if the polarizer is not good then UU will be only = DD after the corrections, but not before.

Then we only have two fitting functions.

astellhorn · 2024-06-27T12:35:44Z

src/ess/polarization/he3.py

+class He3AnalyzerTransmissionFraction(
+    sl.ScopeTwoParams[PolarizerSpin, PolarizationState, sc.DataArray], sc.DataArray
+):
+    """Transmission fraction of the analyzer with polarized incoming beam"""


I would call it He3TransmissionFractionIncomingPolarized and He3TransmissionFractionIncomingUnpolarized.
I know the names are long, but precise

SimonHeybrock requested a review from astellhorn June 24, 2024 14:19

SimonHeybrock commented Jun 24, 2024

View reviewed changes

src/ess/polarization/he3.py Outdated Show resolved Hide resolved

astellhorn reviewed Jun 24, 2024

View reviewed changes

SimonHeybrock commented Jun 25, 2024

View reviewed changes

astellhorn reviewed Jul 1, 2024

View reviewed changes

SimonHeybrock added 8 commits July 2, 2024 10:57

Add mermaid extension

06a5be2

Refactor Zoom workflow for new Sciline

b3f4c2e

Mermaid does not seem to work in notebook

9b985d7

Handle incoming polarized beam for analyzer transmission computation

8ef17e9

Docs and small fix

c63bd85

Remove outdated equation

5f1d4eb

Use clearer names

a94324a

Fix incoming-polarized spin channel handling

34655c9

SimonHeybrock force-pushed the incoming-polarized branch from e57adb6 to 34655c9 Compare July 2, 2024 12:00

SimonHeybrock added 3 commits July 5, 2024 08:59

Use plus/minus trans.fract as input, move channel merge to helper

dcde308

Improve naming and add to-do

f18ea58

Fix return type

723571e

SimonHeybrock enabled auto-merge July 5, 2024 09:19

astellhorn approved these changes Jul 5, 2024

View reviewed changes

SimonHeybrock merged commit 611e4eb into main Jul 5, 2024
3 checks passed

SimonHeybrock deleted the incoming-polarized branch July 5, 2024 09:22

Handle incoming polarized beam for analyzer transmission computation #64

Handle incoming polarized beam for analyzer transmission computation #64

Uh oh!

Conversation

SimonHeybrock commented Jun 24, 2024

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

astellhorn Jun 27, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

astellhorn Jun 27, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

astellhorn Jun 27, 2024 •

edited

Loading

astellhorn Jun 27, 2024 •

edited

Loading