search

HERA-Team / hera_pspec

HERA power spectrum estimation code and data formats
http://hera-pspec.readthedocs.io/en/latest/
BSD 3-Clause "New" or "Revised" License
4 stars 3 forks source link

Normalization and window functions should not technically be calculated on a per-baseline basis. #248

Open aewallwi opened 4 years ago

aewallwi commented 4 years ago

Right now, all of the normalization and demixing machinery in hera_pspec is designed for per-baseline power spectra. Technically, normalization should be happening on the final band powers after they have been binned and averaged. Doing this will require building normalization machinery into uvpspec.

aewallwi commented 4 years ago

Actually, this may not actually be necessary given the assumptions we are already making, that our different redundant baseline groups are uncorrelated (true for short basline delay-spectrum regime). Normalizing per baseline and averaging may (or may not?) be the same as normalizing after averaging. Looking into this now.

aewallwi commented 4 years ago

If you are going for H^-1 normalization (delta window functions), then the answer will be the same (as long as all of your baselines are short so that your K-bins are basically k-parallel bins). If you are going for I normalization, it also makes no difference whether you normalize per baseline and then average. If you are going for some intermediate thing like H^-1/2 or L^-1, then there will be differences. It's unclear if things will be worse at this point, but I think it is worth emphasizing that normalizing after averaging is generally not the same as averaging normalized baseline power-spectra. Maybe someone wants to look into this.

aewallwi commented 4 years ago

Assuming that the k bins are k-parallel bins, you would just have to average the per-baseline H-matrices before computing H^-1/2 or L^-1 on that, instead of doing this per-baseline.

acliu commented 4 years ago

I agree that the operations do not necessarily commute. However, since all the options that are currently available are invertible choices, I wonder if it's worth considering a two-step normalization. We keep the current scheme where people can select the M matrix on a per-baseline basis. This way, people can see the results on a per-baseline basis. After that, we can write code that undoes the per-baseline thing and then reapplies the choice of M properly in an all-baselines-together way. What do you think?

aewallwi commented 4 years ago

I agree with you. It's much easier to understand the impact of normalization choices per-baseline. Propagating normalization matrices into uvpspec, especially if they are time dependent could be storage intensive but if we remember how they were calculated this wouldn't be an issue :).