logbook:commanderissues [Probe Mission Study Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Commander Issues ======




=== E-mail from Hans Kristian (March 1, 2021) explaining Commander Issues ===

Hi, all,

Thanks for looking into this! Here's a quick recap of the main points, in case the emails turn out to be difficult to disentangle:

1) The current sky maps are undersampled, in the sense that the beams are smaller than the pixel size. While this is not a problem for one-shot spherical harmonics codes such as GNILC or SMICA, it is a major issue for iterative codes like Commander that go back and forth between harmonic and pixel space all the time. We need the data model to be structurally complete, essentially, which in practice means that the data must be strongly noise dominated at the highest harmonic multipole. The best way of achieving this is to use pixelized sky maps that have at least 2.5 pixels per beam FWHM. So, if we actually want to simulate a proper PICO configuration with 1.1 arcmin beams, then we need maps at Nside=4096. Alternatively, we can artificially increase the highest PICO frequency beams to 10 arcmin (-> Nside = 1024) or 20 arcmin (-> Nside = 512), which won't really affect the tensor-to-scalar ratio constraints, but only underestimate our ability to reconstruct dust.

2) The current maps have correlated noise produced in harmonic space. This is a problem for us for two reasons: First, on a practical point-of-view, this is a noise model that we don't currently support in Commander, simply because no relevant experiment that we know produces this type of noise, and we therefore haven't spent any time on implementing it. If we actually want correlated noise, then we should go straight to TOD simulations, where the correlated noise is well defined -- this *is* supported in Commander, and we can work with that. On the other hand, if we want to stay in simple pixel-based sky maps, then we currently only support either a full pixel-pixel covariance matrix or scan-modulated white noise (ie., uncorrelated between pixels, but with spatially varying RMS). As a first go, it would be greatly prefered to start with the latter, just to make sure that things work as expected in that case. Then we can go for TOD modelling later. The second problem with harmonic-space generated noise is that it's bandwidth limited, and therefore don't have small-scale variations. Again, no experiment we have ever worked with on our side has a noise behaviour close to that, and we therefore don't support it yet -- the data really should be strongly noise dominated on small scales, otherwise our data model will break down.

3) The PySM thermal dust model has small-scale structure added according to a weird Nside=2 pattern. While not a fundamental problem as long as the data are properly bandwidth limited, as per point 1 above, it creates havoc in the current maps. It's also highly unphysical in general. It would be much better to use a more realistic sky model with no sharp Healpix-determined boundaries in the statistical foreground properties. But again, this is a secondary issue, as long as the signal component is properly bandwidth limited and the data are noise dominated on small scales.

Thanks!

Hans Kristian
User Tools

Page Tools
