Details
-
Type:
Bug
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: jointcal
-
Labels:None
-
Story Points:2
-
Epic Link:
-
Team:Data Release Production
-
Urgent?:No
Description
As discussed in DM-28173, the refcat errors for the astrometric positions are incorrect.
https://github.com/lsst/jointcal/blob/master/src/Associations.cc#L249-L256
if (std::isnan(refCoordinateErr)) { |
star->vx = record->get(raErrKey);
|
star->vy = record->get(decErrKey);
|
} else { |
// Compute and use the fake errors |
star->vx = std::pow(refCoordinateErr / 1000. / 3600. / std::cos(coord.getLatitude()), 2); |
star->vy = std::pow(refCoordinateErr / 1000. / 3600., 2); |
}
|
The code expects star->vx and star->vy to be in units of deg**2, which is what is used when refCoordinateErr is input and converted from mas. However, the units of the refcat are radians. This means that (for Gaia at least) the incorrect-unit errors are about x100 larger than they should be, and presumably they aren't constraining at all.
Attachments
Issue Links
- is triggered by
-
DM-28173 Investigate various issues revealed in the pipe_analysis plots in latest RC2 run
- Done
Activity
Thank you for both catching this bug and fixing it in such short order. I think this is the second jointcal error you caught me out on.
Copying some of my github comments here for posterity, but you're good to merge:
That the dist_rms_relative increased for some tests is surprising to me. As we talked about on the phone, that might still be ok with more constraining refcat uncertainties given that different outliers were also rejected. This brings up a good point as to whether I should have a different outlier rejection threshold for RefStars vs. MeasuredStars (we only want to reject refstars if they're clearly bad, i.e. incorrect matches).
The new difference between the rank update and no rank update CFHT tests concerns me, but looking at the logs doesn't show anything particularly amiss (rank update version took two "outer loops" vs. one for no rank update but that doesn't necessarily mean anything). I would expect for well formed (nearly linear in the fit parameters) input data that there is almost no difference with that setting turned on. With no rank update the refcat relative and internal "absolute" astrometry is very slightly better; I don't know if that is telling us anything useful on this small amount of input data.
I wish I had a way to compute or visualize just how close to "near linear" the chi2 space really is. I'm sure there are tools for that, but I don't have them.
PR is here: https://github.com/lsst/jointcal/pull/167
Jenkins is here: https://ci.lsst.codes/blue/organizations/jenkins/stack-os-matrix/detail/stack-os-matrix/33331/pipeline