limitations of binner.py

[tijmen]

This is not a bug report or really an "issue" but more of a conversation. I was encouraged to post here. @paganol @ziotom78 @marcobortolami @silviamich @fpiacentini

binner.py adds each data sample to the IQU maps by inverting the 3x3 matrix and assuming there is sinusoidal modulation of the polarization signals at 4f.
info_pix[1, 0] += cur_sample * inv_sigma2
info_pix[2, 0] += cur_sample * cos_over_sigma * inv_sigma
info_pix[2, 1] += cur_sample * sin_over_sigma * inv_sigma
I believe this is a good method for reconstructing the temperature and polarization maps from time-ordered data that consists primarily of a smoothly scan-and-sampled IQU map with additive white noise. However, for more realistic data with more complex features (e.g. non-white features like 1/f noise, line noise, and a strong 2f line), this binning mapmaker is either inappropriate or requires heavy pre-filtering such as a band-pass around 4f for reconstructing polarization maps. It would be good to a) acknowledge clearly the limitations of this method and b) write an alternative mapmaker that doesn't separate IQU on a per-sample basis, but either implicitly or explicitly demodulates the half-wave plate polarization modulation.

[ziotom78]

Hi @tijmen, thanks for the contribution. This kind of comments is exactly what's needed to start working on a dedicated map-making solution for LiteBIRD!

I believe this should be discussed together with the MAPLE group, so let's talk with Yuji.

BTW, regarding this comment of yours:

…for more realistic data with more complex features (e.g. non-white features like 1/f noise, line noise, and a strong 2f line), this binning mapmaker is either inappropriate or requires heavy pre-filtering such as a band-pass around 4f for reconstructing polarization maps. It would be good to a) acknowledge clearly the limitations of this method and…

the very first page of the “Map-making” section of the User's Manual states that

The framework provides the following solutions: A binner, i.e., a simple map-maker that assumes that only uncorrelated noise is present in the timelines, […]

[chinoney]

We plant to briefly discuss this business on the next MaPLEs meeting tomorrow. Please call in if you're interested in, @tijmen.

[tijmen]

I think it would be useful to have a binned mapmaking implementation where

• the I map is made from the bandpass-filtered TOD, say, [0,0.5f] with DC-removal and
• the QU maps are made from the bandpass-filtered TOD, say [3.5f, 4.5f] with 4f line removal.

[fpiacentini]

Dear all, I agree with this. I suspect that the 3.5-4.5 f_HWP filter is too narrow. It should rather be 3-5f_HWP, or 3.01-3.99f_HWP to avoid 3 and 5 f lines. Also in this case, I suspect we will be cutting power in the smaller scales of the polarization signal. It must be tested with different filter widths. Francesco

On 8 Dec 2023, at 10:45, Tijmen de Haan ***@***.***> wrote: I think it would be useful to have a binned mapmaking implementation where the I map is made from the bandpass-filtered TOD, say, [0,0.5f] with DC-removal and the QU maps are made from the bandpass-filtered TOD, say [3.5f, 4.5f] with 4f line removal. — Reply to this email directly, view it on GitHub <#277 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFAMXWA4HYGNRBBEWM6ADQDYILORZAVCNFSM6AAAAAA73H24IKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBWHA3DSMJZGY>. You are receiving this because you were mentioned.!

— Prof. Francesco Piacentini [+39 06 4991 4358] Dipartimento di Fisica - Sapienza, Università di Roma http://francescopiacentini.site.uniroma1.it <http://francescopiacentini.site.uniroma1.it/>

[tijmen]

I was recently reading
https://arxiv.org/abs/2305.01045
which also uses continuous polarization modulation. In S3.6.3 they describe bandpass filtering the TOD before solving for map pixels.