Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: meas_astrom, obs_lsst
-
Story Points:5
-
Epic Link:
-
Sprint:DRP S21b
-
Team:Data Release Production
-
Urgent?:No
Description
In our current implementation, it is possible for our SFM astrometric fitter to converge on a fit that, in reality is quite bad and should be considered an effective failure. If not flagged, these visits will get included in the coadds, and wreak more havoc than one might naively expect (namely because their photometric zeropoints can then be so severely biased that these single exposures can be given a lot of weight in the coadd; see DM-30466 for a few striking visual examples). It is thus desirable to have a (configurable) threshold on the mean offset of the fit above which even a converged WCS fit will be deemed a failure.
We do currently have some related (but not equatable) thresholds within some of our fitters (namely fitTanSipWcs and fitSipDistortionWcs:
maxScatterArcsec = lsst.pex.config.RangeField( |
doc="Maximum median scatter of a WCS fit beyond which the fit fails (arcsec); " |
"be generous, as this is only intended to catch catastrophic failures", |
dtype=float, |
default=10, |
min=0, |
)
|
but this is not the same value as we are using, e.g. as the astrometric mean and scatter stats being persisted to the Visit/Exposure summaries (see DM-30701) and having the stopgap in the fitter precludes extra iterations which might have otherwise had a chance at converging on a better solution (and, hence, the "generous" qualifier in the description). The nature of the stats computed and persisted to the summaries also provide a more natural path to justifying the threshold set (which will depend on workflow, e.g. whether an external global calibration is to be performed subsequent to SFM, in which case the tolerance can be much looser as this algorithm will have a good chance of recovering from iffy SFM fits when they are surrounded by good ones).
As such, it is the stats computed outside the fitter and in the AstrometryTask itself that should be compared against our threshold for deeming a WCS fit as a pass/fail. This ticket is to implement such a threshold and set some reasonable and justified thresholds such that we can forestall any calexps with bad astrometry creeping into our coadds.
Attachments
Issue Links
- relates to
-
DM-30466 Investigate bad SFM WCS fits in DP0.1 data
- Done
-
DM-30701 Propagate astrometry offset stats in AstrometryTask and store in ExposureSummaryStats/VisitSummary
- Done
-
DM-32128 Investigate astrometry failure in w_2021_40 processing of DC2
- Done
-
DM-16301 Integrate DESC's checkCcdAstrometry into ProcessCcd itself
- Won't Fix
Thanks for your useful comments on the PR. I think I adopted them all and, while I realize you've already makes this as reviewed, I would appreciate another quick look from you before I merge!
A fresh Jenkins is running.