Hello,
In DP1 schema for the DiaSource table raErr is defined as: “Error in right ascension”. It is not explicitly specified whether raErr is the uncertainty at the source position (i.e. if it includes the factor cos(dec) or not).
If raErr is the uncertainty at the source position, I expect it to be comparable to decErr. If raErr is to be scaled with declination, I expect it to be generally greater than decErr.
Io order to check if raErr already includes the factor cos(dec), I compared raErr and decErr for a DP1 field at high declination (47 Tuc Globular Cluster RA:6.02, Decl:-72.08) to better see the effect of declination. I checked first DiaSource coordinates error and then the Object table errors. The results are shown below.
Surprisingly to me raErr seems significantly smaller than decErr (left panels) and appears to be comparable to decErr after being divided by cos(dec) (right panels). This is true both for DiaSource data (upper panels) and Object data (lower panels).
The same effect id visible in the Extended Chandra Deep Field South (ECDFS), but the difference between raErr and decErr is much smaller because of the lower declination (-28.1 deg).
I do not expect raErr and decErr to be identical, but the difference increasing with declination and the fact that
dividing by cos(dec) the two errors are similar seems strange. Are data ok and these trends are expected? Am I doing something wrong?
Thank you.
Dear Giuseppe,
Thank you for identifying this issue, for providing a well-documented report, and alerting us to this issue!
Indeed, it is appears that raErr does not include a correction for cos(DEC).
The Rubin team will either update the documentation or update the code accordingly.
Once again, many thanks for bringing this to our attention!
Best regards,
Douglas
Dear Douglas, thanks a lot for your reply! I’m not sure how to apply the missing correction: the *cos(DEC) correction is expected to reduce the error, but raErr is already significantly smaller than decErr and I expect the two errors to be comparable. If I compute decErr*cos(DEC), the two error distributions are very similar, as shown below (I used the RSP Aspect to retrieve and plot the data for 47Tuc), as if the two columns were reversed.
If it were raErr to be divided by cos(DEC), (i.e. if raErr is the uncertainty at the source declination) I would expect it to be comparable with decErr and not smaller, but maybe I’m missing something.
Thanks again!
Giuseppe
@deppep - thanks for reposting on this. Since a solution was marked for this topic, your follow-up questions were not seen. I’ve un-marked the solution and we’re following-up internally, and expect to report back late next week.
Hi @deppep and @altavilla, I wanted to let you know that we did indeed find that the RA errors were being over-corrected for cos(dec). This has now been corrected (in ticket DM-53812), so this issue will be fixed in future data releases.
Hi Clare, thanks a lot for clarifying this! So RA errors must be divided by cos(DEC) to remove the over-correction and get the correct values. Thanks again!
Just following up on this after being pointed to the known issues page: do we also need to warn users that they need to correct the covariance for this as well? If you plot the correlation of objects – ra_dec_cov / raerr / decerr – with the new raerr (i.e., raerr’ = raerr/cos(delta), as instructed) then the lengthscale of the correlations now has a dependency on cos(delta). The figure below shows each of the seven DP1 pointings, plotting histograms of Source correlations, with the mean cos(delta) overlaid as vertical lines. In particular the blue line (top row, third from left) shows 47 Tuc @ -72 degrees declination, with a maximum absolute correlation of ~0.3, compared with low-equatorial-latitude fields where the largest absolute correlations are ~1, as expected.
If the covariances were computed by rho*raerr*decerr then they would naturally suffer this same over-correction of raerr and need to be increased by 1/cos(delta) accordingly (which makes sense, we just multiplied by that above when calculating rho, essentially). Or are the covariances right as reported and if one wants the correlations then one needs to know to not correct for raerr when computing them, and that’s what needs adding to the new known issues section?
Hi @Onoddil, thank you for drawing attention to the ra/dec covariance. Yes, this also includes the overcorrection, so ra_dec_cov should be divided by cos(dec) to get the correct value. To reiterate for any readers finding this in the future, this only applies to data releases before DP2.
