# Investigate bad SFM WCS fits in DP0.1 data

XMLWordPrintable

#### Details

• Type: Story
• Status: Done
• Resolution: Done
• Fix Version/s: None
• Component/s:
• Labels:
• Story Points:
5
• Sprint:
DRP S21b
• Team:
Data Release Production
• Urgent?:
No

#### Description

While looking for some "pretty picture" for the DP0.1 data, Jeffrey Carlin noticed some "green, point-like sources that are slightly offset from galaxies in this DC2 (gri-bands) images".  In a 'lengthy" discussion on this slack thread (108 replies and counting!), James Chiang narrowed it down to a bad WCS for detector 64 of the r-band visit 908967 (whereas surrounding fits looked ok).

It was noted that, upon a new processing of the exposure, the "badness" of this fit was revealed in the scatter output from the astrometry task to the logs:

 calibrate.astrometry INFO: Matched and fit WCS in 3 iterations; found 54 matches with scatter = 0.317 +- 0.193 arcsec 

whereas, e.g., the neighboring detector 65 has a more "typical" scatter of:

 calibrate.astrometry INFO: Matched and fit WCS in 3 iterations; found 81 matches with scatter = 0.006 +- 0.003 arcsec 

It was also noted that this bad fit was actually flagged by running checkCchAstrometry.py during the processing, but apparently these flagged detectors were not omitted from from the coadd assembly. Johann Cohen-Tanugi has provided a full list of such bad fits from the DP0.1 run, attached here.

Look into what is going wrong with these WCS fits, starting with a deeper dive on detector 64 of visit 908967.

#### Activity

Hide
Lauren MacArthur added a comment -

Johann Cohen-Tanugi, let me know if you'd like to see any further validations on this ticket.  I have created DM-30657 to add the doPerBandRefMagLim reference culling I've been using above (the option will be defaulted to False, so to make use of it a specific and deliberate config override in any given obs package will be required).  I may also explore a more dynamic culling based on the icSrc detection limits (but perhaps not on the short term).  And, more importantly, Eli is working on the real fix to this vulnerability on DM-30490.

Show
Lauren MacArthur added a comment - Johann Cohen-Tanugi , let me know if you'd like to see any further validations on this ticket.  I have created DM-30657 to add the doPerBandRefMagLim reference culling I've been using above (the option will be defaulted to False, so to make use of it a specific and deliberate config override in any given obs package will be required).  I may also explore a more dynamic culling based on the icSrc detection limits (but perhaps not on the short term).  And, more importantly, Eli is working on the real fix to this vulnerability on DM-30490 .
Hide
Johann Cohen-Tanugi added a comment - - edited

Lauren MacArthur Thanks a lot, I think this is fairly complete. Here is just a hist of the checkCcdAstrometry scatter for all the DC2 logs (run2.2i for the cognizants)

So indeed the value of 0.1" seems to nicely divide into nominal and pathological behaviours. The "nominal" part is a bit weird, with a high tail hiding a ~gaussian centered at ~20  mas, but all in all this validates the guesstimates of 0.1" as a good starting value.

Show
Johann Cohen-Tanugi added a comment - - edited Lauren MacArthur Thanks a lot, I think this is fairly complete. Here is just a hist of the checkCcdAstrometry scatter for all the DC2 logs (run2.2i for the cognizants) So indeed the value of 0.1" seems to nicely divide into nominal and pathological behaviours. The "nominal" part is a bit weird, with a high tail hiding a ~gaussian centered at ~20  mas, but all in all this validates the guesstimates of 0.1" as a good starting value.
Hide
Lauren MacArthur added a comment -

That histogram is quite telling! My only concern about using it to set the config threshold to force failures would be if the scatter coming out of the checkCcdAstrometry script is very different from the one computed from within the astrometry task (i.e. the one printed to the logs). They certainly “should” be very close, but it’s worth checking.

Show
Lauren MacArthur added a comment - That histogram is quite telling! My only concern about using it to set the config threshold to force failures would be if the scatter coming out of the checkCcdAstrometry script is very different from the one computed from within the astrometry task (i.e. the one printed to the logs). They certainly “should” be very close, but it’s worth checking.
Hide
Johann Cohen-Tanugi added a comment -

LGTM

Show
Johann Cohen-Tanugi added a comment - LGTM
Hide
Dominique Boutigny added a comment -

checkCcdAstrometry is using all the sources present in the reference catalog and just applies a magnitude cut while the astrometric scatter reported by the astrometry task is probably only using the selected reference stars (no galaxies). When I wrote checkCcdAstrometry I determined that it was important to keep as much reference sources as possible.

Regarding the failures of the astrometry task, on top of the case where you get a too large astrometric scatter, there are also cases were you get a too small scatter. It correspond to cases were the fit becomes under-constrained. As far as I know this should not happen or only happen marginally with DC2 data because the geometry of the focal plane is perfect and we do not need to fit high order polynomials.

Show
Dominique Boutigny added a comment - checkCcdAstrometry is using all the sources present in the reference catalog and just applies a magnitude cut while the astrometric scatter reported by the astrometry task is probably only using the selected reference stars (no galaxies). When I wrote checkCcdAstrometry I determined that it was important to keep as much reference sources as possible. Regarding the failures of the astrometry task, on top of the case where you get a too large astrometric scatter, there are also cases were you get a too small scatter. It correspond to cases were the fit becomes under-constrained. As far as I know this should not happen or only happen marginally with DC2 data because the geometry of the focal plane is perfect and we do not need to fit high order polynomials.

#### People

Assignee:
Lauren MacArthur
Reporter:
Lauren MacArthur
Reviewers:
Johann Cohen-Tanugi
Watchers:
Chris Walter, Dominique Boutigny, Eli Rykoff, James Chiang, Jeffrey Carlin, Jim Bosch, Johann Cohen-Tanugi, Lauren MacArthur, Lee Kelvin, Robert Lupton, Yusra AlSayyad