A much faster and easier way, with far less PC space required, is to simply go to the MPC
site:
http://www.minorplanetcenter.org/iau/MPCORB/NEAm00.txt
which will give pertinent TODAY's parameters for nearly all objects of interest and
importance in terms of desired observations by MPC and other organizations.

Merely save that file into your Guide folder as "mpcorb.dat" and that will substitute for
the horribly large and many times epoch-challenged MPCORB files that you normally would
download. In addition if you will DUPLICATE this same file and rename it to "neatod.dat",
it will serve as the measuring standard for astrometric reductions via Charon.

Dr. Clay
_____
Arkansas Sky Observatories
MPC H45 - Petit Jean Mountain South
MPC H41 - Petit Jean Mountain
MPC H43 - Conway West
http://www.arksky.org/

----- Original Message -----
From: "Bill J Gray" <pluto@...>
To: <guide-user@yahoogroups.com>
Sent: Sunday, October 31, 2010 10:14 AM
Subject: Re: [guide-user] MPCORB-based position 9' wrong for asteroid 2003UV11 ? why ?


> Hi Peter,
>
> I can't blame MPCORB.DAT for this error. (Well, not accurately,
> anyway.)
>
> The problem is that the elements are for the epoch 2010 July 23,
> and perturbations between then and now are ignored by Guide. Usually,
> this isn't a very big deal (except for people doing asteroid occultation
> work, who need things down to the last milliarcsecond of precision).
> 99% of Guide users will never notice. But 2003 UV11 is a very near-earth
> object. Any perturbations are "magnified" by the object being so close
> to us. A thousand-kilometer error would be negligible for a main-belt
> asteroid two AU from us; it suddenly becomes much more noticeable when
> the object is only .01 AU away.
>
> MPC keeps all elements on a "standard" epoch. In this case,
> 2010 July 23 = JD 2455400.5. The epoch is always an even multiple of
> 200 days, plus .5 days. They usually keep it within 100 days of the
> present... today is 2010 Oct 31 = JD 2455500.5, so you are seeing
> the maximum possible error!
>
> JPL chose the epoch JD 2455502.5 = 2010-Nov-02. You wouldn't see
> much error at all with those elements.
>
> The ideal solution to this problem would be for Guide to do the
> numerical integration so that perturbations would be included. There
> are some problems with this, mostly involving speed. Another excellent
> solution would be for MPCORB to have an epoch that changes more often
> than once every 200 days. That would both decrease the sort of error
> you're seeing now, _and_ mean than if Guide did the numerical integration,
> it would usually be for a few days instead of up to 100 days.
>
> One _can_ create an MPCORB.DAT with a more current epoch. (Or with
> any desired epoch, useful in case you want to run things backward or
> forward a hundred years or so.) The tool required is described at
>
> http://home.gwi.net/~pluto/integrat.htm
>
> It's a bit of a hassle to do this, and I don't expect most people
> to bother. That's one reason having Guide do the integration itself
> still matters.
>
> -- Bill
>
>
> ------------------------------------
>
> To unsubscribe from this group, send an empty email to:
> guide-user-unsubscribe@egroups.comYahoo! Groups Links
>
>
>
>