New Find_orb posted

Bill J Gray Mar 9, 2009

Hi folks,

I got a few bug reports on the recently-posted Find_Orb...
_very_ few, all easy to fix. Then I tried compiling the
Linux console version of Find_Orb, using the latest g++
version, and found some small problems (none of them affecting
Windows users). I also made some very small improvements in
ephemeris generation.

The result is a new "official" version at

http://www.projectpluto.com/find_orb.htm

I'd highly recommend upgrading to this new version.

Now that I've got a stable version posted, I can go back
to making some serious improvements. The following are high
on the list (though not necessarily in the following order).
Just to give you an idea as to where I'm headed (and in case
you'd like to comment, on or off-list):

(1) Statistical ranging (SR). This will "look" a lot like the
current Monte Carlo (MC) solution, but is better suited to very short
arcs. For example, after Richard Kowalski got an hour or two
on 2008 TC3, MC wouldn't have gotten a decent solution. (If you
try entering the first few observations into Find_Orb, and use
the Monte Carlo option, you'll see that the orbits diverge and
you get weird solutions with extreme residuals.) But SR would
have told us that the object was a likely impactor.

(2) Better display of orbital uncertainties. Both SR and
Monte Carlo give you a slew of variant orbits, a.k.a. "virtual
asteroids". Find_Orb really ought to use these to show the
sigmas in quantities such as a, P, q, angular elements, Q,
etc. (In fact, the currently-posted version does all the
calculations. I just need to add display code.)

(3) Fix up the documentation. Find_Orb has changed a lot
over the last year or so. Most things are much simpler than
they used to be, and the documentation needs to reflect that
fact (and give some more details on some of the newer features.)

(4) Show ephemeris uncertainties. You'd get the sort of
scatterplots currently shown on NEOCP.

(5) Automated detection and exclusion of observations that
are below the horizon or in daylight. This can be useful for
blunder detection.

(6) Radar evaluation. After I announced that 2009 DD45 would
be making a close pass by the earth, I got to wondering if it
could have been detected by Arecibo or Goldstone. My plan is to
revise Find_Orb so that if an Arecibo or Goldstone-centric
ephemeris is generated, the 'magnitude' field will be replaced
by some sort of 'radar detectability' measure. I've swapped an
e-mail or two with Lance Benner; he has kindly expanded my
understanding of how radar works and what factors Find_Orb will
need to take into account.

(7) The console version can generate tables of vectors and
lists of close approaches. Tables of orbital elements should
be added, and the capabilities extended to the Windows version.

(8) The console version has a 'downhill simplex' method that
backs up the usual Herget and 'full step' methods. The downhill
simplex method seems to be very robust (unlikely to give weird
divergent orbits the way the other methods do), though somewhat
slow. This needs to be extended to the Windows version.

(9) Inclusion of atmospheric drag. Then I could say something
about where 2008 TC3 landed, for example, instead of saying
"this is where it would have landed if Earth were airless".
Also, it's looking as if Find_Orb may get some use with data
from video observations of meteors.

(10) ...Anyone want to suggest something not listed here?

-- Bill