Is madam destriping also the signal in temperature?

[ggalloni]

Hi,

I am working on the post-PTEP simulations to address the impact of 1/f noise in temperature (30mHz and 100mHz). The analysis aims to provide the Collaboration with a more realistic description of the noise in harmonic space. Specifically, the noise in each channel is described with a white-noise level, a $\ell_{knee}$, and a slope $\gamma$ describing how the noise is enhanced at large scales.

The pipeline is straightforward:

• the simulation maps are taken from /global/cfs/projectdirs/litebird/simulations/LB_e2e_simulations/e2e_ns512/. From there, I am considering both binned and destriped maps to assess the destriper's performance in harmonic space. I am considering the maps with CMB + FG + WN +1/f;
• the input maps are taken from /global/cfs/cdirs/litebird/simulations/maps/post_ptep_inputs_20220522/beam_convolved/coadded/. I am considering the maps with CMB + FG + WN +1/f;
• for each channel, I perform a simple hp.anafast to extract the spectrum of either binned_map - input_map or destriped_map - input_map;
• for each spectrum, I fit the aforementioned parameters (white-noise level, $\ell_{knee}$ and $\gamma$).

The results are shown in the attached figures below. Specifically, I am plotting the results for three representative channels (40 GHz, 140 GHz and 402 GHz). The solid colored lines are the spectra extracted through anafast, while the dashed colored lines represent the fitted curves. In solid black I show the CMB TT power spectrum as a reference.

For binned maps, everything seems to be working fine. On the other hand, you can see that something wrong is happening in the destriped case. This issue seems to be linked to the foregrounds present in the maps. Indeed, plotting the sky map for destriped_map(402 GHz) - input_map(402 GHz) and using norm="hist", I obtain the figure below.

Here, very clearly something is wrong along the galactic plane, especially in the I and IV quadrants, where more foregrounds are present. Indeed, applying a galactic cut to the anafast routine (30 deg), the issue at the spectrum level vanishes:

As regards the 40 GHz case, applying a galactic cut is not sufficient since few point sources are still clearly visible in the map.

In fact, while the excess power at large scales is removed by the galactic cut, the spectrum of the 40 GHz noise still present an unexpected bump at multipole around 500 (see image above).

This behavior can be explained by assuming that the destriper is acting on the signal, thus when I subctract the input maps from the destriped ones I get non-zero "signal residuals" in the noise maps. Clearly, this should not happen and indeed I checked that this is not the case for Q and U maps on the same channels. Also, note that the pattern of positive-negative signal residuals is also correlated to the scanning strategy.

What do you think about this? Is there any solution to such a problem?

[giuspugl]

Thanks a lot, @ggalloni for doing this test! seems to me an effect of the MADAM destriper. When the telescope scans a very bright region the baseline amplitude estimates are biased because of it. @keskitalo , @ziotom78 do you remember this to happen in Planck?

[keskitalo]

There are ways that a destriper can interfere with the sky signal and produce signal error. These require some sort of breakdown of the static signal model that the destriper employs. Sub pixel structure and beam asymmetry are the usual suspects. Planets, variable radio sources and Zodiacal light are examples of dynamic sky emission that also lead to signal error.

I don't remember the simulation specification. Was some sort of time-domain beam convolution used that would have supported sub pixel structure? Was the destriper run at a lower resolution than the final map binning? Did you use any kind of destriping mask? Planck destriping always included masking the bright Galactic emission and point sources to avoid excessive signal error.

[giuspugl]

Thanks a lot for the quick response,

Was some sort of time-domain beam convolution used that would have supported sub pixel structure?

no we employed maps with preconvolved gaussian beams

Did you use any kind of destriping mask?

am pretty sure we didn't . will check the resolution of the destriper .

[paganol]

I think this addresses this issue. We can close it. If we need to change the default e2g matrix in the code we can open a new issue.