Screenshot of interactive Find_Orb
If your needs are simple enough, there is an on-line, server-based version of Find_Orb that may be all you need. The on-line version allows you to enter observed positions in the Minor Planet Center's 80-column observation format, and/or the newer ADES astrometric format , and/or in the AstDyS/NEODys .rwo format, and determine the orbital elements matching those observations and compute ephemerides.
The on-line version has gradually improved. But it doesn't always find an orbit (usually for "hard" cases such as some artificial and natural satellites and sun-grazing comets, or difficult linkages of short arcs). You can't compute Monte Carlo variant orbits, or try out different orbit determination schemes. You can't exclude observations (except by removing them from the input data), or filter them, or fit non-gravitational parameters. If you're looking for these and other advanced capabilities, you'll have to install Find_Orb.
You can click here for information about the Find_Orb users group. (This used to be on Yahoo! Groups, but that service has been dismantled.) Announcements of new versions will be made there; questions about the program or about orbit determination in general, or requests for new features, are welcome.
Find_Orb can take a set of observations of an asteroid, comet, or natural or artificial satellite, given in the MPC (Minor Planet Center) format, the newer ADES astrometric format , and/or the NEODyS or AstDyS formats, and find the corresponding orbit. You can click here for further details on how to format astrometric data for Find_Orb.
Find_Orb is available as executable Windows software, for both 64-bit Windows and 32-bit Windows, and as C/C++ source code that can be compiled to make Windows or Linux or Mac console applications (one interactive, one non-interactive). In what follows, I'll just refer to "Find_Orb", without making a distinction between the various flavors. There are some minor differences, which will be noted where they matter.
The interactive version looks like this, on all platforms.
• Click here to download the 64-bit Windows software
(about 814 KBytes).
• Click here to download the 32-bit Windows software
(about 760 KBytes).
• Click here for C/C++ source code (which can
be compiled for Linux, OS/X, or *BSD. Or DOS or Windows, admittedly
with some difficulty.)
• Click here for information about and download links
for non-interactive, batch-mode Find_Orb for 32-bit and 64-bit Windows.
Find_Orb is a user-friendly program that handles the initial determination of the orbit using the methods of Gauss, Herget, Väisälä, and others. Given some more observations, it can find a "best fit" orbit using the method of least squares . The physical model includes most significant effects on comets, asteroids, and earth-orbiting artificial objects.
There are several situations wherein one might want to use Find_Orb:
• If you're an observer who has started tracking a new object, it can be useful to feed your observations into Find_Orb and get an orbit and ephemerides. The orbit can tell you how "interesting" the object is (perhaps a near-earth object or a comet), and the ephemerides can tell you where to look for follow-up observations. (Note that for this purpose, the on-line version of Find_Orb will usually be all you need.)
• You can use Find_Orb to test the quality of astrometric observations. If you feed your astrometry through Find_Orb, along with some comparison data from others, and your positions line up nicely with theirs, resulting in an orbit with residuals of around an arcsecond, you can be reasonably confident about the quality of your astrometry. Even if all you have is your own data, Find_Orb will show you if some observations don't fit well with the rest of your data.
• 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 instructional purposes; I occasionally hear from people using Find_Orb as part of their coursework.) You can find out what effect Jupiter has on the orbit of an object of interest, or how certain observations worked to change the knowledge of the orbit.
• It can be interesting, just as an educational exercise, to take your own astrometry and generate an orbit from it. If you've set up a telescope, gathered astrometry for an object, and then find its orbit, you have essentially done all of the steps involved in asteroid discovery.
• Occasionally, I hear from people doing more esoteric things with Find_Orb, such as attempting to link the orbit of a comet with possible archived data from the past. Find_Orb has been used to compute impact probabilities for objects such as the Shoemaker-Levy 9 fragments that hit Jupiter in 1994, or the object 2007 WD5 that briefly seemed likely to hit Mars. Most notably, my announcements that 2008 TC3 was going to hit the earth, and that 2014 AA probably had hit the earth, were based on feeding the data through Find_Orb.
Find_Orb is distributed under the GPL (GNU General Public License), version 2, which basically means you can do what you want with it and can use/distribute it without having to pay for it. Use of the source code has some restrictions, though nothing particularly onerous; consult the licence if in doubt. Use in or with commercial software is forbidden without written permission from Project Pluto:
Project Pluto 168 Ridge Road Bowdoinham ME 04008 (UNITED STATES) tel (207) 666 5750 pôç.ötulpťcéjôřp@otúlm (if you aren't a spambot, you should be able to figure this out) http://www.projectpluto.comIf you use it for something interesting, though, please let me know!
As is required by the GPL, source code is provided.
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 free software (with restrictions similar to those for Find_Orb). It was put together by about half a dozen professional astronomers, and can run in Windows 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 many ways, it's much more sophisticated than Find_Orb. (Which sometimes translates into "not as easy to use".) I should note that Find_Orb supports most of those capabilities now.
OpenOrb (or OOrb) has some good routines for handling short-arc objects and finding uncertainties for them, and appears to be reasonably well-documented.
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's CODES software (http://home.earthlink.net/~jimbaer1/), "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." Since it's written in Java, it's somewhat more cross-platform than Find_Orb. (Though now that Find_Orb runs on DOS/Windows, Linux, OS/X, and BSD, it's covering a lot of platforms.)
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.)
ESA's NEOProp 2 looks to have some overlap with Find_Orb, but has more ability to compute close approaches and impact probabilities for longer-term, lower-probability events. It looks to be closed-source, but is freely available for Windows and Linux. (My thanks to R. Mark Elowitz for pointing this software out to me.)
John Rogers' CAA (Computer-Aided Astrometry) software has an orbit-determination part, including the ability to determine ephemeris uncertainty via the Monte Carlo method. Unfortunately, it appears to be no longer available.
If you know of other orbit determination software not listed here, please e-mail me (after removing the accent from the 'ó' in the e-mail address!)
Ideally, one should get a CCD camera and telescope, 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's 80-column 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.
The MPC database search tool lets you enter an object name and get data for it, including a link to the observations file (under "these data are available for download".)
You can use the MPC's MPCAT-OBS service to get large files with all MPC observations of various classes of objects : numbered minor planets, unnumbered minor planets, comets, natural satellites, etc. Some of these files are quite large.
Data for artificial satellites is tougher to come by, but the MPC's DASO (Distant Artificial Satellite Observation) Circulars provide some data for these objects. (Note that a link to a file containing all astrometry from all DASOs is provided at the bottom of the page, and some of the pseudo-MPECs for artsats produced by me will provide astrometry, in situations where I have permission to distribute the data. Which I usually, but not always, do.)
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.
For Windows, you need only download Find_Orb from this page, put it in a folder of your choosing (usually a new one), and unZIP it. (Linux and OS/X users will have to download the source code and compile the program.) Windows users can then add a desktop shortcut to find_o32.exe or find_o64.exe.
When you start it up, you'll see some explanatory text, plus the following four lines:
F Select file containing astrometry [?] C Copy astrometry from clipboard N Give object name and get data from MPC Q Quite
First, please note the [?]. This symbol will appear in other dialogs and menus; clicking on it will get you some more detailed information about the dialog or menu. When in danger or in doubt, click on the [?].
For the nonce, I suggest hitting 'F' or clicking on that line in the menu. Find_Orb will provide a standard file dialog; pick 'example.txt'.
Find_Orb will show you a list of four example objects. Double click on "Example1".
Find_Orb will point out to you that you don't have JPL DE ephemerides. You will probably want to remedy this lack if you make much use of Find_Orb, but for the nonce, you can ignore the warning; Find_Orb can still figure out where planets are, albeit with somewhat poorer precision.
When the object is loaded, Find_Orb will show information about it in a way resembling this screenshot.
Running Find_Orb with example asteroid 'Example1'
We'll try the easy one first. Double-click on 'Example1', and Find_Orb will immediately find the following pretty good orbit:
Orbital elements: Example1 Perihelion 1998 Mar 9.092118 +/- 0.0684 TT = 2:12:39 (JD 2450881.592118) Epoch 1997 Nov 15.0 TT = JDT 2450767.5 Earth MOID: 0.0612 Ma: 0.0049 M 330.76545 +/- 0.030 Find_Orb n 0.25623633 +/- 0.000121 Peri. 72.58768 +/- 0.054 a 2.45494764 +/- 0.000773 Node 47.65358 +/- 0.036 e 0.5742614 +/- 0.000103 Incl. 0.14326 +/- 0.00018 P 3.85 H 16.5 G 0.15 U 6.7 q 1.04516583 +/- 9.13e-5 Q 3.86472946 +/- 0.00147 From 37 observations 1997 Oct. 12-Nov. 15; mean residual 0".50
In this instance (and in most instances), Find_Orb can get a good orbit without needing your help. 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 necessarily be the case for shorter arcs, because the orbit won't be very well determined. It also won't always 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 near-Earth asteroid 'Example2'
The second "example" asteroid, 'Example2', is mostly similar, but it does throw some problems into the system.
Double-click on Example2, and right away, you'll see the following unusual idea of an "orbit".
Orbital elements: Example2
Perigee 1997 Apr 22.936234 +/- 0.000165 TT = 22:28:10 (JD 2450561.436234)
Epoch 1997 Apr 22.0 TT = JDT 2450560.5 Find_Orb
q 16127.9476 +/- 9.43 (J2000 equatorial)
H 22.8 G 0.15 Peri. 351.68247 +/- 0.006
Node 316.32979 +/- 0.0023
e 6.2015493 +/- 0.00323 Incl. 9.74694 +/- 0.0048
From 20 observations 1997 Apr. 21-22 (31.0 hr); mean residual 0".56
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.
Find_Orb has detected that at the epoch, 1997 April 22, 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 go into the Settings dialog, and change the "Element center" from Automatic to Heliocentric. Or, you can change the epoch in the main dialog from 1997 Apr 22 to 1997 Apr 21 or 24. (On either of those dates, Example2 would have been far enough from the earth that an heliocentric orbit would make more sense than a geocentric one. The elements will be quite different, since the asteroid is obviously seriously perturbed by this close encounter.)
Note also that after making these changes, you should click the "Full Step" button. This will cause Find_Orb to recompute the orbit for the new epoch and object center, and to compute and display the uncertainties in the orbital elements.
Also, you'll notice that the perigee distance is comfortably greater than the 6378 kilometer equatorial radius of the earth. So we won't get hit this time. (If that was going to happen, Find_Orb would add an "IMPACT at latitude thus-and-such, longitude thus-and-such" line.)
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 (or lunicentric) orbit. (Example2 is a carefully contrived example. In reality, I've yet to see a natural object come close enough to the moon to give a selenocentric orbit. However, several artificial satellites that were deliberately targeted to pass by the moon, such as STEREO-A, STEREO-B, and a couple of booster rockets, have shown selenocentric flyby orbits. The LCROSS mission impacted the moon, and Find_Orb displays impact coordinates for that case.)
Running Find_Orb with S/2000 S 11 = Saturn XXVI = Albiorix, 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 S/2000 S 11 Saturn XXVI = Albiorix, the discovery of which was announced on 19 December 2000.
First, an important safety tip : usually, you can get decent results with Find_Orb's built-in planetary positions, for most objects. Before attempting satellites of other planets, you basically must set up JPL ephemerides in Find_Orb.
I don't have permission to redistribute the astrometry in this case. But you can click here to download the astrometry for this object. This file is the Minor Planet Electronic Circular (MPEC) giving the original discovery astrometry. You can either save it to a file and then open that file in Find_Orb, or you can copy the observations (it's okay if you get additional text in the process, as long as you get the observations), then use Find_Orb's "Copy Astrometry from Clipboard" option.
Whichever way you do this, Find_Orb will fail to get an orbit that actually goes around Saturn. Instead, you'll get the following Centaur orbit by default. To find a Saturnicentric orbit, Find_Orb will need a little coaching.
Orbital elements: Saturn XXVI = Albiorix = S/2000 S 11 Perihelion 2001 Nov 25.59019 +/- 42.9 TT = 14:09:52 (JD 2452239.09019) Epoch 2000 Dec 16.0 TT = JDT 2451894.5 Sa: 0.0716 Ur: 0.6489 M 353.87373082 +/- 0.50 (J2000 ecliptic) Find_Orb n 0.01777842 +/- 0.000856 Peri. 283.86736 +/- 2.4 a 14.5392031 +/- 0.455 Node 150.88701 +/- 0.11 e 0.4290031 +/- 0.024 Incl. 2.54829 +/- 0.0018 P 55.44 H 11.8 G 0.15 U 8.1 q 8.30183905 +/- 0.0822 Q 20.7765672 +/- 0.992 14 of 15 observations 2000 Nov. 9-Dec. 16; mean residual 0".38
Find_Orb is bright enough to realize that its default orbit puts the object near enough to Saturn that its perturbations are important, and therefore sets the "Saturn" checkbox in the Perturbers group. It also thinks that the last observation has somewhat high residuals, and excludes it.
The data arc spans 2000 November 9 to 2000 December 17. 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). Let's go with the first guess. Either hit 'r', or click on the "R1:" and "R2:" area in the upper left. You'll be prompted to enter R1 and R2; type "8.048 8.157" and hit Enter. Then 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: Saturn XXVI = Albiorix = S/2000 S 11 Perisaturn 2001 Jul 7.29939 +/- 1.64 TT = 7:11:07 (JD 2452097.79939) Epoch 2000 Dec 16.0 TT = JDT 2451894.5 Find_Orb M 286.84753460 +/- 7 (J2000 ecliptic) n 0.35982629 +/- 0.0377 Peri. 1.26734 +/- 3.6 a 0.12895430 +/- 0.00901 Node 107.70698 +/- 2.0 e 0.7577677 +/- 0.00705 Incl. 81.15281 +/- 2.2 P 2.74 H 11.5 G 0.15 U 10.5 q 0.03123689 +/- 0.00277 Q 0.22667171 +/- 0.0153 14 of 15 observations 2000 Nov. 9-Dec. 16; mean residual 0".16
Well, this has much better residuals, but the inclination and eccentricity look a little bizarre. Let's try the alternative assumption of delta = +.1, i.e., the object is on the "far side" of Saturn as seen from Earth. Set R1 = 8.248, R2 = 8.357, repeat the "Herget step" and "Full Steps", and you get:
Orbital elements: Saturn XXVI = Albiorix = S/2000 S 11 Perisaturn 1999 Oct 29.75122 +/- 5.96 TT = 18:01:45 (JD 2451481.25122) Epoch 2000 Dec 16.0 TT = JDT 2451894.5 Find_Orb M 152.28123373 +/- 19 (J2000 ecliptic) n 0.36849771 +/- 0.0473 Peri. 85.86441 +/- 16 a 0.12692326 +/- 0.0109 Node 105.17065 +/- 2.5 e 0.3265332 +/- 0.0675 Incl. 33.72553 +/- 1.2 P 2.67/976.92d H 11.5 G 0.15 U 10.7 q 0.08547859 +/- 0.0158 Q 0.16836793 +/- 0.00607 14 of 15 observations 2000 Nov. 9-Dec. 16; mean residual 0".14
If you look at the file of observations you downloaded, you'll see that this is essentially the solution the MPC published. (Changing the epoch to match the one MPC used, 2001 April 1, will get a closer match.)
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.
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. I (and everybody else who looked at this object when it was first found) went with the second solution, not just because of its lower errors, but because the first orbit was so unlike the orbits of the other satellites. And indeed, the object was followed up and got the permanent designation Saturn XXVI, and the name Albiorix; and using the data available as of mid-2017, one gets this orbit:
Orbital elements: Saturn XXVI = Albiorix = S/2000 S 11 Perisaturn 2014 Dec 2.531482 +/- 0.00799 TT = 12:45:20 (JD 2456994.031482) Epoch 2015 Jun 21.0 TT = JDT 2457194.5 Find_Orb M 93.22190 +/- 0.0038 (J2000 ecliptic) n 0.46502015 +/- 1.1e-6 Peri. 81.59871 +/- 0.0026 a 0.10868841 +/- 1.72e-7 Node 89.72387 +/- 0.0020 e 0.5292368 +/- 1.13e-5 Incl. 34.87535 +/- 0.0008 P 2.12/774.15d H 11.2 G 0.15 U 3.8 q 0.05116649 +/- 1.28e-6 Q 0.16621033 +/- 1.11e-6 200 of 210 observations 2000 Nov. 9-2015 June 21; mean residual 0".356
There's a little twist to this story : based on the initial data, it looked as if the last observation was wrong. With further observation, it actually looks to be pretty good; it was the three observations before it that really ought to have been excluded. It's common in these situations where you don't have a lot of data to think "somebody was wrong here, but we don't have enough information to say who it was".
You can click here to get the full astrometric data set for this and other irregular satellites. (Links are also provided to the full data for comets and asteroids.) You can also click here to find orbit solutions for all irregular, and a few regular, natural satellites.
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.txt 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.
Using Find_Orb to predict impact locations
There are several situations wherein one might want to know the location on the earth, or another planet or moon, where an asteroid or space junk is going to impact. Find_Orb has been used to compute the impact location of 2008 TC3, which impacted in northern Sudan on 2010 October 7; 2014 AA, which impacted in the Atlantic Ocean on 2014 January 1; LCROSS, which impacted on the Moon on 2009 October; Genesis, which impacted in Utah in 2004; several of the Shoemaker-Levy 9 objects, which impacted Jupiter in 1994; and to produce impact predictions for 2007 WD5, which briefly had a small chance of hitting Mars. It has also been used to find the impact point of the Japanese Haybusa probe, but unfortunately, not all the astrometry for that case is publicly available yet.
The example case we will use will be 2008 TC3. First, go to MPCOBS and request data for 2008 TC3. (You can alternatively get the astrometry here, from NEODyS.)
You can then save that data to a file, and run Find_Orb, and click on Open, and load the data. I usually use MPCOBS or NEODyS to display the data; then I copy everything to the clipboard, run Find_Orb, and click with the right mouse button on the orbital elements area; then I select "Open from Clipboard". Either way, Find_Orb will pause a bit before loading up the data and producing these elements:
2008 TC3
Perigee 2008 Oct 7.118796 TT = 2:51:03 (JD 2454746.618796)
Epoch 2008 Oct 7.0 TT = JDT 2454746.5 Find_Orb
q 5849.7208km (2000.0) P Q
H 30.6 G 0.15 Peri. 148.3640 -0.4988773 0.8437959
Node 330.1500 0.6888919 0.2475819
e 1.591833 Incl. 23.4175 0.5258794 0.4761423
From 859 observations 2008 Oct. 6-7 (18.8 hr); RMS error 1.748 arcseconds
IMPACT at 7 Oct 2008 2:45:54.16 lat +20.60295 lon E33.11633
It may appear as if Find_Orb has just done everything for you, as if by magic: here we have the exact place and time of impact! This is slightly misleading. If you click on "Worst Obs", you'll see that there are some strong outliers in the data (mostly cases where the clock wasn't set correctly; you'll see that these have dT values of several seconds, indicating clock errors at that level, but the "cross" residuals are small.) So I'd recommend going into Settings, and setting a "Max Filtered Residual" value of two arcseconds, and clicking OK.
If you do that, and then click on "Filter Observations" several times, you'll eventually get a "No changes made!" message. The elements will then be:
2008 TC3
Perigee 2008 Oct 7.118799 TT = 2:51:04 (JD 2454746.618799)
Epoch 2008 Oct 7.0 TT = JDT 2454746.5 Find_Orb
q 5849.8084km (2000.0) P Q
H 30.6 G 0.15 Peri. 148.3645 -0.4988776 0.8437960
Node 330.1495 0.6888962 0.2475869
e 1.591828 Incl. 23.4170 0.5258736 0.4761395
From 718 observations 2008 Oct. 6-7 (18.8 hr); RMS error 0.872 arcseconds
IMPACT at 7 Oct 2008 2:45:54.50 lat +20.60191 lon E33.11760
But we still aren't quite done yet. First off, I'd turn on all of the perturbers. (As it happens, it's not particularly relevant in this case. Find_Orb has already figured out that the effects of the earth, moon, and sun all matter a lot in this case, and includes them. The planetary perturbations between the time 2008 TC3 was found and the time it impacted, on the other hand, scarcely mattered. But it's good practice.)
Also, the epoch of the elements is at midnight on 7 October. We need to reset the epoch to be somewhat closer to that of impact. Change the 'epoch' field to read 2008 Oct 7.12, click on "Full Step" again, and you'll get
2008 TC3
Perigee 2008 Oct 7.118801 TT = 2:51:04 (JD 2454746.618801)
Epoch 2008 Oct 7.12 TT = JDT 2454746.62 Find_Orb
q 5848.4013km (2000.0) P Q
H 30.6 G 0.15 Peri. 148.4778 -0.4994245 0.8433497
Node 330.0722 0.6889788 0.2478319
e 1.592770 Incl. 23.4243 0.5252459 0.4768024
From 718 observations 2008 Oct. 6-7 (18.8 hr); RMS error 0.872 arcseconds
IMPACT at 7 Oct 2008 2:45:54.43 lat +20.59288 lon E33.12104
That leaves us with a couple of fine points to consider. First, we really ought to account for the fact that a small object such as this will hit the atmosphere and explode a few dozen kilometers above the earth's surface. To account for this, before doing the above steps, you should edit the file 'environ.dat' and add a line such as
COLLISION_ALTITUDE=50000
to specify the altitude, in meters, for which a collision lat/lon should be computed.
The other fine point to consider is that of uncertainty. If you hit the "Monte Carlo" or "Statistical Ranging" buttons, Find_Orb will start to compute alternative virtual asteroids that match the input data. The resulting "virtual impact" locations can then be shown in Guide. (Which I realize not all Find_Orb users have. But Guide has some very good geographic display capabilities that I didn't want to attempt to replicate in Find_Orb. One possible workaround may be to have Find_Orb produce .kmz files of the sort that could be displayed in Google Earth.)
To make such a chart of impact locations, let the "Monte Carlo" or "Statistical Ranging" process run long enough to generate a few dozen or more virtual asteroids. Their orbital elements and impact locations will be stored in the file virtual.txt. Put this file in the same folder as Guide. Then, download this file to your Guide folder, and run Guide. In Guide, hit the ':' button; this will cause Guide to show a solar eclipse path on the earth. But also, as you zoom in, Guide will put symbols on the map of the Earth showing where the virtual impactors landed.
Such charts can be very illustrative of how the uncertainty area shrinks with additional data. For example, when I first announced that that 2008 TC3 was a likely impactor, we had only the initial data from (G96) and (854), and about 10% of the virtual asteroids didn't even hit the earth. Here's what the impact area looked like with that very short arc. (Note that at the time of this impact, Find_Orb wasn't nearly so well equipped to handle the situation. About all I knew was that the nominal perigee, and that of about 90% of the virtual asteroids, was less than the earth's radius; the code to compute impact lat/lons and to create these charts was added in response to 2008 TC3.)
Fortunately, Cristovao Jacques and Gordon Garradd ignored my statement that the object probably couldn't be recovered. With their data from (E12) and (D90), the uncertainty area was narrowed down to a strip in northern Sudan. With still more data, the uncertainty area shrank to an area about one kilometer long.
Usually, Find_Orb does a good job of deciding which perturbers are actually important for a particular case. As you may have noticed in the above examples, it could recognize that the Earth and Moon are important perturbers for objects that come near the earth, and that Saturn should be used for an object coming near to that planet.
However, its selections aren't always perfect. It errs on the side of leaving out perturbers, because including them can make the program run somewhat slowly. (You'll probably not notice this unless you've an object with a longer orbital arc -- usually some years -- or a slower machine than is usual these days.) You can, therefore, select whichever perturbers you'd like using check-boxes in the main Find_Orb dialog. The next time you do a 'full step' or Herget step, or compute an ephemeris, those perturbers will be used.
There is also a "Toggle Perturbers On" button. When clicked, this causes Find_Orb to use all major perturbers, currently defined to be Mercury through Pluto, with the Earth and Moon handled separately. Asteroids are not toggled on with this button, since they almost never matter very much and slow the program down (admittedly, not by a lot in most cases). Click here for more information on asteroid perturbers.
I expect that people will have different ideas as to what 'All Perturbers' should mean. One can edit the file environ.dat in a text editor, and add a line such as
DEFAULT_PERTURBERS=7007fe
to cause 'All Perturbers' to include Pluto and asteroids. Alternatives are:
DEFAULT_PERTURBERS=7fe (all perturbers except asteroids)
DEFAULT_PERTURBERS=3fe (Mercury-Pluto, with the Earth and Moon
treated as a single object at their barycenter)
DEFAULT_PERTURBERS=1fe (same as above, but with Pluto excluded)
DEFAULT_PERTURBERS=7005fe (all objects except Pluto)
Or, if you dislike what 'All Perturbers' provides, you can just toggle objects on manually.
Be advised that I've yet to see a case where Pluto mattered. You have to search a bit to find cases where asteroids matter. Usually, it's because the object passed close by to a large asteroid, at a slow enough speed that the smaller object was perturbed. When this happens, however, it can be used to determine the mass of the asteroid causing those perturbations.
Combining and cross-referencing observations
Let's say you have observations of a single object, but under two or more designations. This happens fairly often, sometimes in cases where you just want to give it a try and see if you can get the observations to link. Find_Orb offers several ways to do this, at varying levels of complexity.
Simplest, perhaps, is to put all the observations into one file, load it up "normally" into Find_Orb, and select one of the designations. Then look for the 'AddObj' menu item, and click on that. Now, click on the other designation.
You'll now have all observations loaded as if they were of one object, and can solve an orbit for them. If you have more than just two designations, click on 'AddObj' again and select the third, fourth, and/or fifth designations.
Also fairly simple is to do the same thing, except add the command-line option -c ("combine"). Do that, and Find_Orb will just combine all observations right away. There are two drawbacks to this : Windows users are not generally command line oriented, and if the file contains A, B, and C, you can't just combine A and C. (Of course, you can make a separate file that leaves B out.)
Similarly, if you put the line COM Combine all in the file before any observations, Find_Orb will combine all the observations.
The final method is trickier, but more powerful. Here's an example, involving an unusual artificial satellite that has actually been "discovered" under about 30 different designations. For this example, we'll just consider two of them.
COM fullname C1AUGE1 = ZTF0Edd = 'Multijunk'
C1AUGE1* C2020 09 24.26481800 22 03.27 -06 30 05.3 17.76GVNEOCP703
C1AUGE1 C2020 09 24.27531200 22 41.38 -06 24 18.4 18.29GVNEOCP703
C1AUGE1 C2020 09 24.28055800 23 00.00 -06 21 24.9 VNEOCP703
C1AUGE1 C2020 09 24.29906500 24 05.89 -06 11 06.9 17.44GVNEOCPI52
COM = C1AUGE1
ZTF0Edd* C2020 09 20.38741901 53 57.96 +00 44 30.8 ~9KEw 17.85RUNEOCPI41
ZTF0Edd C2020 09 20.38776601 54 00.72 +00 44 49.1 ~9KEw 17.85RUNEOCPI41
ZTF0Edd C2020 09 20.38788201 54 01.64 +00 44 57.9 ~9KEw 17.70RUNEOCPI41
ZTF0Edd C2020 09 20.38822901 54 04.37 +00 45 16.0 ~9KEw 17.70RUNEOCPI41
The first comment line tells Find_Orb, "The object specified in the next line of astrometry -- which happens to be C1AUGE1 -- should be referred to by the name C1AUGE1 = ZTF0Edd = 'Multijunk'." That's the name that will appear when orbital elements are written out, for example, and in the object selection menu. (Leave out the COM fullname line, and the object would just be referred to as C1AUGE1.) The name refers to its habit of being picked up every now and then as a 'new' artsat.
The second comment line tells Find_Orb, "The object specified in the next line of astrometry -- which happens to be ZTF0Edd -- should be combined with the astrometry for C1AUGE1." This particular object has been on NEOCP a few times, so my artsat observation file has a slew of COM = C1AUGE1 lines in it, one for each time that's happened.
Other objects in the file will be unaffected. Note also that the COM fullname line isn't just for linkages; you can use any time you want the object's name to be something other than the default you'd normally get from unpacking the designation.
The MPC has provided a way to submit proposed linkages. These can be of two or more objects in the ITF, NEOCP, or unnumbered or numbered objects, in any combination. The submission has to be in a particular format for identifications in the JSON format.
If you've used the methods in the above section to persuade Find_Orb to compute an orbit based on observations with more than one designation, Find_Orb will automatically create a linkage.json file in its configuration directory (the directory in which Find_Orb is installed if you're under Windows, or ~/.find_orb on other OSes.) By default, you can just submit that JSON file to MPC.
However, you'd be telling MPC that your name is John Doe, at j.doe@example.com. You should edit the file link_def.json, modify your contact details, and save the result as link_hdr.json.
Ideally, it would be helpful if you could load up a set of observations, sit back, and watch while Find_Orb solved for the orbit. This is not quite possible yet, but the "Auto-Solve" button can now do this in most cases.
The idea is that, after loading observations with "Open", you click "Auto-Solve". There is generally a bit of flickering as the automatic solver tries assorted solutions and converges (we hope) on the correct orbit. Finally, the hourglass turns back to a cursor and you're done.
This almost always works for "normal" objects. Near-Earth objects sometimes give it trouble, especially if it turns out that the object is headed almost straight toward or straight away from us. Satellites, both natural and artificial, usually don't work. (I'm working on both limitations. One thing to try is to shorten the initial arc, or shut off the current arc and select some other part of the full arc of observations to start with.) It's always worth giving this function a try, though; it has sometimes surprised me, finding orbits with initial guesses so stupid that I never expected them to lead to solutions.
The main Find_Orb dialog has a "Simplex" button. This refers to the "downhill simplex" (DS) method of function minimization. Much of what I know about DS comes from this section of Numerical Recipes in C; I'd refer you to that for mathematical details, but a capsule explanation follows.
Click on this button, and Find_Orb will use the downhill simplex method in an attempt to find the "best" orbit fitting the current observations. Unlike other methods, this takes into account the actual nature of asteroid orbits; ordinary main-belt orbits will be chosen in preference to exotic near-light-speed ones. You may find that you have to click this a couple of times before it converges somewhere near that point. You can click here for more information about the downhill simplex method. (Note that at least thus far, I've not added the "superplex" method to Windows Find_Orb. It is available in the console version, but doesn't seem to offer any tremendous advantage over the standard simplex method.)
When you have a very short arc of observations (say, a newly-found object that you've seen over the last week or so), the orbit is usually so poorly defined that neither you nor Find_Orb have much of an idea as to how far away the object really is. In such cases, if you use the "Herget Step" or "Full Step" buttons, the orbit may diverge and become totally ridiculous.
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.
Finding orbits with the method of Gauss
The method of Gauss is one of the most widely used initial orbit determination methods. It was most famously used when the first asteroid, (1) Ceres, was discovered shortly before conjunction with the sun; Gauss was able to determine a good enough orbit to acquire the object after it came out from behind the sun.
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 observation 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:
• It's best used on an arc of weeks to a few months. Use a longer or shorter arc, and you may not end up with a reasonable orbit. (Though sometimes, you will get a perfectly good orbit with longer or shorter arcs... and it may fail with intermediate arcs, especially if the object's motion is along an essentially straight line over that time.)
• There can be zero to three solutions returned by this method. If no valid solution was found, you'll get a message to that effect. Otherwise, clicking on "Gauss" again will cycle through the valid solutions. In certain cases, the solution will only be nominally "valid", and you'll see wacky residuals. Usually, that means you're looking at the wrong solution, and clicking on "Gauss" again will get you the right one.
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".
• As currently implemented, this method is intended solely for objects in heliocentric orbit. I am a little tempted to make suitable adjustments to allow for planetocentric orbits, thereby creating an additional tool for handling artificial and natural satellites. But I've not done that yet, and doubt that it would lead to better orbit determination (Find_Orb generally does quite well on such objects already.)
Click on the "Settings..." button, and you are provided with control over most of the inner workings of Find_Orb:
• Constraints: Allows you to specify that you want, say, a circular or parabolic orbit, or one with a=3, etc. This is quite a powerful (and therefore involved) feature, and therefore there is a section on constrained orbits.
• Reference: By default, the "reference" shown in the orbital elements is to Find_Orb, but you can change it to give your name. This text will appear among the orbital elements on-screen, and in any "pseudo-MPEC"s you generate.
• Monte Carlo noise: One can set the amount of "noise" used in the Monte Carlo and statistical ranging functions; the default amount is .5 arcseconds.
• Element precision: 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.
Note that it can be tempting to say that, if the uncertainties shown indicate that the elements are only good to (say) 0.01 degree, you should set the precision to two or three digits. Oddly, this is really not a good idea. The problem is that if someone attempts to re-create an ephemeris with truncated elements, they'll get serious errors when compared to the original observations. So keeping at least four digits is advisable.
• "Element center" box: By default, Find_Orb selects the most "reasonable" object center. If an object is close to the Earth at the epoch, it gives geocentric elements. If it's close enough to Jupiter, you get jovicentric elements. (By 'close enough', we mean "within the sphere of influence" of that object.) Most of the time, this automatic selection gives you "ordinary" heliocentric elements.
However, you can override this and insist that Find_Orb give you elements relative to another solar system body. (This is mostly used when the object is close to us, and geocentric elements would really make sense, but you need elements for another program that requires heliocentric data.) You can also get orbital elements relative to the solar system barycenter. Barycentric elements can be quite useful for TNOs, which are far enough out that they are basically orbiting the solar system barycenter, rather than the sun.
• "Use sigma file" check-box: By default, observations are all given the same uncertainties (sigmas) in position, magnitude, and timing. If they are in .rwo format, then the sigmas given in that file will be used. Turn on this check-box, and sigmas from #sigma tags or from sigma.txt will be used.
• Apply debiasing: Checking this box causes Find_Orb to apply the FCCT14 debiasing method. ( Click here for more information about FCCT14. Essentially, Farnocchia, Chesley, Chamberlin, and Tholen did some work to measure the systematic biases in various star catalogs for various parts of the sky. Their software, and now Find_Orb, can use those measurements to compensate for these biases.) Turn this checkbox on, and FCCT14 biases will be subtracted from input astrometry. The first time you use it, Find_Orb will realize it doesn't have the necessary data file, and will give you instructions on how to access the data file used for FCCT14 (or you can click here to get the debiasing data file (about 7.4 MBytes, decompressing to about 27 MBytes) without waiting for Find_Orb to nag you about it.)
• Alternative orbit format: Normally, you would leave this box checked. Find_Orb will then show MOID information for most planets, and uncertainties in orbital elements if a "full step" is performed. However, this format does not exactly match the eight-line format used by MPC. Un-check this box if you need MPC format (for example, when supplying data to a planetarium program.)
• Precise residual check-box: Checking this will cause residuals to be show with an extra digit. This option has long been available in console Find_Orb; I've found it handy mostly in ensuring that Find_Orb was replicating results from NEODyS and AstDyS, right down to the milliarcsecond. (In the normal course of things, the only observations I can think of that might be good to such a level would be HST and Hipparcos ones, and the VLBA observations of Saturn.)
• Comet magnitudes section: The choice here is between "total" or "nuclear" comet magnitudes. (The choice is irrelevant for anything except comets.) 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, we'd have some uncertainties (sigmas) for the photometry. (Find_Orb allows one to set magnitude uncertainties, but it's not of much practical use, since one rarely knows what those uncertainties are!)
• Physical model: The "standard" model is the simple gravitational one (and the only one most people will ever use): sun and any selected perturbers, general relativity, oblateness of planets... click here for details on the force model. In this model, a "full step" leads to Find_Orb fitting six parameters: the position and velocity of the object at the time of epoch.
If you hit the '*' (asterisk) key, Find_Orb will provide a list of non-gravitational effects that can be included. At present, these are somewhat limited (though usually sufficient), modeling the basic effects of solar radiation pressure (SRP) on space junk and smaller rocks, and of comet outgassing on comets. The menu will have a [?] symbol at the upper right; clicking on this will get full documentation of the various options.
• Filtering section: The "filtering" section determines what happens when you click on "Filter Obs". The default is to filter as before, in the manner probably used by almost all orbit computers: observations greater than a "Max residual" limit are excluded, and those within that limit are included. The limit is specified in sigmas. By default, Find_Orb assumes identical uncertainties for all observations, though this can be adjusted by setting uncertainties for observations in a variety of ways.
Alternatively, one can assign a "blunder probability". This new way of filtering observations is described here. The basic idea is that observations far from prediction are included to the degree we think they are not blunders. (By default, I'm assuming that 2% of all observations are blunders. If we knew, a priori, which observations were in that 2%, we'd just eliminate them... but we don't.) An observation close to prediction will be included at nearly full weight; one ten sigmas off prediction will have almost zero effect on the solution. An observation two or three sigmas will be included, but to a lesser degree than would otherwise be the case.
• Over-observing parameters: The "over-observing parameters" section addresses situations where one observer gets so much data that her results dominate the orbit solution. For example: on occasion, you'll find that an object was observed three times by one observer, four by another, three by yet another... and then there's somebody who made 57 measurements on one night. In the normal course of things, the guy who made 57 measurements will dominate the solution, even if he made 57 bad observations. (The usual cause of over-observing is data gathered for a light curve, but there can be other reasons. I think some observers just believe that "more is better", instead of just being "more".)
I've tried to come up with a good solution to this issue, and have implemented one based on ideas kindly suggested independently by Marco Micheli and Alan Harris, currently called the "t-and-k scheme". The idea is that if, over a t-day time period, the number of observations n_obs made is greater than a constant k, then the observations should be reweighted downward by k/n_obs. Thus, the weight given to the entire arc will be as if only k observations had been made. This effectively caps how much influence one observer can have over a given time span t.
In the Settings dialog, one can set t ("time range", defaulting to one day) and k ("observation ceiling", defaulting to five observations.) With these parameters, if Find_Orb notices that a given observation is one of 57 made from the same observatory during the same day, the observation will be given 5/57 of the weight it would otherwise receive. (Alternatively, you could say that its uncertainty will be increased by sqrt(57/5). That works out, mathematically, to be the same thing.)
Thus, the total effect of the 57 observations would be as if five had been made. All 57 will still be used; this helps to remove random noise that would have been apparent had we, say, just taken five observations and tossed the rest. But that observatory will no longer dominate the orbit.
Set the "time range" to be zero, and it becomes impossible to over-observe an object, and this scheme is effectively disabled.
Now, I basically pulled those default values out of my hat. My general gut feeling is that after somebody has taken five observations on one night, they are usually not getting much information from subsequent observations, and if you pretend that they really are getting useful data, there's a risk that any systematic biases they have will swamp all the good data. But there is room for differences of opinion here, which is why t and k are user-settable options.
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)
e=1,i=144 (constraint for a Kreutz sungrazer type of orbit)
P=1436m,i=0,e=0 (constraint for a geosynchronous satellite: circular, no
inclination, period of one sidereal day)
Q=15000km (constrain apogee to 15000 kilometers)
O=134 (ascending node constrained to 134 degrees)
o=56.7 (longitude of periapsis constrained to 56.7 degrees)
n=0.3141 (mean motion is 0.3141 degrees/day)
G=0.12 (reset magnitude slope parameter)
A=0.006 (constrain area/mass ratio to 0.006 m^2/kg)
By default, the unit for orbital period constraints is years; but one can add 'm' for minutes (as shown for the geosat example above), 'd' for days, or 'h' for hours. Distances are assumed to be in AU, but one can add 'km' (as in the same example above) for kilometers.
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.
Click on the "Filter Obs" button, and Find_Orb will perform observational filtering using the scheme selected in the filtering section of the Settings dialog. If this filtering 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.
Determining uncertainties with the Monte Carlo and statistical ranging methods
Often, Find_Orb breaks a cardinal tenet of physics: it gives all sorts of numbers without giving you any idea as to how accurate they are. You can give it a few observations made over a one-week period in 1973 and generate ephemerides for the present, and it will happily crunch out positions to .1-arcsecond precision, totally ignoring the fact that said positions are probably nowhere near the right part of the sky. (You can usually say that a short arc will lead to huge errors when extrapolated in this way, and that a long arc will have high accuracy, but it's surprisingly hard to be sure unless you actually compute the errors.)
If you're an observer, you have a real need to know just how exact the ephemeris is. If the positions are good to within a few arcseconds, you may decide that there is no point in re-observing the object; the current knowledge of its orbit is good enough. If the uncertainty is a few arcminutes, you know that taking an image or two will nail down the orbit nicely. And if the uncertainty is huge, you'd at least like to know what part of the sky should be searched.
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/medium uncertainties. (It's the method Find_Orb uses when sigmas are shown on-screen for orbital elements.) 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.
Usually, the method to use in Find_Orb is the "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.)
If your arc is quite short, the Monte Carlo orbits will usually "blow up"; you'll get orbits light-years away that make no physical sense. If that happens, the thing to do is to stop the MC process and click instead on "Statistical Ranging".
SR is, from the standpoint of the user, not much different from Monte Carlo. The advantage of SR is that you can use it even if you have only two observations, and/or a really short arc. So why isn't it the preferred method? Simple: if the arc is much longer (long enough so that "full steps" converge), SR becomes extremely slow. So only use it if MC fails.
SR works by taking a guess at the distance and radial velocity of the first observation. (It has some logic in it that enables it to set some limits on both distance and radial velocity, so it won't waste time considering hyperbolic orbits or orbits that are light-years away.) It then finds the orbit that would bring an object to the last observation. If the residuals are low enough that the orbit can be considered "reasonable", then the orbit is written out to mpcorb.dat and virtual.txt (just as would happen in Monte Carlo). Hence my comment that, from the viewpoint of the user, SR doesn't "look" all that different from MC. They're just different ways of finding alternative orbits that fit whatever data you have.
To be added: when you generate an ephemeris, all the variants should be integrated so that scatter-plots can be shown of "where the asteroid might be at time X", as well as just showing that "the uncertainty at time X is Y arcseconds at position angle Z". Also, uncertainties can often be computed just using the covariance matrix; and uncertainties in the orbital elements from any of these methods really should be shown to the user.
Saving orbital elements and residuals to a file
At any point, if you want to save the results, click on "Save Elements" and you'll be able to create an ASCII file containing the text in the "orbital elements" box. You can also click on "Save Residuals" and create a text file containing all the data in the observations/residuals list box.
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.
Be advised that elements.txt, and any similar file you make using "Save Elements", contains data beyond the eight-line MPC formatted data. The file will also contain a state vector, MOIDs for eight planets, Tisserand criteria with respect to the Earth, Jupiter, and Neptune, and some "housekeeping" data such as when the elements were written, which perturbers were included, and the version date for Find_Orb. You'll probably just ignore most of this data, but it can come in handy every now and then.
By default, the format of the "Save Residuals" file is essentially that of the list box. However, if you specify a .res extension, then Find_Orb will realize that you want the MPC format for residuals. In this abbreviated format, only the date, observatory code, and residuals are stored for each observation, packed so that there are three observations/line, and a brief blurb is given for each observatory. Thus, something like
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
is transformed to
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 time, a number of steps, and a proposed step size in days, and a lat/lon. 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.
The starting time for the ephemerides can be input in a variety of formats; click here for details.
In computing the ephemeris, Find_Orb will include the effects of any perturbers you selected in the "main" dialog, and any non-gravitational effects selected in the Settings dialog.
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 'Sun' for heliocentric ephemerides, 'Mer' for Mercuricentric ephemerides, 'Ven' for Venus-centered (Cytherian? Venerian?), 'Mar' for Mars, and so on, up to 'Plu' for Pluto and 'Lun' for the Moon. 'Ast1' will generate Ceres-centric ephemerides, and 'Ast15' will generate (15) Eunomia centered ephemerides. Note that only the 300 asteroids used in Find_Orb are available.
You can also add your own 'MPC code' for topocentric sites on the Earth, Moon, Sun, or planets; see rovers.txt for details. (The most common use of this has been to support observations of artificial satellites from people who don't have MPC codes. But it can also be used for generating ephemerides from the surface of another planet. I've also used it, for example, to specify the exact locations of all telescopes on Mauna Kea, instead of leaving them lumped together under the (568) code.)
There are six radio buttons to choose from six different types of ephemerides. The default is "Observables", which provides data such as RA/dec, alt/az, and similar quantities. If you choose to make an "Observables" ephemeris, you can use check-boxes for items such as motion details (how fast the object is moving, in arcminutes per hour, and the position angle at which it is moving), alt/az, radial velocity, and so forth. (Of course, the alt/az checkbox doesn't accomplish anything for geocentric ephemerides.)
Also available is a "State Vectors" radio button. Click on this, and each ephemeris line will give a Julian Day followed by the position and velocity in Cartesian coordinates, in AU and AU/day, relative to the observer. (Thus, one can set the "observer" to be station code 500, center of the earth; or Sun, center of the sun; or Lun, center of the moon, and so on, entering the station code in the "Latitude" box.)
The "Cartesian coords" results in the same sort of output, except that only the positions are given (i.e., the velocities are omitted).
Occasionally, it may be useful to have a table of the orbital elements, to show how they change over time. The "MPCORB elements" and "8-line elements" options will accomplish this, resulting in the orbital elements at each ephememis step being output.
Finally, the "Close Approaches" radio button will cause only the dates/times of closest approach over the ephemeris span to be displayed. For this, it's best to select geocentric (or heliocentric or planetocentric) coordinates; a short step size would be needed for topocentric coordinates, to account for the relatively high-frequency rotation of the earth.
Observable ephemerides use the UTC (Coordinated Universal Time) scale. Others use the TT (Terrestrial Time) timescale.
Whenever you generate an ephemeris, Find_Orb creates a "pseudo-MPEC" with the filename mpec.htm. Clicking on the "Pseudo-MPEC" button will bring it up in your browser. 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 179.3 Phase 0.7 RA vel -4.28'/hr decvel 9.15'/hr dT=-1.49 sec
ang vel 10.10'/hr at PA 334.9 radial vel -1.150 km/s cross -0.22 9.6 days ag
Delta= .00807 r= 0.9918 mag=18.40 mag (computed)=18.34 2009 Jan 16 6:38:01
MPEC ????-B14 Obj alt 73.5 az 127.9 Sun alt -73.2 az 310.0
(G96) Mt. Lemmon Survey (N32.44283 W110.78872)
K09B00D* C2009 01 16.27641 07 53 19.03 +21 35 31.9 18.4 V EB014G96
The first line gives the elongation and 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. If the observation was reasonably recent, you'll also get an indication of how many days (or hours or minutes) ago it was made.
The third 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 fourth line shows the altitude/azimuth of the object and of the sun at the time of the observation. That can be a useful sanity check at times; if the object is below the horizon, or the sun above it, you should probably disregard the observation. In some cases, there will be a reference preceding that data, to an MPEC or MPC IAUC or other publication.
The fifth line gives the observatory name, three-character code, latitude, and longitude.
The sixth and final line shows the observation data in the original MPC 80-byte form.
Setting coordinate epochs other than J2000
By default, the input from an MPC-formatted or .rwo- formatted file is assumed to be in J2000. However, you can insert #coord epoch lines to specify a given epoch. For example,
COM coord epoch 1905.0
J96X01X C1997 10 18.97256 00 30 26.10 +03 07 12.3 691
J96X01X C1997 10 19.65954 00 29 27.92 +03 01 07.2 691
COM coord epoch mean
J96X01X C1997 10 21.03352 00 27 34.62 +02 49 01.9 709
COM coord epoch app
J96X01X C1997 10 21.72050 00 26 37.40 +02 43 00.9 17.3 709
COM coord epoch 2000
J96X01X C1997 10 22.06400 00 26 09.76 +02 40 01.9 709
J96X01X C1997 10 22.75098 00 25 13.19 +02 34 04.0 709
The first two observations would be assumed to be 1905.0 coordinates. Next is a position in mean coordinates of date, followed by a position in apparent coordinates of date. And for the last two, the epoch would return to the default J2000.
Note that the coordinates will be read in, then precessed immediately. So the coordinates shown in Guide will be in J2000.
Also note that MPC knows nothing of this. Send 'em positions of this sort, and they'll ignore the COM line and try to handle those positions as if they were in J2000. So DO NOT send this sort of data to MPC!
Find_Orb will initially set a "reasonable" epoch for the orbital elements of the object, rounded to an integer Julian Day (noon UT of a particular 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.) In truth, you can input the epoch in a variety of formats; click here for details.
Some may want all orbits to be on a fixed epoch. (MPC orbits, for example, are usually at 200-day epoch intervals.) One can edit the file environ.dat and add a line such as
EPOCH=2455600.5
to have all orbits start out with epoch JD 2455600.5 = 2011 Feb 8. (One can then override that fixed epoch with the epoch edit box, of course.) One can specify the epoch in environ.dat with any of the time formats used in the epoch box.
If you have occasion to turn on the "asteroids" perturber box, you may wonder exactly which asteroids are included. Commonly, this would be (1) Ceres, (2) Pallas, and (4) Vesta (the "CPV" model), and indeed, Find_Orb used to include only these.
However, Find_Orb can now include perturbations from the 300 most massive asteroids. Click here for details. (As you'll see, it's now required that you download a file of orbital elements in order to get this capability.)
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). Such "problem cases" have gotten rarer over the years, but they still happen sometimes.
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 and STEREO sun-grazing comets. These can give the software a serious headache! For these, I usually set r1=r2=1, then use a constraint of "e=1,i=144", corresponding to a Kreutz sun-grazer. A few Herget steps usually get a passable answer, with the full steps polishing it off. If the arc is long enough, I can then switch the constraint to just "e=1" and do full steps successfully.)
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.
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 can also add lines to the input file of astrometry to indicate that particular observations are shut off. For example, if you loaded the following data:
J97Z99Z C1997 04 21.12432 13 56 34.48 -09 11 06.7 x13.5 V 413
J97Z99Z C1997 04 21.16887 13 56 49.70 -09 11 08.1 13.5 V 413
J97Z99Zi C1997 04 21.21342 13 57 03.97 -09 11 16.6 413
COM suppress_obs
J97Z99Z C1997 04 21.25797 13 57 16.44 -09 11 31.6 413
J97Z99Z C1997 04 21.30252 13 57 26.35 -09 11 51.4 13.4 V 413
J97Z99Z C1997 04 21.34707 13 57 33.13 -09 12 14.3 413
COM include_obs
J97Z99Z C1997 04 21.39162 13 57 36.42 -09 12 37.9 413
J97Z99Z C1997 04 21.43617 13 57 36.13 -09 12 59.7 413
J97Z99Z C1997 04 21.48072 13 57 32.47 -09 13 17.1 413
...the middle three observations would be turned off when the data were first loaded. Also, the first observation would be toggled off by the 'x' in column 65 (just before the magnitude value, not otherwise used in an MPC report), and the third observation would be toggled off by the 'i' in column 13 (where the discovery asterisk might normally go). The observations would still appear and you'd see their residuals; they just wouldn't be used when the initial orbit was computed. (If you just want Find_Orb to completely ignore some observations, not having them show up anywhere in the program, use COM ignore obs and COM end ignore obs instead. It'll be as if the lines in between don't even exist.)
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 can 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 uncertainties 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, Tycho-2, and CMC-14, are routinely getting results good to a tenth of an arcsecond or so.
In theory, every observation should come with an uncertainty (sigma) that gives you an idea as to how much it should be trusted. We would then know that the data that is good to 0.01 arcsecond should have a much greater impact on the orbit solution than data that's only good to ten arcseconds. We should also know the uncertainty in the magnitude and in the observation time.
That's the theory. Unfortunately, we rarely know what the sigmas actually are. The 80-column MPC format allows one to report the time of observation, RA/dec, and magnitude, but not the uncertainties in those quantities. The new ADES (IAU2015) format provides a way to specify uncertainties, That's the best-case scenario : if you happen to have data in ADES with uncertainties specified, Find_Orb will read them and use them. But at least at present, MPC doesn't export the uncertainties they've collected back to the world. If you search the MPC database for a particular object, you can get astrometry for it... but it'll be in the 80-column format with no uncertainties given.
And even if the data were returned in ADES format (which I keep hoping it eventually will be), the fact remains that until recently, people weren't reporting uncertainties, so we've decades of sigma-less data. So we have to resort to the following crude methods.
• Sigmas set by precision: At the very lowest level, the precision of the input sets a lower limit on the uncertainties. If the declination is given to 0.1 arcseconds (the usual value), the sigma on the position will be at least 0.1 arcseconds. If the magnitude is given to an integer magnitude, then the sigma on the magnitude will be at least one magnitude. Usually, the uncertainty will actually be worse than this (and will be determined using one of the following methods), but looking at the number of digits in the input data at least lets us avoid the error of assuming that "2014 January 28.14" represents time to the millisecond level.
• Sigmas set in the .rwo format: If your data is in the .rwo format used by AstDyS and NEODyS, the sigmas on magnitude and position are given along with the data. (AstDyS and NEODyS use a astrometric debiasing model to both remove systematic biases and to compute approximate astrometric uncertainties based on the expected error from the reference catalog used, the location in the sky, and (sometimes) other factors.) .rwo data does not include timing uncertainties (it has an "accuracy" determined from the number of places given in the input data), so those are determined as they would be for MPC's 80-column astrometric data format, as described below.
• Sigmas set by 'rules': The 80-column format doesn't allow you to specify any sigmas whatsoever for optical data. So for data in that format, Find_Orb makes some guesses based on the history of some stations as to the uncertainties in time, date, and magnitude. These guesses (essentially rules such as "(J95) really gets good timing, down to about 0.1 seconds" and "astrometry before 1993 is usually photographic and not good to better than three arcseconds") are given in the file sigma.txt, which replaces the now-obsolete weights.txt. You can edit sigma.txt with any text editor or word processor. (Click here to see the default version. It's quite heavily commented and should be easy to follow.)
This is a really barbaric way of assigning uncertainties, but is much better than assuming all observations to be equal. You'll also perhaps notice that it assumes the uncertainties are circular, i.e., the uncertainty in RA is the same as that in dec. We'll get into ways to handle elliptical uncertainties below.
If you wish, you can force all observations to be treated equally, by un-checking the "Use Weights" check-box in the Settings dialog. If this is turned off, all astrometry is assumed good to 0.5"; all magnitudes to 0.5 magnitudes; and all times to one second (except radar observations; those are always assumed to be "perfectly" timed, which is pretty close to reality.)
Note that you won't normally want to do this. About the only situation where you would use uniform uncertainties for all observations would be to allow you to compare Find_Orb's results to those from a different program.
If you want to change these 0.5"/0.5 magnitude/one-second default uncertainties, edit the file sigma.txt and look for the "catch-all" line near the bottom, just above the paragraph about "how to assign sigmas".
• Sigmas set with comment lines: You can set sigmas within the input file of astrometry, by adding lines such as
(One or more records 80-column astrometric data; group A) COM Posn sigma 0.3 COM Mag sigma 0.01 (One or more records 80-column astrometric data; group B) COM Time sigma 15 COM Posn sigma 0 (One or more records 80-column astrometric data; group C) COM Mag sigma 0 COM Posn sigma 0.37 0.21 43 (One or more records 80-column astrometric data; group D)
Here, uncertainties for the observations in group A are assigned "normally", using the sigma.txt rules. Observations in group B will all be given positional uncertainties of 0.3 arcseconds and photometric uncertainties of 0.01 magnitude.
In group C, we set a timing uncertainty of 15 seconds. COM Posn sigma 0 tells Find_Orb to revert to the default sigma.txt rules for astrometric uncertainty; the photometric uncertainty is left at 0.01 magnitude. In group D, we go back to sigma.txt for photometric sigmas, too.
Group D also defines an elliptical uncertainty, with axes 0".37 by 0".21, tilted at position angle 43 degrees. The idea is that if COM Posn sigma is followed by one number, the uncertainty is circular; two numbers, and you're giving RA and dec uncertainties (the position angle is implicitly zero); three numbers, and it's an error ellipse tilted relative to the RA/dec axes by the specified position angle.
The advantages of using COM keywords are that it's easy to read and MPC will accept the data for submission. They won't actually use your sigmas and nobody else will see them. However, I'm reasonably sure they keep your original data submission (I certainly hope they do; it would be absolutely bonkers not to.) So if they eventually switch to the long-delayed ADES (IAU2015) format, your uncertainties could be added to the new records.
• Sigmas set within 80-column MPC records: In Find_Orb, one can specify sigmas in RA and dec in the MPC's 80-column format using columns 57 to 65. Those are really reserved for internal MPC use. Submissions to MPC must leave these blank. However, if you put two numbers in there, Find_Orb will assume they are the RA and dec uncertainty for that observation in arcseconds.
If you put two numbers in there and an 'm' into column 65, Find_Orb will assume the uncertainties are in milliarcseconds. Put a 'u' in column 65, and it'll assume microarcseconds. Click here for an example of sigmas set using this method.
Unfortunately, only Find_Orb will recognize these sigmas, and MPC will reject observations if you do this. So it really has limited utility.
• Tholen-style sigmas: Dave Tholen "extends" the MPC format in a different way: he stores the "usual" 80 columns, then an RA sigma in six bytes and a dec in six bytes. So the total line length is 92 bytes. For example :
YB98FF0 C2017 01 26.63462509 35 34.343+17 09 32.12 18.3 G T12 0.077 0.033 YB98FF0 C2017 01 26.63509309 35 39.585+17 09 30.08 18.4 G T12 0.092 0.061
This is easier to read than the above solution of stuffing the sigmas into the usually blank bytes 57-65. It does have the same problem in that MPC will bounce the data.
Setting sigmas 'by hand': Finally, you can specify uncertainties by selecting one or more observations, then clicking on the "Sigmas" button in the Find_Orb dialog. You'll be prompted for the positional uncertainty for the observation(s), in arcseconds. This makes it look as if only the uncertainty in position can be reset in this manner. In truth, there's a little hidden trickery here: you can enter (for example) m.3 to reset the magnitude uncertainty for the observation(s) to 0.3 mags, or t.01 to set the uncertainty in timing to 0.01 seconds.
Weaknesses in the error model: Find_Orb has, I think, the most advanced modelling of errors of any orbit determination program. In addition to allowing one to set uncertainties in position, time, and magnitude, it has blunder management to mitigate the effects of dubious or completely wrong data, and "over-observing" parameters to ensure that an observatory that makes huge numbers of measurements can't dominate the result too greatly. However, aside from the fact that determining uncertainties is, in itself, an uncertain business, it still has the following weaknesses.
Correlations between observations: Find_Orb mostly assumes that errors between successive observations are uncorrelated. In reality, it's common for people to get a few observations on a given night where the timing is consistently wrong (i.e., if you start out with your timing wrong by ten seconds, it'll probably still be wrong by ten seconds at the end of the night.) If your photometry setup isn't too good and you're measuring magnitudes that are .3 mags too faint, they'll probably all be .3 mags too faint. And so on. In this regard, Find_Orb's simple model in which errors are random and (mostly) Gaussian falls flat. (The deviation from Gaussian is mostly handled by the use of blunder management.)
I've only vague ideas as to how this might be fixed. The currently implemented "over-observing" strategy does help get around the most noticeable aspect of this problem: namely, the fact that if one observatory gets a zillion observations on one night, and they're all consistently off, it can overwhelm the (correct) observations made elsewhere and dominate the solution.
Why timing uncertainty matters: Traditionally, orbit solutions are based on the assumption that the observer measured the time exactly. However, not everybody does get timing right. With a fast-moving object, you can often see than one or more observers failed to set the timing correctly, and their positions fall a few seconds "ahead" or "behind" everybody else's. In Find_Orb, you can see this by looking at the information shown when you click on such an observation: you'll see that the "cross-track" error is reasonable, even though the overall residuals may be quite high. In short, the object really did pass by that RA/dec; it just didn't do so at the time specified in the observation.
Most objects are slow enough so that timing errors are not too troublesome. The problems arise when the object is moving quickly. For example, suppose your astrometry is good to 0.7 arcseconds, and you observe an object moving 0.4 arcseconds per second, and your timing error is six seconds. That is to say, your timing error could add an error of 2.4 arcseconds along the object's line of motion. (The perpendicular component -- the "cross-residual" -- would be unaffected by the timing error, and still good to 0.7 arcseconds.)
The total error along the direction of motion would be sqrt( .72+2.42)=2.5 arcseconds. Essentially, the object's uncertainty ellipse is no longer a circle of radius 0.7 arcsec; it has been stretched out to have a major axis of 2.5 arcsec along the direction of motion, but still has a 0.7 arcsec minor axis perpendicular to that.
I think people haven't worried about this because it didn't matter so much for a long time. Few fast-movers were observed, and the positional uncertainty wasn't as low as can be achieved with current CCDs. But as astrometry has gotten better and faster objects are observed, the effects of poor timing have become more noticeable.
In some cases, things might be a lot worse. Somebody may have gotten an image of a meteor, for example, from which we can say: "The object can be seen at such-and-such RA/dec in the image, but we have only a vague idea as to when the image was taken." The Chelyabinsk meteor, caught on many dashboard cameras, springs to mind as an example.
This is still useful data. It still constrains the orbit (though not as well as a properly-timed observation). However, to make use of it, we have to include the uncertainty in the timing. I know of no other orbit software that includes timing uncertainty, though I very much doubt that doing so is original with me.
Ideally, we'd "fix" the problem by getting observers to time their observations correctly, but that's not as easy as it might seem. I think a lot of observers just make sure their computer's clock is set to within a few milliseconds, but remain unaware of timing issues caused by the fact that the "image time" is for the beginning or end of the exposure instead of its midpoint; or because there is some latency in the shutter; or maybe the "image time" is the time all the data finished coming in from the camera. For some professional setups, things just get worse: the shutter is big enough and takes long enough to open/close that the time is a function of where you are in the image. About the only way around this is to observe fast-moving objects with "known" ephemerides, and to check that your positions match. There are a few artificial satellites that fill the bill; I'll add comments about this later.
Note that even if we did get everybody to fix this problem, we would still have the issues of archived observations that were not properly timed, plus problems arising from meteor camera observations.
As mentioned above, one very serious weakness in how timing uncertainty is handled remains, and that is that we've assumed random timing errors. In reality, the error is usually strongly correlated over a night's observations: for example, the computer's clock might have been three seconds fast all night. (Or the software might store the time of the beginning or end of the exposure, or when the data was received, as described above.)
It's been suggested by several people that the "clock error" of a particular site could be included as an extra parameter to be solved for, much as one can solve for (say) asteroid masses or non-gravitational parameters as extra parameters. This is tempting, though I see possible problems with trying to solve for too many parameters with too little data.
Setting precise and non-standard-format times and RA/decs for observations
The current MPC format for optical astrometry allows one to specify the time to a precision of .000001 = 1e-6 day, or 86.4 milliseconds. Usually, that's sufficient. (In fact, most observations are given to only five decimal places, or .864 second precision). But certain NEOs and many artificial satellites move so fast that it would be best to specify the time more precisely, especially for video-based observations.
Similarly, positions are usually given to .01 second in RA and 0.1 arcsecond in declination, with the option of using another digit if you're suitably confident in your data. On rare occasion, though, you may want more (or less) precision than this.
Find_Orb provides a couple of ways to get around these problems. For timing, I'd suggest using any of several alternative time formats. Essentially, instead of using the MPC's YYYY MM DD.ddddd format, you can specify the time in the same columns using different formats, thereby allowing you to give more digits and/or specify the time in HH:MM:SS.ssss form, or in JD or MJD form.
Alternatively, you can put a line of the following sort in front of the observation in question:
COM time 2009 Mar 3.1415926535897 COM time 2009 3 3 14:15:09.265358 COM time 2454894.31415926
Basically, one can reset the time to arbitrary precision, and with a somewhat arbitrary format (any of the formats used when specifying epochs or ephemeris start dates can be used; click here for details.) The subsequent observation will be assumed to have been made at the time specified, and the time stored in the MPC observation line will be ignored.
Yet another alternative is use of the .rwo format, which allows time to be specified to 10-10 day, or 8.64 nanoseconds.
A warning, though: the double-precision values (64-bit floats) used in Find_Orb have 52 bits of precision. Find_Orb handles times in the Julian Day system, so its precision for current-day events is about 40 microseconds. Anything beyond that just won't get handled correctly. And as you approach that level of accuracy, roundoff error will become a big issue. I don't really know at what point one would actually have to worry about all of this, but it might be well before approaching the 40 microsecond level. (There are a couple of ways of getting around this, if it ever becomes an issue. Find_Orb could switch to "long doubles" with 64 bits of precision, giving us a 4096-fold improvement. A precision of 10 nanoseconds should be enough for anybody. Times could be stored in days since 2000 January 1, instead of in the Julian Day system of days since noon on 1 January -4712; this would improve precision by a factor of 512 for dates/times between 1980 and 2020, where it matters most. Combine the ideas, using long doubles for days since 2000 January 1, and we'd have a precision of 20 picoseconds.)
RA/decs can be stored in a variety of ways, to allow for input in decimal hours or decimal degrees, or for extra digits. Columns 33 to 56 of data in the existing 80-column MPC format contain the RA/dec data. MPC usually accepts and uses the first two formats shown below. The others are not official MPC formats, though the low-precision flavors have shown up for some ancient comet observations and for SOHO/STEREO data, which tend to be of coarse quality. Here, 'z' means either 'h'ours or 'd'egrees.
hh mm ss.sss (MPC uses this for 'precise' RAs)
zz mm ss.ss (MPC uses for most RAs & 'precise' decs)
zz mm ss.s (MPC uses for most decs & low-precision RA)
zz mm ss (Used by MPC, only rarely)
zz mm (Used _very_ rarely by MPC)
zz mm.m (Maybe used by MPC once or twice)
zz mm.mm
zz mm.mmm
zz mm.mmmm
zz mm.mmmmm
zz mm.mmmmmm
zz. (degrees or hours)
zz.z
zz.zz
zz.zzz
zz.zzzz ... can go up to nine places in RA or
eigt places for declination
ddd. (used for RA only)
ddd.d
ddd.dd ... can go up to eight places (again, RA only)
HHMMSSs (RA to .1 second)
ddmmSSs (dec to .1 arcsecond)
HHMMSSss (RA to .01 second)
ddmmSSss (dec to .01 arcsecond)
... and so forth until...
ddmmSSsssss (dec to 10 microarcseconds)
HHMMSSssssss (RA to one microsecond)
Find_Orb supports all these formats because I've had input data from sources such as Mars Express (astrometry for Deimos and Phobos) and VLBA observations of Saturn. That last is extremely precise, requiring the last two microarcsecond formats shown above (click here to see the result for the Saturn VLBA data). This precision will also be needed, I hope, for data from the Gaia mission. Gaia is supposed to reach 20 micro-arcsecond accuracy at magnitude 15.
Extending the time range for observations and ephemerides
By default, if you attempt to use Find_Orb to generate ephemerides for dates before the year -1000 or after the year +3000, you'll get an error message. Also by default, only a range of 200 years of observations can be handled by the program. Usually, dates outside those ranges indicate some sort of a blunder, and the user should be warned about them. But if you're actually doing something that requires larger time ranges, you should edit the text file environ.dat and look for these lines:
TIME_RANGE=-1000,3000
MAX_OBSERVATION_SPAN=200
Change those numbers, and you can revise the accepted time ranges. Note that Find_Orb is not really set up for long-range integrations; if you want to see what happens to an object over hundreds of thousands of years, you're pretty much out of luck. However, if you use the JPL DE-431 ephemeris (see the next section on how to do that), you can get good results over the entire range of that ephemeris, which is roughly -13000 to +17000.
What do you do if you don't have an observatory code?
I will first note that the MPC provides instructions on how to get your own observatory code. However, you may not want to wait. (Even if you're willing, it can take a long time for the code to come through.) Or you may just have a few observations made from some oddball location. Find_Orb provides three different ways of handling this problem (aside from the fourth method, that of getting the MPC to issue you an observatory code).
• You can use the "roving observer" extensions provided by MPC. Essentially, your observations all have code (247), and each line of astrometric data is accompanied by another line giving your lat/lon and altitude. This is a somewhat awkward way of doing things, but it does work.
• As mentioned at the above 'how to get your own observatory code' link, you can specify COD XXX in your observation header, and use code (XXX) for all your observations. You then provide another 'comment' line in the observation header that gives your latitude/longitude. This is probably the simplest method, but does assume that you have only one location to add. The resulting header might look a bit like
COD XXX COM Long. 239 18 45 E, Lat. 33 54 11 N, Alt. 100m, Google Earth
...along with the usual TEL, OBS, MEA, NET, etc. header lines. The above would be for an observer at longitude 120° 41' 15" West; the MPC allows only East longitudes, in degrees/minutes/seconds. (The coordinates are for a point off the coast from San Diego, California. There isn't an observatory there, unless you take a boat and a telescope out there.)
Find_Orb is considerably less picky. The longitudes can be east or west, and you can pick any three-character abbreviation you want. So the following...
COD C-2 COM Long. 131 41 59.26 W, Lat. 53 58 08.7 N, Alt. 5896m, from a dream COD Q2v COM Long. 27 18 28 W, Lat. 14 14 21.3571 S, Alt. 42m, rough guess
...would cause any subsequent observations from C-2 and Q2v within that file to be assumed to be from those lat/lon. Also, with Find_Orb, the latitudes and longitudes can be in decimal degrees with zero minutes and seconds, or degrees and decimal minutes and zero seconds; i.e., the following lines would all describe the same point :
COM Long. 31 10 36.0 W, Lat. 53 17 45 N, Alt. 17m, from sextant obs COM Long. 31 10.6 0 W, Lat. 53 17.75 0 N, Alt. 17m, from sextant obs COM Long. 31.11 0 0 W, Lat. 53.2958333 0 0 N, Alt. 17m, from sextant obs
You can even use these if you think an existing MPC code is incorrectly placed; lines such as the above will override the usual sources of MPC station locations. But this is for Find_Orb's use only; if submitting to MPC, you will have to stick to COD XXX, east longitudes, and degrees/minutes/seconds, and no excuses.
Once Find_Orb has loaded astrometry with such headers, you can generate (for example) (Q2v)-centric ephemerides. However, it'll "forget" about those stations when you close the program.
Also Find_Orb-specific: if you use the above, you can specify the observatory name on the COD line, e.g.,
COD Q2v Mid-South Atlantic Ocean Observatory
• The final method is Find_Orb specific. If you edit the text file rovers.txt distributed with Find_Orb, you will see details and examples of how to add your own MPC codes. As you will see, I've used this to add "MPC codes" for several artificial satellite observers and the separate locations of the telescopes on Mauna Kea (MPC lumps them all in one location with one observatory code, which is sometimes problematic; we do get objects close enough to the earth that the exact locations matter). The planets, sun, solar system barycenter, and some natural satellites (including the moon) also get their own codes, as do a lot of radio telescopes and some other scopes that MPC insists on lumping under one code. This is a powerful, easy, and very useful system. But if you use any of these codes, MPC will look at your astrometry and have no idea what's going on. Consider it to be "for internal use only".
Speeding Find_Orb up by using JPL DE ephemerides
Find_Orb comes with some code built into it o compute where the moon and planets are, with moderate precision. But it's a really good idea to have it use a JPL ephemeris file. The JPL files can be large, but the resulting planetary positions are more accurate and are computed more quickly, causing the program to run a lot faster overall.
Most people can simply download one of the following files to their Find_Orb directory. (On Windows, this will be the directory in which Find_Orb is installed. On non-Windows systems, it will be the ~/.find_orb directory.) Find_Orb will automatically detect the file and use it.
•
A 13.6 MByte file covering years 1900 to 2050
•
A 36 MByte file covering years 1800 to 2200
•
A 110 MByte file covering years 1550 to 2650
•
A 2.72 GByte file covering years -13000 to +17000
For most purposes, any of the first few files will suffice. But some people may be doing longer-range computations; for them, the bigger files will be worth the download time and disk space.
The files come from various 'versions' of JPL's ephemerides, with the last two being from their most recent (2021) update. But it is unlikely that you would ever be able to detect any differences with the older versions.
Some Windows users have had problems accessing these files. They are on a JPL ftp server, and some Windows browsers have started to restrict ftp access. You can either try a different browser (this works for some people) or you can download this 14 MByte file covering years 1900 to 2050 , or download this 53 MByte file covering years 1600 to 2200. These links use http instead of ftp; all browsers should be able to get them. (My thanks to Andrew Lowe for hosting that second file.)
If you already have a JPL ephemeris file that you'd like to use, or if you want to put the file in a different directory, you should edit the file environ.dat in the directory in which Find_Orb is installed (on Windows) or in the ~/.find_orb directory (on anything else), and look for a line reading JPL_FILENAME. The paragraph above that line will explain how to change it.
C/C++ source code for Find_Orb
You can click here to access the current Find_Orb source code on GitHub. (The source code used to be provided as a ZIP file on this site. GitHub works a lot better...)
You can click here for directions on how to build Find_Orb for Linux, OS/X, and *BSD. You should probably have some experience with building software from source before doing this. It's not rocket surgery, but there is a learning curve.
Find_Orb can be built for Windows natively, using Microsoft's Visual C/C++ compiler, or cross-compiled from Linux using the Mingw-w64 compiler. I tend to assume that Windows users will prefer pre-compiled binary files, though at least a few people have built Find_Orb using the MSVC makefile. However, I've not really gotten around to documenting that yet.
Running console find_orb: Once built, you can simply run, for example, find_orb example.txt . It will work as described on this page.
Non-interactive (batch-processing) mode:
The second program compiled from the source code , fo (fo64.exe or fo32.exe under DOS/Windows), 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 works as follows. Suppose you have a file of astrometry, astrometry.txt . You would run the following command on the Windows or Linux or Mac command line:
fo astrometry.txt
(modified to fo32 or fo64 on Windows). You can click here for details on how to run fo (command line options, where the output files go, etc.) fo has a lot of options to control ephemeris generation and such.
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:
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. P and Q are displayed in J2000 equatorial coordinates.
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 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 automatic choice; there is a setting to force heliocentric (or other-centric) orbits.
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" natural object within the moon's sphere of influence, and therefore haven't seen Find_Orb generate a selenocentric orbit... though note that spacecraft frequently do lunar flybys, and therefore have selenicentric orbits for epochs close to the flybys.)
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
Tisserand criterion: The Tisserand criterion is sometimes used to see if an object might have been captured from parabolic orbit, usually by Neptune or Jupiter.
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.