search

Bill-Gray / lunar

Basic astronomical functions
https://www.projectpluto.com/source.htm
GNU General Public License v2.0
92 stars 46 forks source link

Astcheck: stalls for objects with poorly determined orbits #16

Closed dpieterse closed 2 years ago

dpieterse commented 2 years ago

When I tried matching some of my detections to all known objects (in MPCORB and in JPL's comet database, which I combined into a SOF-format catalogue using mpc2sof.cpp) using astcheck.cpp, I encountered some stalls. These happen when astcheck attempts to match some of the comets with poorly determined orbits to my observation. Specifically this happens in the function _compute_asteroidloc (called in line 708 in astcheck).

Example:

 0011819  C2020 10 04.88134 01 00 32.05 -72 00 16.0          19.5 G      L66

When matching the observation above, I'm getting a stall when astcheck attempts to match the observation to C/2002 Q6.

Could you add a time-out option to the position computation, so that whenever it stalls on an object like this, astcheck simply skips it and continues with the next known object?

Bill-Gray commented 2 years ago

Thank you. I tried your example case and got the same problem.

I suppose I could have done some sort of 'skip it' step, but this is really a bug; it should be fixed, not simply side-stepped. So I investigated a bit. Turns out that when fed a single observation, astcheck was computing the object position for JD 0. I've fixed this (commit 474b22a8b90f6f22d9b). When I run it on your example, it now figures out that it's C/2002 Q6.

I've used astcheck almost solely in "motion" mode (two or more observations, so that identifications can be done on the basis of both position and motion). The bug doesn't occur in that case, so I never noticed it. Apparently, the occasional instances where I did have single observations/no motion never triggered the bug.

However, I'm currently working on improving the program's abilities for handling single observations; I have some folks who want to use it for "what objects are in this field" problems. So there will be further fixes/improvements coming for this program that may (or may not) be useful for you. It also means that if you run into other bugs or have suggestions for improvements, this is an excellent time to mention them.

dpieterse commented 2 years ago

Thank you so much for you quick response and fix!

I very much look forward to the further improvements you mention. I'm planning to run astcheck on all (single) detections made with the MeerLICHT & BlackGEM telescopes, to find asteroids in our data that we cannot identify with linking software (which requires at least 3 detections). And indeed, using it to predict which objects are in a field is also extremely useful.

The two suggestions that I currently have for improvements are:

Bill-Gray commented 2 years ago

Hmmm... not sure what you mean about 'used on the JPL comet database'. It currently does that, using JPL's DASTCOM. (Which is about as good as we have at present. MPC's comet elements are incomplete and sometimes in error, and the IMCCE elements are not updated all that often.

On the second bit : that's something the folks I'm working for are very interested in, as am I. It will require my generating orbital elements with uncertainties; as you say, we can't get those from MPC or JPL. (Such a catalog will be a useful thing in and of itself. It will probably cover only the unnumbered minor planets; for numbered minor planets, we can assume the uncertainty is "low". I don't expect to try for comets, at least at first.)

It's not apt to happen really soon, but it'll make it possible to identify tracklets even if they are quite far off prediction.

dpieterse commented 2 years ago

Perhaps I'm misunderstanding what the DASTCOM database is. I downloaded the JPL orbital elements of the comets from: https://ssd.jpl.nasa.gov/dat/ELEMENTS.COMET (as listed here https://ssd.jpl.nasa.gov/sb/elem_tables.html). When I try running integrat on this file, it doesn't recognize any of the comets for integration.

Your documentation (https://www.projectpluto.com/pluto/integrat.htm) doesn't mention running integrat on JPL's comets. It does mention running integrat on the MPC comet elements, which indeed works. But as you mention, using JPL comet elements would be preferable.