clean up windows

[pmcdonal]

Attached is what the first k_obs element of this ELG quadrupole window matrix:
/global/cfs/cdirs//desi/survey/catalogs/Y1/LSS/iron/LSScats/v0.4/blinded/pk/pk/wmatrix_smooth_ELG_LOPnotqso_NGC_0.8_1.1_default_FKP_lin.npy
looks like (when rebin=5)

ELGquadW.pdf

Monopole is not as bad and it improves quickly with increasing k_obs. Ok, a short-term solution is to just drop low k elements, but we at least need to figure out what is good enough to include when publishing...

[adematti]

Thanks for the report, looks pretty bad indeed! I'll see whether there is anything obvious to do about this in the quite ad-hoc process of building this window matrix.

[adematti]

I haven't figured out yet an easy way to damp these wiggles, except of course applying a Gaussian damping beyond e.g. k > 0.1 h/Mpc to the k-window (i.e. the power of the randoms that's fed into the window matrix computation)...

[pmcdonal]

Do you understand why they are there? They aren't so bad for all cases - it isn't clear in my head if it is possible that something with some oscillation is actually correct, with this just being more ratty than it should be for numerical reasons... (the z slice is not really very wide, with sharp edges... these slices being another thing I wish we'd had time to think about more carefully...)

[adematti]

I'll try to compute the window matrix for increasingly complex geometries to get some intuition