kvangorkom / pandeia-coronagraphy Goto Github PK

When the Pandeia library PSFs are generated, the requested offsets for the PSFs are forced to nearest integer upsampled pixel, and then recentered by a simple pixel remapping after the call to WebbPSF (so the convolution kernel created from the PSF is centered). For on-the-fly PSFs, I've intentionally avoided forcing the offset to an integer multiple of the upsampled pixel, since we care (particularly for MIRI) about small changes to these spatially-dependent PSFs. However, the pixel remapping approach then has the side effect of producing a slightly off-center convolution kernel.

Possible mitigation strategies: interpolate the PSF for the centering step (I really don't want to do this), or adopt a higher upsampling value.

Several functions are currently living in scene (load_calculation, save_calcation, calculate_batch) that more properly belong under engine. This will require updating notebooks.

Hello,

I have been testing the MIRI SGD notebook and running into issues when generating the KLIP reference. This is related to uncorrected nan's in the SGD reference images, possibly due to saturation artifacts, that cause the code to crash.

Here's what is in the original code -

slope = r['2d']['detector'] 
reg = analysis.register_to_target(slope,target_slope,rescale_reference=True)
sgd_reg.append(reg)
sgd_reg = np.array(sgd_reg)

I modified it in the following manner (also zero'd mean for references) -

slope = r['2d']['detector']
slope_mean_sub = slope - np.nanmean(slope)
slope_mean_sub[np.isnan(slope_mean_sub)] = 0
reg = analysis.register_to_target(slope_mean_sub,target_slope,rescale_reference=True)
sgd_reg.append(reg)

This does result in the central PSF artifact not getting completely removed in the target-reference but that could be corrected by drawing a mask on the central 0.1-0.2 arcsec.

Hi @kjbrooks @kvangorkom - since @kvangorkom's no longer here at ST, do we have a transition plan for which repository to use for future development on this? I was just reminded by @abhijithrajan that I never made a PR for my version of this that re-enables the LRU caching for faster calculations.

Should I submit that PR here, to @kjbrooks's fork of this repo, or somewhere else? Should we make a new fork of this inside the spacetelescope organization and declare that is the new primary master? I'm happy with whatever, just want to make sure that we all agree on the right path.

The functools32.lru_cache decorator (currently decorating engine.get_psf_on_the_fly) does not update the function cache when called on a separate process (as in when performing calculations with engine.calculate_batch).

There are other caching implementations that appear to play nicely with multiprocessing, but that'd require adding a 3rd-party dependency, which I'd rather avoid. (Alternatively, I could roll my own, but that adds a failure mode I'd rather not deal with.)