Re: [find_orb] Re: Positional uncertainty PA value?

Andy Puckett Nov 11, 2014

I am very very happy that Find_Orb is now presenting uncertainties in ephemerides based on the iterative process of solving a single best-fit orbit to the observations.  I have been kludging my way through this for years, running Monte Carlo orbits, visualizing them in Guide, etc.  To have an estimate presented immediately is amazing!

Except when I have observations that fail to fit.  For example, I am looking at just the 6 observations of 2004 YW5 on 2014 10 22:

     K04Y05W  C2014 10 22.33863 02 13 29.79 +29 54 39.2          18.7 Vq~1AxpG96
     K04Y05W  C2014 10 22.35424 02 13 29.39 +29 54 34.6          18.9 Vq~1AxpG96
     K04Y05W  C2014 10 22.37343 02 13 28.84 +29 54 29.0          18.9 Vq~1AxpG96
     K04Y05W  C2014 10 22.38901 02 13 28.44 +29 54 24.3          18.8 Vq~1AxpG96
     K04Y05W  C2014 10 22.45264 02 13 26.87 +29 54 04.8          19.8 gN~1AxpI41
     K04Y05W  C2014 10 22.47917 02 13 26.22 +29 53 56.4          19.7 gN~1AxpI41

At the time, these observations were unconnected with this final designation, bearing instead the NEOCP designation VUA993A.  Find_Orb actually does a fair job of getting a reasonable orbit immediately upon loading the data.  However, pressing "Auto-Solve" produces a completely ludicrous ultrahyperbolic orbit.  I have tried starting with the Vaisala button and then making a few presses of Herget Step, but it's not quite as good as that first solution.  I'm not sure if I tried any Full Steps or not.

Is there a standard recipe I could follow in trying to get a reasonable orbit for such a short 3.4-hr arc?  Is there a constraint I could plug in to avoid hyperbolic orbits?  (I keep hoping that inequalities could be valid constraints, but the docs hint that only equalities are.)  I don't want to use any post-facto knowledge of the current orbit in doing this, because I'm presenting this as a project to a college student along with unsubmitted observations from the next day, and he does not yet know the above official designation.

Also, is there any reason that the recipe followed by Find_Orb to find an initial orbit upon loading data shouldn't produce an uncertainty estimate?

Thanks all,
Andy Puckett

Asst Prof, Earth and Space Sciences
Columbus State University

On Tue, Nov 11, 2014 at 8:55 PM, Bill Gray pluto@... [find_orb] <find_orb@yahoogroups.com> wrote:
 

Hi Peter, Tony,

Yup, you're right; Find_Orb is measuring the uncertainty position
angle in the wrong direction. I've checked the code, and I see
exactly where I got the negative sign in there, and have fixed it.
I'll post this in a bit... there are a few things I should clean up
before I post an update.

There will still be some ambiguity for more precise cases; as
Tony mentioned, when the uncertainty is small, the uncertainty
"ellipse" becomes more of an uncertainty "circle". There will also
sometimes be a disagreement of 180 degrees, because if the
uncertainty ellipse sticks out, say, a little north of due
east at position angle 73 degrees, it also sticks out a little south
of due west at position angle 253. Find_Orb always gives a value
between 0 and 180 degrees; MPC sometimes picks the westward-aiming
side of the uncertainty ellipse.

As Tony points out, you also get some differences between Find_Orb,
MPC and NEODyS because of different assumed uncertainties in the
observations, and because Find_Orb accounts for timing errors,
over-observing, and blunder management. As far as I know, NEODyS
has an over-observing scheme that gives lower weight to a station
that has submitted many observations in one night; but I don't think
they include timing errors or blunder management. I don't think MPC
includes any of these effects.

For objects with significant (more than a few arcseconds) uncertainty,
you'll mostly see disagreements in the magnitude of the uncertainty.
We'll usually have roughly the same position angle of uncertainty...
that is, we'll all tell you, "look a little north of due east and
a little south of due west", but we won't quite agree on just how far
out you'll need to look.

-- Bill

On 11/11/2014 03:31 PM, lists@... [find_orb] wrote:
>
>
> Tony,
>
> I probably shouldn't have confused things with 2014 VQ! All the other objects I've tried (single opp NEOs last observed a few years ago) like 2009 VZ have very stable PAs of uncertainty and as originally mentioned, MPC and NEODyS agree closely, FO doesn't.
>
> I think you're very likely right that FO is counting these uncertainty PAs clockwise from N, the opposite to the MPC, even though the direction of motion on the sky matches the MPC values and is counting anticlockwise from N.
>
> Peter
>
>
> ---In find_orb@yahoogroups.com, <tony.evans@...> wrote :
>
>
> Peter, I think the problem with a situation like this that the uncertainty is small (FO says 0.1") and the PA of the uncertainty is itself uncertain. It can vary hugely depending on exactly which set of observations FO/MPES are using. The frequent arrival of new observations and revisions of the elements will cause big changes in the uncertainty PA.
>
> When using FO, the exact settings will also cause differences - contents/use of sigma.txt file. Filter setting, time of download of obs DB etc.
>
> This morning (9:00 UT) I get an uncertainty PA of 23.0 from the MPES for J95 at 1:00 on 11/11.
>
> Using FO, and depending on which observations I select, sigma.txt, filter, I can get uncertainty PAs that range from 4 to 157 for J95 at 1:00 on 11/11.
>
> The objects I originally tried had big uncertainties 2014 MQ67 and 2011 JU2 so the exact settings make little difference and MPES/FO should get near identical results.
>
> Tony
>
>
>