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
#4

A post was split to a new topic: Change request for Solar System association prompt products documentation

#5

Hi Jake,

Thanks very much for clarifying. That makes sense, and I thought this might be the case.

Some of the cutouts do appear to show cometary activity, so I’ll assume that, for now, identifying these kinds of potential comet alerts will involve some manual inspection for those beyond the current association threshold.

Thanks again for looking into this!

#6

Hi Madeleine, it looks like Jake’s response answered your question. Thanks, Jake.

Meg, I see your request for the documentation change. I’m going to move your post to a new topic under the “support” category and make a Jira ticket for the requested change.

#7

Hello,
just for my understanding, the comet I discussed in this post: My pipeline caught comet C/2025 A4 in today’s Rubin alerts doesn’t have ssObjectId for the same reason, correct? Its separation from the predicted comet position is about 7 arcsec (field “center dist” in the results of Sky Bot search). Comet C/2025 A4. diaSourceId 170433140703626474

comet _C2025_A4
comet _C2025_A41816Ă—1296 270 KB

1 Like
#8
orbit dia_source_id date visit det SNR sep " resid " fit RMS "
230P / P/2009 U6 170560701366536256 2026-06-20 2026061900444 51 29.61 0.214 0.198 0.388
294P / P/2008 A2 170587109849039700 2026-06-26 2026062500594 186 18.08 0.289 0.313 0.422
294P / P/2008 A2 170587115620401313 2026-06-26 2026062500637 186 28.10 0.254 0.225 0.421
294P / P/2008 A2 170604725241118740 2026-06-30 2026062900767 160 18.59 0.282 0.222 0.420
294P / P/2008 A2 170604725298266145 2026-06-30 2026062900768 13 18.60 0.248 0.295 0.420
70P / P/1970 Y1 170587112334164116 2026-06-26 2026062500613 62 8.49 0.259 0.218 0.388
70P / P/1970 Y1 170604720342171714 2026-06-30 2026062900731 32 8.28 0.140 0.146 0.387
94P / P/1984 E1 170591538864717873 2026-06-27 2026062600825 119 11.62 0.209 0.178 0.461
94P / P/1984 E1 170604735235096703 2026-06-30 2026062900842 22 11.48 0.268 0.200 0.457
2 Likes
#9

Hi Jake, or anyone from the Solar System Processing Team,

I just want to ask a follow up question about the comet associations. From some of the other community posts, it sounds as though at least some of these detections may now be linked to the corresponding comet orbits/designations. I am still a little confused about how to check this association myself.

In the Fink alert packets, diaSource.ssObjectId = 0, and the ssSource and mpc_orbits fields are still null, so the Solar System association is not visible in the packet. Is there another database, table, or service that I should be using to check the most recent association for a diaSourceId? I would be very grateful for any guidance on a recommended way to do this.

Many thanks,
Madeleine

1 Like
#10

@mcleod It would be helpful if you could point out where you’re not finding this information in the prompt products documentation/where you went looking in the documentation for this information so that the SSSC can request updates to the documentation to make it easier for other new users to the alerts/prompt products data.

2 Likes
#11

Hi Meg. The main documentation sections I have looked at are the alert packets, source association, solar system prompt processing and the SSSource and mpc_orbits schemas. I have also used the notebook for how to query the MPC for a known comet or asteroid and then filter to find Rubin X05 observations. My understanding is that to use this you need to know which comet or asteroid you are looking for and then see whether Rubin has observed it. What I was hoping to determine is if there is a way where given an arbitrary diaSourceId, can I check whether that alert has been associated to a known comet or asteroid without already knowing which object to search for? My current understanding of the documentation is that, if the DiaSource was associated to an SSObject during alert production, then the alert should contain a non-zero ssObjectId and for some alerts I have found this to be the case. I know that for objects outside of the 1 arcsec radius this won’t be the case. I think the main thing I am confused about is that Anton was able to check “LSST diaSourceId detections against the current known-object / orbit-association data for LSST detections” but for those IDs I get null fields in Fink alert for SSO so I wanted to understand where these associations were found and to clarify that I am understanding the alert association fields correctly. Thanks, Madeleine

2 Likes
#12

Hi Madeleine,

Yes, this is exactly the point that confused me too.

I initially treated null/zero SSO association fields in the original alert packet as meaning that the detection was “free” or not associated with a known Solar System object. After rebuilding the data locally, I no longer think that is a safe assumption.

My current interpretation is:

  • the SSO fields in the original alert packet reflect the prompt alert-time association state;
  • if ssObjectId is null/zero in that packet, it does not necessarily mean that the same diaSourceId is not associated with a known object later;
  • the association can appear through later Solar System processing, MPC ingestion, or current known-orbit association products.

To avoid relying only on the original alert packet, I downloaded the Fink medium packets built from public Rubin alerts, without cutouts, ingested them into a normalized local database, and rebuilt the association layer locally.

The current local raw layer contains:

  • lsst_sso_raw.dia_source_observation: 14,959,313 unique diaSourceIds
  • lsst_sso_raw.rubin_membership_assertion: 38,868,453 local DiaObject membership assertions
  • lsst_sso_raw.sso_current_alert: 784,096 rows with SSO / SSSource / mpc_orbits fields
  • exact MPC/SBN replica matches: 317,246 X05 observations
  • current known-orbit X05 associations: 421,103 distinct diaSourceIds

The important result is that I currently see 421,099 known X05 diaSourceIds that are present in the raw dia_source_observation table with ssObjectId = 0, but they are still linked through the current known-orbit observation layer.

So the associations I mentioned were not coming only from the SSO fields in the original alert packet. They were found by joining the raw alert detections against a reconstructed current known-object / orbit-association layer built from the Fink SSO packet state and local MPC/SBN replica.

As a scale check, one of the heaviest days I processed was 2026-02-24:

  • files: 109,786
  • current packet rows: 2,867,529
  • normalized DiaSource observations: 7,880,412
  • final membership links: 7,807,802
  • prvDiaSources elements: 182,962,771
  • prvDiaForcedSources elements: 499,370,326

After rebuilding this layer, many apparent “free” detections disappeared from my candidate lists because they were actually already associated with known Solar System objects.

So for an arbitrary diaSourceId, I think the safest answer is: checking only the original alert packet is not enough. I would also check it against the current SSO / known-orbit association layer.

This is my current approach. I have only been working with this system for a few months, so I am still learning and I may be making mistakes. It is also possible that my solution is more complicated than necessary and that there is a simpler way to do this. I am still trying to understand all the layers of this rather complex system.

Thank you,
Anton

1 Like
#13

Hi Madeleine,

Checking whether diaSource.ssObjectId = 0 is a great check. If you’re seeing that, then the object was not associated to a known SSO at the time of alert generation. If someone else is seeing X05 observations of that object in the minor planet center, then I bet that the ephemeris had drifted from the MPC orbit, we “rediscovered” it >1 arcsec away from the official position, and submitted those detections to the Minor Planet Center which recognized it as an already-discovered object and associated our detections to it. Let me know if there are further questions.

1 Like
#14

Is there another database, table, or service that I should be using to check the most recent association for a diaSourceId?

There should eventually be a solar system table in the prompt processing database (PPDB) which includes updates to the initial alert state, but it doesn’t exist yet.

1 Like
#15

Hi Jake,

That makes sense, thanks so much for clarifying!

1 Like
#16

Hi Anton,

Thanks so much for sharing!

1 Like
#17

One more comet in the Rubin alerts on July 9, 2026 with no SS association, but known in MPC with separation 1.58: C/2025 M2, diaSourceId: 170644228667342899, 170644235646664778

1 Like
#18

Hello LienaDreams

There are 5 of them.

170631096324063692
170631103303385438
170635504017998393
170644228667342899
170644235646664778

2 Likes
#19

@recoil77 Thank you, Anton, you have built a great project and a web site. Congratulations on your own observatory code and first asteroid discovered! Amazing progress!

2 Likes