Matson, Robert D. Feb 10, 2013
> Date: Wed, 6 Feb 2013 21:37:13 -0500[Non-text portions of this message have been removed]
> From: pluto@...
> To: find_orb@yahoogroups.com
> CC: alessandro_odasso@...
> Subject: Re: [find_orb] (6995) Minoyama
>
> Hi Alessandro,
>
> Hmmm... a bit of a puzzling case here.
>
> > If you solve the orbit using all observations, with _no_perturbing_
> > asteroid_ you have the following residuals for the 1956 observations:
>
> I tried generating ephemerides for 1956. I don't have your observations,
> but expect that computing orbits with the astrometry available from MPC,
> running from 1978 to 2012 and then computing ephemerides for 1956 should
> allow me to see any effects due to asteroid perturbations.
>
> What I saw was that toggling asteroid perturbers on or off changed
> the predicted location for 1956 by a few tenths of an arcsecond. Seems
> strange that you're seeing so much more!
>
> > What is strange with (6995) is another thing.
> >
> > If you choose Venus as a perturber, the overall residual improves
> > from 0.599 to 0.589 but the specific individual residuals of the 1956
> > observations deteriorate :
> >
> > ...In practice, turning Venus on, destroys the benefits of taking into
> > account the (big) asteroids.
>
> I've seen some odd effects of this sort, where turning off a perturber
> causes residuals to drop. This does _not_ mean that you're better off
> ignoring that planet! You can be certain that the actual universe never
> shuts off perturbers.
>
> > (2) - Find_Orb is right, Venus is a strong perturber and this suggests
> > us that there are probably other unknown asteroid perturbers which almost
> > counterbalance the Venus effect.
>
> As it happens, I was indeed unable to resist the urge to add the 300
> asteroid perturbers in Jim Baer and Steve Chesley's BC-405 ephemerides.
>
> I ended up using the method suggested in my most recent e-mail on the
> subject. BC-405 provides elements at 40-day intervals. Find_Orb
> computes the position for each object at the start and end of those
> intervals and stores that data (i.e., it only has to be computed once).
> During an integration, Find_Orb checks to see if our object is in the
> "box" defined by the coordinates of each object at the start and end
> of those forty days. It turns out that usually, there are zero or one
> perturbers out of the 300 that need to be checked (though I've seen
> situations where four needed to be checked).
>
> The end result is that a "full step" with asteroid perturbers turned
> on now takes about twice as long as a "full step" without asteroid
> perturbers; i.e., the asteroid perturbers double the computational
> load. (I've ideas for improving this, but really should get back to
> other projects...) I tried it first on (50278) 2000 CZ12, an
> object that was strongly perturbed by (15) Eunomia :
>
> http://tech.dir.groups.yahoo.com/group/mpml/message/17235
>
> Find_Orb defaulted to a pretty ugly orbit for this object. Adding in
> asteroids didn't help previously, since Find_Orb was limited to Ceres,
> Pallas, and Vesta. With BC-405 in the mix, I'm now getting a perfectly
> reasonable result.
>
> Anyway... I've tried it with (6995), with no significant effect. So
> I don't think this object is experiencing another asteroid perturber.
>
> -- Bill