Thanks for your question and your interest in the THOR algorithm. THOR is the product of my PhD dissertation so I figured I’d take a stab at answering your question. It’s super humbling and inspiring to see it mentioned on stack exchange – bucket list item checked off, thank you!
Background and Motivation:
To discover asteroids, survey telescopes will take an image of the night sky and then come back about 30 minutes later and take another image. In the time between those images, stars and galaxies will not have moved but asteroids will have shown discernable motion. The detections of asteroids measured from these images are known as "tracklets". The same telescope then comes back a few nights later and takes another series of images to try to re-observe the same asteroid (observe another tracklet). Once you’ve observed the asteroid on a few distinct nights you’ve then made the discovery.
The key detail is that telescopes must observe the same area of the sky multiple times in one night to discover asteroids since they rely on observing tracklets. The gif below shows how tracklets are observed. In this example, 4 observations per night are made (known as “quads”) over the course of 5 nights. The detections that get highlighted in blue are all the asteroids observed with tracklets.
What we wanted to do with THOR was find a way to make it so that telescopes didn’t need to take a series images of the same area of the sky within one night. Instead, we wanted to find a way that allowed telescopes to perform a variety of different observing campaigns that perhaps focus on other science and/or require a different pattern of observations. A cool side-effect of this is that if you could remove the requirement to observe tracklets suddenly it might be possible to find asteroids in a lot more astronomical datasets. Many astronomical datasets were not made with asteroid discovery in mind -- they don't have tracklets!
How Tracklet-Less Heliocentric Orbit Recovery (THOR) Works:
Transformations
In the left panel in the gif above, the grey dots represent simulated observations extracted from images taken by a telescope over a 2-week period. There are asteroids in these data but they can be very difficult to spot. The non-linearity of their motion in part due to our motion around the Sun and the rotation of the Earth, and the fact that there are many, many detections makes this a challenging problem. There are also no traditional tracklets as only one image is taken a day.
In THOR we use test orbits to find asteroids. Using a test orbit, we can propagate that orbit backward and forward through time and calculate exactly where it would appear in our images. One advantage of this is that we also know how far away the test orbit would be from us at any point in time and how fast it's moving. In the gif, the red dots in the left panel represent where a particular test orbit would appear in each of the images from which these data were extracted. As the red dot moves we grab detections near the predicted position of the orbit at that time (these get highlighted in blue as the red dots appear).
For each of the test orbit’s predicted positions, we can make a simple assumption: let’s assume that all the detections near the location of the test orbit at that time are at the same distance from the Sun as our test orbit. When we make this assumption, we have all of the information we need to transform the grey detections into a frame that is centered on the motion of our test orbit. This transformation is similar to having a camera located at the Sun, and from the Sun tracking and following the motion of an asteroid while taking images. These transformed detections are plotted in the right panel. Notice how suddenly you can see lines and curves? These lines and curves are other asteroids that have similar orbits to our test orbit. It’s the same data as in the left panel just visualized in a different way to make it easier to spot asteroids. In the right panel, because our detections have been transformed to be centered on the motion of our test orbit, the red dots from the left panel have collapsed to a single dot in the right panel. In the transformed frame centered on its own motion, the test orbit would appear at the center as a single point.
Hough Transform
The 3D Hough transform component is how we programmatically extract the lines and curves from the right panel in the gif above. Fundamentally, the blue detections are 3-dimensional: they have a time dimension and two position dimensions. We collapse the problem to 2-dimensions by assuming some velocity offsets relative to our test orbit’s motion. We shift the detections with each velocity offset to see if the lines collapse into small clusters. These clusters can then be identified by cluster finding algorithms like DBSCAN. Below is an example (from Moeyens et al. 2021). The blue detections are the same type of detections as in the right panel in the gif from earlier, but for a different dataset and different test orbit. The blue lines connect the blue detections that belong to the same asteroids. A few of these lines are in different colors so we can more clearly see the effect of applying the velocity offsets. Notice how if we guess the correct velocity offset, ($d\theta_{X}/dt, d\theta_{Y}/dt$), the black line in the left panel becomes a small cluster in the right panel? For each test orbit, we run a grid of 90,000 such velocity guesses.
Once the lines have been extracted with the method above, we can then try a different test orbit and see if we can find more objects. In practice, for multi-year data we use 10,000s-100,000s of test orbits!
Test Orbit Selection (Phase Space Gridding)
How do we pick test orbits (the phase space gridding component)? This is on-going research but for the time being we’ve had a lot of success with simply picking known asteroids from different regions (populations) of the solar system. This will likely change as we keep tuning THOR to be better and better at finding interesting objects but for now it has been doing an adequate job.
Hope this helps!
