Skip to content

confusing allocation of downgrade factors for correct power in case of post_filt_rel_downgrade and ivar filtering #17

@zatkins2

Description

@zatkins2

in the common case of harmonic and ivar filtering, we need to be careful about downgrading and keeping track of the associated factors that modify the power of the model and the final sim:

making a model

  1. the sqrt_ivar is always modified by a factor of the actual downgrade that went into making it

after it's ivar-flattened, let the power at a given ell by X (if it's actually white noise described by ivar, it will be the power for std white noise at that resolution)

  1. other than truncation, after the filtering, sqrt_cov_ell is not modified

so at ell, the actual power spectrum is still X, regardless of the size of the pixels that a realization with that power spectrum will be drawn into (assuming no aliasing, which is true)

drawing a sim

  1. the ivar is downgraded, so it is increased by a factor of post_filt_rel_downgrade**2 relative to before filtering

we divide the sim by sqrt_ivar, so the net effect is the power spectrum at ell goes to X/post_filt_rel_downgrade2. why is this wrong? shouldn't it be the case the sqrt_ivar goes up? well, sort of -- sqrt_ivar is just a map with some features that says what regions are more or less noisy. imagine it can be normalized such that it's A * sqrt_ivar_norm, where sqrt_ivar_norm does not modify the power spectrum of whatever map it multiplies (assuming no mode-coupling). then multiplying by sqrt_ivar in step 1 applies A**2 to the power spectrum. step 2 doesn't change the power spectrum. In step 3, we want to divide out the same sqrt_ivar in the beginning to divide out the factor of A**2 and reintroduce the same topology. but we've artificially introduced another factor of post_filt_rel_downgrade2.

we get rid of it here, where it's read from filter_kwargs. but this means it needs to be supplied to filter_kwargs for the call to get_sim_static. obviously this is true when built from a config, but it's not in general -- something must "remember" to add it to filter_kwargs to preserve the memory of how the model was built. it would be better if that were stored in the model somehow

P.S. what about the notion that sqrt_ivar "should" go up? that depends on what we mean by sqrt_ivar. if the noise is ~white at high ell, and we haven't downgraded so much to get out of that floor, then one could make an "empirical" ivar map, and they should see it has indeed increased by roughly the expected factor. but the power spectrum should be the same as in the beginning. thus, the power spectrum of the resolution-appropriate ivar-flattened map would change, but in our case, it doesn't. this suggests we should probably store the post_filt_rel_downgrade factor in sqrt_cov_ell, but it doesn't matter (and also, this would only "actually correspond to what's happening" if the noise is white, and also shouldn't happen if we don't do ivar filtering, but do do post_filt_rel_downgrading)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions