Details
-
Type:
RFC
-
Status: Implemented
-
Resolution: Done
-
Component/s: meas_astrom
-
Labels:None
Description
The default SIP polynomial order for FitTanSipWcsTask is currently 4. This RFC proposes reducing the default to 2.
Background:
This fitter is used by processCcd.calibrate.astrometry (AstrometryTask) to get a first guess of wcs which is stored in the calexps. In a normal DRP, this wcs gets refined later in the jointcal step. Currently the fit is done per CCD and has no knowledge of the camera model. (We plan on doing full-focal plane fits in the future). AstrometryTask iterates through alternating matching and fitting steps. The default matcher was recently changed to the more robust MatchPessimisticB, but getting a robust WCS depends on both the matcher and fitter being robust.
Reasons for the proposal:
- Lower order is more robust
- The default order of 4 has surprised some users. Most recently, in the DC2/imsim reprocessing, we've seen some failures due to bad WCS solutions which are prevented by a lower default order (e.g.
DM-17737/DM-17731).
obs_package plan to produce no change in behavior for existing cameras:
- obs_lsst already started overriding this to 2 in https://github.com/lsst/obs_lsst/pull/80 I will remove the overrides to normalize the configs.
- obs_decam has no overrides. Krzysztof Findeisen, Meredith Rawls, I will override this back to 4. Holler if you think 2 would work better.
- obs_subaru: overriden by wcsFitter.order=3. Can trace this config back to 2013. https://github.com/lsst/obs_subaru/commit/266eb7abb79a16abf4756c4e74ceb5a071d8c679
- obs_sdss: does not refit wcs.
- obs_cfht: overriden by wcsFitter.order=3
Somewhat surprised that there haven't been any comments on this so far.
I think this is a reasonable proposal. The most important caveat that I can think of is how strong the optical distortions are on edge chips. Certainly, from the jointcal HSC fits, the WCS looks like it changes quite quickly toward the edges. I would worry that a 2nd order polynomial wouldn't be enough to handle that. I suppose that changing the obs packages to keep their current behavior means we can study it better in the future.
A 2nd order fit is probably what we want anyway, once we start including the camera model.