Hyperlinc: Solar System Object Linking via Orbital Plane Clustering

Abstract

Drawing on Heliolinc concepts, this technique starts with heliocentric cartesian projection of transient sources then searches for common relative heliocentric angular motion among sources sharing the same orbital plane. The search is repeated for all hyperplanes containing a sufficient number of transients. Unlike Heliolinc, this technique averages out astrometric error in a best fit sense and requires no state vector estimation or orbit propagation. And unlike the path of an object traced on the observer relative sky plane used by classic moving object detection methods, the orbital plane of a solar system object in heliocentric coordinates is constant. The physical model underlying the algorithm is validated for 14 and 28 days with JPL Horizons ephemeris data. The algorithm is then applied to Catalina Sky Survey single field data to achieve 98% recovery of known objects. Future work will extend the analysis to multiple nights and make tracklets optional.

Introduction and motivation

In my Heliolinc CSS Superfield study I had difficulty linking the very category of objects I was searching for across multiple nights: dim objects with fewer than 3 detections per night. Dim objects close to the limiting magnitude of the telescope have poor astrometric accuracy, and Heliolinc is known to have more difficulty linking detections with poor astrometry. When I tried to resolve the Superfield study’s issues by using more nights of data, recovery of known objects got even worse as errors were propagated over larger durations. I hypothesized then that Heliolinc’s difficulties with poor astrometric accuracy were due to the way it compounds error by deriving and propagating orbits from two state vector estimates, both of which are inaccurate to varying degrees. This is not as much of an issue with Rubin/LSST as its astrometric accuracy is 0.05”, but with CSS it’s more like 0.35” or worse for detections near the limiting magnitude. It might greatly benefit surveys with relatively poor astrometry to average out those errors in a best fit sense instead of multiply them.

Figure 1. Recovered and Unrecovered known objects from the Heliolinc CSS Superfield study. Dim objects with fewer detections and poor astrometry are harder to recover. Left: detection count vs. RMSE; Right: detection count vs. visual magnitude.

Comparison of linking techniques and their sources of error

Before introducing Hyperlinc, it would be useful to review and compare existing linking techniques and how they search for moving objects. Each technique has much in common with the others, but the differences help inform what Hyperlinc is doing that's new. Figure 2 attempts to represent these similarities and differences at a high level.

Figure 2. Stylized representations of linking techniques for the same transient source data. Left: Fitting a straight line to RA/DEC sources in the observer sky plane; Middle: Astrometric errors "propagated" by some tracklets in heliocentric coordinates; Right: Orbital plane best fit and heliocentric angular separation as a function of time best fit.

Classic moving object detection (e.g. CSS, PAN-STARRS MOPS): Figure 2 (left)

At a high level, the classic, time-tested and extremely productive linking strategy employed broadly in the field begins with finding transient sources that are close to one another on the observer sky plane at closely separated observation times. Two or more of such sources that are linear in space (and optionally their separation in time) define a tracklet. Thus, an intra-night tracklet is generated by finding RA and DEC observations that fit a line well. If linking tracklets to one another across closely spaced nights, one strategy (employed by MOPS[1]) fits the motion of transient sources on the sky plane with a quadratic model. Stylistically, this technique is represented by the left most box in figure 2: a line of best fit, linear intra-night and quadratic inter-night, is found for observations of the same object.

The drawback of this technique is that RA and DEC observations are not always linear or even quadratic on the observer sky plane. Over a long enough duration, they never are. Classical techniques manage this problem by using short duration follow up observations, usually 2-4 per night over the course of 30-60 minutes to create intra-night tracklets. Motion on the sky is likely to be linear over this duration. Linking a tracklet on one night to a tracklet from the same object on another night is a bigger challenge. To find tracklets that meet that criteria, MOPS looks for combinations of tracklets that fit a quadratic model and validates those candidates with OD as it extends the candidate arc to more and more tracklets. But again, over long enough durations, motion for a non-heliocentric observer won’t conform to that model. Retrograde motion, for example, demonstrates both nonlinear sky plane motion and nonlinear relative motion in time to the extreme - see Figure 3 below. Still, this technique and techniques like it are the workhorses of moving object detection astronomy and work extremely well for surveys with a cadence geared towards moving object detection.

Heliolinc: Figure 2 (center)

The middle box of Figure 2 stylizes Heliolinc[2] and its sources of error. Heliolinc first asserts a heliocentric range in order to project observer relative RA and DEC observations to heliocentric cartesian positions. Heliolinc then uses n=2 sized tracklets to estimate the velocity component of the state vector by solving Lambert’s problem at each of the tracklet’s two asserted heliocentric positions. Combined with the position estimate, the velocity estimate yields a full state vector that defines an orbit passing through both asserted positions associated with the tracklet which we can then propagate to a common reference time. All observations of the same object should propagate to the same position and velocity at the same reference time for a well hypothesized range estimate.

In a sense, Heliolinc is a complete numeric solution to the astrodynamic problem of moving object detection – all you have to do is iterate over enough range hypotheses until you arrive at the one that represents the object you’re observing well. However, as the center box illustrates, n=2 tracklets with astrometric error “propagate” to different positions at the reference epoch, which we’ll choose to be the time of the left-most observation: the blue dot at time t=0. Propagate is in quotes because I’m representing nonlinear orbit propagation with a straight line "propagation" here for simplicity. If the observations at time t=2 and t=3 were perfectly measured, they would straight line propagate to the blue dot at t=0. But since there are errors in one of the measurements (at t=2), the position of the (2,3) tracklet propagated to time t=0 will not be at the same position as the t=0 observation. And the longer they propagate in time the greater the error will be. Since Heliolinc works by clustering on propagated states (in 6 dimensions representing both position and velocity rather than position alone as Figure 2 represents), this introduces an error that is fundamentally different and less desirable than a best fit line.

Hyperlinc: Figure 2 (right)

Hyperlinc begins with heliocentric projection of transient sources to an asserted range and yields a position vector just like Heliolinc. But instead of estimating the state vector and propagating an orbit, Hyperlinc first finds clusters of sources sharing the same orbital plane.

How do you determine whether sources are on the same orbital plane? Given two heliocentric cartesian positions for the same object at two different times, the cross product of those two position vectors normalized by its length yields a unit vector perpendicular to the plane the object is moving on. This unit normal vector to the plane - also known as the orbital pole or orbital normal - is constant for any two position vectors pointing to the same object when properly accounting for direction of motion in time. Thus by searching for sources with heliocentric positions perpendicular to an orbital normal, one can find sources that are on the same orbital plane. I’ll expand on other techniques for searching over orbital normals in a later section.

Sources must be coplanar to be the same object, but sharing the same plane is not sufficient. False positive sources (e.g. CCD noise) may reside on the plane as well, for instance. And more than one object could also occupy the same plane. Consider co-orbitals and near co-orbitals, one object trailing another by 120 degrees on the same (or same-ish) orbital plane, for example. Objects with different eccentricities could also occupy the same plane. To prune false positive sources and resolve different distinct objects on the same plane, we need to model the relative motion of the sources with respect to one another. Heliolinc does this with orbit propagation. Hyperlinc, in a manner somewhat analogous to MOPS, uses linear and quadratic models of relative heliocentric angular motion in time. But instead of modeling this motion on the observer sky plane, Hyperlinc uses motion along the constant orbital plane in heliocentric angular coordinates. Another, perhaps more intuitive, way to think of this is that we're modeling constant angular velocity and constant angular acceleration of true anomaly as a function of time with the linear and quadratic fits respectively. The validation data in the next section demonstrates that quadratic modeling of relative angular motion in heliocentric coordinates has small errors over 14 and 28 day durations.

I haven’t talked about tracklets so far with Hyperlinc. That’s because Hyperlinc doesn’t require tracklets in the same way Heliolinc and classical linking techniques do.

A quick aside to define some terms as I’m using them. A tracklet is 2 or more observations taken on the same night that are hypothesized to belong to the same object. A track or a link connects multiple tracklets to the same object – this connecting is called linking. Heliolinc uses n=2 sized tracklets. If you have 4 detections of the same object on one night Heliolinc tries to link them 2 at a time. If you have more detections of that object on another night those are linked 2 at a time by night as well. With Hyperlinc, there is the potential to connect individual detections. Due to how most existing surveys work, the concept of linking is generally thought of as something accomplished across multiple nights. With Heliolinc and Hyperlinc, however, I think of linking as the process of connecting observations of the same object to one another over one or more nights. In some sense this over-generalizes the linking problem and removes the distinction between inter and intra-night linking. Some might object to the revision of the terminology, but I think it's a useful way to think of the astrodynamical problem in a more generalized way. I would agree, however, that you haven’t really solved the linking problem until you’ve done it across multiple nights. My point is just that, physically, there's not really a difference between intra-night and inter-night.

Classical methods like MOPS use nightly tracklets to build up candidate links one tracklet at a time by a kind of bootstrap combinatorial extrapolation on the sky plane. Heliolinc uses n=2 tracklets to estimate an orbit from two observations so that it can propagate those observations to a common epoch. Since Hyperlinc looks for sources on the same orbital plane, if there is a real moving object on that plane, all of its detected sources will be on that plane. Thus Hyperlinc only has to find sources with common relative motion on one plane at a time. This makes Hyperlinc cadence agnostic and removes the same night tracklet requirement of MOPS and Heliolinc. Hyperlinc could find sources on nights with single observations, in theory. However, this study only looks at single night data, so this claim still has to be validated with future work.

Other linking techniques

THOR

I will only quickly mention it, because I am the least familiar with it, but Hyperlinc also shares some characteristics with THOR[3]. My very shallow understanding of THOR is that it generates many ‘test orbits’ and then looks for transient sources that are near those orbits and moving at a rate broadly consistent with an object on that orbit. The object doesn’t need to have the exact characteristics of the test orbit for this to work. If the sources move in the approximate manner of the test orbit they can still be linked.

Hyperlinc does not specify particular orbits but rather looks for common orbital planes among transient sources and then searches for common relative motion among the sources on each of those planes independently. Hyperlinc and THOR thus seem like two different approaches for isolating the same two components of solar system object motion.

The original Heliocentric Linking paper

Prior to Heliolinc, the Holman & Payne paper[4] that introduced the concept of heliocentric linking used pairs of inter-night tracklets on separate nights to find tracklets on a third night that fit great circle motion in heliocentric coordinates. Orbit determination then refined the search for subsequent tracklets as a candidate link was recursively assembled. Hyperlinc flips the order of these steps in a sense. First it finds all the sources on the same heliocentric orbital plane, then it tries to find common relative motion amongst those sources.

Validation of the Hyperlinc physical model with 14 and 28 days of JPL ephemeris data

The two tables below show the errors for Hyperlinc’s decomposition of the model for solar system object motion into 1) a constant orbital plane and 2) motion on that orbital plane. Using heliocentric position vectors from JPL Horizons, angular RMS deviations from the mean orbital plane are calculated. Next, the RMS of heliocentric angular separation deviations from a linear and quadratic model are calculated relative to the t=0 observation. Mean, 95th percentile and max errors are shown for each measure for the first 1000 numbered known objects at the bottom of the table. The first table uses 14 days of simulated observations. The second table uses 28 days. All measures are in arcseconds. Both tables are scrollable.

To summarize the tables below, for both 14 and 28 day models, the RMS deviation of the unit polar vector from the mean plane unit vector is negligible. This is the unsurprising numerical confirmation that a solar system object travels on a constant orbital plane. More interestingly, the relative motion of an object on its orbital plane over 14 days has a 12" RMS error for a linear model and a 0.076" RMS error for a quadratic model at the 95th percentile for the first thousand numbered objects. For 28 days, the first thousand numbered objects have a 53" RMS error for a linear model and a 0.69" RMS error for a quadratic model at the 95th percentile. The takeaway here is that a quadratic model of the angular motion of an object as a function of time along its orbital plane has a sub arcsecond RMS error for 95% of the objects modeled in this evaluation over durations of 14 and 28 days.

Table 1. Physical model 14 days; all values in arcseconds (scrollable table - aggregate measures at bottom)

Table 2. Physical model 28 days; all values in arcseconds (scrollable table - aggregate measures at bottom)

The Hyperlinc algorithm

To summarize one more time, the Hyperlinc algorithm 1) finds transient sources sharing the same orbital plane and then 2) searches for common relative angular motion among sources on that plane. Let’s examine each of these parts in more detail.

1) Finding orbital planes

There are at least three techniques that I can think of to generate orbital planes from transient source populations:

1. Cross all n=2 tracklets' asserted positions and normalize each of the resulting vectors to generate a set of unit orbital poles for each tracklet. Cluster on the set of orbital poles. This is the approach I am currently using.
2. Bin all of the unit orbital poles for an entire sphere and then look for sources that are separated by 90 degrees from each of those orbital pole vectors (e.g. have the smallest dot product with the unit orbital pole) over that set. In practice, you’d probably combine this with #1 in some fashion. Maybe have a coarse global binning and allow somewhat finer local binning where the unit poles generated by technique #1 were dense.
3. Use a Hough transform-like technique to find regions where all of the planes an individual source might lie on overlap with other sources.

2) Finding common motion on an orbital plane

For each set of transient sources on a plane, the next step is to look for sources with common relative heliocentric angular motion in time – the angle specified by a source, the Sun/barycenter and another source.

In the data validation section above I showed the results of linear and quadratic model fits to heliocentric angular separation of one source to another in time. For each source on the plane that I want to test against other sources for common relative motion I employ what I think of as a coarse cluster fine fit (CCFF) method.

For a given source on the orbital plane, first calculate the constant angular separation rate to all other sources that would “propagate” those other sources back to the origin source over the time interval between source observations. Clustering on this separation rate yields a set or sets of sources that are moving at approximately the same constant angular velocity with respect to the origin source you’re testing. This is the coarse cluster and is analogous to the linear fit model in the validation section above.

Ideally, since each source can represent only one solar system object, there should be only one cluster. In practice that will certainly not always be true. So for each coarse cluster we’ll use a quadratic model to fine fit the angular separations of the coarse clustered sources in time and reject any set of sources that don’t have an RMS error better than some threshold - a threshold much smaller than the linear model. You can also optionally reject individual sources in the set that have large residuals. Non-rejected source sets are then added to the final set of candidate links.

Scaling

How will this algorithm scale beyond single night data with hundreds of thousands of transient sources to multi night surveys with millions of transient sources? The answer, if I’m being honest, is that it’s an open question. But I’m optimistic given the initial single field CSS data runtime is less with Hyperlinc than with my version of Heliolinc. Obviously that’s no indicator that a substantially larger dataset won’t blow up for a larger N, but it’s better than the opposite scenario as a starting point.

Schematically, Hyperlinc looks like this in Python pseudocode:

links = []
orbital_planes = generate_orbital_planes(sources)
for orbital_plane in orbital_planes:
  on_plane_sources = find_on_plane_sources(orbital_plane,sources)
  for on_plane_source in on_plane_sources:
    plane_links = find_common_motion(on_plane_source,on_plane_sources)
    links.append(plane_links)

So Hyperlinc is at least O(n²) right now and potentially O(n³) depending on how find_common_motion() is implemented. This is substantially worse than Heliolinc’s O(n log n). But as written above, this Python pseudocode will test relative angular motion of the same sources with respect to one another over and over again. One key to reducing the time complexity will be ensuring that this test only happens once for a given set of sources. There is also the potential to introduce a reference epoch analogous to Heliolinc. When I extend this study to multiple nights I will be spending a lot more time thinking about that inner loop. I'm confident I'll stay out of the O(n³) zone, but I don't know where the final results will land yet. On the plus side, the algorithm is highly parallelizable on the orbital plane in the outer loop.

Results: Hyperlinc with Catalina Sky Survey data

Finally, let’s look at how this algorithm performs on some real world observations. Once again I’ll be using Catalina Sky Survey data. This study looks at the observations from all fields CSS observed on the night of February 23rd 2023. There are 90 fields that acquired data that night and 25 which did not – or at least had no FITS images.

For each field I first produce a set of transient sources from the Source Extractor detected sources by removing any source that was within 0.75” of any other source in any other observation of the same field on the same night to delete stationary sources from the data. I then use Hyperlinc to search for n=4 sized candidate links in these transient sources. In future work I’ll extend this to difference image sources and find n=3 candidate links as well. I've somewhat arbitrarily chosen to constrain the search to objects moving at a maximum of 5 degrees per day on the observer sky. Also, since there are only 4 observations per night for each field, I am only using the linear model for relative angular motion fits.

The table below summarizes the results for each field and links to web pages with their individual analysis. The aggregate measures across all of the the fields are at the bottom of the table. For the night, Hyperlinc found 7,294 candidate links, 6,709 of those links corresponded to known objects and 585 were unknown candidate links. 98.02% of the known objects with less than 1" astrometric error in the transient source data were recovered by Hyperlinc.

I'll describe how to interpret the analysis pages next.

Table 3. Results for 90 Hyperlinc processed CSS fields on 2023-02-19 (scrollable table - aggregate measures at bottom)

Interpreting the results

For each CSS field that took observations on the night, I produce a web page with Hyperlinc results. Each of these 90 web pages shows a large plot of all transient sources in the field with the candidate links that Hyperlinc found and the CSS ‘normals’ that overlap with Hyperlinc links. The MPC submitted normals that Hyperlinc did not find, if there are any, are also noted. I'll review the information presented on one of those web pages here.

I’ve tried to compare my results with CSS’ results for each field as best I can, but it’s not an apples-to-apples comparison. CSS does not publish the transient sources that it uses, and the set of transients that I compute is not identical to CSS’. Additionally, CSS produces some n=3 candidate links and also has difference image sources in some of its links. Fundamentally, what I want to do is determine if I’m finding the same unknown n=4 candidate links that CSS submits to the MPC for the set of CSS Source Extractor only sources that are in my transient source set.

Broadly, the colored dots in the plot above (Figure 4) are Hyperlinc descriptors and the circles are CSS descriptors. The gray dots are transient sources.

Green numbered dots are links that Hyperlinc found. If the green numbered link is bolded and prefixed with UNK, there is no known object associated with the sources in the link, otherwise the numbered dots are associated with known objects in the field retrieved from JPL's Small Body Identification API with SBIdent. There is no a-priori information used to identify known objects here, nor are they preferentially extracted from the set of links that Hyperlinc produces. The same process that yields unknown links also yields known object links. The known links are identified only after Hyperlinc produces its final set of candidate links.

The MPC submitted links that CSS finds that weren’t associated with a known object at the time the observations were taken are denoted by blue circles. These blue circles are CSS submitted ‘normals’. I’m also specifically calling out CSS submitted normals that are NEO candidates with a .neos attribute on the plot (see top-left blue link in Figure 3 above). Orange circles indicate ‘normal’ links that CSS found but did not submit to the MPC – probably because a human looked at the image cutouts and didn’t think the observations represented a real object. Again, for all of these I’m only showing the CSS candidates that are of length n=4 with sources that are also in my transient source set.

Red circles indicate candidate links that CSS did not find that Hyperlinc did. Red dots show known objects that Hyperlinc did not find.

One note about these CSS normals. While there were no known objects associated with them at the time the observations were taken, it’s very possible that these very CSS’ observations lead to them being designated by the MPC. So some of the CSS normals in the plot above do not have an UNK prefix by them for the Hyperlinc link. This is because the detections were known, designated objects by the time I processed the data with Hyperlinc months later.

Below the large sky plane image is a one row summary table showing the counts of objects recovered (Figure 5, above). From left to right the table shows:

• total links found: The number of candidate links generated by Hyperlinc
• known objects found (2”): The number of Hyperlinc links that match a known object to 2” or better
• unknown links: The number of links Hyperlinc found that don’t match any known object
• good astrometry knowns (1”): The number of known objects in the transient sources with less than 1" astrometric error - (this is the target I'm trying to achieve)
• good astrometry knowns found: The number of links Hyperlinc found for objects that have less than 1" astrometric error
• CSS normal submits: The count of n=4 CSS normal links that were submitted to the MPC and in my transient source set
• CSS normals linked: The count of n=4 CSS normal submits that Hyperlinc also found
• additional unknown links: The number of links that Hyperlinc found that weren’t in the set of CSS links (i.e. not in the CSS .mtds file)

When I first started generating links with Hyperlinc on real data, I had the fortunate problem of finding links that were matching known objects with what I consider bad astrometry. Hyperlinc was generating links for observations where one or more of the detections had an astrometric error of more than 1” from JPL ephemeris data. My usual threshold for matching is a detection less than or equal to 1” from the JPL data. I had to create a new category of matches for objects up to 2” so that I wouldn’t mischaracterize these links. You can see in Figure 5 above that I matched 161/162 objects that had astrometry of 1” or better. But there were an additional 17 objects that had a detection with an error between 1-2” that I was also able to match. I consider this early evidence of Hyperlinc’s ability to average out astrometric error.

Next is a table showing all of the unknown links and various image metrics (Figure 6, above).

• link id: The ID that identifies the Hyperlinc link and appears below green markers in the plot
• observer RMS: The RMS of the link in arcsec on the RA/DEC observer sky
• length: The number of sources in a link (they’re all 4 for this study)
• rgs: The number of range guesses used by Hyperlinc (they’re all 1 for this study)
• found: The number of times the set of sources that constitute the link were found
• mean mag: The mean magnitude of the candidate link sources
• mag std: The normalized standard deviation of the magnitudes
• pct close: The fraction of off-diagonals that have source extractor sources within 2” of the detection frame source
• sep RMS: Linear separation (common angular motion) fit RMS in arcsec
• plane RMS: RMS of the plane fit in arcsec
• sum RMS: Sum of 1) Observer RMS, 2) Plane RMS, 3) Sep RMS
• bg pct close: Like pct close but checking for background subtracted center values in an off-diagonal that are greater than the detection frame
• bg col pct: Fraction of columns where the diagonal background subtracted center value is not greater than sum of the rest of the column
• bg max col mean pct: Mean of non detection background subtracted center values as fraction of detection frame by column - take the highest value of all columns
• bg std: Normalized standard deviation of background subtracted center values of diagonal detection frames
• is CSS normal: Candidate link also found in CSS .mtds file

Finally, for each unknown link there is a cutout visualization of the candidate link along with a track visualization and the MPC formatted observations for the link (Figure 7, above).

The 4x4 cutout shows the detection location and time on the diagonal and then the same detection location at all other times on the off-diagonal. Time advances on the vertical axis from top to bottom. So the first column shows the detection frame in the top cutout and the 3 cutouts below it are the same location at the 3 subsequent observations on the same night. For the second column the detection frame is now the second one from the top and so on. Ideally, you want to see a centered source along the diagonal and then an either empty center on the off-diagonal or the source offset from the center indicating it has moved in between observations. I'll describe some image processing techniques I'm developing to try to quantify this visual pattern in the next section.

Below the cutouts to the left is a simple visualization of the track on the observer sky in RA/DEC. And to the right of that are the MPC formatted data for the observations.

Image metrics

For each link produced by Hyperlinc I calculate a number of metrics in order to further filter unknown candidate links. Some of these measures are derived from astrometric data, but others are calculated from processing the calibrated FITS image files that CSS produces for each observation. In Figure 7 above, the Δbg value below each cutout is the mean of the values of the center four pixels minus an estimated constant background of the 9x9 pixel field of the cutout. This Δbg value attempts to normalize the center detection pixel value's deviation from the background across different observation frames. I want to highlight three metrics derived from this Δbg value that I use to help filter non-physical candidate links.

The first metric, bg pct close, checks to see if there is a background removed center (a Δbg value) in the non-detection frames of a cutout column that has a greater value than the detection frame. It’s looking for unregistered sources that fall just below the Source Extractor threshold for detection.

The next metric, bg col pct, tells you what fraction of the four columns of the cutout have background removed center values on the non-detection observations that sum to a value greater than the detection observation center values. A value of zero means that all the non-detection observations for each column most likely don’t have a source in them. 0.25 would tell you that one column has non-detection observations that sum to more than the detection observation. Since the non-detection frames should not have a source in them, ideally, the sum of the background removed center values should be zero - or at least some number less than the background removed detection center.

My favorite of the image metrics is the awkwardly named bg max col mean pct. For each column, I average the background subtracted center values for the non-detection frames and divide this by the background subtracted center value for the detection frame. bg max col mean pct is the maximum of those 4 calculated ratios (one for each column). What is this measure getting at? With the background removed, all of the off-diagonal center pixels in each column should ideally average to zero when there is no source present because they’re just noise. The detection frame, however, should be a larger number because there’s a transient source there. Dividing the former by the latter for each column should then yield four small numbers. If you take the maximum of these ratios over all the columns and it’s still a small number, it’s a good indication that there are sources in the diagonal that are not present in the off-diagonal for all observation times. The smaller the number better.

These bg measures (which I will probably rename to something a little more intuitive) try to turn the task of visually validating cutouts for real objects into something calculable and algorithmic. You’ll also notice that many of the CSS normals have small bg measures. And though I don’t display the measure for known objects, they also have low bg metrics. In fact, the bg threshold values that I’m using as filters were chosen by looking at a few fields worth of known objects and selecting thresholds at the far right of the distributions of each bg metric. I then used those constant thresholds for all fields in this study. Just to be clear, I didn't find the thresholds for each field that would recover all known objects - that would be incorporating a-prior information. Instead, I chose constant thresholds at the start of the analysis and used those thresholds without modification for all 90 fields for the night.

All of the unknown links I’m highlighting have zero bg pct close and bg col pct values as well as low bg max col mean pct values. Real objects may not always have zero bg pct close and bg col pct values. If a stationary source is in the same location as a transient source, bg pct close and bg col pct will be non-zero. That scenario is probably better addressed by incorporating difference imaging data, which I hope to implement next. For this study I’m highlighting the more simple scenario of a transient source occupying a location where no stationary source (probably) exists.

In summary, for all of the interesting unknowns I’ll highlight below, bg pct close and bg col pct are zero and bg max col mean pct are relatively small. In theory this means that 1) there are no close by stationary sources in non-detection observations below the Source Extractor threshold, 2) the non-detection frame center values are probably consistent with noise 3) the non-detection frame center values are small relative to the detection frame center values. All of this suggests you’re dealing with a real moving object rather than noise or a stationary source masquerading as a transient source.

NEO candidates that CSS and Hyperlinc found

It appears that CSS found 9 NEO candidates on the night of February 19th 2023 judging by the number of .neos files their pipeline created. However, four of those candidates used either difference image sources or manual sources. Thus only five of these nine NEOs were detectable by my algorithm because the others contained sources not in my transient source dataset. I did find those five candidates that CSS did, and I’ll link to them here. Again, remember that I only visualize unknown objects and at the time that I ran my code the MPC had already designated 2/5 of these links. Hyperlinc still found with them no a-priori information; I just don’t visualize candidate links if they are associated with known objects as of my algorithm’s run date (mid-May 2023), which is substantially after CSS processed these fields and submitted data for them to the MPC.

NEO candidates that both Hyperlinc and CSS found

• N16056-23Feb19 ID: 1868 - Designated so no cutouts
• N23056-23Feb19 ID: 1175 - Designated so no cutouts
• N25055-23Feb19 ID: 245 - Undesignated as of May 2023
• N27053-23Feb19 ID: 1032 - Undesignated as of May 2023
• N27058-23Feb19 ID: 1174 - Undesignated as of May 2023 (wow, that's a bright one)

Interesting unknown candidate links CSS (maybe) didn't find

Finding new unknown moving objects in fields that have already been searched by CSS is not an easy task. There's not much, if anything, left to find. But Hyperlinc did generate 585 unknown candidate links whose sources were not in any CSS link that I could find. The caveat there is that CSS might have found some of these with difference image sources, which I'm not using. The other explanation for most of these is that they just aren't high enough quality to validate. Many of them are pretty dim and dim sources are hard to distinguish from noise. There are no home runs here that are completely obvious objects that CSS missed. Still, I've tried to point out some of the more promising ones.

Below are unknown candidate links with good image metrics. But even with good image metrics, you still have to look at the cutouts and decide if the data suggest a real object or not. I rely substantially on the Δbg value below each of the cutouts to do this. It tells me how far above or below the background the center pixels values are. For validation I like to see the detection Δbg value greater than 2x any other value in the column and at least one or two Δbg values on the same column in the non-detection cutouts close to or below zero. I've put a diamond (⬥) next to the candidates that meet this criteria in the list below. I should probably create an an image metric for this in the future.

All of these candidates are moving pretty fast on the the observer sky. Remember to scroll up on the linked pages to see the candidate link on the sky plane to see this. Also recall that red circles on that plot highlight a candidate link that CSS did not find and that Hyperlinc did. This list is sorted from brightest to dimmest.

Unknown candidate links Hyperlinc found with good image metrics that CSS (maybe) did not find

• N25059-23Feb19 ID: 181; Mag: 21.19
• N16059-23Feb19 ID: 1322; Mag: 21.57
• N29060-23Feb19 ID: 466; Mag: 21.66 ⬥
• N34012-23Feb19 ID: 148; Mag: 21.68 ⬥
• N29057-23Feb19 ID: 1196; Mag: 21.72
• N29057-23Feb19 ID:1657; Mag: 21.72 ⬥
• N29058-23Feb19 ID: 2174; Mag: 21.84 ⬥
• N27059-23Feb19 ID: 2173; Mag: 21.88
• N29058-23Feb19 ID: 1479; Mag: 21.86 ⬥
• N29058-23Feb19 ID: 318; Mag: 21.96
• N23057-23Feb19 ID: 366; Mag: 22.05
• N29054-23Feb19 ID: 971; Mag: 22.18
• N23055-23Feb19 ID: 765; Mag: 22.22
• N27052-23Feb19 ID: 910; Mag: 22.34

Future work

There’s still a lot of work to do to validate Hyperlinc’s utility beyond this work. While the physical model that underlies Hyperlinc would seem to work at timeframes up to at least 28 days, real-world data has repeatedly presented unexpected challenges in my experience.

My eventual goal is still to link objects over multiple nights that CSS cannot because there are too few detections (less than 3) for any single night – that’s what I was trying to do with the Heliolinc 10 night Superfield study. But I’m going to spend more time with single night data before I attempt this again. I want to improve Hyperlinc’s recovery of known objects beyond 98% - or at least understand why I'm missing linkable objects - and iterate on some of the image metrics that I’ve just started to explore and seem to be extremely useful for filtering non-physical candidate links. I also want to investigate different techniques for generating orbital planes as I’m still using tracklets to build the set of orbital planes Hyperlinc searches. This technique works pretty well, but I expect that the other techniques I outlined above will work better and scale better. And finally, I also need to incorporate difference image sources and perhaps eventually infer 4th source locations from high quality n=3 sized candidate links.

Once I can consistently link known objects of all types while simultaneously minimizing the number of unknown ‘noise’ candidate links, I’ll start trying to link over more than one night. This is a different strategy than my previous attempts where I’ve linked small field single night data and then leapt to linking large multi-field, multi-night data. I’m going to try an incremental process this time so that I can address the issues that come with bigger datasets one at a time rather than all at once. And obviously scaling is going to be one of those issues somewhere along the way as well. It’s probably best to approach that incrementally too.

Conclusion

Conceptually, I believe Hyperlinc’s isolation of transient sources by orbital plane is distinct enough from existing techniques like Heliolinc, MOPS and THOR to merit further exploration. This study shows that Hyperlinc can achieve 98% recovery of known objects with good astrometry for a single night of Catalina Sky Survey data. Hyperlinc is able to recover even more known objects with poor astrometry beyond that 98%, suggesting the ‘best fit’ nature of the linking technique has some ability to average out astrometric error. And since the physical model that underlies the algorithm was validated for 14 and 28 days with idealized observations, there is preliminary evidence that it can work for multi-night linking as well.

Acknowledgements

Eric Christensen, Siegfried Eggl and Ari Heinze provided numerous meaningful contributions to this work for which I’m very grateful. They did not, however, contribute any of the errors that may be present.

References

1. The Pan-STARRS Moving Object Processing System
2. HelioLinC: A Novel Approach to the Minor Planet Linking Problem
3. THOR: An Algorithm for Cadence-Independent Asteroid Discovery
4. A Dwarf Planet Class Object in the 21:5 Resonance with Neptune

Published: 6/4/2023