Polarization angle vs orientation of a detector

[ziotom78]

I am reporting here an email exchange between myself and @mreineck about the term “polarization angle”. What follows here is an excerpt from a few email from Martin:

I'm arguing that what we are currently calling the "polarization angle" should not be called polarization angle, but simply "psi" or so, since it is not necessarily related to polarization at all.

Imagine a beam that is only sensitive to I, but elliptical instead of axisymmetric. Then we still need three angles (theta, phi, psi) to describe how the beam is oriented relative to the sky, but none of them has to do with polarization.

[…]

I think there are two things:

• the naming issue described above
• the fact that in some parts of the framework, the effect of a HWP is emulated by adding two times the HWP angle to the "polarization angle". This only makes sense for ideal HWP and axisymetric beams, as far as I understand.

For the fully general case, beam convolution (and its adjoint, which will probably be used by mapmaking) needs the full set of θ, φ, ψ, and α (HWP angle) to do its job,and currently the interface is not set up for this.

[ziotom78]

Here is an excerpt from my answers:

Instead of “polarization angle” we might call it “orientation of the detector”, but they are clearly two different concepts.

Probably the most general approach would be to encode the time-ordered pointings using a matrix with four columns instead
of three.

However, I think this would be an overkill and would also be quite disruptive of the way the API is encoded. If we assume that there are only a few ways a HWP can modify the polarization, we could compute the HWP angle on the fly for each sample; in particular, I see two options:

• HWP rotating at a constant speed: α=ωt+α₀;

• HWP struck on a fixed position.

Both options are really the same, provided that the angular frequency ω can be zero. Then the 4π convolution module would just
take compute the HWP angle on the fly given the two parameters ω and α₀.

However, I am not an expert of HWPs: is it reasonable that ω be always constant?

[ziotom78]

And finally, here is Martin's answer:

Instead of “polarization angle” we might call it “orientation of the detector”, but they are clearly two different concepts.

I like "orientation"! Perhaps the easiest way to think about things is that (θ, φ, ψ) are the Euler angles that transform the beam from its "nominal" pointing/orientation (pointing to the North pole with some fiducial orientation) to the desired pointing/orientation.

I see. Probably the most general approach would be to encode the time-ordered pointings using a matrix with four columns instead of three.

However, I think this would be an overkill and would also be quite disruptive of the way the API is encoded. If we assume that there are only a few ways a HWP can modify the polarization, we could compute the HWP angle on the fly for each sample; in particular, I see two options:

• HWP rotating at a constant speed: α=ωt+α₀;

• HWP struck on a fixed position.

Both options are really the same, provided that the angular frequency ω can be zero. Then the 4π convolution module would just take compute the HWP angle on the fly given the two parameters ω and α₀.

However, I am not an expert of HWPs: is it reasonable that ω be always constant?

How about simply having a function or class object that produces an alpha array given an array of points in time? Implementing it for the two cases you mention is trivial, and if really necessary, users can override it as they like.

[fpiacentini]

Hi Maurizio,

On 5 Mar 2024, at 17:46, Maurizio Tomasi ***@***.***> wrote: However, I am not an expert of HWPs: is it reasonable that ω be always constant?

No. It will for sure fluctuate around the nominal value. The stability of omega and the knowledge of omega are requirements still to be consolidated. Francesco — Prof. Francesco Piacentini [+39 06 4991 4358] Dipartimento di Fisica - Sapienza, Università di Roma http://francescopiacentini.site.uniroma1.it <http://francescopiacentini.site.uniroma1.it/>

[ziotom78]

PR #305 disambiguates between the HWP angle and the orientation angle. We still need to optimize the computation of the angle and of the pointings, so that it can be done “on the fly” instead of storing all the pointing in memory, but this is an optimization and not a structural change.

I think we can close the discussion; feel free to reopen it if you believe there is still something that needs to be settled.