Clarification about LSST alert astrometric uncertainties for ADES export

Support Fink
#1

Hi Rubin team,

I saw the previous discussion about the DP1 raErr issue and the cos(dec) correction. My question is related, but not exactly the same: I am working with LSST/Fink alert packets and trying to generate ADES PSV files for moving-object candidates.

Before exporting ADES, I wanted to understand the correct mapping from the LSST alert fields:

raErr
decErr
ra_dec_Cov

to the ADES fields:

rmsRA
rmsDec
rmsCorr

My first assumption was:

rmsRA = raErr * 3600
rmsDec = decErr * 3600
rmsCorr = ra_dec_Cov / (raErr * decErr)

To check this, I compared LSST alert detections with matching X05 observations already present in a local MPC/SBN obs_sbn replica.

The correlation part seems to behave as expected:

rmsCorr ~= ra_dec_Cov / (raErr * decErr)

But for rmsRA and rmsDec, the X05 rows where these fields are populated seem to match this pattern much better:

rmsRA ~= sqrt((decErr * 3600)^2 + 0.01^2)
rmsDec ~= sqrt((raErr * 3600)^2 + 0.01^2)

So it looks like either the axes are swapped somewhere, or I am misunderstanding the intended ADES convention, or there is some X05/MPC export detail that I do not know about.

One more detail: later LSST/X05 matches do exist in my local data through March and April, but in those later obs_sbn rows the rmsRA, rmsDec, and rmsCorr fields appear to be empty. So I cannot use later data to confirm or reject the February pattern.

Could you please clarify the recommended policy for third-party ADES generation from LSST alert packets?

Should I fill rmsRA, rmsDec, and rmsCorr using a specific Rubin/X05 convention, or is it better to leave these ADES fields blank ?

Thanks!

#2

Reporting uncertainties when available is good practice. So is adding 0.01 arcsec in quadrature to the nominal RA and Dec uncertainties, to avoid unreasonably small uncertainties sometimes assigned to very bright objects. I believe your handling of rmsCorr is also correct.

Switching RA and Dec uncertainties is not correct, and if we did that it was a mistake. I have checked our submission code, and it appears to be correct, meaning our normal submission pathways would not lead to switched uncertainties. I think the switching may have been a one-time mistake (by me) affecting only our submissions of tracklets from First Alerts, which was a non-standard process. If you can provide a specific example of switched uncertainties, that would help test my hypothesis about the scope of the problem.

#3

Hi Ari,

Thank you for checking this and for the clarification.

Here is one concrete example where the populated X05 obs_sbn uncertainties appear switched in my local MPC/SBN replica.

LSST alert row:

diaSourceId = 170054985636642836
visit = 2026022400888
detector = 101
UTC time = 2026-02-25 07:28:43.254876
RA = 149.13865781269126
Dec = 2.7979181180728467
band = z

raErr = 2.8946943e-05 deg
decErr = 3.4360284e-05 deg
ra_dec_Cov = -6.786156e-10 deg^2

raErr arcsec = 0.10420899
decErr arcsec = 0.12369702
corr_from_cov = -0.6822827587

Using the same-axis mapping with the 0.01 arcsec quadrature term gives:

expected rmsRA = 0.1047
expected rmsDec = 0.1241

rmsRA = sqrt((raErr * 3600)^2 + 0.01^2)
= sqrt(0.10420899^2 + 0.01^2)
= 0.10468770
≈ 0.1047

rmsDec = sqrt((decErr * 3600)^2 + 0.01^2)
= sqrt(0.12369702^2 + 0.01^2)
= 0.12410057
≈ 0.1241

Matching obs_sbn row:

obs_sbn id = 609484591
provid = 2026 DW29
trksub = RL00Tfm
stn = X05
mode = CCD
UTC time = 2026-02-25T07:28:43.256Z
RA = 149.1386578
Dec = 2.7979181
band = Lz
astCat = Gaia3
photCat = LSST2502

rmsRA = 0.1241
rmsDec = 0.1047
rmsCorr = -0.6823
mag = 22.088
rmsMag = 0.1029

The match looks clean to me:

time difference: about 0.0011 seconds
coordinates: same at the displayed precision
band: z / Lz
magnitude from LSST psf_flux: 22.08787
obs_sbn magnitude: 22.088
computed rmsMag: 0.10287
obs_sbn rmsMag: 0.1029

The correlation also matches the expected covariance formula:

LSST corr_from_cov = -0.68228275
obs_sbn rmsCorr = -0.6823

But the RA/Dec uncertainties appear switched:

same-axis expected:
rmsRA = 0.1047
rmsDec = 0.1241

obs_sbn has:
rmsRA = 0.1241
rmsDec = 0.1047

As an additional note, in my strict matched subset with populated uncertainty fields, the swapped-axis model fit better for 16,840 rows out of 17,991. The same-axis model fit better for 0 rows, and the remaining 1,151 rows were effectively ties, mostly where raErr and decErr were nearly equal.

Sorry for taking more of your time on this. I know these are very new data, and I am not trying to over-report a historical issue. To make sure this was not a mistake on my side, I also re-downloaded this specific alert from Fink and recomputed the relevant values from scratch. The result was the same. I just want to provide a concrete example if it helps identify the scope of the old switched-uncertainty submissions.