Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: meas_astrom
-
Labels:None
-
Story Points:12
-
Epic Link:
-
Sprint:Science Pipelines DM-W16-6, DRP F16-2, DRP F16-3, DRP F16-4, DRP F16-5
-
Team:Data Release Production
Description
lsst.meas.astrom.sip.makeCreateWcsWithSip, our C++ implementation of a TAN-SIP WCS fitter, fits for X and then Y. Thus it must be called several times (e.g. by FitTanSipWcsTask) in order to converge. Please make makeCreateWcsWithSip fit for X and Y simultaneously. This would simplify its use and speed up fitting.
In addition, please investigate whether outlier rejection can be added to makeCreateWcsWithSip. As of DM-3492 outlier rejection is implemented in FitTanSipWcsTask, but it would make makeCreateWcsWithSip easier to use and speed up fitting if makeCreateWcsWithSip did the outlier rejection itself. On the other hand, the current solution may be sufficient.
Once the above is implemented, please simplify FitTanSipWcsTask by removing the unneeded extra iterations used to work around these problems.
Attachments
Issue Links
- relates to
-
- To Do
-
- To Do
-
- Done
-
- Done
-
- Won't Fix
-
- Won't Fix
-
- Won't Fix
-
- Won't Fix
-
- Won't Fix
- mentioned in
-
Page Loading...
Activity
I've created a new issue for reconsidering nulling the low-order SIP terms, as Fred Moolekamp has proposed.
Merged to master following successful Jenkins runs (including py3). Big thanks to all reviewers and testers!
Jim Bosch: Could you add a brief note to the release notes (https://confluence.lsstcorp.org/display/DM/Data+Release+Production+WIP+F16+Release+Notes) describing what has been done here, please? That should certainly include a brief description of why this is better than the old implementation. It's not immediately obvious to me from scanning this issue whether this has caused any interface changes which will be noticeable to external users (ie, somebody who just wants to run a task to get their work done, rather than diving into the code); if so, please also mention them in the notes.
The code looks good to me. There are two things that concern me slightly, which may be best covered in new tickets.
The first is that the CRPIX values are set to the center of each CCD. Even if we don't attempt to fit the CRPIX values, I think it would be best to use the center of the focal plane, not the center of each CCD, as the origin of the polynomial expansion. I'm fairly certain that the fit will be much better, and there could potentially be CCD to CCD variances in the astrometric accuracy as the symmetry of the focal plane will affect the polynomial fit of a given CCD.
The other issue is the question as to whether or not it is ok to keep the linear terms (A_10, A_01, B_10, B_01) in the FITS header. I attached a document to this ticket that I wrote describing how to transform from polynomial coefficients to the CD matrix and 2nd order (and higher) A,B coefficients, more in line with the SIP standard.