Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: None
-
Labels:
-
Story Points:6
-
Epic Link:
-
Team:Data Release Production
-
Urgent?:No
Description
It has not yet been decided exactly how we will handle the problematic PSFs noted in DM-35552 (and see discussion on DM-36763 and this confluence page). In finalizing the plan, it would be interesting to know if these exposures would have been included in the coadd in the case where the error was caught (and thus calexp datasets would have been persisted). The exclusion criteria would come from the SelectPsfWcsImages task used in makeWarp, for which we have the following currently set for HSC processing:
# Maximum median ellipticity residual
|
config.select.maxEllipResidual=0.007 |
|
|
# Maximum scatter in the size residuals, scaled by the median size
|
config.select.maxScaledSizeScatter=0.009 |
Attachments
Issue Links
Activity
This has been further discussed on this Slack thread. It turns out there are some significant ISR differences between the w_2022_12 psfEx run and the w_2022_44 piff runs (see icExp_0_26048.pdf
) being compared here, so a direct comparison of where the PSF models failed is not strictly valid.
Also noted on that thread is that, where the measurement does succeed for the piff run, the PSF determinant radius can vary from ~1.7 -> 6.5 (see psfs_piff_vs_psfEx_0_26048.pdf) and that there are large regions where there are no calib_psf_used stars:
- magenta: piff/w_2022_44
- green: psfEx/w_2022_12
so the PSF can't be well constrained in these regions (and it seems piff's extrapolated models can get pretty funky). Both are clearly not good (i.e. we probably should not be including these poorly modeled detectors in the coadds), so we need metric(s) that can capture this (as noted above, our nominal PSF QA metrics are not capturing this!) Suggestions included:
- a cut on number of used stars probably would flag this image - I assume most fully-successful images have many more - and if not, a cut on number of stars in quadrants/octants/N-tants definitely would.
- a “variation across the field” metric
Would you mind giving this a look when you get a chance? Feel free to request any further diagnostics that might help with DM-36930!
LGTM. Thanks for the analysis!
To test this, I have run (note the --config calibrate:deblend.catchFailures=True override):
To assess their INCLUDE/REJECT status for the coadd, I retrieved the appropriate metadata from the calexps. I looked at the above two config thresholds and added:
# Maximum mean on-sky distance (in arcsec) between matched source and rerference objects post-fit. A mean distance greater than this threshold raises a TaskError and the WCS fit is considered a failure. The default is set to the maximum tolerated by the external global calibration (e.g. jointcal) step for conceivable recovery. Ap [^DM-36843_calibrate.log] propriate value will be dataset and workflow dependent.Somewhat surprisingly, it seems these all would have survived the thresholds and made it into the coadds. Yusra AlSayyad was interested to know if the same would be the case for these detectors when we were running psfEx. To look into this, I've computed the same numbers for the pre-piff HSC/runs/RC2/w_2022_12/
DM-34125collection.The numbers look like with piff [psfEx]:
So one of the psfEx detectors would have been excluded from the coadd.
Going a bit deeper, I also computed the psf image at all the locations for the sources that got the following in the logs (see attached) of my run:
and compared them with the same for the psfEx collection:
(or, better yet, this one also includes some views on the icExp image itself: nanPsf_piff_vs_psfEx_vs_icExp.pdf
)
nanPsf_piff_vs_psfEx.pdf
There are only a few (3 out of 27) that actually failed with psfEx as well, so it seems piff looks slightly less stable (this may be of interest for DM-36930 Joshua Meyers).
The only odd (in that if there really are "no good stars", why is this not a failure?) thing I noticed in the logs (see attached) of the run I did here was: