(24 Aug 1999) Find_Orb tracks Cassini!
There is an e-mail group for Find_Orb users at http://groups.yahoo.com/group/find_orb/. 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.
(18 Feb 2010) Andy Puckett pointed out that inclusion of asteroid perturbers was broken. I fixed this.
(18 Feb 2010) At Andy Puckett's suggestion, I've added an 'All Perturbers On' button (which becomes an 'All Perturbers Off' button when perturbers are on). Click here for details.
(18 Feb 2010) Handling of the new WISE (C51) observations was sometimes not as good as it might be. Satellite observations are provided in two lines; sometimes, for WISE data, those lines were the opposite of what one might expect. I revised Find_Orb to handle that situation, and to do somewhat better error checking on the observations in general.
(21 Oct 2009) The console app version is now known as find_orb (or, under Windows, find_orb.exe). It had previously been known as dos_find, which got increasingly confusing as it was ported to Linux and OS/X!
(21 Oct 2009) The program handles the absence of key files more intelligently now, giving you warning messages or errors as needed. Also, the absence of ephemeris files is not as disastrous as it once was. It's still best to set up JPL ephemeris files, but you'll get pretty good results for most objects without them (though the program is apt to be slower).
(21 Oct 2009) One can now compute ephemerides from the surface of another planet or moon or the sun. It was already possible to compute ephemerides from the center of any planet or the moon or the sun. But you can now do it from surfaces, too. You can see how by looking at rovers.txt. An example "rover" is given for the impact point of the LCROSS mission. Given astrometry for LCROSS, this results in an ephemeris with the range dwindling to zero at the time of impact.
This may also allow one to include "off-earth" observations from the surfaces of planets. But I have no data with which to test that idea yet.
(21 Oct 2009) The console app version now shows impact data in blinking text, just to make sure you don't overlook possible impacts. Similarly, MOIDs less than .01 AU are shown blinking. This may be extended to some other text that really should get user attention. Unfortunately, I don't see a way to do this properly in Windows (yet).
(17 Sep 2009) Reiner Stoss pointed out that the posted version was actually the April one, completely missing the improvements listed below for 28 May. I've posted a current version. In addition to actually providing the improvements that should have been made in May, the current version has several bug fixes that will, I think, resolve some crashes that were reported. Also, there's a "maximize" button for the main and ephemeris dialogs.
Also: a while back, I posted some pseudo-MPECs with NEOCP data. Shortly thereafter, MPC added the following note at the end of all NEOCP astrometry files:
REMARK: Not to be redistributed. For personal use only.
So all pseudo-MPECs you generate now will have the lines with NEOCP data "redacted", sort of like a classified document.
(28 May 2009) Bug fixes: Reiner Stoss pointed out that you should be able to save residuals in MPC format by using a .res extension. It turned out that this had been "broken" for a little while now. Also, the program crashed when it encountered an MPC code it didn't know about, instead of giving the "MPC code XXX is unknown" message it was supposed to show. (This happens most frequently when one has new data with new observatories, but an out-of-date list of MPC observatories.) Both bugs are now fixed.
(15 Apr 2009) A few small fixes:
(6 Apr 2009) On 1 March, I revised the main dialog and ephemeris dialog so they were resizable. But you could make them too small; it was left up to you. Now, the main dialog can only be resized in height, and you're prevented from making either dialog so small as to cause trouble. Also, the ugly font for ephemerides has been replaced with a more readable one. Also, a make file for the MinGW compiler (a version of the gcc compiler for Win32) is included, and a few small changes made to the source code to accommodate that compiler.
(24 Mar 2009) John Dailey asked about some problems in compiling the Linux console version on a 64-bit system. It turned out that this was possible to do, after we made some small modifications to certain parts of the program that assumed 32-bit integers. While I was about it, I also cleaned up most of the remaining g++ compiler warnings.
(9 Mar 2009) Recompiling the Linux console version with Ubuntu 8.10 and a current g++ compiler turned up a small bug (nothing affecting DOS/Windows users). I also fixed a few compiler warnings.
(9 Mar 2009) Andy Puckett suggested that if ephemerides were made with, say, a .02-day step size, then the ephemerides should be given to .01-day precision. Now, they are.
(5 Mar 2009) Several improvements:
(3 Mar 2009) The handling of JPL DE ephemerides is simplified. In most cases, as long as the JPL ephemeris file is in the Find_Orb folder, Find_Orb will recognize it, without you having to add its name to environ.dat.
(3 Mar 2009) You can specify positions in epochs other than J2000, useful when dealing with historical data in mean coordinates or B1950 or other epochs.
(1 Mar 2009) Several improvements:
COLLISION_ALTITUDE=50to have the impact data reflect an altitude of (for example) 50 km.
(14 Oct 2008) Three small improvements:
(10 Sep 2008) Several small improvements:
(25 Feb 2008) Several small improvements:
(13 Nov 2006) Several improvements:
(3 May 2006) The MOID (Minimum Orbit Intersection Distance) relative to the Earth's orbit is shown if that distance is less than one AU. It is also shown for other planets if the distance is small enough (limits are .1 AU for Mercury, Venus, and Mars, and one AU for the other planets).
(3 May 2006) It's possible to reset the weights for observations, in any of three different ways. Click here for details.
(3 May 2006) You can now get ephemerides in Cartesian coordinates (either position-only, or position-plus-velocity).
(3 May 2006) The text-based (console) version of Find_Orb now supports some mouse commands, at least on some platforms.
(3 May 2006) In addition to MOID data, a few other minor details are now shown in the elements, such as the apoapsis distance (Q) and the time of perihelion, expressed in HH:MM:SS form.
(4 Oct 2005) There is no longer an integration step size control. It's no longer needed; Find_Orb now automatically detects the step size needed at each point in the integration. This can result in some tremendous gains in speed. It also improves accuracy; in the past, people would sometimes load observations for artificial satellites without dropping the step size, and would get bizarre results. That shouldn't happen now.
(4 Oct 2005) Find_Orb can now read ephemerides from the Minor Planet Center's NEOCP (Near-Earth Object Confirmation Page) as if they were observational data. To do this, set the NEOCP ephemeris to be from a topocentric MPC station. (The main reason for this is that a topocentric ephemeris will include some parallax, making the range determination much more accurate. Actually, you can use a geocentric ephemeris, but the solutions tend to be lousy.) Save the entire ephemeris, including the header line that says "Below are the results of your request", etc.
(Note that as of early 2007, this is a less important feature. MPC used to provide no data for NEOCP objects but ephemerides. Now, you can get the raw observations and feed them to Find_Orb, just as with any object. That's a much better idea than using an NEOCP ephemeris... but you can still do it if you want. I do it occasionally because you can get ephemerides for all NEOCP objects at once, then use the text-based (console) version in its non-interactive mode. That gets me orbits for all the objects at once. In a perfect world, I'd do the same thing after getting the observations for all NEOCP objects at once. But you can only get the observations on an object by object basis.)
Aside from selecting a topocentric MPC code, and perhaps changing the "Start ephemerides at now + (blank) hours" options, you should leave everything at its default setting. That is, you should have a one-hour ephemeris step, full output, and positions in full sexagesimal. Save the resulting page as either text or HTML, and load it into Find_Orb, and you should see the NEOCP objects listed. You should be able to click on them and get orbits for them, just as if the input file was one of actual observations.
Be warned that MPC doesn't always include perturbations for NEOCP objects. This may seem a bit odd, given that the objects are NEOs. But you may find that when you load these objects into Find_Orb, the program will automatically recognize that perturbations from the Earth should be included, and it'll generate some ugly residuals. But if you turn off the Earth and Moon, and do a "full step", the residuals go back to something more normal.
If that happens, don't use the Find_Orb ephemeris. Go back to the NEOCP, get the raw observational data for that object, and solve for the orbit again.
(4 Oct 2005) The effects of general relativity are now included. I had written an essay here about how easy it is to add GR to orbital computations. Then I failed to do so. The oversight is now fixed.
(4 Oct 2005) Some small fixes: the format for the NEODyS and AstDyS .rwo files was changed recently, and the new version of Find_Orb can read both "old" and "new" format files. The new version can also handle the Minor Planet Center's workaround for numbered minor planets from (100000) to (619999). (The MPC's format for optical observations only allows asteroid numbers to be stored in five characters, so the numbering of the 100000th asteroid precipitates an "A100K Crisis". The workaround is that such numbers can be "packed" as A0000 = (100000) to Z9999 = (359999), then a0000 = (360000) to z9999 = (619999); this should handle everything until the new MPC observation format is implemented.)
Also, I fixed a bug that was, I think, keeping the program from working on the Mac. And I changed the initial orbit determination routine to favor (by a small margin) prograde orbits over retrograde.
(17 Mar 2005) The Italian files for Find_Orb have been updated, courtesy of Giuliano Pinto. Most of Find_Orb will now run in Italian, and quite a bit of it in French. (If you're interested in translating Find_Orb into other languages, click here for information on how to do it.)
(22 Feb 2005) There is a new "Settings..." button. Clicking on this bring up a Settings dialog, wherein you can reset six key parameters. Click here for details.
(22 Feb 2005) In addition to the usual perturbers (all nine planets and the moon), there is an "Asteroids" check-box. This turns on perturbations from (1) Ceres, (2) Pallas, and (4) Vesta, the only objects normally used in orbital calculations. Be warned that they don't seem to matter very much. I only know that Find_Orb is using them because of three clues. First, if you extend the number of digits shown (using the new "Settings..." feature), you'll see that they change when the asteroids are toggled on. Second, if you feed Find_Orb data for any of these three asteroids, the orbit goes haywire when you check the "Asteroids" box and do a Full Step. The program will attempt to compute the perturbations of the asteroid on itself, and gets bizarre results.
The third reason I know that it's working is that I fed Find_Orb data for (197) Arete, with the astrometry coming from AstDyS. (See the following section about use of AstDyS data.) This object had a close pass by Ceres some decades ago, and the resulting deviation in its path has been used to determine the mass of Ceres. I found that if I did a solution with "asteroids" checked, the RMS error dropped a bit relative to the RMS error without "asteroids" checked.
(22 Feb 2005) Previously, the program could only read in observations in the MPC 80-column format. It can now also read in observations in the NEODyS and AstDyS .rwo format. This is convenient, since you can visit these sites and get full astrometry for most asteroids.
(22 Feb 2005) The source code for Find_Orb now compiles to a much more useable console application, ideal for use in DOS and Linux. It now uses the curses library under both platforms. In some ways, the console application is now "spiffier" than the Windows app.
(22 Feb 2005) The observer data shown at the bottom of the dialog box when you click on an observation is much more comprehensive now.
(14 Dec 2004) Some bugs in ephemeris generation and in the 'save residuals' function are now fixed. (A few people had seen crashes when using these functions.)
(14 Dec 2004) The initial orbit determined when you first load observations for an object is much better now. For most objects, in fact, it may be all you need.
(?? May 2004) There is now a "worst obs" button. Click on this, and Find_Orb will highlight the included observation with the worst residual. You can then decide whether to exclude that observation.
(?? May 2004) Further to the above, there is also a new "filter obs" button.
(26 Aug 2003) A few small improvements have been made to the "pseudo-MPEC" capability. Some of the existing capabilities, such as editing the list of observatory Web sites and so on, are better documented now.
(11 Apr 2003) There is now a Gauss button, to determine orbits by that method.
(11 Apr 2003) The "pseudo-MPECs" now link the observatory lat/lon text to maps indicating where these observatories are on the earth. Also, as is discussed at the above link, you can cause Find_Orb to insert your name in the elements.
(11 Apr 2003) The astrometry for the Earth-orbiting IMP8 satellite has finally enabled me to test Find_Orb's handling of the earth's equatorial bulge, the "J2" effect. (Testing this required a satellite orbiting close enough to the earth for a long enough time. The J2 effect drops rapidly with distance from the earth; satellites such as J002E3, for example, are almost totally unaffected.) It turned out that the force due to J2 was computed correctly, but with the wrong sign. This is now corrected. (I seriously doubt that anyone has been using Find_Orb in a situation where this matters!)
(7 Mar 2003) Fixed two bugs that caused crashes (for some people) when they tried to create ephemerides or use the new Monte Carlo feature. The former crash occurred if you used Find_Orb's built-in routines to compute planetary positions, instead of having it get planetary positions from the JPL DE ephemerides. While this bug is fixed now, use of DE ephemerides is still highly recommended. The program can run a lot faster if it uses one.
Also, the Monte Carlo function got confused when dealing with objects orbiting planets (artificial and natural satellites.) This has been fixed.
(10 Feb 2003) Find_Orb can now compute ephemeris uncertainty regions, using the observational Monte Carlo method.
(10 Feb 2003) Find_Orb now generates a "pseudo-MPEC" .HTML page, vaguely resembling those produced by the Minor Planet Center.
(9 Dec 2002) In the course of analyzing the orbit of J002E3, an object originally assumed to be a near-Earth asteroid but now almost conclusively determined to be the SIVB stage from the Apollo 12 mission, I found that the mass value used for the Earth was slightly in error. You would never have noticed it with asteroids/comets, which don't linger close to the earth for weeks on end; nor with artificial satellites, where you (usually) don't have extremely long orbital arcs. Anyway... it's fixed.
(4 Nov 2001) Following some prompting by Pertti Pääkkönen, I fixed most of the problems that were apparent when attempting to run the program in Linux.
(26 Apr 2001) There is now a way to get constrained orbits, in which you specify an assumed eccentricity, and/or semimajor axis, orbital period, inclination, etc.
The program will now run in Italian or French, if you've selected one of these language in Guide. If you don't have Guide, just make a file named STARTUP.MAR containing one of the following lines:
51 language i 51 language f
(28 Mar 2001) A whole slew of revisions, some of which have been present for a while but not documented, but some are actually new:
Auto-Solve button: In most cases, you can use this to automatically get an orbit, without much need to be knowledgeable about how orbits are determined. Click here for details.
Väisälä orbits: There is now a button for generating this sort of preliminary orbit. Click here for details.
You can now save lists of residuals in the MPC format. Click here for details.
There are now console (text-base) versions of DOS, Linux, and Mac Find_Orb; the source code for Find_Orb posted on this site supports both.
(1 Jan 2000) Two people pointed out that Find_Orb doesn't properly handle objects with observations straddling 1 Jan 2000 0:00 UT. The observations after that date are shown first in the residuals box, instead of after the 1900s observations. This has been fixed. It just involved telling Windows not to sort the residuals, so there was no change made in the source code posted on this site.
Find_Orb can take a set of observations of an asteroid or comet, given in MPC (Minor Planet Center) format or the NEOIBO or AstDyS formats, and find the corresponding orbit. The MPC format is a "standard" used by most astrometry software, including Charon. You can click here for details of the MPC format.
Find_Orb can determine orbits of artificial Earth satellites and for satellites of other planets. It exists as a 32-bit Windows program, and as C/C++ source code that can be compiled for a Windows or Linux or Mac console application. In what follows, I'll just refer to "Find_Orb", without making a distinction between the various flavors.
Click here to download the Windows version (about 508 KBytes).
Click here to download the C/C++ source code (about 177 KBytes).
Find_Orb is a user-friendly program that handles the initial determination of the orbit using the method of Herget. Given some more observations, it can find a "best fit" orbit using the method of least squares . It's sufficiently bright to include the perturbing effects of the planets and Earth's moon, those of Jupiter's four largest satellites, several of Saturn's satellites, and those of the three largest asteroids.
Find_Orb is, in some ways, of limited practical value. Most people will measure the position of an object on several nights, using a CCD camera with software such as Charon, and e-mail the observations to the Minor Planet Center. The MPC will accumulate observations, then report the resulting orbit and ephemerides via IAU Circulars and MPECs.
But there are several situations wherein one might want to use Find_Orb:
If you're tracking a near-earth object (NEO), you may not be able to wait for a revised orbit from the MPC. With Find_Orb, you can take any available astrometry, then generate an orbit and/or ephemeris.
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. So astrometrists in general may have an interest in the software.
Inquiring Minds are sometimes curious about the entire "black art" of turning astrometric data into orbital elements. This was my main motivation for writing Find_Orb. (And it's turned out to be useful for academic purposes; I occasionally hear from 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. Some people have used it to do 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 announcement that 2008 TC3 was going to hit the earth was based on feeding the data through Find_Orb, and some people were able to use it to determine the impact point and time.
Find_Orb is copyrighted freeware. Use in or with commercial software is expressly forbidden without written permission from Project Pluto:
Project Pluto 168 Ridge Road Bowdoinham ME 04008 (UNITED STATES) tel (207) 666 5750 fax (207) 666 3149 pluto@projectpluto.com http://www.projectpluto.comBut aside from such commercial uses... please use it freely. (If you use it for something really interesting, please let me know!)
At some point, I expect to put the source code under the GNU Public Licence (GPL).
Other orbit determination software of interest
Perhaps the most widely-used publicly available software comparable to Find_Orb, allowing you to include perturbing objects and to do both initial and full least square orbit fitting, is the OrbFit software. It's also freeware (with restrictions similar to those for Find_Orb). It was put together by about half a dozen professional astronomers, and can run in Windows 95/98/NT or Unix. FORTRAN source code is provided. (You can also click here for information about the C/C++ code for Find_Orb.)
OrbFit also includes code to do some quite advanced tasks, such as figuring out proper orbital elements, impact probabilities, use radar observations, compute error values for almost all parameters, etc. In most ways, it's much more sophisticated than Find_Orb.
Pasquale Tricarico has informed me of the development of the ORSA (Orbit Reconstruction, Simulation and Analysis) project. This will provide a core library and a set of tools for orbital determination tasks.
Jim Baer'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." It also does some things in the area of computing covariance matrices and sigmas that are not (yet, anyway) implemented in Find_Orb. Since it's written in Java, it's somewhat more cross-platform than Find_Orb.
Aldo Vitagliano's SOLEX package includes an orbit-determination program, FindOrb (same as my software but without the underscore). SOLEX also has some impressive capabilities (not available anywhere else, as far as I know) for integrating the entire solar system forward/backward in time. So it can compute where planets were tens of thousands of years ago or from now. (Most software, my own included, is accurate over only a few thousand years.)
John Rogers' 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.
Where does one get observations to feed to Find_Orb?
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 format, of course, so you can feed the MPECs directly into Find_Orb, without even bothering to eliminate the other text associated with an MPEC; Find_Orb will recognize which lines contain observations and which contain other data.
Also, one can get observations for most asteroids from NEODyS and AstDyS, in their .rwo format.
You can use the MPC's MPCOBS service to get observations for any given object. (This used to be a subscription-only service, but now, anyone can use it.) Or you can click here for access to MPC's databases of astrometric data. Note that the files with data for all numbered or unnumbered minor planets are enormous, and Find_Orb can't actually load all of them; you need to edit the files and extract observations of interest.
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.)
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.
You'll first have to download Find_Orb from this page, copy it to your Guide directory, and unZIP it. Installed in Windows, it will provide a rather ugly icon showing a yellow sun with an object orbiting it.
When you start it up, you'll get a big dialog box. There is an "Open..." button in the upper left corner; click on it and select the example file from the Open File dialog box.
Right below that "Open..." button is a small list box that will show all the objects Find_Orb found in that file. In the case of this file, it will find observations for two imaginary objects, 1996 XX1 and 1997 ZZ99, the Mir space station, and Sinope (Jupiter IX, a faint outer satellite of Jupiter).
Running Find_Orb with 1996 XX1
We'll try the easy one first. Double-click on 1996 XX1, and Find_Orb will immediately find the following pretty good orbit:
Orbital elements: 1996 XX1 Perihelion 1998 Mar 8.969361 TT = 23:15:52 (JD 2450881.469361) Epoch 1997 Oct 23.0 TT = JDT 2450744.5 Earth MOID: 0.0615 Ma: 0.0049 M 324.90486 (2000.0) P Q n 0.25622617 Peri. 72.47300 -0.50277705 -0.86441415 a 2.45501256 Node 47.71103 0.79213685 -0.46159042 e 0.5741561 Incl. 0.14296 0.34602664 -0.19930493 P 3.85 H 15.8 G 0.15 q 1.04545211 Q 3.86457302 From 13 observations 1997 Oct. 12-22; RMS error 0.485 arcseconds
In this instance (and in most instances), Find_Orb can get something close to the right orbit without you having to adjust it. The residual errors are in the proper ballpark (under an arcsecond or so.) The orbit has a large enough MOID with the Earth so that it's not a danger to us, though Martians might worry about the Mars MOID of .0049 AU. Again, you'll usually get an answer that indicates a sensible, non-threatening object.
In this case, you are basically ready to go; you could compute an ephemeris or feed the orbital elements to another program without further work. This won't be the case for shorter arcs, because the orbit won't be very well determined. It also won't be the case for longer arcs or objects coming near a planet (usually the Earth), where perturbations are a factor. It also wouldn't be the case if there are some erroneous observations that ought to be excluded from the orbit fit. An example of the perturbation problem follows.
Running Find_Orb with example asteroid 1997 ZZ99
The second "example" asteroid, 1997 ZZ99, is mostly similar, but it does throw some problems into the system.
Double-click on 1997 ZZ99, and right away, you'll see the following unusual idea of an "orbit".
Orbital elements:
1997 ZZ99
Perigee 1997 Apr 22.935609 TT = 22:27:16 (JD 2450561.435609)
Epoch 1997 Apr 23.0 TT = JDT 2450561.5 Find_Orb
q 14941.6690km (2000.0) P Q
H 22.9 G 0.15 Peri. 356.23652 0.62657228 -0.76960718
Node 312.51135 -0.71062719 -0.49939125
e 5.8196325 Incl. 9.59986 -0.32002525 -0.39788586
From 35 observations 1997 Apr. 21-22; RMS error 1.128 arcseconds
In this case, Find_Orb has automatically latched on to the correct orbit, and has detected that the earth and moon are significant perturbing forces. The check-boxes for both objects in the "Perturbers" section are turned on. Note that Find_Orb isn't always bright enough (yet) to detect this sort of situation.
Also, you'll notice that the perigee distance is comfortably greater than the 6378 kilometer radius of the earth. So we won't get hit this time.
Guide has detected that at the epoch, 1997 April 23, the object is so close to the earth that it makes more sense to talk about its orbit relative to us, rather than its orbit relative to the sun. That is to say, the object is within our "sphere of influence". If you'd rather see the heliocentric orbit, you can use the Settings... Heliocentric Orbits Only check-box. Or, you can set the epoch to be a few days ahead of the encounter on April 23, or a few days after it. (The elements will be quite different, since the asteroid is obviously seriously perturbed by the encounter.)
Somewhat oddly, this object actually comes within the very small sphere of influence of the moon, and if you set the epoch to April 22.5 and do a Full Step, Find_Orb will show you a selenocentric orbit. (1997 ZZ99 is a carefully contrived example. In reality, the only cases for which I've seen selenocentric orbits have been artificial satellites such as LCROSS and STEREO-A and STEREO-B, which were specifically targeted to impact or pass the moon.)
Running Find_Orb with S/2000 S 11, a satellite of Saturn
At one time, I was at somewhat of a loss for astrometry to provide for irregular satellites of gas giants. Fortunately, this is no longer the case. The ideas discussed below will be quite general, but the example used will be the satellite S/2000 S 11, the discovery of which was announced on 19 December 2000.
Click here to download the astrometry for this object. This file is the Minor Planet Electronic Circular (MPEC) giving the original discovery astrometry. Load it into Find_Orb, and you'll get a Centaur orbit with not-very-good residuals by default. To find a Saturnicentric orbit, Find_Orb will need a little coaching.
Find_Orb is bright enough to realize that its default orbit puts the object near to Saturn, and therefore sets the "Saturn" checkbox in the Perturbers group.
The data arc spans 9 November 2000 to 17 December 2000. Consulting with an ephemeris program (or with the JPL Horizons system) tells you that, on those dates, Saturn was about 8.148 and 8.257 AU from the Earth. Since a natural satellite basically is just dragged around by a planet, you can be confident that the distance to the satellite was about (8.148 + delta) and (8.257 + delta) AU on those dates (assuming only a fraction of an orbit was completed).
If you look at the orbits of known irregular satellites of Saturn, you'll see that they have semimajor axes in the ballpark of a=.1 AU. I usually use initial guesses, therefore, of delta = -.1 AU (a guess assuming the object is on the near side of the planet) and delta = .1 AU (assuming the far side of the planet). Going with the first guess, set R1 = 8.048 and R2 = 8.157, click on "Herget Step" a few times, then on "Full Step" a few times. Rather quickly, the program will settle down on an orbit resembling the following:
Orbital elements: S/2000 S 11 Perisaturn 2001 Jul 6.675722 TT Epoch 2000 Dec 2.0 TT = JDT 2451880.5 M 272.38363 (2000.0) P Q n 0.40436636 Peri. 5.58450 -0.36000669 -0.07200746 a 0.1193108 Node 110.56628 0.81289929 -0.51345927 e 0.7685389 Incl. 83.45621 0.45780992 0.85508743 P 2.44 H 11.0 G 0.15 q 0.0276158 From 15 observations 2000 Nov. 9-Dec. 17; RMS error 0.552 arcseconds
Well, this has reasonably low residuals, but the inclination and eccentricity look a little bizarre. In any case, let's now try the alternative assumption of delta = +.1. Set R1 = 8.248, R2 = 8.357, repeat the "Herget step" and "Full Steps", and you get:
Orbital elements: S/2000 S 11 Perisaturn 2002 Apr 1.933825 TT Epoch 2001 Apr 1.0 TT = JDT 2452000.5 M 211.67402 (2000.0) P Q n 0.40533552 Peri. 73.30298 -0.83559992 0.05564627 a 0.1191205 Node 107.06023 -0.17734258 -0.96891430 e 0.3806275 Incl. 34.86662 0.51992536 -0.24105718 P 2.43 H 10.9 G 0.15 q 0.0737800 From 15 observations 2000 Nov. 9-Dec. 17; RMS error 0.474 arcseconds
If you look at the file of observations you downloaded, you'll see that this is essentially the solution the MPC published.
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 most of the data, one gets this orbit:
Orbital elements: Saturn XXVI = Albiorix = S/2000 S 11 Perisaturn 2001 Dec 27.043157 TT = 1:02:08 (JD 2452270.543157) Epoch 2001 Apr 1.0 TT = JDT 2452000.5 Find_Orb M 235.3085 (2000.0) P Q n 0.4617462 Peri. 60.1568 -0.8204340 -0.0720332 a 0.1092016 Node 110.2299 0.0006200 -0.9921431 e 0.472264 Incl. 37.1909 0.5717407 -0.1022900 P 2.13/779.54d H 11.1 G 0.15 q 0.0576295 Q 0.1607736 From 114 observations 2000 Nov. 9-2009 Feb. 20; RMS error 0.552 arcseconds
Running Find_Orb with (simulated) astrometry for the Mir space station
It is possible, though not necessarily very useful, to run Find_Orb to determine the orbit of an artificial Earth satellite. I didn't have any actual test data to use, unfortunately, so I generated an example. I did this by starting up Guide, setting my lat/lon to that of an MPC station, and generating an ephemeris for a pass of the Mir space station. If you run Find_Orb, open the EXAMPLE file, and double-click on "Mir", you'll load up the simulated observations in question.
Again, a decent guess for R1 and R2 matters here. The default guess of 1 AU is obviously nonsense for an earth-orbiting object. Reset these to .00001 AU. This corresponds to about 1500 km, which is a good "low-earth orbit" distance.
Check the "Earth" box and run a few Herget steps. You'll quickly see convergence to these values:
Orbital elements: Mir Perigee 1998 Jun 20.810218 TT Epoch 1998 Jun 20.8 TT = JDT 2450985.3 M 171.29447 (2000.0) P Q n5660.54255256 Peri. 132.79498 -0.81371242 -0.44835486 a 6720.118 km Node 28.13785 -0.15470880 -0.44641400 e 0.0057829 Incl. 51.66791 0.56030106 -0.77439813 P 91.58m H 24.2 G 0.15 q 6681.256 km From 10 observations 1998 Jun. 20-20; RMS error 158.892 arcseconds
The RMS errors are admittedly a bit shocking. The reason for their size will be explained further on. You'll notice that the period of 91 minutes is decent for a low-earth object. The perigee distance still keeps Mir from plowing into the Earth (remembering that the radius of the Earth at the equator is 6378 km).
Before you click on the "Full Step" button, I must suggest that you take an unusual step. By default, when you full-stepped, Find_Orb would shift the epoch back to Jun 16.0. The problem is that attempting to extrapolate this short arc back by about five days (about 700 times its own length) would be unstable; you need an epoch that is closer to the observations. So reset the epoch to 2450985.34. This is right in the middle of the actual observation set, and will be quite stable.
Having done that, a few Full Steps get you this orbit.
Orbital elements: Mir Perigee 1998 Jun 20.810114 TT Epoch 1998 Jun 20.8 TT = JDT 2450985.3 M 168.93682 (2000.0) P Q n5652.74897459 Peri. 132.46347 -0.81106791 -0.45313414 a 6726.294 km Node 28.13381 -0.15214408 -0.44720528 e 0.0048460 Incl. 51.67437 0.56481946 -0.77115296 P 91.71m H 24.2 G 0.15 q 6693.698 km From 10 observations 1998 Jun. 20-20; RMS error 39.292 arcseconds
For a longer arc, or a higher satellite, the Moon might come into play. But if you check that box and do more Full Steps, you won't see much of a difference.
The reason for those huge residuals is a simple one. The MPC format allows for a maximum precision in time of .0864 seconds = 10-6 days. In that seemingly brief period of time, Mir can move about 700 meters. When it's 1000 km away (and for some of these observations, it was much nearer), 700 meters = 140 arcseconds. Until Find_Orb can read other (non-MPC) formats, this will be a problem.
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).
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 the asteroids (Ceres, Vesta, and Pallas). 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. I had to search to find a case where the asteroids mattered: (197) Arete is in a resonance with (1) Ceres, and if you use the full astrometry for Arete in Find_Orb and work carefully, you can show that failing to include Ceres results in poorer residuals. (With further work, you could use that fact to determine a mass for Ceres.)
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.
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 observations comes closest to the midpoint of these two, will be used. The resulting orbit will fit those three observations with near-zero residuals, and the other observations with passably small residuals.
Be warned: this method was ideally suited to the pre-computer era. It can get you a good preliminary orbit with relatively little effort. But it does have some quirks, some inherent in the method itself, some inherent in how I implemented that method:
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.
Click on the "Settings..." button, and you are provided with control over items such as constraints on the orbit (a topic large enough to given its own section). You can also set a "Reference" text. This text will appear among the orbital elements on-screen, and in any "pseudo-MPEC"s you generate. (By default, the "reference" is to Find_Orb.)
In addition, one can set the amount of "noise" used in the Monte Carlo function; the default amount is .5 arcseconds. Also, the threshhold used in the Filter Obs function can be reset, as can the precision used for elements. By default, this is set to 5, meaning that the angular elements are shown to five digits; other quantities have their precisions set accordingly. You can reset it to any number of digits from 1 to 10.
There is also a "Heliocentric only" check-box, off by default. If an object is within a planet's "sphere of influence" (the point where planet-centered osculating orbital elements are a better approximation to the object's motion than heliocentric elements), Find_Orb will usually switch from heliocentric to planet-centered elements. You will usually be perfectly happy with this, but if you really need heliocentric elements for some purpose, you can click on "Heliocentric Only" and elements will then be shown in that manner.
There are also radio buttons to select either "total" or "nuclear" comet magnitudes. This controls the type of magnitude shown in the orbital elements and ephemerides. In each case, only total or nuclear magnitudes from the observations will be considered in computing the absolute magnitude M, and the orbital element display will show M(T) or M(N). (These parameters are also known as M1 and M2. But I can never remember which is which, and assume others may have the same problem.)
There are multiple problems associated with this change. If you've got data with some nuclear magnitudes and no total magnitudes, and tell Guide to use total magnitudes, the orbital elements and ephemerides will show no magnitudes at all. The MPC's optical astrometry format lets you specify a comet magnitude as total or nuclear, but doesn't let you specify a band for it. Observers differ wildly in the validity of their magnitude data, and that's especially true for comet magnitudes; ideally, that data would be weighted, and the weighting for photometry would be separate frow the (existing) weighting for astrometry. But at present: caveat user.
Usually, clicking on "full step" results in a general solution in which all six orbital parameters are adjusted. But under some circumstances, it can be helpful to impose a "constraint" on the orbit. The most common examples are specifying that e=1 (a parabolic orbit) or that the object is at perihelion at the time of observation (a Väisälä orbit.)
It's possible to use Find_Orb to specify much more general constraints. For example, let's say you have loaded data for an object into Find_Orb and have found the value a=4.5 for the semimajor axis. If you're familiar with minor planet groups, you'll know that such a value would be possible, but very unlikely. It's more likely that the object is a Hilda (the next group in, with a=4.2 on its outer edges) or a Jupiter Trojan (the next group out, with a=5.05 on its inner edge.)
You can test the first possibility by clicking on the Settings button, and entering "a=4.2" into the Constraints box. Click OK, and then click on Full Step. Find_Orb will look for an orbit with that semimajor axis. You may have to hit Full Step several times before it converges on an a=4.2 solution, and when it does, you may find that the RMS error grows to an unacceptably high value. If so, the possibility that the object is a Hilda will have to be rejected.
Similarly, you can set "a=5.05" in that edit box and see if that converges, to confirm or dismiss the possibility of a Jupiter Trojan orbit.
You can also set constraints on the eccentricity, perihelion distance, orbital period, and inclination, and even combine constraints, such as:
e=.3 (constrain eccentricity to be .3) e=0 (force a circular orbit) q=1 (force an orbit whose perihelion brushes the earth's orbit) i=15 (force an inclination of 15 degrees) P=248 (force orbital period of 248 years, that of a Plutino) a=5.1,e=0 (combined forcing of a 5.1 AU semimajor axis and circular orbit)
Usually, when you have a very short arc of observations (or a very distant object), you'll find that forcing odd constraints does not necessarily raise the RMS error very much. This simply means that the range of possible values for each parameter is still very large. As more astrometry is gathered, the range drops sharply, meaning that the parameters are better-determined than was once the case. (Try to force an orbit too far from its valid range, and Find_Orb will often fail to converge to a solution.)
It's also possible to constrain the magnitude slope parameters. For comets, this defaults to K=10; for asteroids, to G=.15. However, you can set constraints such as K=18 or G=.12. This isn't necessarily a good idea (it would be better if Find_Orb had the ability to determine K or G from the observed photometry), but one can do it if desired.
Click on the "Filter Obs" button, and Find_Orb will automatically exclude observations with total residuals of worse than one arcsecond, and automatically include all those with total residuals better than one arcsecond. If this doesn't result in any changes, it will report that fact. Otherwise, it will do a "full step". Applying this button a few times will usually result in convergence on a good solution, and automatically rejects outliers.
Some will object, reasonably, that the one-arcsecond limit is sometimes too high (for example, if you're dealing with highly precise observations from Hipparcos or UCAC-2 based or FASTT astrometry), and is sometimes too low (for example, if the data comes from any of the surveys or is old photographically-based astrometry). If you go into the Settings dialog, you'll see a "Max Filtered Residual" option, set to the default of one arcsecond. You can revise this limit as desired.
Determining uncertainties with the Monte Carlo method
So far, Find_Orb has broken 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.
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 uncertainties. Another common method is the "observational Monte Carlo" one, used by John Rogers' CCD Astrometry and by the OrbFit software (OrbFit also supports several other methods of computing uncertainties). Steve Chesley described six different ways of going at the uncertainty problem in an MPML post.
Right now, Find_Orb supports only the "observational Monte Carlo" approach. In this scheme, you take the initial observations and add some Gaussian "noise" to them, and solve for the orbit that fits these slightly-mangled points best. This creates a "virtual asteroid", representing a possible orbit that fits your actual observations passably well. Then you repeat.
Eventually, you have a swarm of "virtual asteroids" that, it's hoped, combine to illustrate the region in which the real asteroid might actually be. That region usually starts out as an ellipse, and when plotted on the sky, the virtual asteroids look like a squashed globular cluster.
As time passes by, the "virtual asteroids" spread out in one direction (usually along the line of variation), and the uncertainty region resembles a long, thin line. The line will develop some kinks and curves over time, especially if part of the line passes close to a planet. Sometimes, virtual asteroids will cluster at one or more points on the line, indicating areas where the object is most likely to be found.
To use this method in Find_Orb, proceed as follows. Solve for the orbit as you normally would. Set the "epoch" to be passably near the time span over which you want to know the positional uncertainty, and click on "Monte Carlo".
Find_Orb will pause while it computes the first virtual asteroid. You'll see the element and residuals display flash with a revised orbit, one with somewhat higher residuals (usually) than you originally had. Then it will flash again and again, as new virtual asteroids are computed. The "Monte Carlo" button will change to count the number of virtual asteroids created thus far. You can click on that button to stop computing virtual asteroids, and click on it again to resume computing them. (You can also switch to other tasks while virtual asteroids are computed in the background.)
As the virtual asteroids are computed, their orbital elements are added to the file mpcorb.dat. This file has the format of the MPC's MPCORB database, which can be read by most desktop planetarium programs.
One key point here: you may well want to set the amount of Gaussian noise added in Monte Carlo computations. If you click on "Settings...", you'll see an option to set the "Monte Carlo noise" level; this defaults to .5 arcseconds. Exactly what this value really ought to be is a matter of some debate, but it ought to reflect the uncertainties in the observations. That is, if you figure they're good to one arcsecond, a noise level of 1 makes sense. I've used the method with older photographic-era measurements good to about four arcseconds, and used a noise level of four, and have used a smaller noise level with more precise astrometry.
Use your planetarium software to display the mpcorb.dat generated by Find_Orb, and you will see a slew of numbered asteroids illustrating the current uncertainty area of the "real" asteroid. (I chose this approach because it meant people could view the uncertainty area in the program of their choice; it also makes it easy to see how that area changes over time.)
Eventually, I want to add in "statistical ranging" and (assuming I'm understanding it properly!) a "semi-linear" method of uncertainty estimation. The first is a better method for short orbital arcs and for handling KBO/Centaur objects where the distance to the target really hasn't been nailed down very well. The second would, I think, allow for faster computation and, perhaps, make it a little easier to show results in tabular form: each entry in an ephemeris might be followed by a numerical positional uncertainty and angle. The current observational Monte Carlo method is wonderful for a graphical approach, though, and is easy to understand and program.
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.
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 (the same one you've set up in Guide). Edit these and click on "Go", and it will generate an ephemeris in the list box. Click on "Save", and you can write the results to a file.
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.
You can also tell Find_Orb to include motion details (how fast the object is moving, in arcminutes per hour, and the position angle at which it is moving) with the "Motion Details" check-box. There is also an "Alt/Az" checkbox which will add that data to the ephemerides. (Of course, the alt/az checkbox doesn't accomplish anything for geocentric ephemerides.)
You can enter a three-character MPC observatory code in the latitude box. Do this, and Find_Orb will ignore the longitude box and just set your position to that of the MPC code. Use an MPC code of 500 to indicate a geocentric position. Use an MPC code of 'v' to get geocentric Cartesian positions. Use an MPC code of 'V' to get geocentric Cartesian positions with velocity (that is, state vectors). Units are AU and AU/day.
Use an MPC code of '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.
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.)
The ephemerides generated with 'v' and 'V' are on the TT (Terrestrial Time) timescale. All other, "normal" ephemerides are on the UTC (Coordinated Universal Time) scale.
Whenever you generate an ephemeris, Find_Orb creates a "pseudo-MPEC" with the filename mpec.htm. This looks a bit like the standard Minor Planet Center MPECs, listing the observations, stations supplying the observations, orbital elements, and ephemerides (with the time span determined by that given in the "Make Ephemeris" dialog.) It differs from the MPC version in that it is heavily linked; you can click on an observation to see its residuals, or on a residual to see its observation, or on a three-character observatory station code to find out which observatory that is, or on the observatory's lat/lon to get a map of that observatory, or (usually) on an observatory name to get that observatory's home page. Click here for some examples.
A few hints to customize/improve the "pseudo-MPECs" you generate:
Getting data about the observations
Click on any observation in the list box at the bottom of the dialog box, and you'll get a few lines of text just below the list box giving data about that observation. Here's an example:
Elong 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,
#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
#coord epoch 0
J96X01X C1997 10 21.03352 00 27 34.62 +02 49 01.9 709
J96X01X C1997 10 21.72050 00 26 37.40 +02 43 00.9 17.3 709
#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. The next two, with "epoch 0", would be assumed to be mean coordinates of date. (Properly speaking, there should be a provision for apparent coordinates of date, which see common use in older publications.) And for the last two, the default epoch would return to J2000.
Note that the coordinates will be read in, then precessed immediately. So the coordinates shown in Guide will be in J2000.
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.
When Find_Orb doesn't find an orbit
In the above examples, Find_Orb converged (eventually) to a solution. This is not always the case, which is why the program can't (yet) just read the MPC observations and spit out an orbit, unattended. Sometimes it will latch on to a solution involving a Warp 10 orbit around Alpha Centauri; sometimes the Herget method collapses toward r1=r2=0 (that is, the object is floating just in front of the telescope).
One way to avoid this is to give Find_Orb a better handle on the actual distance to the object. You can do that by setting R1 and R2 to a better guesstimate, and then clicking on "Herget" a few times. As you have seen, this was absolutely essential for the S/2000 S 11 and Mir cases.
Also, in the case of some comets, I've found it helpful to restrict the output to a cometary orbit. If you've run through a 'full solution' and the eccentricity is pretty close to 1, try clicking on the Settings button and entering "e=1" in the Constraints box. Then do a few more iterations; you'll probably see that the residuals don't change very much. (This is especially important when figuring orbits for SOHO sun-grazing comets. These can give the software a serious headache!)
For non-comets, use of other orbital constraints can be helpful. You might try setting the eccentricity and/or the perihelion distance to a likely-seeming value, for example; if it works, you can then experiment with other nearby values to see if the residuals drop.
Sometimes, if only a few observations are available, you'll get wild orbits that still have small residuals. This just means that the orbit was very poorly determined. The resulting orbit will generally still give decent apparent positions for a few days, even if it does look rather odd. After those few days, you can then observe the target again and get more positions, which may be enough to get a "realistic" orbit.
I've yet to see the program fail completely, though sometimes a little playing with parameters was required before it behaved itself properly and didn't generate "RMS error 345184.9 arcseconds"-like nonsense.
Quite often, you'll find that, while most of the observations "fit" the orbit well, with residuals of under an arcsecond, there are a few observations with suspiciously high residuals, that make you wonder if perhaps that observation was of poor quality. If so, double-click on the observation in question; Find_Orb will re-fit the orbit, with that observation excluded. Double-click on the observation again, and you can toggle it back into consideration.
You can also select multiple observations, then click on the "Toggle Obs" button. All the observations will then be turned on or off.
You should consider the possibility that the observation really is good. Find_Orb follows the classical method of finding an orbit that reduces the "overall" error, as expressed by the sum of the squares of the residuals. In some unusual circumstances, this can cause a perfectly decent observation to have artificially high residuals. For example, if you have a "cluster" of observations and add in one observation from the distant past or future, that distant observation will have anomalously large residuals.
Under no circumstances should high residuals keep you from reporting the astrometric observations in question to the MPC! The people at MPC will be quite capable of deciding whether to ignore a given observation, and (in part because they will have more observations) will be far better equipped to judge which observations are really problem cases.
Setting the weights for observations
Not all observations are created equal. Back in the era of photographic astrometry, results good to a few arcseconds were perfectly okay. In the beginning era of CCD astrometry, results were often good to an arcsecond (still all-too-often the case, I'm afraid... which is a pity; getting much better astrometry isn't necessarily difficult.) People using more modern star catalogues, such as the UCAC-2, Tycho-2, and CMC-14, are routinely getting results good to a tenth of an arcsecond or so.
It makes sense to "weight" the observations accordingly: to ensure that when you're computing an orbit, the better observations have a greater impact on the solution. Until recently, there was no way to do that in Find_Orb. Now, one can set the weight of an observation in three different ways.
(Some MPC or .rwo astrometric records) #Weight .1 (Some more records of lesser quality observations) #Weight 3 (Some more records of really good observations) #default_weight (Go back to the default weighting scheme, using weight.txt)then the first few records will be weighted in the usual manner, using weight.txt. Then some observations will be weighted at a tenth the default amount; then more will be weighted heavily; and then Find_Orb will revert to using default weights.
That's in the ideal world, though. I've not had a chance to implement this feature yet.
Setting precise times 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 have been moving so fast that it would be best to specify the time more precisely, especially for video-based observations.
To work around this, you can put a line of the following sort in front of the observation in question:
#time 2009 Mar 3.1415926535897 #time 2009 3 3 14:15:09.265358 #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.
A warning, though: the double-precision values (64-bit floats) used in Find_Orb have 53 bits of precision. Find_Orb handles times in the Julian Day system, so its precision for current-day events is about 25 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 25 microsecond level.
Speeding Find_Orb up by using JPL DE ephemerides
By default, Find_Orb computes planetary and lunar positions using the PS-1996 and ELP series. These don't require much file space, but they can be quite slow. You'll never notice with most of these examples. But in some cases (very near-earth objects and such), you'll see that Find_Orb takes a long time to do its work. Most of that time is spent in computing planetary positions.
To speed things up, you can switch to use of the JPL DE ephemerides. These are the fundamental ephemerides from which series approximations such as PS-1996, ELP, and VSOP were derived. Use of DE is only marginally more precise (not many people will notice the difference), but frequently a lot faster, especially with longer orbital arcs that require more planetary positions to be computed.
You can learn a bit about JPL DE ephemerides here, and find out how to purchase or download (free) DE data here. (You can also find a DE file on the second Guide 8.0 CD-ROM.) You will then have a file with an extension such as '.200', '.405', or '.406' (corresponding to the DE-200, DE-405, or DE-406 ephemeris). In most cases, you can just put that file in your Find_Orb folder, and the program will automatically detect it and make use of it. The only change you are apt to notice is that the program will run faster.
That automatic detection relies on the file name being one of those given in jpl_eph.txt, which will usually be the case for any JPL ephemeris file you've downloaded or copied from the Willmann-Bell CD or from the second Guide 8.0 disk. However, suppose you've downloaded the source files for a DE ephemeris and built it yourself, giving it a new name. Or suppose you've put the JPL ephemeris file in some other folder, perhaps because some other program is also using it. In such cases, you would edit ENVIRON.DAT and add a line such as
JPL_FILENAME=d:\unix.405
Note: Linux users would instead, or also, add something like:
LINUX_JPL_FILENAME=/cdrom/unix.405
Incidentally, if you wind up solving orbits that run outside the span of the DE file you've provided, Find_Orb will fall back on the PS-1996 and ELP solutions.
C/C++ source code for Find_Orb
You can click here to download the source code for a console-mode version of Find_Orb (about 177 KBytes.) This has been compiled and run successfully on Windows (with the Visual C/C++, OpenWatcom, and MinGW (gcc for Windows) compilers), and on Linux, and Mac OS/X using the GNU gcc compiler. You'll also need to get the source code for basic astronomical computations, also on this site; and you'll have to have downloaded the Windows version at the top of this page, since the DOS and Linux versions use many of the same files for tasks such as computing planetary positions, figuring out which observatory is which, and so on.
If you're compiling for DOS/Windows, the OpenWatcom version is simplest: build the basic astronomical functions library with wmake -f watmake and then use wmake -f watfind.mak to build find_orb.exe. Similarly, with the gcc compiler in Linux or Mac, one can use make -f linlunar.mak and make -f linmake. With the MinGW compiler, one would run make -f lunar.mng, then make -f makefile.mng.
On all platforms, the program uses the curses library, which is either already included with most Linux distributions or easily installed. A simplified (but sufficient) version of the library for the OpenWatcom compiler is provided with find_sou.zip. For Microsoft C/C++ or MinGW, you'll need to get the PDCurses (Public Domain Curses) library, and build it. (Which is easy to do.)
For the Microsoft compiler, build the library of basic functions with nmake lunar.mak. Then run nmake dos_find.mak. You'll then be able to run, say, find_orb example to process the objects in the 'example' file.
Mac version: Eric Christensen did some work to get find_orb to compile on a Mac. The process is essentially that described for Linux. However, if you're running on an older, non-Intel Mac, you must be sure to set up the program to use JPL ephemerides. The default method used for planetary/lunar ephemerides in Find_Orb is byte-order sensitive (at least right now) and won't work on Mac (or other non-Intel-endian machines.) However, it's recommended that you use JPL ephemerides anyway, because it makes the program immensely faster.
Running find_orb: Once built, you can simply run, for example, find_orb example (in DOS) or ./find_orb example in Linux. The objects in the file you've specified will be listed, and you can use the cursor keys to select the object you're interested in. (If there's only one object, it's automatically selected.)
The overall function of the console version is very similar to that of the Windows version; it's just that things are done in text mode instead of graphically. find_orb uses the same underlying functionality as its Windows cousin; only the interface is different. Hit '?' (or any other key not understood by find_orb) and you'll get a list of keyboard commands, straight from the dos_help.txt file.
So why did I bother porting Windows Find_Orb back to a console app? Three reasons. First, the Windows UI code is significantly more difficult to puzzle out. Most of the people who have asked me about source code for orbit determination were interested in math and physics, and not the idiosyncrasies of Bill Gates' OS. Second, the 'console' version made the port to Linux almost trivial. And third... I find that a well-designed console app is (for me) much easier to use than a mouse-based one. (I've known others with this prejudice. The common factor seems to be that we can all type much more rapidly than we can use a mouse.)
At some point, I'll probably post the Windows UI code. But posting source code for Charon will be a higher priority. If you'd like to see the Windows source "as is", e-mail me, and I'll send it out in all its current lack of glory (Windows GUI code is never glorious.)
Non-interactive (batch-processing) mode:
The console version, find_orb, can read in all observations from a file of input astrometry, puzzle out which objects are present, and spit out orbital elements for them. This somewhat experimental feature works as follows. Suppose you have a file of astrometry, astrometry.txt . You would run the following command on the DOS or Linux or Mac command line:
./find_orb astrometry.txt -i
find_orb would process each object, telling you its name and summary data, then finding its orbit. A very basic summary of its semimajor axis, eccentricity, and inclination would be shown on the console. The full elements would be written out in the one-line MPCORB format to the file mpcorb.dat. They would simultaneously be written out in the eight-line MPC format to the file elements.txt.
That's about all there is to it. This is still somewhat experimental, and there's still work to be done: for example, the code just puzzles out the initial solution, and if the arc is very long, it won't go through the sort of process the "Auto-Solve" button uses to get the full arc and to exclude outliers. Still, it's useful if one just has a slew of short-arc data to examine.
Some more things Find_Orb will eventually do
As is always the case, I have a wish list of things I'd like to see Find_Orb do someday:
Cometary orbit. Many comets have orbits with eccentricities that are extremely close to 1, meaning their orbits are highly elongated ellipses (Hale-Bopp, for example) or closely resemble parabolas. Go into the Settings dialog and set the "constraint" of e=1, and Find_Orb will search for a cometary orbit. This can be especially helpful if you have only a few observations to work with; in such cases, telling Find_Orb that the orbit must be parabolic (cometary) makes it much more likely that it will converge to a solution. (This is usually a good idea for a preliminary orbit, where there are few observations. When you find that both a cometary and non-cometary orbit converge, but the non-cometary one has a significantly smaller RMS error, switch to the non-cometary.)
Elongation. The angle Sun-Earth-Target. When close to zero degrees, the object is in conjunction with the sun. When close to 180 degrees, the object is almost exactly opposite the sun. See also phase.
Epoch. In the case of an orbit that includes the effects of perturbing objects, the orbital elements will change slowly with time. Thus, elements eventually become "outdated", and you need to replace them with new elements with an epoch closer to the time of observation. That's why Find_Orb has a small edit box to select the desired epoch, as a Julian day .
Full step. Once you have found a good approximation to an object's orbit using (for example) the Herget method , you can find the "best fit" orbit (the one that best matches all the observations of the object) by taking a few full steps. The "full step" uses a mathematical tool known as the method of least squares.
Herget method. This is one pretty good method for computing an approximate orbit from a set of observations. It works by assuming that two observations (usually the first and last observations) were at known distances, and then working to improve the quality of those distances to decrease the residuals. Eventually, the "steps" in the Herget method lead to a minimum set of residuals, and you have a fair approximation to the object's true orbit. Once that happens, you can switch to taking full steps.
The more mathematically adventurous may be interested in this description of some of the math underlying the method of Herget , with particular emphasis on some of the ways it is both 'simplified' and made more powerful in Find_Orb.
Julian Day. (Not to be confused with the Julian calendar, which is a very different thing!) The Julian Day (JD) system is a means of counting off time as the number of days elapsed since noon, 1 Jan -4713. By simply using the number of days (including fractional days) elapsed from that instant, we avoid the complexities associated with the traditional day/month/year, hour/minute/second system. Also, by putting the starting instant in the distant past, over 6700 years ago, we avoid negative numbers.
Irregular satellite. Natural satellites tend to fall in one of two groups. The first, "regular" sort orbits close to a planet, in the plane of the equator of the planet, in the same direction the planet rotates (a prograde orbit). All known regular satellites have had their rotation tidally locked to their primary, so that (as with the earth's moon) they do not appear to rotate as seen from the primary. The assumption is that they were formed at the same time as the planet.
Irregular satellites, on the other hand, have orbits independent of the equator or rotation of the planet, and can be either prograde or retrograde. They also are quite distant from the primary. All four gas giants have such satellites.
Least squares. The method of least squares is a common mathematical tool, originated by C. F. Gauss sometime around 1800. It starts with the assumption that you have gathered some observations (in our case, of positions of a celestial object) and have a theory, or "model", to describe them (in our case, Newton's laws of motion). The differences between observed and computed values are called residuals; the method of least squares states that the "best" model will find a minimum of the sum of the squares of the residuals. (There's some hedging to account for the fact that some observations will be more precise than others, and an additional assumption that the distribution of errors resembles a normal distribution, also known as a "Gaussian distribution" or, more popularly, a "bell curve".)
Magnitude parameters. The magnitudes of asteroids and comets are predicted using quantities for each object known as "magnitude parameters". These are H and G for asteroids, with G (the "slope parameter") usually left set to .15, and M(T) or M(N) and K for comets. In this situation, K defaults to 10, and one can choose between M(T) (for total magnitudes) or M(N) (for nuclear magnitudes) in the Settings menu. You can also reset the K and G magnitude parameters if you wish, though this is probably not a good idea in general.
MOID. The Minimum Orbit Intersection Distance, or MOID, is the minimum distance between two orbits, neglecting perturbations. It's computed by assuming that two objects (usually the earth and an asteroid or comet) will continue swinging around in their orbits, and looking for the place where the distance between those orbits would be a minimum.
Sometimes, that minimum distance will be so small that it looks as if the two objects will collide, but that's not necessarily the case for two reasons. First, when object A reaches that point, object B will usually be somewhere else. Second, the computation ignores perturbations. So it's a good first estimate as to how close the object can get to you, but it takes a much more detailed analysis to determine if the object is going to hit you. A large MOID usually means the object is no hazard at all; a small one means you should keep an eye on it and find out if it really is a hazard.
Find_Orb shows the MOID not only between the asteroid/comet and the Earth (if it's less than one AU), but also the MOIDs between the object and all planets (if those MOIDs are small enough to be interesting.)
Perturbations. Objects orbiting the Sun would, in theory, trace paths of perfect ellipses, parabolas, or hyperbolas. However, the gravitational forces (a.k.a. perturbations) exerted by all the planets, satellites, and (less significantly) asteroids in the solar system make the actual motion much more complex. Find_Orb has a set of check-boxes that allow you to include (or, by default, not include) the perturbing effects of these objects.
Phase. The angle Sun-Target-Earth. When close to zero degrees, the object is almost fully illuminated by the sun. When close to 180 degrees, the object is about to transit the sun, and is almost totally un-illuminated. See also elongation.
P, Q, R vectors. MPC orbital elements, and the elements shown in Find_Orb, give the P and Q vectors in columns to the right of the 'standard' elements. The vectors are frequently used in computing positions from orbital elements. P is a unit vector giving the direction from the sun's center to the perihelion point of the object's orbit. Q is a unit vector at right angles to P, but in the plane of the object's orbit. R is a unit vector at right angles to both of these (and therefore, at right angles to the plane of the orbit). Thus, Q = R x P, R = P x Q, and P = Q x R, where 'x' is the vector cross-product operation. The benefit of all this is that, if we know the object is at true anomaly v and distance from the primary r, we can say that its position is
r * (P cos v + Q sin v)
'R', the normal vector to the plane of the orbit, is almost never shown, since it does not appear in the above formula.
Residuals. When you attempt to determine an orbit for an object, you will always find some difference between the "observed" positions (measured from a CCD image), and the "computed" positions (computed using the orbit you have determined). These differences are known variously as "observed minus computed", or "O-C", or as "residual errors", or "residuals". Ideally, they should represent the random errors in observation that inevitably happen in the real world.
Retrograde. As viewed from a point far "above" the ecliptic, almost all planets and satellites orbit in a counterclockwise direction, also known as "prograde". A few satellites of the gas giants, however, go in the opposite direction, also known as "retrograde". All of these objects are quite small and faint.
RMS error. "RMS" = "Root mean square"; it's a modified version of the average of the residuals. (To be mathematically precise, it is the square root of the average value of the square of the residuals. If you took the squares of all the residuals, averaged them, and took the square root of the result, you would have the RMS error.) With CCD-based observations measured using Charon, and with an accurate orbit, the RMS error should be about an arcsecond or better. If the errors are much greater than that, you either should continue working on the quality of the orbit, or check to see if there are problems with the observations.
Sphere of Influence. For an object in orbit around a planet, it makes sense to use planet-centric orbital elements. For an object far from any planet, it makes sense to use heliocentric elements. There is an almost spherical region around each planet where planet-centric elements are a better choice: that is, a two-body solution centered on the planet would better represent the object's motion than a two-body solution centered on the sun. That region is the planet's "sphere of influence."
You can override Find_Orb's judgment and insist on only heliocentric orbits; there is a check-box for that.
Danby shows that for a planet of mass Mp at distance R from the sun (of mass Ms), this sphere has radius r where
r = R (Mp/Ms)(2/5)
Following are the radii of the sphere of influence for most of the planets. (For the moon, we have to switch to r=R(Mmoon/Mearth)(2/5), where R is the earth-moon distance. So far, I've yet to see a "real" object within the moon's sphere of influence, and therefore haven't seen Find_Orb generate a selenocentric orbit... though note that one can be generated for the example case 1997 ZZ99.)
Planet r(AU) r(km) Mercury 0.001 112000 Venus 0.004 614000 Earth 0.006 921000 Mars 0.004 575000 Jupiter 0.322 48000000 Saturn 0.365 54300000 Uranus 0.346 51600000 Neptune 0.579 86000000 Pluto 0.022 3300000 Moon 0.00046 69000
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.