Documentation for Find_Orb, and an upcoming change

Bill Gray Jun 19, 2014

Hello all,

First off... I'm very happy to say that Tony Evans has just posted
a "Find_Orb Reference Guide" at :

http://www.myastrostuff.com/SRG/Find%20Orb%20Reference%20Guide%20140614.pdf

I think this will be quite useful in figuring out how to get Find_Orb
to behave properly. It's true that the Find_Orb page on my site gives
you a lot of details; but my docs were written by the same guy who wrote
the software, and that's not necessarily a good idea. When you document
your own software, you subconsciously assume some things as being
"obvious" which, to somebody else, aren't going to be "obvious" at all.
So I owe Tony a very big thank you for this.

Secondly... while Tony was doing this, I was busy working on something
that will immediately make some parts of the documentation obsolete.
Namely, I've been trying to improve the way in which Guide handles
uncertainties, previously described as "weighting".

This isn't posted yet, but people who set observational weights/
uncertainties should be aware that the methods for specifying them will
be changing quite soon.

There were two defects with the old method. First, if you set a
weight of (say) 4 for an observation, it was treated internally as meaning
the astrometric error (sigma) was 0.25 arcseconds; in other words, the
sigma was the inverse of the weight. Especially with the inclusion of
radar data, with uncertainties in round-trip-time and Doppler shift,
it made more and more sense to speak, not in terms of "weights", but
of "uncertainties" or "sigmas".

This became especially true because I've needed to add the ability to
specify uncertainties in magnitude and timing, in addition to the
uncertainty in astrometry. If you look at

http://www.projectpluto.com/sigma.txt

you'll see how this works. 'sigma.txt' looks much like 'weights.txt',
except with extra columns for the mag and timing uncertainties and the
fact that the positional sigma is stored, instead of its inverse.

I'm quite happy about these changes. The inclusion of timing errors
will be a big improvement for close-approaching/rapid-moving objects. (I
don't know of any orbit computers who are including timing errors, but
I'm realizing that we all should.) Including magnitude errors will be
_really_ helpful, mostly in giving us the ability to set large sigmas
for certain "offenders" who provide junk photometry; there are situations
where I've thought we had a really big rock that turned out to simply
result from bad photometry that had been given the same weight as the
good stuff. (I must concede that the theoretical usefulness of this
approach has a problem in practice : namely, figuring out the uncertainty
in any quantity is hard to do, and the existing 80-column astrometric
format doesn't provide any help at all.)

-- Bill