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!