Interface with destriper

[paganol]

We collect here the updates regarding the inconsistency we found in the current implementation of the destriper map-making. The map produced by toast2 and the map produced by litebird_sim using our interface to the toast2 destriper are inconsistent.

[giuspugl]

I think i found the inconsistency and it's mainly due to the pointing weights when we have a spinning HWP.

Running w/ a spinning HWP

The procedure i followed was proposed a while ago by @paganol and @sgiardie. We initialize noise-only (1/f + white) tods w/ lbs and then run the destriper with the interfaced toast2 mapmaker . As an extra validation we also use the same pointing and tods to populate a toast-like tod. then we compare the tods post destriper to see how the offset have been removed.

1. the first thing to notice is that the PCG of the destriper to solve for the amplitude of the offset after 70 iterations does not converge to 1e-13, but it stalled at around 1e-6 residuals for both lbs and toast . I think this is an indication that the data model is somewhat unconsistent.
   

2. Moreover, as you can see from the plot above it seems that it is not working properly at all: there is a low freq. modulation in the tod that wasn't present in the input signal( see left and right panels) . Indeed the baselines (orange and blue ) are one order of magnitude larger than the expected value (green) (middle plot) .

Running w/o a spinning HWP

When we turn off the HWP and run exactly the same cases as above everything seems to work as expected .

1. PCG converges to 1e-13 after 9 iterations for both lbs and toast.
2. the tods are effectively destriped as they lack of the low freq. offset ( very visible in the PSD , right panel).

We should thoroughly look into the way the weights are used to construct the tods, i think the bug should be somewhere there.