Polarization/asymmetry

[Tom-Willemsen]

As an instrument scientist on muon beamlines, and on SANS/reflectometry beamlines that do polarization measurements, I want to be able to scan over "polarization"/"asymmetry" as my measured quantity

This quantity is calculated as (A-B)/(A+B)

• On SANS instruments e.g. LARMOR, A and B correspond to intensity in different DAE periods (before/after switching a flipper)
• Or reflectometry instruments e.g. POLREF, the situation is the same as on LARMOR
• On muon instruments, A and B correspond to measuring from different detector banks

ibex_bluesky_core should grow some support for these concepts.

---

Beware of correlations when propagating uncertainties, even after deriving the proper uncertainty expression for (A-B)/(A+B) we still need to ensure that A and B are not correlated with each other.

• e.g. correlation could happen if A and B are both divided by (and therefore correlated with) the same monitor counts prior to calculating polarization and this would then cause output uncertainties to be incorrect. In SANS/refl use case this shouldn't be true as there are separate monitor counts for each run (up/down flipper state). For muon use case it's the same run but no normalisation is done.

---

Acceptance criteria

• Talk to the scientists (e.g. in a scans catchup meeting or emails) to make sure we have correctly understood what we need to implement, what can be common, and what needs to be different (from science perspective)
• A function for correctly propagating uncertainties through the above expression.
  • def polarization(a: scipp.Variable, b: scipp.Variable) -> scipp.Variable:
  • Note: top and bottom of fraction are correlated so cannot just use scipp's built-in mechanisms for this
  • The partial derivatives with respect to a and b are:
    
  • Formula for uncertainty propagation given partial derivatives: https://en.wikipedia.org/wiki/Propagation_of_uncertainty#Simplification
  • Note: scipp uses variance throughout instead of std. dev.
• A PeriodPolarizingDae or similar device - which subclasses either Dae or SimpleDae, to cater for SANS/refl use-case
  • trigger()ing this device should lead to measurements in two different dae periods being taken, swapping the flipper in-between
  • read() must publish asymmetry and a asymmetry uncertainty.
  • Will likely need to take a reference to a generic "flipper object" to use (which may just be a BlockRw), so that it will be reusable across multiple sans/refl beamlines
• An MuonAsymmetryDae or similar device - which subclasses either Dae or SimpleDae, to cater for muon use-case
  • trigger()ing this device should take a single DAE measurement, but A and B are then intensities from different detectors.
  • read() must publish asymmetry and a asymmetry uncertainty
  • Split out into a different issue
• Pull out as much as reasonably possible into common helpers used by both of the above devices

Planning

10/01/25 - 00:13:45
28/11/24 - 00h37m