RE: [find_orb] "Future" Astrometry Ignored in Find_Orb

Andrew Lowe Dec 14, 2015

Message
Thanks Bill, your explanation for keeping those future dates works perfectly.
 
As for why I want to do this, I'd like to update my listing of upcoming close approaches of PHAs:
 
http://members.shaw.ca/andrewlowe/ALL-PHAS.HTM
 
with Aldo Vitagliano's Solex 11.09 numerical integrator.  But to do that, all the PHA orbits need to have a common epoch, and Hathor's orbit in Horizons has a non-standard epoch.  Now, since Hathor has a very good orbit (due in part to radar), I just loaded between 50 and 60 widely-spaced dates of ephemerides from 1960-2095, and computed the orbit from their ephemerides.  If I ever need the orbit at a different epoch, I just use the same data and enter a new epoch.  I know this is unconventional and not for everyone, but it fits my purposes.
 
One final thing; a purely gravitational solution is lousy.  Horizon's ephemerides include an A2 term to fit the data better (if you check out the residuals in the MPC's solution, they throw out entire apparitions because they don't include the A2 term).  Horizon's value is -3.03e-14.  As a check, when you turn on the comet non-grav term within Find_Orb, it computes A2=-2.84e-14.  Not too bad at all, is it Bill?
 
While most PHAs have well-behaved solutions, there are at least two objects, Hathor and Hermes included, where multiple close approaches to the earth can really affect the accuracy if the initial orbit is deficient.
 
Andrew
 
-----Original Message-----
From: find_orb@yahoogroups.com [mailto:find_orb@yahoogroups.com]
Sent: December 14, 2015 11:10 AM
To: find_orb@yahoogroups.com
Subject: Re: [find_orb] "Future" Astrometry Ignored in Find_Orb

 

Hi Andrew,

Take a look in 'environ.dat'. You should (if you're using a somewhat
recent version of Find_Orb) have a line that says

TIME_RANGE_OBS=1000,2020

This should probably say something more along the lines of "no future
observations", rather than cutting them off at 2020. (Or, perhaps,
have Find_Orb do what it does for many other errors, and have it
give you a warning message.) Anyway, change that to 2089 or whatever
your maximum date is, and you should be all set.

Now, that said... I'm still not clear on how adding in the Horizons
positions will help. Your best bet would be to get all current data
from the NEODyS system (MPC doesn't have radar data, quite important
in these cases). I got the data from

http://hamilton.dm.unipi.it/~astdys2/mpcobs/numbered/2/2340.rwo

The Yarkovsky effect will cause some trouble for a small object such
as this over a long enough time span. So take another look in 'environ.dat'
for the 2009BD line. This has a bit of explanation above it, showing
how it enables a "standard" outward-forcing radiation force, plus an
"along orbit" one. Set 2009BD=1, and start up Find_Orb and load the
2340.rwo file. "Auto-Solve" will get you a decent orbit to start
with, but with high residuals and no non-gravs.

Go into Settings, and turn on the 'comet non-grav' model, and
click OK. Then use "Filter Observations to throw out the outliers.
I threw out those beyond two sigmas. After I did this a few times,
I got a "No changes made!" message.

At this point, I set the epoch to 2069 Oct 21 and did a 'full step',
and got

Orbital elements: (2340)
Perihelion 2069 Aug 11.291296 +/- 0.000174 TT; A1=6.31e-12, A2=-2.64e-14
Epoch 2069 Oct 21.0 TT = JDT 2477040.5 Earth MOID: 0.0058 Ve: 0.0904
M 90.04958 +/- 0.00026 Me: 0.0261 Find_Orb
n 1.27352894 +/- 5.65e-7 Peri. 40.55329 +/- 0.00007
a 0.84294033 +/- 2.49e-7 Node 210.63965 +/- 0.000017
e 0.4510473 +/- 1.14e-7 Incl. 5.93055 +/- 0.000015
P 0.77/282.67d H 20.4 G 0.15 U 3.1
q 0.46273433 +/- 2.04e-7 Q 1.22314633 +/- 3.22e-7
383 of 426 observations 1976 Oct. 25-2014 Dec. 6; mean residual 0".44

You'll note that by doing this, you get orbital elements that have
formal uncertainties. (Actually, you would get sigmas if you used
Horizons "observations", too, but without a knowledge of how good
the Horizons ephems were, the sigmas would be meaningless.)

-- Bill

.