Are these track-like residuals expected in filtered Fink LSST alerts?

Support Fink
#1

Hi, I am working with Fink LSST alerts and made a binary sky map of alerts that survived:

  • an ML moving-object-like filter
  • MPC matching with astcheck singleton mode at 30 arcsec

I used alerts from 2026-02-23 to 2026-02-26 in a 5 deg radius field centered at RA=150 deg, Dec=1 deg.

The image uses a simple local planar projection. Alerts were deduplicated by diaSourceId, and each surviving alert was drawn as a single white pixel with no smoothing or intensity accumulation.

The result shows a surprisingly large number of short linear track-like structures.

Is this qualitatively expected, or does it suggest that my filtering / known-object removal is still leaving many non-target alerts?

I can provide more implementation details if needed.
PNG attached.

layer_2026-02-23_24_25_26_cropped_grid_x4
layer_2026-02-23_24_25_26_cropped_grid_x42494×2395 159 KB

2 Likes
#2

Anton,

That looks pretty neat.

RA=150 deg, Dec=1 deg at the end of February would have been not too far from the Antihelion, and only about 8 degrees below the ecliptic. I would not be surprised if the LSST were to detect hundreds to a few thousand new asteroids in a 5 degrees radius under these conditions. I also notice that most tracks are in the same orientation. You could check if the phase angle from your analysis is in the range of what would have been expected for main-belt asteroids.
I also noticed on your image that the tracks that are at a different angle than the majority tend to be longer, which would be expected for NEOs.

The pros will probably have more insight, but it would be useful to know how many tracks you actually have on this image. Just eyeballing, I’m incapable of saying if it is a few hundred or a few thousand.

Also, would you be willing to share the code that you use to generate this analysis? I would love to try it myself.

Thanks,
JF

1 Like
#3

I’m currently working with fink alerts from 2026-01-26 to 2026-03-31.

My ID routines aren’t finished yet, but so far I’ve been able to link the following :
already known objects:
9,157 detections linked to 654 numbered objects
17,459 detections linked to 575 unnumbered objects (1Opp and MOpp)

new objects:
14,519 detections linked to 3,059 new 2-nighters
86,685 detections linked to 1809 new 1Opp objects (min. 3 nights)
11,738 linked to 148 new MOpp objects (with other detections from the ITF)

So yes, we can expect several thousand.

1 Like
#4

Thanks for the confirmation Andreas. Any chance you could share the code used to identify tracklets from the fink alerts?

JF

#5

I use methods similar to the ones Ari mentioned in this post:

1 Like
#6

Quick update from the “binary bitmap of surviving alerts” side.

I pushed the analysis quite a bit further from just pics. All points below are already after:

  • the ML moving-object-like filter
  • local astcheck / MPChecker-like singleton matching at 30 arcsec

So this is no longer the raw alert layer; it is already a post-known-object-veto candidate layer.

I tested two intraday branches:

  • 4-point minimum tracklets
  • 3-point minimum tracklets

and then ran:

  • same-day iterative merging
  • a curvature-aware multi-night brute-force linker

At the moment these are still track / orbit hypotheses, not final orbit solutions yet.

Main field around the original bitmap region (RA 148–152, Dec 0–4)

This is where the strongest effect appears.

  • 3-point branch: 2157 tracks = 1391 multi-night + 766 doubles
  • 4-point branch: 1933 tracks = 1302 multi-night + 631 doubles

If I look only at the longer arcs (4+ nights):

  • 3-point branch: 894 tracks backed by 314,777 points
  • 4-point branch: 839 tracks backed by 307,596 points

An interesting detail is that the 3-point branch does not merely add more short chains. In this region it seems to push some solutions upward in arc length: compared to the 4-point branch, it has fewer 5-night tracks but more 6-, 7-, and 8±night tracks. Using overlap tests, I found 68 cases where a 4-point 5-night track is almost fully contained in a 3-point 6±night track.

Second dense region (RA 184–189, Dec 5–10)

Here the gain is much smaller, but still real.

  • 3-point branch: 1305 tracks = 787 multi-night + 518 doubles
  • 4-point branch: 1295 tracks = 768 multi-night + 527 doubles

For 4+ nights:

  • 3-point branch: 623 tracks backed by 122,092 points
  • 4-point branch: 598 tracks backed by 120,175 points

In this region the 3-point branch gives a modest, fairly uniform increase across 4–7 night tracks, with almost unchanged fit quality. I also see some upward extension here, but much less strongly than in the main field: only 8 high-overlap cases of the same 5-night → 6+ pattern.

Third, much weaker region (RA 56–66, Dec -51 to -46)

This one is mostly a negative result:

  • both branches currently give 2 tracks total
  • the 3-point branch greatly increased the input tracklet pool there, but that did not translate into more multi-night tracks

Current pipeline snapshot

Across the three test regions:

  • 3-point branch: 3464 tracks = 2179 multi-night + 1285 doubles
  • 4-point branch: 3230 tracks = 2071 multi-night + 1159 doubles

If I restrict to the two strong regions and only look at 4+ night tracks, I get:

  • 3-point branch: 1517 long-track hypotheses backed by 436,869 points
  • 4-point branch: 1437 long-track hypotheses backed by 427,771 points

So relative to the original bitmap: yes, a large fraction of those short linear features can be turned into candidate intraday tracklets and then into multi-night track hypotheses. The 3-point branch appears useful mainly because in at least one dense field it sometimes extends arcs rather than only inflating the candidate count.

Next step on my side is orbit fitting. I will likely keep both branches: the 4-point one is a bit cleaner, while the 3-point one sometimes produces longer arcs.

I can share a cleaned-up technical note and code once I package it better.

2 Likes