Gridded Centres, Thermal Noise, PS Foregrounds

[BellaNasirudin]

This test is not converging. The parameters used are Smin=1e-1, Smax=1 for for CorePointSourceForegrounds and Tsys=200, integration_time =120 s for CoreInstrumental. We use the same parameters in base_definitions, with 500 realisations for the covariance.

Next step will be to:

1. reduce amplitude of foregrounds covariance
2. increase observation time

commit 6c06e903d4758d2832c5e7115074d039f4aba795

[steven-murray]

Cool. Let's see a plot of the signal to noise on each mode and a covariance at a single u. That might give more indication of why it's not converging.

On Mon, Nov 5, 2018, 1:11 AM BellaNasirudin <notifications@github.com wrote:

This test is not converging. The parameters used are Smin=1e-1, Smax=1 for for CorePointSourceForegrounds and Tsys=200, integration_time =120 s for CoreInstrumental. We use the same parameters in base_definitions, with 500 realisations for the covariance.

[image: image] https://user-images.githubusercontent.com/30033904/47988195-8dd9df80-e11c-11e8-8c1d-0a69a4d52957.png [image: image] https://user-images.githubusercontent.com/30033904/47988217-9e8a5580-e11c-11e8-839b-202e31302c50.png

Next step will be to:

1. reduce amplitude of foregrounds covariance
2. increase observation time

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/BellaNasirudin/py21cmmc_fg/issues/18, or mute the thread https://github.com/notifications/unsubscribe-auth/ABNo3i9yLRr3bEq4RrNXvog8lMw74a5Mks5usACWgaJpZM4YOCEz .

[steven-murray]

As a precursor to running this test properly, I am running small boxes and doing 2D PS diagnostics. I get the following plot:

There is some kind of bug that makes the first |u| bin here drop right down. It sprang up when I changed the code to omit the auto-correlations (baselines with zero length). Ignoring that, however, there is still a lot of weirdness going on. For one, the foregrounds seem to have exactly the same structure as the EoR, except brighter by 5 orders of magnitude everywhere. There is no thermal noise here. This doesn't make any sense to me, and will definitely result in non-converging chains.

Any ideas?

[BellaNasirudin]

Which commit is this plot based on?

For the 0 covariance, I figured out that it is due to the fixed random seed (for some reason, it is a constant for both foregrounds AND EoR ). This is why we keep on getting the same foregrounds each time. I have fixed this for the foregrounds with commit 5b8429b6b44f0dae65c1fd5b4fd8ec5fca93f51f , although I am uncertain whether the same random seed is still being used for the signal and MCMC with this fix. This can potentially cause a bias.

This is the resulting diagnostic plot:

This is run with DEBUG =1. I have also changed nfreq = 60 if DEBUG else 100 since it doesn't make sense to have such coarse channels.

[steven-murray]

Sorry, I should have posted the commit. I think it was this one: d9985a4035624161855bad4f488efc5e5a1410d6. I actually didn't notice that the "sigma" plot in my post had nothing in it... I'm pretty sure I usually get non-zero values there. I will check it out.

My two concerns were (1) that the FG and EoR seem to exhibit almost exactly the same structure, which we don't expect, I think (i.e. we expect the EoR to have more power at large kpar) and (2) the FG seem to be larger than EoR everywhere (your plot shows that the FG are only a bit higher than EoR, which is a bit of a relief, but still, I would expect the FG to drop more significantly at high kpar). This is going to make it very difficult to constrain EoR parameters!

Just thinking now -- I remember you mentioning that you needed to interpolate visibilities onto the grid cells when gridding, rather than just averaging within the grid cell, to get the sharp drop-off in the FG. I never did revert to this behaviour. It might be worth a try!

Please see my comments on your recent commits, as well :-)

[BellaNasirudin]

I figured out what was wrong. I plotted the EoR box and the stitched and coarsened boxes based on commit 5b8429b6b44f0dae65c1fd5b4fd8ec5fca93f51f

Notice that the flux density has not been coarsened correctly. I have fixed this with commit efd039fedf82f8c53d227e685e58109c50409db7. Here's the corresponding Diagnostic PS:

It looks a lot better but I would say that it is still not quite right since the foregrounds "wedge" is supposed to be a rectangular block at lower k_perp, and the PS drops down at higher k_perp. This is why I was trying to use only half of the weights with commit 5b8429b6b44f0dae65c1fd5b4fd8ec5fca93f51f as I suspect it has something to do when we're calculating the PS. I will look into this in more detail.

As for interpolating onto the grid cells, I think that should not be a problem here since we are using the grid centres anyway :-)

[steven-murray]

Awesome. So the problem with tiling/coarsening (other than normalisation), is that the EoR is so small on that grid that most scales will be wrong (i.e. larger than the EoR box). It's unclear that anything can be trusted in such a case. This is why I bumped up the tile diameter for the tests, so we didn't encounter that problem on top of everything else. Of course, we're going to have to make it MWA specs at some point anyway, so your idea might be better :-)

Slightly off-topic, but just came to mind: are we sure that the redshift-sampling of the lightcone is good enough for our purposes? It strikes me that the EoR looks a lot like the FG, which might be because we're using too-coarse a grid of redshifts, making it evolve "smoothly" like foregrounds.

I had the same thought as you, concerning interpolating onto grid cells, and even wrote that into my previous comment, but then deleted it because I realised that baselines migrate with frequency. So just because they are aligned with grid centres at minimum frequency doesn't mean they are at every frequency! Therefore it might be important (though, as you know, I get the feeling it's not).