Explanation of Find_Orb ephemeris details
Explanation of Find_Orb ephemeris details Observations : The observations can be in the MPC 80-column format and/or ADES format in XML and/or PSV form, and/or in the AstDyS/NEODys .rwo format. You can mix-and-match among these formats, which can be helpful if you have data from multiple sources. Click here for specifics about the format of the astrometry you can use in this and other tools on this site.
Anything that isn't an observation or an observer detail will simply be disregarded. The current limit is about 5000 observations.
Object name: Enter an object name here, and Find_Orb will get astrometry for it from the Minor Planet Center. This can be in addition to any observations cut-and-pasted to the text box or provided in an uploaded file.
Epoch of orbital elements: By default, you'll get a "reasonable" epoch (one that's within a day of the time of the last observation). But you can set it to a desired date/time, using any of the formats used in specifying the starting date for the ephemerides.
Residual format: MPC usually gives residuals to a precision of 0.1 arcsecond. By default, this software usually provides another digit of precision. Every now and then, for testing purposes, it can be useful to have a third digit. (It's rare to actually find data good to a milliarcsecond; this is mostly used to allow comparison of results with those from other programs.)
It can also be useful to see the residuals as expressed in "along-track" difference in time (i.e., "the object would have been here 23 seconds earlier") and in "cross-track" difference (i.e., "the object missed the predicted point at that time by 0.23 arcseconds"). This can help in diagnosing timing errors of the sort that often occur with nearby, very fast moving objects.
Redact NEOCP astrometry:
By default, all astrometry is shown in the resulting page.
If you're planning on re-distributing the page, though, you should
check this box. That will cause NEOCP astrometry
to be shown "redacted" (blacked out, like this
I^P[#ldH6g*/]?\x%, with an explanation
that one should look on the NEOCP for the data).
The reason is that MPC frowns on redistribution of NEOCP data; the data is considered to be preliminary, not fully checked, and solely for personal use. (A few observers have given the "green light" for redistribution; their data is never redacted, even if it came from NEOCP and you've checked this "redact" box.)
If you do not intend to redistribute the astrometry (i.e., don't intend to post the pseudo-MPEC on your blog or Web site or what-have-you), you can leave this box unchecked, and NEOCP data will be shown unredacted.
Ephemeris starting date : This is quite flexible. 'now' is the default, but one can provide dates such as '2014 dec 25', 'Feb-13 3:00', '2015/2/13 03:14:15.9', and it will be interpreted properly. (Note that one shouldn't get too sloppy; '2015-5-6' could be either May 6 or June 5, and '05-06-07' could be interpreted as a (two-digit) year, month, and day in any of six orders, probably but not definitely in the 21st century. Caveat user. I usually go with a four-digit year and three-character month; "2015 Feb 18" is unambiguous, no matter how you scramble the pieces. But essentially, if a human can figure it out, this program should be able to.)
Input such as 'MJD 12345.6', 'jd 2451545', 'now+3h', and 'Wed 3:14:16 PM' will also work; click here for the full list of time input options.
Step size: This defaults to being in days, but input such as '2h' will lead to a two-hour ephemeris step size, or '10m' for a ten-minute step size. One can use '.1' to get a step size of a tenth of a day, and so forth. Negative step sizes will result in a backwards-running ephemeris.
MPC code or latitude/longitude: This defaults to 500, for a geocentric ephemeris. But it can be any of nearly 2000 three-character observatory codes assigned by the MPC. As an extension, you can use "codes" Sun for the Sun, Mer for Mercury, ... Plu for Pluto, and Lun for the Earth's Moon.
Also, you can enter lat/lon values in any of the following formats :
w69.9,n44.01 N44.01 W 69.9
...that is to say, latitude and longitude in either order, separated by either a comma or a space, in decimal degrees.
Faint limit: This defaults to 99, meaning that output will be suppressed if the object would be fainter than magnitude 99. (Which does sometimes happen, if the object passes between the earth and the sun. But it's rare. You might reset this to your own observable magnitude limit, so as to get only the ephemerides that are really practical for you.)
Ephemeris type: By default, one gets "observable" quantities: RA/dec, magnitude, elongation, and so on. But you can request tables of state vectors, Cartesian coordinates, orbital elements in either the MPC's MPCORB format or the more verbose "eight-line" format; or you can get a list of close approaches to the observer over the ephemeris span.
For close approach tables, it's a good idea to pick the geocenter or another planet or moon's center. Topocentric close approach tables usually look like garbage, due to the daily distance variation as the earth rotates.
Alt/Az: Causes the altitude and azimuth of the object to be given in the ephemerides. Obviously, if you do this for a geocentric viewpoint or a planet-centered or moon-centered or heliocentric viewpoint, this will be disregarded.
Radial velocity: Causes the radial velocity, in km/second, to be given in the ephemerides.
Visibility indicator: For topocentric ephemerides, this gives a two-character indication of how "visible" the object is. The letters used are :
* Daytime (sun above horizon)
C Civil twilight (sun below horizon, but by less than 6 degrees)
N Nautical twilight (-12 < sun's altitude < -6 degrees)
A Astronomical twilight (-18 < sun's altitude < -12 degrees)
(none of the above) Full nighttime; sun below -18 alt
m Moon is in the sky, less than 50% illuminated
M Moon is in the sky, more than 50% illuminated
l Object transiting in front of moon
L Object occulted by moon
a Below altitude/horizon limits set for the observing site
d Outside declination limits for your site/mount
e Outside elongation limits for your site/mount
h Outside hour angle limits for your site/mount
g Some galactic confusion
G Lots of galactic confusion
B Object is below the horizon
The idea for this indicator was shamelessly lifted from the JPL Horizons ephemeris system, with many modifications.
Suppress unobservables: For topocentric ephemerides, this will cause output to be suppressed if the object is below the horizon or it's full daylight at the time. That is to say, if you couldn't actually observe the object at that time from that place, it won't get mentioned in the ephemerides.
For (251) Arecibo and (253) Goldstone, the daylight part is ignored. Radar guys don't care about such things. However, the object must be within 19.5 degrees of the zenith at Arecibo, or 70 degrees at Goldstone.
Motion: Causes the apparent motion of the object, in arcminutes/hour (or, equivalently, arcseconds/minute) to be given in the ephemerides.
Element center: By default, the program will automatically select a "reasonable" center for orbital elements. If the object orbits the sun, you get heliocentric elements; for an earth-orbiting artificial satellite, you get a geocentric orbit, and so on. However, you can override the default choice of an element center. In particular, barycentric elements are sometimes the desired choice for distant solar system objects.
Phase angle bisector (PAB): The PAB is a quantity sometimes of interest to those doing light curves: it gives the ecliptic latitude and longitude of the point midway between the observer-target and the sun-target vectors.
Ground track: Gives the latitude and longitude of the point on the earth's surface where the object is at the zenith. This is sometimes useful with objects coming close to the earth or impacting the earth.
Computer-friendly ephems: The ephemerides should be more easily amenable to parsing by computers. For example, the date/time will be given as a JD, the RA/dec will be given in decimal degrees instead of in Babylonian base-60 form, distances will uniformly be given in AU (instead of switching to kilometers for smaller distances), and so on.
Note that the current system is doubtless not bulletproof. In particular, to avoid the possibility of the program locking up and needing to be killed, I've set it to time out after five seconds. Give it a long enough arc of observations, and it'll give up, exit somewhat gracelessly, and you won't get a result.
Language: This is a work in progress. Some text (currently not much; month names and a few phrases) will be shown in the selected language; everything else will remain in English. If you've an interest in adding a language or completing an existing one, please let me know. (It's quite straightforward to do it, except that like most Americans, I really only know one language!)
Sky brightness: Background sky brightness from the sun, moon, and airglow, in magnitudes/arcsec^2. The model is from Bradley E. Schaefer, Sky & Telescope, May 1998, pages 57-60. Source code, with comments and references that may be useful, is available.
Galactic confusion: A number from zero to 99 will be shown, 0=nowhere near a dense star field, 99=core of a very dense star field. This is based on the number of Gaia-DR2 stars in the area. I'm awaiting feedback as to just how much trouble a 'confusion factor' of, say, 30 will cause for observing a given object. (Some observers just don't observe below a given galactic latitude, but the real area within which things get too confused is more complicated than that. It also includes areas around globulars and the Magellanic Clouds; the confusion factor computed in this software will include those areas.)
PsAng is applied mostly to comets : it is the position angle at which an observer would see an ionized gas tail, if that tail pointed exactly away from the sun (i.e., if the gas was found exactly along a ray going out the comet opposite the sun). See the related 'PsAMV' value below.
PsAMV is applied mostly to comets : it is the position angle at which an observer would see a dust tail, if that tail pointed back along the object's orbit. Heavier dust particles will essentially do this; they will come off the comet and go into a very slightly higher orbit, and gradually fall behind the comet and spread out along the orbit. Actual mid-size particles will be found somewhere between this angle and the one specified by 'PsAng' (described above), the theoretical angle at which an ionized gas trail would be seen.
PlAng is the angle between the observer and the target's orbital plane, as measured from the target. If it is positive, you are looking at the object from above the ecliptic. This quantity can be useful with comets.
Constellation will show you the three-letter abbreviation for the official IAU constellation corresponding to that point.
SNR: For topocentric sites, Find_Orb will attempt to compute the signal/noise ratio you could expect for that target at that site. It has a decent knowledge of telescope diameters (mostly scraped from MPECs) and the sky brightness model is decent, but this should be considered mostly a rough indicator of what to expect. The basic theory of how SNR and exposure times are computed is described here (documentation of how it's done for the Lowell Discovery Telescope). I basically just implemented this, aside from a somewhat more sophisticated sky brightness model.
Exposure time, like SNR (see preceding paragraph), is computed for topocentric sites.
Output: By default, you get a 'traditional' HTML pseudo-MPEC, resembling the MPC's MPECs. You can, however, get various JSON files instead.
• At first, feed all the observations to the form and click "compute orbit". This will almost always work. If it does, that's your orbit; unless some observations have unusually large residuals, there is no real point in then running a solution using a subset of your observational data. (If you get a strange orbit, perhaps not including all the observations, then you might try a subset of your data. But this is very rarely required.)
• This page will work for almost all ordinary situations. But if some of your astrometry is a bit poor, or if the length of the observation is more than about a decade, the program may not get an orbit. (It will devote about 15 seconds of processing time, then give up.) Some situations still call for some human interaction to get the program to look in the right place for an orbit. If that happens to you, I'd suggest that you use the Find_Orb software (on which this service is based). It offers many more options, such as the ability to constrain the orbit (say, tell it that the orbit is parabolic), handle non-gravitational parameters, get orbital elements for objects not orbiting the sun, and so on and so forth. Or you can contact me, send me the astrometry, and I'll offer an opinion.
• 2020 May 06: You can now specify, instead of the default HTML output, various JSON outputs. Also, there's a new 'galactic confusion' quantity available in ephemerides.
• 2019 Sep 15: Added comments on how to solve for orbits for interstellar objects.
• 2018 Jun 16: You can supply data in ADES format in XML and/or PSV form. (Previously, all data had to be in the "traditional" MPC 80-column format.) You can mix ADES and 80-column data. Click here for specifics about the format of the astrometry you can use in this and other tools on this site.
• You can feed astrometry for 1I/ʻOumuamua and get a correct orbit, complete with sigmas.
• 2017 Dec 2: You can specify the name of any object, on NEOCP or otherwise, in the above 'object name' box. Find_Orb will grab the astrometry for that object from MPC.
• 2017 Jan 29: Added a form for getting customized ephemerides for an NEOCP object (since extended to work for all objects). Useful if you're interested in such an object and don't have astrometry to add to the solution.
Also, if you're frequently generating ephemerides for a specific place and/or time span and/or number of steps and/or object, you can specify those parameters on the URL. For example,
http://www.projectpluto.com/fo.htm?obj_name=Phreddo&mpc_code=J95&epoch=-11&year=2017 jan 19&n_steps=13&stepsize=10m
would cause astrometry to be retrieved for the NEOCP object Phreddo; ephemerides would be (J95)-centric; the epoch for the orbital elements would be 11 days ago; ephemerides would start on 2017 January 19, for thirteen steps of ten minutes.
Create a bookmark containing the bits and pieces of the above URL that actually matter to you (usually your MPC code, number of ephemeris steps, and ephemeris step size), and you can go to that URL and already have those fields set. (Alternatively, this could be set via cookies. I may eventually offer that option.)
• 2016 Nov 4: In addition to being able to cut/paste astrometry, or specify a file to be uploaded, one can enter an object name. This can be an NEOCP designation, or an asteroid name such as "Eros", or a number (for numbered asteroids), or a comet designation such as "C/2017 U4", or an asteroid designation such as "2009 SJ209".
In this regard, be advised: my server gets "fresh" NEOCP data once every 15 minutes, in the course of updating my on-line summary of current NEOCP objects. So really recent NEOCP data may not show up via this new method.
As per the above note, astrometry can be provided via one, two, or three of these methods.
By default, Find_Orb is strongly inclined to get non-interstellar orbits. The reason is that about 99.9% of the time, such an orbit will be wrong, and can mislead you into thinking you've got a much more exciting object than you really do. Such orbits usually mean you don't have enough data, or that some of the observations are wrong.
However, we now know of two objects that really are on interstellar orbits. If you give Find_Orb data for ʻOumuamua or 2I = C/2019 Q4 (Borisov), Find_Orb will notice the 'I' designation and recognize that interstellar orbits should be considered, and it'll get a correct answer. (Though unfortunately, it'll be one that doesn't include non-gravitational effects. For that, you'll have to download the interactive Find_Orb software, run it, load the astrometry, and turn on non-gravs. This is true for all comets, by the way.)
Alternatively, if you've got astrometry for an object that doesn't have an interstellar 'I' designation, you can either mangle the designation to be interstellar; or (more reasonably, in my opinion) insert the following line before the astrometry :
COM interstellar
Do this, and Find_Orb will consider interstellar orbits and get the right answer.
Note that if you feed this page data for an interstellar object, but it does not have an interstellar designation or the COM interstellar line, Find_Orb will search valiantly for a non-interstellar orbit. It will find one, but the fit to the observations will be terrible. Which is how we figured out that these two objects were interstellar: no "normal" orbit would fit.
Note that I have a pseudo-MPEC posted for ʻOumuamua, with other comments about this unusual object, as well as similar information for C/2019 Q4 (Borisov).
I can be reached at pôç.ötulpťcéjôřp@otúlm. If you're a human instead of a spambot, you can probably figure out how to remove the diacritical marks...