Orbit determination from observations

Last updated 13 November 2006

Italian version of this page

French version of this page

(24 Aug 1999) Find_Orb tracks Cassini!

Revisions

(13 Nov 2006) You can now select multiple observations, then toggle all of them at once (using a new "Toggle Obs" button) or set all of their weights at once (using a new "Set Weight" button).

(13 Nov 2006) You can now get motion and alt/az data in the Make Ephemeris box. Click here for details.

(13 Nov 2006) The text-based (console) version of Find_Orb now includes some ability to just read a file full of astrometry and crunch out orbits, without user interaction. Click here for details.

(13 Nov 2006) The magnitude parameters are now shown more intelligently: H and G are given for asteroids, M(T) and K (or M(N) and K) for comets. For asteroids, magnitude parameters are also correctly adjusted for magnitude band (previously, that information was ignored!)

One can select total or nuclear comet magnitudes in the Settings dialog. The magnitude parameter K defaults to 10, and the asteroid magnitude slope parameter G to .15 (the "usual" values for a newly-found object), but you can constrain K or G to other values.

(3 May 2006) The MOID (Minimum Orbit Intersection Distance) relative to the Earth's orbit is shown if that distance is less than one AU. It is also shown for other planets if the distance is small enough (limits are .1 AU for Mercury, Venus, and Mars, and one AU for the other planets).

(3 May 2006) It's possible to reset the weights for observations, in any of three different ways. Click here for details.

(3 May 2006) You can now get ephemerides in Cartesian coordinates (either position-only, or position-plus-velocity).

(3 May 2006) The text-based (console) version of Find_Orb now supports some mouse commands, at least on some platforms.

(3 May 2006) In addition to MOID data, a few other minor details are now shown in the elements, such as the apoapsis distance (Q) and the time of perihelion, expressed in HH:MM:SS form.

(4 Oct 2005) There is no longer an integration step size control. It's no longer needed; Find_Orb now automatically detects the step size needed at each point in the integration. This can result in some tremendous gains in speed. It also improves accuracy; in the past, people would sometimes load observations for artificial satellites without dropping the step size, and would get bizarre results. That shouldn't happen now.

(4 Oct 2005) Find_Orb can now read ephemerides from the Minor Planet Center's NEOCP (Near-Earth Object Confirmation Page) as if they were observational data. To do this, set the NEOCP ephemeris to be from a topocentric MPC station. (The main reason for this is that a topocentric ephemeris will include some parallax, making the range determination much more accurate.) Save the entire ephemeris, including the header line that says "Below are the results of your request", etc.

(Note that as of early 2007, this isn't a very important feature. MPC used to provide no data for NEOCP objects but ephemerides. Now, you can get the raw observations and feed them to Find_Orb, just as with any object. That's a much better idea than using an NEOCP ephemeris... but you can still do it if you want.)

Aside from selecting a topocentric MPC code, and perhaps changing the "Start ephemerides at now + (blank) hours" options, you should leave everything at its default setting. That is, you should have a one-hour ephemeris step, full output, and positions in full sexagesimal. Save the page as a plain ASCII file, and load it into Find_Orb, and you should see the NEOCP objects listed. You should be able to click on them and get orbits for them, just as if the input file was one of actual observations.

A few warnings: if you click on "File... Save Page", you may not actually get the page. Instead, the file will contain an error message about how no object was selected for the ephemeris. To get around this, I've used "Select All" (or selected all the text with the mouse), hit Ctrl-C (Copy), then gone to a text editor and hit Ctrl-X (paste).

Also, MPC doesn't always include perturbations for NEOCP objects. This may seem a bit odd, given that the objects are NEOs. But you may find that when you turn on the earth and moon as perturbers for one of these objects, the orbit goes haywire. Or you may not, either because MPC included perturbations or because the object is far enough away that perturbations don't matter anyway.

Also, I fixed a bug that was, I think, keeping the program from working on the Mac. And I changed the initial orbit determination routine to favor (by a small margin) prograde orbits over retrograde.

The third reason I know that it's working is that I fed Find_Orb data for (197) Arete, with the astrometry coming from AstDyS. (See the following section about use of AstDyS data.) This object had a close pass by Ceres some decades ago, and the resulting deviation in its path has been used to determine the mass of Ceres. I found that if I did a solution with "asteroids" checked, the RMS error dropped a bit relative to the RMS error without "asteroids" checked.

(26 Aug 2003) A few small improvements have been made to the "pseudo-MPEC" capability. Some of the existing capabilities, such as editing the list of observatory Web sites and so on, are better documented now.

(11 Apr 2003) There is now a Gauss button, to determine orbits by that method.

(11 Apr 2003) The "pseudo-MPECs" now link the observatory lat/lon text to maps indicating where these observatories are on the earth. Also, as is discussed at the above link, you can cause Find_Orb to insert your name in the elements.

(11 Apr 2003) The astrometry for the Earth-orbiting IMP8 satellite has finally enabled me to test Find_Orb's handling of the earth's equatorial bulge, the "J2" effect. (Testing this required a satellite orbiting close enough to the earth for a long enough time. The J2 effect drops rapidly with distance from the earth; satellites such as J002E3, for example, are almost totally unaffected.) It turned out that the force due to J2 was computed correctly, but with the wrong sign. This is now corrected. (I seriously doubt that anyone has been using Find_Orb in a situation where this matters!)

(7 Mar 2003) Fixed two bugs that caused crashes (for some people) when they tried to create ephemerides or use the new Monte Carlo feature. The former crash occurred if you used Find_Orb's built-in routines to compute planetary positions, instead of having it get planetary positions from the JPL DE ephemerides. While this bug is fixed now, use of DE ephemerides is still highly recommended. The program can run a lot faster if it uses one.

Also, the Monte Carlo function got confused when dealing with objects orbiting planets (artificial and natural satellites.) This has been fixed.

(10 Feb 2003) Find_Orb can now compute ephemeris uncertainty regions, using the observational Monte Carlo method.

(10 Feb 2003) Find_Orb now generates a "pseudo-MPEC" .HTML page, vaguely resembling those produced by the Minor Planet Center.

(9 Dec 2002) In the course of analyzing the orbit of J002E3, an object originally assumed to be a near-Earth asteroid but now almost conclusively determined to be the SIVB stage from the Apollo 12 mission, I found that the mass value used for the Earth was slightly in error. You would never have noticed it with asteroids/comets, which don't linger close to the earth for weeks on end; nor with artificial satellites, where you (usually) don't have extremely long orbital arcs. Anyway... it's fixed.

You can learn a bit about JPL DE ephemerides here, and find out how to purchase or download (free) DE data here. (You can also find a DE file on the second Guide 8.0 CD-ROM.) You will then have a file with an extension such as '.200', '.405', or '.406' (corresponding to the DE-200, DE-405, or DE-406 ephemeris). Suppose the file was on your CD-ROM, and had a name such as d:\unix.405. To get Find_Orb to make use of that file, edit ENVIRON.DAT and add a line such as

JPL_FILENAME=d:\unix.405

Note: Linux users would instead, or also, add something like:

LINUX_JPL_FILENAME=/cdrom/unix.405

About the only major difference you'll see is in speed. Incidentally, if you wind up solving orbits that run outside the span of the DE file you've provided, Find_Orb will fall back on the PS-1996 and ELP solutions.

Also, following some prompting by Pertti Pääkkönen, I fixed most of the problems that were apparent when attempting to run the program in Linux.

(26 Apr 2001) There is now a way to get constrained orbits, in which you specify an assumed eccentricity, and/or semimajor axis, orbital period, inclination, etc.

51 language i
51 language f 

(28 Mar 2001) A whole slew of revisions, some of which have been present for a while but not documented, but some are actually new:

(1 Jan 2000) Two people pointed out that Find_Orb doesn't properly handle objects with observations straddling 1 Jan 2000 0:00 UT. The observations after that date are shown first in the residuals box, instead of after the 1900s observations. This has been fixed. It just involved telling Windows not to sort the residuals, so there was no change made in the source code posted on this site.

What is Find_Orb?

Find_Orb can take a set of observations of an asteroid or comet, given in MPC (Minor Planet Center) format or the NEOIBO or AstDyS formats, and find the corresponding orbit. The MPC format is a "standard" used by most astrometry software, including Charon. You can click here for details of the MPC format.

Find_Orb can determine orbits of artificial Earth satellites and for satellites of other planets. It exists as both a 16-bit Windows program, and as a 32-bit Windows program. The only difference between the two is that the 32-bit version is considerably faster. In what follows, I'll just refer to "Find_Orb", without making a distinction between the two flavors.

Find_Orb is a user-friendly program that handles the initial determination of the orbit using the method of Herget. Given some more observations, it can find a "best fit" orbit using the method of least squares . It's sufficiently bright to include the perturbing effects of the planets and Earth's moon, those of Jupiter's four largest satellites, several of Saturn's satellites, and those of the three largest asteroids.

Why does Find_Orb exist?

Find_Orb is, in some ways, of limited value. Most people will measure the position of an object on several nights, using a CCD camera with software such as Charon, and e-mail the observations to the Minor Planet Center. The MPC will accumulate observations, then report the resulting orbit and ephemerides via IAU Circulars and MPECs.

There are three groups that might want to use Find_Orb. First, there are a very few people tracking near-earth asteroids (NEAs) who have the need to get updated orbits right away, almost immediately after an observation is made. Since NEAs tend to come, then go, almost immediately, it would be well if observers could get instant feedback on the orbital elements. Find_Orb provides this.

Second, I've used Find_Orb to test the quality of astrometric observations. If someone measures an asteroid several times using Charon, and I feed their results through Find_Orb and see that their positions line up nicely on an orbit with residuals of around an arcsecond, I start to feel much better about the quality of their astrometry. So astrometrists in general may have an interest in the software.

Third, Inquiring Minds are sometimes curious about the entire "black art" of turning astrometric data into orbital elements. This was my main motivation for writing Find_Orb. (And it's turned out to be useful for academic purposes; I occasionally hear from students using Find_Orb as part of their coursework.)

There is a fourth reason, particular to my own needs as a vendor of astronomy software. I found a set of observations of four of the outer satellites of Jupiter (J-6, 7, 8, and 9), and wanted to use them to derive a theory to describe their motion. Their motions are quite bizarre; in fact, two of these satellites are in retrograde orbits. As will be described below, Find_Orb can indeed solve for such orbits; I've gotten good solutions for all of the irregular satellites of Jupiter (and, more recently, for all other irregular satellites in the solar system, including the new irregular satellites of Saturn and of Uranus and Jupiter. I've even gotten orbits for the Galileans and a few of the inner satellites of Saturn and Uranus, but these push the limits of what the software can do. The orbits "work", but are not especially good.)

Restrictions on use

Find_Orb is copyrighted freeware. Use in or with commercial software is expressly forbidden without written permission from Project Pluto:

But aside from such commercial uses... please use it freely. (If you use it for something really interesting, please let me know!)

Other orbit determination software of interest

Perhaps the most widely-used publicly available software comparable to Find_Orb, allowing you to include perturbing objects and to do both initial and full least square orbit fitting, is the OrbFit software. It's also freeware (with restrictions similar to those for Find_Orb). It was put together by about half a dozen professional astronomers, and can run in Windows 95/98/NT or Unix. FORTRAN source code is provided. (You can also click here for information about the C/C++ code for Find_Orb.)

OrbFit also includes code to do some quite advanced tasks, such as figuring out proper orbital elements, impact probabilities, use radar observations, compute error values for almost all parameters, etc. In most ways, it's much more sophisticated than Find_Orb.

Pasquale Tricarico has informed me of the development of the ORSA (Orbit Reconstruction, Simulation and Analysis) project. This will provide a core library and a set of tools for orbital determination tasks.

Jim Baer recently wrote to point out his recently-published CODES software (http://home.earthlink.net/~jimbaer1/), which "performs comet/asteroid initial and least-squares orbit determination, collision analysis, ephemeris calculation, and object identification. CODES utilizes integrated n-body mechanics that account for cometary thrusting (if applicable) and gravitational perturbations (including relativistic effects) from the Sun, nine planets, Earth's Moon, and up to 300 asteroids." It also does some things in the area of computing covariance matrices and sigmas that are not (yet, anyway) implemented in Find_Orb.

Aldo Vitagliano's SOLEX package includes an orbit-determination program, FindOrb (same as my software but without the underscore). SOLEX also has some impressive capabilities (not available anywhere else, as far as I know) for integrating the entire solar system forward/backward in time. So it can compute where planets were tens of thousands of years ago or from now. (Most software, my own included, is accurate over only a few thousand years.)

John Rogers' CCD Astrometry software has an orbit-determination part, including the ability to determine ephemeris uncertainty via the Monte Carlo method.

If you know of other orbit determination software not listed here, please e-mail me.

Where does one get observations to feed to Find_Orb?

Ideally, one should get a CCD camera and download Charon (astrometry software that works with Guide), gather images and positions for some asteroids, and report those positions to the Minor Planet Center. As a side benefit, one can use those positions in Find_Orb.

Originally, I tested Find_Orb using observations reported in Minor Planet Electronic Circulars (MPECs). The observations are reported in MPC format, of course, so you can feed the MPECs directly into Find_Orb, without even bothering to eliminate the other text associated with an MPEC; Find_Orb will recognize which lines contain observations and which contain other data.

Also, one can get observations for most asteroids from NEODyS and AstDyS, in their .rwo format

A file containing "observations" for two totally imaginary asteroids, a (real) satellite of Jupiter, and simulated observations of the Mir space station is supplied with Find_Orb. The asteroid cases are the most practical; they ensure that you will have two "known" cases to work with before trying your own observations.

Starting Find_Orb

You'll first have to download either the 16-bit or 32-bit Find_Orb from this page, copy it to your Guide directory, and unZIP it. Installed in Windows, it will provide a rather ugly icon showing a yellow sun with an object orbiting it.

When you start it up, you'll get a big dialog box. There is an "Open..." button in the upper left corner; click on it and select EXAMPLE from the Open File dialog box.

Right below that "Open..." button is a small list box that will show all the objects Find_Orb found in that file. In the case of this file, it will find observations for two imaginary objects, 1996 XX1 and 1997 ZZ99, the Mir space station, and Sinope (Jupiter IX, a faint outer satellite of Jupiter).

Running Find_Orb with 1996 XX1

We'll try the easy one first. Double-click on 1996 XX1, and Find_Orb will immediately find the following pretty good orbit:

Orbital elements:
1996 XX1
   Perihelion 1998 Mar 8.969361 TT = 23:15:52 (JD 2450881.469361)
Epoch 1997 Oct 23.0 TT = JDT 2450744.5   Earth MOID: 0.0615   Ma: 0.0049
M 324.90486              (2000.0)            P               Q
n   0.25622617     Peri.   72.47300     -0.50277705     -0.86441415
a   2.45501256     Node    47.71103      0.79213685     -0.46159042
e   0.5741561      Incl.    0.14296      0.34602664     -0.19930493
P   3.85           H   15.8     G   0.15   q 1.04545211  Q 3.86457302
From 13 observations 1997 Oct. 12-22;   RMS error 0.485 arcseconds

In this instance (and in most instances), Find_Orb can get something close to the right orbit without you having to adjust it. The residual errors are in the proper ballpark (under an arcsecond or so.) The orbit has a large enough MOID with the Earth so that it's not a danger to us, though Martians might worry about the Mars MOID of .0049 AU. Again, you'll usually get an answer that indicates a sensible, non-threatening object.

In this case, you are basically ready to go; you could compute an ephemeris or feed the orbital elements to another program without further work. This won't be the case for shorter arcs, because the orbit won't be very well determined. It also won't be the case for longer arcs or objects coming near a planet (usually the Earth), where perturbations are a factor. It also wouldn't be the case if there are some erroneous observations that ought to be excluded from the orbit fit. An example of the perturbation problem follows.

Running Find_Orb with example asteroid 1997 ZZ99

The second "example" asteroid, 1997 ZZ99, is mostly similar, but it does throw some problems into the system.

Double-click on 1997 ZZ99, and right away, you'll see the following unusual idea of an "orbit".

Orbital elements:
1997 ZZ99
   Perigee 1997 Apr 22.935609 TT = 22:27:16 (JD 2450561.435609)
Epoch 1997 Apr 23.0 TT = JDT 2450561.5                  Find_Orb
q 14941.6690km           (2000.0)            P               Q
H   22.9  G 0.15   Peri.  356.23652      0.62657228     -0.76960718
                   Node   312.51135     -0.71062719     -0.49939125
e   5.8196325      Incl.    9.59986     -0.32002525     -0.39788586
From 35 observations 1997 Apr. 21-22;   RMS error 1.128 arcseconds

In this case, Find_Orb has automatically latched on to the correct orbit, and has detected that the earth and moon are significant perturbing forces. The check-boxes for both objects in the "Perturbers" section are turned on. Note that Find_Orb isn't always bright enough (yet) to detect this sort of situation.

Also, you'll notice that the perigee distance is comfortably greater than the 6378 kilometer radius of the earth. So we won't get hit this time.

Guide has detected that at the epoch, 1997 April 23, the object is so close to the earth that it makes more sense to talk about its orbit relative to us, rather than its orbit relative to the sun. That is to say, the object is within our "sphere of influence". If you'd rather see the heliocentric orbit, you can use the Settings... Heliocentric Orbits Only check-box. Or, you can set the epoch to be a few days ahead of the encounter on April 23, or a few days after it. (The elements will be quite different, since the asteroid is obviously seriously perturbed by the encounter.)

Somewhat oddly, this object actually comes within the very small sphere of influence of the moon, and if you set the epoch to April 22.5 and do a Full Step, Find_Orb will show you a selenocentric orbit. (I've yet to see a real-world case of this. 1997 ZZ99 is a carefully contrived example.)

Running Find_Orb with S/2000 S 11, a satellite of Saturn

At one time, I was at somewhat of a loss for astrometry to provide for irregular satellites of gas giants. Fortunately, this is no longer the case. The ideas discussed below will be quite general, but the example used will be the satellite S/2000 S 11, the discovery of which was announced on 19 December 2000.

Click here to download the astrometry for this object. This file is the Minor Planet Electronic Circular (MPEC) giving the original discovery astrometry. Load it into Find_Orb, and you'll get a Centaur orbit with not-very-good residuals by default. To find a Saturnicentric orbit, Find_Orb will need a little coaching.

First, and perhaps obviously: you have to click the "Saturn" checkbox. Find_Orb is not likely to find a Saturnicentric orbit if it doesn't include the perturbations from Saturn!

The data arc spans 9 November 2000 to 17 December 2000. Consulting with an ephemeris program (or with the JPL Horizons system) tells you that, on those dates, Saturn was about 8.148 and 8.257 AU from the Earth. Since a natural satellite basically is just dragged around by a planet, you can be confident that the distance to the satellite was about (8.148 + delta) and (8.257 + delta) AU on those dates (assuming only a fraction of an orbit was completed).

If you look at the orbits of known irregular satellites of Saturn, you'll see that they have semimajor axes in the ballpark of a=.1 AU. I usually use initial guesses, therefore, of delta = -.1 AU (a guess assuming the object is on the near side of the planet) and delta = .1 AU (assuming the far side of the planet). Going with the first guess, set R1 = 8.048 and R2 = 8.157, click on "Herget Step" a few times, then on "Full Step" a few times. Rather quickly, the program will settle down on an orbit resembling the following:

Orbital elements:
S/2000 S 11
   Perisaturn 2001 Jul 6.675722 TT
Epoch 2000 Dec  2.0 TT = JDT 2451880.5
M 272.38363              (2000.0)            P               Q
n   0.40436636     Peri.    5.58450     -0.36000669     -0.07200746
a   0.1193108      Node   110.56628      0.81289929     -0.51345927
e   0.7685389      Incl.   83.45621      0.45780992      0.85508743
P   2.44           H   11.0           G   0.15      q 0.0276158
From 15 observations 2000 Nov. 9-Dec. 17;   RMS error 0.552 arcseconds

Well, this has reasonably low residuals, but the inclination and eccentricity look a little bizarre. In any case, let's now try the alternative assumption of delta = +.1. Set R1 = 8.248, R2 = 8.357, repeat the "Herget step" and "Full Steps", and you get:

Orbital elements:
S/2000 S 11
   Perisaturn 2002 Apr 1.933825 TT
Epoch 2001 Apr  1.0 TT = JDT 2452000.5
M 211.67402              (2000.0)            P               Q
n   0.40533552     Peri.   73.30298     -0.83559992      0.05564627
a   0.1191205      Node   107.06023     -0.17734258     -0.96891430
e   0.3806275      Incl.   34.86662      0.51992536     -0.24105718
P   2.43           H   10.9           G   0.15      q 0.0737800
From 15 observations 2000 Nov. 9-Dec. 17;   RMS error 0.474 arcseconds

If you look at the file of observations you downloaded, you'll see that this is essentially the solution the MPC published.

This sort of "double solution" is a common pattern. After you get a few more observations, you can usually discard one solution because its RMS errors start to grow. At present, I'm going along with everybody else in thinking that the second solution is the likely one, not just because of its lower errors, but because the first orbit is so unlike the orbits of the other satellites.

In most cases, this approach will get you an orbit. In a few cases, you need to play around with delta a bit. In a few cases, especially if the arc is very short, all you get is diverging solutions with absurd eccentricities and residuals; I've got some special, pretty weird code to handle such situations.

Running Find_Orb with (simulated) astrometry for the Mir space station

It is possible, though not necessarily very useful, to run Find_Orb to determine the orbit of an artificial Earth satellite. I didn't have any actual test data to use, unfortunately, so I generated an example. I did this by starting up Guide, setting my lat/lon to that of an MPC station, and generating an ephemeris for a pass of the Mir space station. If you run Find_Orb, open the EXAMPLE file, and double-click on "Mir", you'll load up the simulated observations in question.

Again, a decent guess for R1 and R2 matters here. The default guess of 1 AU is obviously nonsense for an earth-orbiting object. Reset these to .00001 AU. This corresponds to about 1500 km, which is a good "low-earth orbit" distance.

Check the "Earth" box and run a few Herget steps. You'll quickly see convergence to these values:

Orbital elements:
Mir
   Perigee 1998 Jun 20.810218 TT
Epoch 1998 Jun 20.8 TT = JDT 2450985.3
M 171.29447              (2000.0)            P               Q
n5660.54255256     Peri.  132.79498     -0.81371242     -0.44835486
a    6720.118 km   Node    28.13785     -0.15470880     -0.44641400
e   0.0057829      Incl.   51.66791      0.56030106     -0.77439813
P  91.58m           H   24.2           G   0.15      q 6681.256 km
From 10 observations 1998 Jun. 20-20;   RMS error 158.892 arcseconds

The RMS errors are admittedly a bit shocking. The reason for their size will be explained further on. You'll notice that the period of 91 minutes is decent for a low-earth object. The perigee distance still keeps Mir from plowing into the Earth (remembering that the radius of the Earth at the equator is 6378 km).

Before you click on the "Full Step" button, I must suggest that you take an unusual step. By default, when you full-stepped, Find_Orb would shift the epoch back to Jun 16.0. The problem is that attempting to extrapolate this short arc back by about five days (about 700 times its own length) would be unstable; you need an epoch that is closer to the observations. So reset the epoch to 2450985.34. This is right in the middle of the actual observation set, and will be quite stable.

Having done that, a few Full Steps get you this orbit.

Orbital elements:
Mir
   Perigee 1998 Jun 20.810114 TT
Epoch 1998 Jun 20.8 TT = JDT 2450985.3
M 168.93682              (2000.0)            P               Q
n5652.74897459     Peri.  132.46347     -0.81106791     -0.45313414
a    6726.294 km   Node    28.13381     -0.15214408     -0.44720528
e   0.0048460      Incl.   51.67437      0.56481946     -0.77115296
P  91.71m           H   24.2           G   0.15      q 6693.698 km
From 10 observations 1998 Jun. 20-20;   RMS error 39.292 arcseconds

For a longer arc, or a higher satellite, the Moon might come into play. But if you check that box and do more Full Steps, you won't see much of a difference.

The reason for those huge residuals is a simple one. The MPC format allows for a maximum precision in time of .0864 seconds = 10^-6 days. In that seemingly brief period of time, Mir can move about 700 meters. When it's 1000 km away (and for some of these observations, it was much nearer), 700 meters = 140 arcseconds. Until Find_Orb can read other (non-MPC) formats, this will be a problem.

Still, you really need some sort of orbit so you can make predictions as to where the object might be in a few nights. The most common way to do this is with a Väisälä orbit, where you assume that the object is near perihelion, and make a guess as to the perihelion distance. In Find_Orb, this is done by entering your guess in the R1 field and clicking "Väisälä". R2 is ignored.

The "classical" sort of Väisälä orbit uses only two observations (usually the first and last) and ignores all others. The method implemented in Guide does take advantage of more than two observations, using the others to minimize errors. You don't really need to know how or why this is done, but if you're curious, you can click here for the mathematical details.

The method is described a bit in Methods of Orbit Determination for the Micro Computer and in Fundamentals of Celestial Mechanics. The method of Gauss has been refined and adjusted by swarms of mathematicians, and therefore comes in endless flavors; I chose that described in the former book.

The method of Gauss works with three observations. Click on the "Gauss" button in Find_Orb, and the first and last unexcluded observations in the arc, along with whatever unexcluded observations comes closest to the midpoint of these two, will be used. The resulting orbit will fit those three observations with near-zero residuals, and the other observations with passably small residuals.

Be warned: this method was ideally suited to the pre-computer era. It can get you a good preliminary orbit with relatively little effort. But it does have some quirks, some inherent in the method itself, some inherent in how I implemented that method:

In some cases, you'll get two or three solutions with decent residuals. You may be able to toss out one or two because they correspond to weird orbits beyond Alpha Centauri or objects three kilometers away from Earth. Or, all the solutions may look reasonable, in which case all you can do is wait for more data to find out which solution is "right".

The Settings dialog

Click on the "Settings..." button, and you are provided with control over items such as constraints on the orbit (a topic large enough to given its own section). You can also set a "Reference" text. This text will appear among the orbital elements on-screen, and in any "pseudo-MPEC"s you generate. (By default, the "reference" is to Find_Orb.)

In addition, one can set the amount of "noise" used in the Monte Carlo function; the default amount is .5 arcseconds. Also, the threshhold used in the Filter Obs function can be reset, as can the precision used for elements. By default, this is set to 5, meaning that the angular elements are shown to five digits; other quantities have their precisions set accordingly. You can reset it to any number of digits from 1 to 10.

There is also a "Heliocentric only" check-box, off by default. If an object is within a planet's "sphere of influence" (the point where planet-centered osculating orbital elements are a better approximation to the object's motion than heliocentric elements), Find_Orb will usually switch from heliocentric to planet-centered elements. You will usually be perfectly happy with this, but if you really need heliocentric elements for some purpose, you can click on "Heliocentric Only" and elements will then be shown in that manner.

There are also radio buttons to select either "total" or "nuclear" comet magnitudes. This controls the type of magnitude shown in the orbital elements and ephemerides. In each case, only total or nuclear magnitudes from the observations will be considered in computing the absolute magnitude M, and the orbital element display will show M(T) or M(N). (These parameters are also known as M1 and M2. But I can never remember which is which, and assume others may have the same problem.)

There are multiple problems associated with this change. If you've got data with some nuclear magnitudes and no total magnitudes, and tell Guide to use total magnitudes, the orbital elements and ephemerides will show no magnitudes at all. The MPC's optical astrometry format lets you specify a comet magnitude as total or nuclear, but doesn't let you specify a band for it. Observers differ wildly in the validity of their magnitude data, and that's especially true for comet magnitudes; ideally, that data would be weighted, and the weighting for photometry would be separate frow the (existing) weighting for astrometry. But at present: caveat user.

Getting constrained orbits

Usually, clicking on "full step" results in a general solution in which all six orbital parameters are adjusted. But under some circumstances, it can be helpful to impose a "constraint" on the orbit. The most common examples are specifying that e=1 (a parabolic orbit) or that the object is at perihelion at the time of observation (a Väisälä orbit.)

It's possible to use Find_Orb to specify much more general constraints. For example, let's say you have loaded data for an object into Find_Orb and have found the value a=4.5 for the semimajor axis. If you're familiar with minor planet groups, you'll know that such a value would be possible, but very unlikely. It's more likely that the object is a Hilda (the next group in, with a=4.2 on its outer edges) or a Jupiter Trojan (the next group out, with a=5.05 on its inner edge.)

You can test the first possibility by clicking on the Settings button, and entering "a=4.2" into the Constraints box. Click OK, and then click on Full Step. Find_Orb will look for an orbit with that semimajor axis. You may have to hit Full Step several times before it converges on an a=4.2 solution, and when it does, you may find that the RMS error grows to an unacceptably high value. If so, the possibility that the object is a Hilda will have to be rejected.

Similarly, you can set "a=5.05" in that edit box and see if that converges, to confirm or dismiss the possibility of a Jupiter Trojan orbit.

You can also set constraints on the eccentricity, perihelion distance, orbital period, and inclination, and even combine constraints, such as:

e=.3        (constrain eccentricity to be .3)
e=0         (force a circular orbit)
q=1         (force an orbit whose perihelion brushes the earth's orbit)
i=15        (force an inclination of 15 degrees)
P=248       (force orbital period of 248 years,  that of a Plutino)
a=5.1,e=0   (combined forcing of a 5.1 AU semimajor axis and circular orbit)

Usually, when you have a very short arc of observations (or a very distant object), you'll find that forcing odd constraints does not necessarily raise the RMS error very much. This simply means that the range of possible values for each parameter is still very large. As more astrometry is gathered, the range drops sharply, meaning that the parameters are better-determined than was once the case. (Try to force an orbit too far from its valid range, and Find_Orb will often fail to converge to a solution.)

It's also possible to constrain the magnitude slope parameters. For comets, this defaults to K=10; for asteroids, to G=.15. However, you can set constraints such as K=18 or G=.12. This isn't necessarily a good idea (it would be better if Find_Orb had the ability to determine K or G from the observed photometry), but one can do it if desired.

The "filter obs" button

Click on the "Filter Obs" button, and Find_Orb will automatically exclude observations with total residuals of worse than one arcsecond, and automatically include all those with total residuals better than one arcsecond. If this doesn't result in any changes, it will report that fact. Otherwise, it will do a "full step". Applying this button a few times will usually result in convergence on a good solution, and automatically rejects outliers.

Some will object, reasonably, that the one-arcsecond limit is sometimes too high (for example, if you're dealing with highly precise observations from Hipparcos or UCAC-2 based or FASTT astrometry), and is sometimes too low (for example, if the data comes from any of the surveys or is old photographically-based astrometry). If you go into the Settings dialog, you'll see a "Max Filtered Residual" option, set to the default of one arcsecond. You can revise this limit as desired.

Find_Orb can now generate data to be used in plots such as this. Here, you can see the uncertainty region (which has elongated into a line and developed a bit of a banana-like curve), showing it as it was at the time of the first recovery observation... and that observation (yellow symbol) is embedded in the lower part of that banana.

There are several ways of computing ephemeris uncertainties. Jim Baer's CODES software and the JPL Horizons system both use a covariance matrix method; this is very fast and works beautifully for small uncertainties. Another common method is the "observational Monte Carlo" one, used by John Rogers' CCD Astrometry and by the OrbFit software (OrbFit also supports several other methods of computing uncertainties). Steve Chesley described six different ways of going at the uncertainty problem in an MPML post.

Right now, Find_Orb supports only the "observational Monte Carlo" approach. In this scheme, you take the initial observations and add some Gaussian "noise" to them, and solve for the orbit that fits these slightly-mangled points best. This creates a "virtual asteroid", representing a possible orbit that fits your actual observations passably well. Then you repeat.

Eventually, you have a swarm of "virtual asteroids" that, it's hoped, combine to illustrate the region in which the real asteroid might actually be. That region usually starts out as an ellipse, and when plotted on the sky, the virtual asteroids look like a squashed globular cluster.

As time passes by, the "virtual asteroids" spread out in one direction (usually along the line of variation), and the uncertainty region resembles a long, thin line. The line will develop some kinks and curves over time, especially if part of the line passes close to a planet. Sometimes, virtual asteroids will cluster at one or more points on the line, indicating areas where the object is most likely to be found.

To use this method in Find_Orb, proceed as follows. Solve for the orbit as you normally would. Set the "epoch" to be passably near the time span over which you want to know the positional uncertainty, and click on "Monte Carlo".

Find_Orb will pause while it computes the first virtual asteroid. You'll see the element and residuals display flash with a revised orbit, one with somewhat higher residuals (usually) than you originally had. Then it will flash again and again, as new virtual asteroids are computed. The "Monte Carlo" button will change to count the number of virtual asteroids created thus far. You can click on that button to stop computing virtual asteroids, and click on it again to resume computing them. (You can also switch to other tasks while virtual asteroids are computed in the background.)

As the virtual asteroids are computed, their orbital elements are added to the file mpcorb.dat. This file has the format of the MPC's MPCORB database, which can be read by most desktop planetarium programs.

One key point here: you may well want to set the amount of Gaussian noise added in Monte Carlo computations. If you click on "Settings...", you'll see an option to set the "Monte Carlo noise" level; this defaults to .5 arcseconds. Exactly what this value really ought to be is a matter of some debate, but it ought to reflect the uncertainties in the observations. That is, if you figure they're good to one arcsecond, a noise level of 1 makes sense. I've used the method with older photographic-era measurements good to about four arcseconds, and used a noise level of four, and have used a smaller noise level with more precise astrometry.

Use your planetarium software to display the mpcorb.dat generated by Find_Orb, and you will see a slew of numbered asteroids illustrating the current uncertainty area of the "real" asteroid. (I chose this approach because it meant people could view the uncertainty area in the program of their choice; it also makes it easy to see how that area changes over time.)

Eventually, I want to add in "statistical ranging" and (assuming I'm understanding it properly!) a "semi-linear" method of uncertainty estimation. The first is a better method for short orbital arcs and for handling KBO/Centaur objects where the distance to the target really hasn't been nailed down very well. The second would, I think, allow for faster computation and, perhaps, make it a little easier to show results in tabular form: each entry in an ephemeris might be followed by a numerical positional uncertainty and angle. The current observational Monte Carlo method is wonderful for a graphical approach, though, and is easy to understand and program.

Also, whatever elements are shown in the dialog are also saved in the file elements.txt (in the "standard" eight-line MPC format, same format as shown in the dialog), and in the single-line MPC format in the file mpc_fmt.txt. This latter format is the one used in the MPCORB.DAT and similar files on the MPC's ftp site and the mirrors of that ftp site.

 1  3 24.30998   704 12 10 22.03  -08 50 15.1  -0.06  -0.04   0.562  1.556
 1  3 24.33638   704 12 10 16.94  -08 49 50.4  -0.25   0.20   0.562  1.556
 1  3 24.34986   704 12 10 14.38  -08 49 38.8   0.19  -0.72   0.562  1.556
 1  3 25.19163   859 12 07 38.08  -08 36 23.3   0.30   1.86   0.565  1.560
 1  3 25.19471   859 12 07 37.48  -08 36 22.1   0.07   0.18   0.566  1.560
 1  3 25.40278   474 12 07  0.19  -08 33  3.6   0.05  -0.32   0.566  1.561
 1  3 25.40405   474 12 06 59.96  -08 33  2.3   0.16  -0.19   0.566  1.561
 1  3 25.40925   474 12 06 58.97  -08 32 57.9  -0.10  -0.58   0.566  1.561

010324 704  .06-  .04-    010325 859  .30+  1.9+    010325 474  .16+  .19-
010324 704  .25-  .20+    010325 859  .07+  .18+    010325 474  .10-  .58-
010324 704  .19+  .72-    010325 474  .05+  .32-

Station data:
(474) Mount John Observatory, Lake Tekapo  (S43.9876 E170.4650)
(649) Powell Observatory, Louisburg   (N38.6464 W94.6997)
(704) Lincoln Laboratory ETS, New Mexico  (N33.8185 W106.6591)
(859) Wykrota Observatory-CEAMIG  (S19.8240 W43.6903)
(918) Badlands Observatory, Quinn   (N43.9908 W102.1306)

Creating and saving an ephemeris

Click on the "Make Ephemeris" option, and Find_Orb will bring up a small dialog box with a starting day, month, and year, and a number of steps and a proposed step size in days, and a lat/lon (the same one you've set up in Guide). Edit these and click on "Go", and it will generate an ephemeris in the list box. Click on "Save", and you can write the results to a file.

In computing the ephemeris, Find_Orb will include the effects of any perturbers you selected in the "main" dialog.

You can also tell Find_Orb to include motion details (how fast the object is moving, in arcminutes per hour, and the position angle at which it is moving) with the "Motion Details" check-box. There is also an "Alt/Az" checkbox which will add that data to the ephemerides. (Of course, the alt/az checkbox doesn't accomplish anything for geocentric ephemerides.)

You can enter a three-character MPC observatory code in the latitude box. Do this, and Find_Orb will ignore the longitude box and just set your position to that of the MPC code. Use an MPC code of 500 to indicate a geocentric position. Use an MPC code of 'v' to get geocentric Cartesian positions. Use an MPC code of 'V' to get geocentric Cartesian positions with velocity (that is, state vectors). Units are AU and AU/day.

The ephemerides generated with 'v' and 'V' are on the TT (Terrestrial Time) timescale. All other, "normal" ephemerides are on the UTC (Coordinated Universal Time) scale.

Making a "pseudo-MPEC"

Whenever you generate an ephemeris, Find_Orb creates a "pseudo-MPEC" with the filename mpec.htm. This looks a bit like the standard Minor Planet Center MPECs, listing the observations, stations supplying the observations, orbital elements, and ephemerides (with the time span determined by that given in the "Make Ephemeris" dialog.) It differs from the MPC version in that it is heavily linked; you can click on an observation to see its residuals, or on a residual to see its observation, or on a three-character observatory station code to find out which observatory that is, or on the observatory's lat/lon to get a map of that observatory, or (usually) on an observatory name to get that observatory's home page. Click here for some examples.

A few hints to customize/improve the "pseudo-MPECs" you generate:

Getting data about the observations

Click on any observation in the list box at the bottom of the dialog box, and you'll get a few lines of text just below the list box giving data about that observation. Here's an example:

Elong 165.4    Phase 7.6    RA vel -0.85'/hr   decvel -0.37'/hr   dT=22.96 sec
ang vel 0.93'/hr at PA 246.6    radial vel -7.813 km/sec    cross 0.32
Steward Observatory, Kitt Peak-Spacewatch  (N31.9580 W111.5990)
Delta= 0.9214  r= 1.9024  mag=17.40  mag (computed)=17.19   1997 Oct 16 21:53:45
     J96X01X  C1997 10 16.91160 00 33 19.02 +03 25 30.9          17.4        691

The first line gives the phase at the time of the observation, followed by the motion of the object in RA and declination. (The motions are in units of arcminutes per hours, which are the same as arcseconds per minute.) Next, the "residual in time", dT, is given. This describes the difference between the computed time of the observation and that given in the observation data.

The "residual in time" is especially helpful if you think the observer may have had a clock error. You will sometimes see observations of very fast moving objects (VFMOs) with large, but consistent, residuals. When that happens, you should check the dT values and the "cross" value (given just below the dT value). The "cross" value indicates how far off the observation was from the predicted track.

If you see a series of observations wherein the "cross" values are all normal residual values (say, under an arcsecond), but the residuals in RA and dec are abnormally large, you can suspect a timing error, and dT will tell you how large that timing error is.

The second line tells you the rate of apparent motion of the object, and the position angle at which it is moving. This is essentially the same data as "RA vel" and "dec vel", expressed in a different form. It is followed by a radial velocity, in km/second, and the cross-track residual.

The third line gives the observatory name, latitude, and longitude. In some cases, there will be a reference preceding that data, to an MPEC or MPC IAUC or other publication.

The fourth line gives the distance to the target, delta; the distance between the target and the Sun, r; the observed magnitude (this may be blank); the computed magnitude (this may also be blank, if no magnitude data was reported for the target); and the time of observation, expressed in "conventional" calendar/hh:mm:ss notation.

The fifth line shows the observation data in the original MPC 80-byte form.

Epoch box

Find_Orb will initially set a "reasonable" epoch for the object, rounded to an integer Julian Day. Normally, you will not bother to re-set this. However, you can reset the epoch to any desired value, by entering it in year/month/day form (such as "2005 4 13" for 2005 April 13); or in Julian Day form (such as "2453400.5" for JD 2453400.5 = 2005 Jan 30.) Also, keep in mind that if no perturbers are being considered (all the "check boxes" are unchecked), then the epoch is irrelevant.

When Find_Orb doesn't find an orbit

In the above examples, Find_Orb converged (eventually) to a solution. This is not always the case, which is why the program can't (yet) just read the MPC observations and spit out an orbit, unattended. Sometimes it will latch on to a solution involving a Warp 10 orbit around Alpha Centauri; sometimes the Herget method collapses toward r1=r2=0 (that is, the object is floating just in front of the telescope).

One way to avoid this is to give Find_Orb a better handle on the actual distance to the object. You can do that by setting R1 and R2 to a better guesstimate, and then clicking on "Herget" a few times. As you have seen, this was absolutely essential for the S/2000 S 11 and Mir cases.

Also, in the case of some comets, I've found it helpful to restrict the output to a cometary orbit. If you've run through a 'full solution' and the eccentricity is pretty close to 1, try clicking on the Settings button and entering "e=1" in the Constraints box. Then do a few more iterations; you'll probably see that the residuals don't change very much. (This is especially important when figuring orbits for SOHO sun-grazing comets. These can give the software a serious headache!)

For non-comets, use of other orbital constraints can be helpful. You might try setting the eccentricity and/or the perihelion distance to a likely-seeming value, for example; if it works, you can then experiment with other nearby values to see if the residuals drop.

Sometimes, if only a few observations are available, you'll get wild orbits that still have small residuals. This just means that the orbit was very poorly determined. The resulting orbit will generally still give decent apparent positions for a few days, even if it does look rather odd. After those few days, you can then observe the target again and get more positions, which may be enough to get a "realistic" orbit.

I've yet to see the program fail completely, though sometimes a little playing with parameters was required before it behaved itself properly and didn't generate "RMS error 345184.9 arcseconds"-like nonsense.

Excluding observations

Quite often, you'll find that, while most of the observations "fit" the orbit well, with residuals of under an arcsecond, there are a few observations with suspiciously high residuals, that make you wonder if perhaps that observation was of poor quality. If so, double-click on the observation in question; Find_Orb will re-fit the orbit, with that observation excluded. Double-click on the observation again, and you can toggle it back into consideration.

You can also select multiple observations, then click on the "Toggle Obs" button. All the observations will then be turned on or off.

You should consider the possibility that the observation really is good. Find_Orb follows the classical method of finding an orbit that reduces the "overall" error, as expressed by the sum of the squares of the residuals. In some unusual circumstances, this can cause a perfectly decent observation to have artificially high residuals. For example, if you have a "cluster" of observations and add in one observation from the distant past or future, that distant observation will have anomalously large residuals.

Under no circumstances should high residuals keep you from reporting the astrometric observations in question to the MPC! The people at MPC will be quite capable of deciding whether to ignore a given observation, and (in part because they will have more observations) will be far better equipped to judge which observations are really problem cases.

Setting the weights for observations

Not all observations are created equal. Back in the era of photographic astrometry, results good to a few arcseconds were perfectly okay. In the beginning era of CCD astrometry, results were often good to an arcsecond (still all-too-often the case, I'm afraid... which is a pity; getting much better astrometry isn't necessarily difficult.) People using more modern star catalogues, such as the UCAC-2, Tycho-2, and CMC-14, are routinely getting results good to a tenth of an arcsecond or so.

It makes sense to "weight" the observations accordingly: to ensure that when you're computing an orbit, the better observations have a greater impact on the solution. Until recently, there was no way to do that in Find_Orb. Now, one can set the weight of an observation in three different ways.

(Some MPC astrometric records)
#Weight .1
(Some more records of lesser quality observations)
#Weight 3
(Some more records of really good observations)
#default_weight
(Go back to the default weighting scheme,  using weight.txt)

then the first few records will be weighted in the usual manner, using weight.txt. Then some observations will be weighted at a tenth the default amount; then more will be weighted heavily; and then Find_Orb will revert to using default weights.

C/C++ source code for Find_Orb

You can click here to download the source code for DOS and Linux versions of Find_Orb (about 115 KBytes.) (Success has also been reported on compiling this software on the Mac.) You'll also need to get the source code for basic astronomical computations, also on this site; and you'll have to have downloaded one of the two Windows versions at the top of the page, since the DOS and Linux versions use many of the same files for tasks such as computing planetary positions, figuring out which observatory is which, and so on.

In DOS, if you have Microsoft C/C++ or the OpenWatcom compiler, you can then make a 32-bit console app version of Find_Orb. First, build the library of basic functions with nmake lunar32.mak. Then run the dos_make batch file. You'll then be able to run, say, dos_find example to process the objects in the 'example' file.

In Linux, use make -f linmake to compile the 'basic astronomical functions' into the archive lunar.a. Having done that, make -f lin_make will compile the assorted pieces of Find_Orb and produce a Linux executable (still called 'dos_find'... I probably should have chosen a name more like 'con_find', for 'console'!)

Eric Christensen did some work to get Find_Orb to compile on a Mac. The process is essentially that described for Linux. However, you must be sure to set up the program to use JPL ephemerides. The default method used for planetary/lunar ephemerides in Find_Orb is byte-order sensitive (at least right now) and won't work on Mac (or other non-Intel-endian machines.)

The overall function of this console version is very similar to that of the Windows version; it's just that things are done in text mode instead of graphically. dos_find uses the same underlying functionality as its Windoze cousins; only the interface is different. Hit '?' (or any other key not understood by dos_find) and you'll get a list of keyboard commands, straight from the dos_help.doc file.

So why did I bother porting Windoze Find_Orb back to DOS? Two reasons. First, the Windoze UI code is significantly more difficult to puzzle out. Most of the people who have asked me about source code for orbit determination were interested in math and physics, and not the idiosyncrasies of Bill Gates' OS. Second, the 'console' version made the port to Linux almost trivial.

At some point, I'll probably post the Windoze UI code. But posting source code for Charon will be a higher priority. If you'd like to see the Windoze source "as is", e-mail me, and I'll send it out in all its current lack of glory (Windows GUI code is never glorious.)

Non-interactive (batch-processing) mode:

The console version of Find_Orb can read in all observations from a file of input astrometry, puzzle out which objects are present, and spit out orbital elements for them. This new, somewhat experimental feature works as follows. Suppose you have a file of astrometry, astrometry.txt . You would run the following command on the DOS or Linux or Mac command line:

dos_find astrometry.txt -i 

dos_find would process each object, telling you its name and summary data, then finding its orbit. A very basic summary of its semimajor axis, eccentricity, and inclination would be shown on the console. The full elements would be written out in the one-line MPCORB format to the file mpcorb.dat. They would simultaneously be written out in the eight-line MPC format to the file elements.txt.

That's about all there is to it. This is still somewhat experimental, and there's still work to be done: for example, the code just puzzles out the initial solution, and if the arc is very long, it won't go through the sort of process the "Auto-Solve" button uses to get the full arc and to exclude outliers. Still, it's useful if one just has a slew of short-arc data to examine.

Some more things Find_Orb will eventually do

As is always the case, I have a wish list of things I'd like to see Find_Orb do someday:

Definitions of a few terms:

Cometary orbit. Many comets have orbits with eccentricities that are extremely close to 1, meaning their orbits are highly elongated ellipses (Hale-Bopp, for example) or closely resemble parabolas. Go into the Settings dialog and set the "constraint" of e=1, and Find_Orb will search for a cometary orbit. This can be especially helpful if you have only a few observations to work with; in such cases, telling Find_Orb that the orbit must be parabolic (cometary) makes it much more likely that it will converge to a solution. (This is usually a good idea for a preliminary orbit, where there are few observations. When you find that both a cometary and non-cometary orbit converge, but the non-cometary one has a significantly smaller RMS error, switch to the non-cometary.)

Elongation. The angle Sun-Earth-Target. When close to zero degrees, the object is in conjunction with the sun. When close to 180 degrees, the object is almost exactly opposite the sun. See also phase.

Epoch. In the case of an orbit that includes the effects of perturbing objects, the orbital elements will change slowly with time. Thus, elements eventually become "outdated", and you need to replace them with new elements with an epoch closer to the time of observation. That's why Find_Orb has a small edit box to select the desired epoch, as a Julian day .

Full step. Once you have found a good approximation to an object's orbit using (for example) the Herget method , you can find the "best fit" orbit (the one that best matches all the observations of the object) by taking a few full steps. The "full step" uses a mathematical tool known as the method of least squares.

Herget method. This is one pretty good method for computing an approximate orbit from a set of observations. It works by assuming that two observations (usually the first and last observations) were at known distances, and then working to improve the quality of those distances to decrease the residuals. Eventually, the "steps" in the Herget method lead to a minimum set of residuals, and you have a fair approximation to the object's true orbit. Once that happens, you can switch to taking full steps.

The more mathematically adventurous may be interested in this description of some of the math underlying the method of Herget , with particular emphasis on some of the ways it is both 'simplified' and made more powerful in Find_Orb.

Julian Day. (Not to be confused with the Julian calendar, which is a very different thing!) The Julian Day (JD) system is a means of counting off time as the number of days elapsed since noon, 1 Jan -4713. By simply using the number of days (including fractional days) elapsed from that instant, we avoid the complexities associated with the traditional day/month/year, hour/minute/second system. Also, by putting the starting instant in the distant past, over 6700 years ago, we avoid negative numbers.

Irregular satellite. Natural satellites tend to fall in one of two groups. The first, "regular" sort orbits close to a planet, in the plane of the equator of the planet, in the same direction the planet rotates (a prograde orbit). All known regular satellites have had their rotation tidally locked to their primary, so that (as with the earth's moon) they do not appear to rotate as seen from the primary. The assumption is that they were formed at the same time as the planet.

Irregular satellites, on the other hand, have orbits independent of the equator or rotation of the planet, and can be either prograde or retrograde. They also are quite distant from the primary. All four gas giants have such satellites.

Least squares. The method of least squares is a common mathematical tool, originated by C. F. Gauss sometime around 1800. It starts with the assumption that you have gathered some observations (in our case, of positions of a celestial object) and have a theory, or "model", to describe them (in our case, Newton's laws of motion). The differences between observed and computed values are called residuals; the method of least squares states that the "best" model will find a minimum of the sum of the squares of the residuals. (There's some hedging to account for the fact that some observations will be more precise than others, and an additional assumption that the distribution of errors resembles a normal distribution, also known as a "Gaussian distribution" or, more popularly, a "bell curve".)

Magnitude parameters. The magnitudes of asteroids and comets are predicted using quantities for each object known as "magnitude parameters". These are H and G for asteroids, with G (the "slope parameter") usually left set to .15, and M(T) or M(N) and K for comets. In this situation, K defaults to 10, and one can choose between M(T) (for total magnitudes) or M(N) (for nuclear magnitudes) in the Settings menu. You can also reset the K and G magnitude parameters if you wish, though this is probably not a good idea in general.

MOID. The Minimum Orbit Intersection Distance, or MOID, is the minimum distance between two orbits, neglecting perturbations. It's computed by assuming that two objects (usually the earth and an asteroid or comet) will continue swinging around in their orbits, and looking for the place where the distance between those orbits would be a minimum.

Sometimes, that minimum distance will be so small that it looks as if the two objects will collide, but that's not necessarily the case for two reasons. First, when object A reaches that point, object B will usually be somewhere else. Second, the computation ignores perturbations. So it's a good first estimate as to how close the object can get to you, but it takes a much more detailed analysis to determine if the object is going to hit you. A large MOID usually means the object is no hazard at all; a small one means you should keep an eye on it and find out if it really is a hazard.

Find_Orb shows the MOID not only between the asteroid/comet and the Earth (if it's less than one AU), but also the MOIDs between the object and all planets (if those MOIDs are small enough to be interesting.)

Perturbations. Objects orbiting the Sun would, in theory, trace paths of perfect ellipses, parabolas, or hyperbolas. However, the gravitational forces (a.k.a. perturbations) exerted by all the planets, satellites, and (less significantly) asteroids in the solar system make the actual motion much more complex. Find_Orb has a set of check-boxes that allow you to include (or, by default, not include) the perturbing effects of these objects.

Phase. The angle Sun-Target-Earth. When close to zero degrees, the object is almost fully illuminated by the sun. When close to 180 degrees, the object is about to transit the sun, and is almost totally un-illuminated. See also elongation.

P, Q, R vectors. MPC orbital elements, and the elements shown in Find_Orb, give the P and Q vectors in columns to the right of the 'standard' elements. The vectors are frequently used in computing positions from orbital elements. P is a unit vector giving the direction from the sun's center to the perihelion point of the object's orbit. Q is a unit vector at right angles to P, but in the plane of the object's orbit. R is a unit vector at right angles to both of these (and therefore, at right angles to the plane of the orbit). Thus, Q = R x P, R = P x Q, and P = Q x R, where 'x' is the vector cross-product operation. The benefit of all this is that, if we know the object is at true anomaly v and distance from the primary r, we can say that its position is

r * (P cos v + Q sin v) 

'R', the normal vector to the plane of the orbit, is almost never shown, since it does not appear in the above formula.

Residuals. When you attempt to determine an orbit for an object, you will always find some difference between the "observed" positions (measured from a CCD image), and the "computed" positions (computed using the orbit you have determined). These differences are known variously as "observed minus computed", or "O-C", or as "residual errors", or "residuals". Ideally, they should represent the random errors in observation that inevitably happen in the real world.

Retrograde. As viewed from a point far "above" the ecliptic, almost all planets and satellites orbit in a counterclockwise direction, also known as "prograde". A few satellites of the gas giants, however, go in the opposite direction, also known as "retrograde". All of these objects are quite small and faint.

RMS error. "RMS" = "Root mean square"; it's a modified version of the average of the residuals. (To be mathematically precise, it is the square root of the average value of the square of the residuals. If you took the squares of all the residuals, averaged them, and took the square root of the result, you would have the RMS error.) With CCD-based observations measured using Charon, and with an accurate orbit, the RMS error should be about an arcsecond or better. If the errors are much greater than that, you either should continue working on the quality of the orbit, or check to see if there are problems with the observations.

Sphere of Influence. For an object in orbit around a planet, it makes sense to use planet-centric orbital elements. For an object far from any planet, it makes sense to use heliocentric elements. There is an almost spherical region around each planet where planet-centric elements are a better choice: that is, a two-body solution centered on the planet would better represent the object's motion than a two-body solution centered on the sun. That region is the planet's "sphere of influence."

You can override Find_Orb's judgment and insist on only heliocentric orbits; there is a check-box for that.

Danby shows that for a planet of mass Mp at distance R from the sun (of mass Ms), this sphere has radius r where

r = R (Mp/Ms)^(2/5)

Following are the radii of the sphere of influence for most of the planets. (For the moon, we have to switch to r=R(Mmoon/Mearth)^(2/5), where R is the earth-moon distance. So far, I've yet to see a "real" object within the moon's sphere of influence, and therefore haven't seen Find_Orb generate a selenocentric orbit... though note that one can be generated for the example case 1997 ZZ99.)

Planet    r(AU)      r(km)
Mercury   0.001     112000
Venus     0.004     614000
Earth     0.006     921000
Mars      0.004     575000
Jupiter   0.322   48000000
Saturn    0.365   54300000
Uranus    0.346   51600000
Neptune   0.579   86000000
Pluto     0.022    3300000
Moon      0.00046    69000

Väisälä orbit. A newly-discovered object may have only two known observations, or may have been observed over so short a period that its orbit is not at all well-defined (that is, you can't tell if it's a nearby object moving slowly or a more-distant object moving rapidly, and any possibility in that range seems equally likely.) In fact, this is usually the case for a newly-found object. When this happens, it's common to determine a Väisälä orbit: one in which it's assumed that the object is at a particular distance from the sun, and that it is moving at right angles to the sun (that is, it's either at perihelion or aphelion). Given that assumption, the orbit is precisely defined, and you can generate an ephemeris that will (usually) be good enough to recover the object a few nights later. Click here for details on how to determine a Väisälä orbit.