Known comets missing Solar System association fields

Science
#1

Hi,

I wanted to raise a possible Solar System association issue, or at least check whether I am interpreting the alert packets correctly.

Before comet associations were added to the Rubin alert pipeline, I wrote some code to manually search Rubin alerts for possible comet matches. The code goes through each night of Rubin observations, compares alert positions/times with predicted ephemeris positions for known comets, and records close positional matches.

I believe associations are now up and running for the comets that are in the MPCORB. I have continued running this code recently, and I am finding several matches between Rubin alert sources and known comets. All of these comets appear in the public MPC comet file, but in the alert packets, diaSource.ssObjectId = 0, all the ssSource fields are null, and the mpc_orbits fields are also null. So they appear to be transient alerts with no Solar System association attached.

Could the Solar System Processing Team check whether these objects are being associated as comets correctly during the pipeline process, and if so whether these alert packets should have received Solar System associations?

I have listed below the comet names, alert IDs, and separations for the ones I have found so far, so that it is easier to take a closer look.

Please let me know if I am interpreting these packet fields incorrectly, or if there is a better way to check whether these alerts received Solar System/comet associations.

Thank you,
Madeleine

Candidate comet-alert matches found so far:

2026-06-29

Comet name: 160P/LINEAR
Alert ID / diaSourceId: 170600269617299985
Separation: 2.06 arcsec

Comet name: 160P/LINEAR
Alert ID / diaSourceId: 170600262637978125
Separation: 2.09 arcsec

2026-06-28

Comet name: C/2019 E3 (ATLAS)
Alert ID / diaSourceId: 170595944383905807
Separation: 1.07 arcsec

2026-06-27

Comet name: 178P/Hug-Bell
Alert ID / diaSourceId: 170591528296120582
Separation: 8.97 arcsec

Comet name: 84P/Giclas
Alert ID / diaSourceId: 170591534172864597
Separation: 1.05 arcsec

Comet name: 344P/Read
Alert ID / diaSourceId: 170591539747618922
Separation: 7.32 arcsec

Comet name: 491P/Spacewatch-PANSTARRS
Alert ID / diaSourceId: 170591540588052652
Separation: 1.29 arcsec

2026-06-26

Comet name: 70P/Kojima
Alert ID / diaSourceId: 170587112334164116
Separation: 0.52 arcsec

Comet name: C/2019 E3 (ATLAS)
Alert ID / diaSourceId: 170587116603965478
Separation: 1.22 arcsec

2026-02-20

Comet name: 472P/NEAT-LINEAR

Alert IDs / diaSourceIds:

170032911482355882
170032910272299077
170032914992463904
170032928249610343
170032902744048271
170032902621365115
170032906649469058
170032915777323095
170032904889958641
170032899960079426
170032900730782388
170032906271981602
170032903830897059
170032900608622779
170032906916331542
170032914725601468
170032904220443061
170032907171659829
170032901804523894
170032914858770448
170032901668733578
170032900074373180
170032913897226426
170032905891348513
170032906405675101
170032905157869666
170032906782638200
170032905695789120
170032909870695359
170032904757837840
170032902206652790
170032911885533195
170032903681999572

1 Like
#2

Hi Madeleine,

We associate solar system objects which are detected within 1.0 arcseconds of the expected ephemeris position. It looks like all your examples have separation greater than an arcsecond, which matches my expectation for how our pipeline will perform. It’s definitely possible to pick up extra detections that we don’t (yet), but the false positive rates increase unless you’ve got extra information beyond on-sky positions. I imagine that a tracklet linking algorithm which performs much better on the >1 arcsec ephemeris drift case could be implemented, but probably won’t be imminently.

1 Like
#3

Oop, just saw this one! Interesting – I’ll check in.

1 Like