Proposed new orbital element format

1: Motivation

I'm currently working on revisions to two pieces of my software, 'astcheck' (similar to the MPC's MPChecker) and integrat (numerically integrates orbital elements to a desired epoch). 'astcheck' can use either MPCORB or the Lowell Observatory ASTORB elements. 'integrat' can use MPCORB or the MPC's CometEls.txt format.

I will also be writing an ephemeris program that has to generate uncertainties. To do that, I need orbital elements with covariances, or at least with variant orbits. The only way I can do that at present is to use the AstDyS/NEODyS' OEF format and data. (Which doesn't include comets or natural satellites. IMCCE does provide comet elements... using yet another format.) I expect that I'll have to compute my own catalogs of orbital elements for asteroids, comets, and natural satellites.

So I have a variety of tools, each of which has to deal with orbital elements in different formats for no particularly good reason. Each format is limited in what it can do. The comet format is the only one suited for parabolic or near-parabolic or hyperbolic orbits. All of them are for heliocentric orbits only (no way to handle objects orbiting planets, except for the MPC natural satellite format) and the epochs have to be on integral days. And only OEF handles sigmas and/or a covariance matrix at all... and even then, only for heliocentric objects with elliptical orbits.

On top of that, my own Find_Orb software spits out orbital elements in something vaguely resembling the MPC's eight-line format. (P and Q vectors are dropped, sigmas are added, q and Q given. Here's an example element set for a satellite of Neptune.) The result is pretty good from the viewpoint of human readability, gives uncertainties, and handles any eccentricity or epoch or central object (including orbiting planetary satellites and asteroids; it looked as if I might be doing some work for the Dawn folks at one point). I expect to stick with it for conveying elements to merely human users. But it's not well-suited for machine readability, and doesn't have a covariance matrix.

Some time ago, Gareth Williams kindly added the ability for MPC to provide orbital elements for about 17 different planetarium programs, including my own, each presumably with its own specific format. This has proved quite useful, but with 50/50 hindsight, I wish we'd just had a common exchange format suitable for all objects, compatible across programs.

I'm also hoping to come up with a format good enough to get widespread acceptance from the community. This is the really challenging bit. I'd like to avoid this problem.

Standards

But I'd settle for a format that could cover the following use cases. Fortunately, I don't think that will be particularly difficult.

1.1 Existing orbital element formats

Format Elliptical? Para/hyperbolic? Non-heliocentric? Non-gravs? Sigmas? Covariances?
MPCORB.DAT (asteroid) Yes No No No No No
MPCORB.DAT (comet) Yes Yes No No No No
MPC 8-line Yes Yes Yes Yes No No
CmtEls.DAT (MPC) Yes Yes No No No No
MPC natural satellites Yes Yes Yes No No No
ASTORB.DAT Yes No No No No No
IMCCE comets Yes Yes No Yes No No
OEF (OrbFit) Yes No No No Yes Yes

Spoiler alert: my current proposed format gets a 'yes' for the first four categories. For well-determined orbits, I'm weaseling my way around the sigmas issue by storing a one-sigma variant orbit; in such cases, the difference between the nominal and one-sigma-variant orbits gives you your sigmas. I'm further weaseling my way around covariances by saying that instead of storing an explicit 6x6 (or larger, if non-gravs are included) matrix, one can store the nominal orbit and six (or more) variant orbits, with the variants corresponding to one-sigma variations along the eigenvectors of the covariance matrix. In some ways, that would actually be easier to use.

For shorter arcs, where the covariance may be undefined and/or meaningless, one could store a bunch of variant (statistical ranging) orbits.

Of course, one could similarly "store covariances" or variant orbits with any of the above formats. In the remaining categories -- the ability to store orbits of all kinds, not just elliptical heliocentric orbits without non-gravitational parameters -- the advantages of the proposed format are undisputable.

2: Design goals

The new format should :

• Be able to handle any object. That is to say, unusual eccentricities or orbiting unusual objects should be possible. Storing either comet, asteroid, or artsat magnitude parameters should be supported.

• Be able to handle non-heliocentric elements. These should include, at the very least, objects orbiting centered on the planets, their satellites, and asteroids and comets. (For example, the orbit of Dawn around Ceres or Vesta, or of Rosetta around 67P.) Also, of course, the solar system barycenter, and possibly planetary barycenters (for example, the irregular satellites of the gas giants are best represented as orbiting barycenters.)

Conceivably, orbits around other stars (exoplanets, double stars) could be handled as well. I'm open to the idea, anyway.

• Be able to store uncertainties and/or covariance matrices, if available. (So far, that appears to mean OEF elements and Find_Orb elements.)

• Store the metadata given with the existing formats. For example : references, number of observations used, observed arcs, U values, etc.

• Be extensible. If the Lowell folks want to store the sort of "current ephemeris uncertainty" data they currently generate, for example, or if MPC wants to continue storing a code indicating which perturbers were used, they should be able to do so. Ideally, this would allow one to round-trip MPCORB or ASTORB or similar data to this new format and back.

• Be able to include non-gravitational parameters. These would be (at least) comet-style A1, A2, and/or A3, with these being either truly cometlike (Marsden-Sekanina model) or just solar radiation pressure type. One should also be able to specify Yarkovsky and/or YORP parameters. And/or the "dT" parameter sometimes added to A1, A2, A3.

• Allow one to specify a reference system. Most elements will be J2000 or ICRF, ecliptic or equatorial (default will be assumed to be ecliptic). Artsat orbits are frequently referenced to the earth's true or mean equator, and inner planetary satellites are often referenced to their planet's equators.

• There should be a standard way to specify the physical model used: which planetary ephemeris was used, which planets, etc. The "etc." does get to be a bit daunting. My own code includes general relativity (but only from the sun), asteroid perturbers (up to 300 of them), non-spherical body effects for the earth and other planets, and atmospheric drag for the earth. The presence of non-zero non-gravitational parameters should be enough to indicate that those forces are included.

I'd suggest not getting too specific. MPCORB tells you which planets and asteroids were used, if any, and which DE version was used. I'd at least want flags to indicate if GR and non-spherical body effects were included, even though neither of those is really a binary situation. (Do you include J2? A few other zonal terms? A full spherical harmonic expansion? Which one, and to what order? I include a full Earth gravitational model, but the number of terms used drops off with increasing distance. In what cases in your code do you treat the earth and moon, or Jupiter and Galileans, as distinct objects?)

• There should be some passably standard way of being able to say "this is a Vaisala orbit" or "this is constrained to e=0" or "this is a full six-parameter fit to the data". Or "this is a one-sigma variant orbit", or "an orbital (or observational) Monte Carlo clone". Or "a statistical ranging clone". (Or "these are proper elements, not osculating ones". In which case we have additional parameters to store...)

• Handle non-integer epochs. Not all elements are given with the epoch neatly on an integer date, especially artificial satellite ones. Also, I got a request a while back, I think when 2012 DA14 did its close flyby, for elements at several epochs near the flyby, for use in a telescope control program that could only do an heliocentric two-body solution. The program in question just took the element set closest to a desired time, with a small enough spacing so that the earth's perturbations wouldn't cause too much trouble in the interim. Which leads to...

• Allow one to specify "use between" dates. For example, one might have elements for Voyager 2 to be used between the earth-Jupiter leg; another element set to be used during the Jupiter flyby; another between Jupiter and Saturn... you get the idea: a "patched conic" approach. Incidentally, after the Neptune flyby, Voyager 2 had an heliocentric eccentricity of 6.28. Another reason to support seemingly impossible cases. (Eccentricities in the thousands relative to planets are common for asteroid flybys.)

This is also helpful with an artsat where you have one set of elements from before a maneuver was made, and another set after the maneuver was made. (E.g., ExoMars, for which we have elliptical geocentric elements from the parking orbit, plus heliocentric elements from after it left that orbit to head out for Mars.) And comets do strange things, such that it's often best to say: "Here are elements fitted to observations at apparitions A, B, and C; here's a different set fitted to D, E, and F, after the comet did something really weird in between."

• Some "housekeeping" data : I always store elements with the date/time they were computed and the version of the software that made them, and I'd recommend that be a standard practice.

3: Possible issues

• The need to handle any orbit, including parabolic and hyperbolic ones, means we'd work in terms of periapsis distance and time of periapsis (instead of in terms of major axis and mean anomaly). Shouldn't be a real problem, though; for elliptical orbits, it's easy enough to convert q and Tp to mean anomaly/major axis form.

• Slightly more complicated to handle is the distinction between cometary/Keplerian orbits (angles are expressed as inclination, omega, Omega, mean anomaly) and equinoctial elements (h, k, p, q). The latter are used in OEF, and do a nice job of avoiding mathematical singularities. You don't have to worry about discontinuities when the inclination or eccentricity are nearly zero. (Again, though, it's an easy enough conversion.)

• Things get trickier, though, with covariances and sigmas. I'm currently punting on this, as described below. But we may eventually want a "standard" covariance form. Matt Holman suggested covariances in state vector form. My only problem with that is that covariances in equinoctial elements make looking for linkages a lot easier. (Under no circumstances should covariances involving discontinuous/singular quantities, such as semimajor axis, inclination, ascending node, mean anomaly, etc. be used. Just Say No to divide-by-zero errors!)

• OEF provides eigenvectors and eigenvalues, which I think is a nice touch. If you want to look along the line of variation or generate orbital Monte Carlo variants, you're good to go. This does have the same issue as the above (i.e., which quantities are we looking at?).

• I mentioned having multiple element sets for "patched conic" orbits, but there are other situations where a single object might have more than one set of elements. In particular, how do we handle statistical/stochastic ranging and Monte Carlo, where the "orbit" is really described as a collection of orbits? (Perhaps not a big problem. I may simply provide a bazillion orbits for the same object in some cases, with an 'orbit type' column indicating if the orbit is a nominal one, e-assumed, or a statistical ranging or MC variant orbit.)

• I assume somebody is going to argue in favor of XML, now that we're going to be using it for the new astrometry format. As shown above, I would argue instead for something that is at least vaguely human-readable, and for that to be the only option (none of this business of "we have PSV and XML as equal citizens"). Make one choice and stick to it (and ideally, make that choice a readable/editable format, i.e., not XML). I am glumly prepared for the likelihood of losing that argument, though. If so, I reserve the right to disavow having proposed this idea...

4: My current plan

As described in the 'motivation' section, this has become a pressing issue for me. I've software on which I cannot move forward until I have a way of storing asteroid, comet, and planetary and natural satellite elements in a common format, with uncertainties. So I'll proceed on my own, with hopes it'll result in something useful for the rest of the world. Unfortunately, due to "mission focus", I'm going to ignore some things that a more complete solution should consider.

The simplest way to explain what I'll be doing is probably with an example, showing elements for 2008 RA146, C/2015 V3, XT921943 (an object on NEOCP at the time I wrote this), and S510923 (a recently-found artificial satellite in high earth orbit).

C |Name        |Tp      .       |Te      |q         |i  .      |Om .      |om .      |e         |n_u  |n_o  |rms. |Tfirst     |Tlast      |H . |G  ^
        K08RE6A 20130917.6816829 20150124 2.64460102  12.073006 348.995362  33.654403 0.07317995    26    26   0.2 20080904.41 20150124.38 17.0 0.15
       CK15V030 20151124.7625892 20160816 4.23557363  86.231723   2.340841   0.805102 0.99490148    93    98   0.9 20151102.27 20160810.03 10.7 10.0
        XT92194 20161211.3351536 20161010 1.09902248  16.554061 188.229039 236.267507 0.23331548    26    26   0.3 20161006.23 20161010.06 22.5 0.15
 3      S510923 20161002.1031180 20161002 0.00083484  15.018367 351.954150 325.717825 0.03212643    28    28   6.6 20160401.36 20161002.92 31.0 0.15

• Elements will be stored in a PSV-like manner. The first line will be a "header" line specifying what data will be given and how many bytes are allocated for that data. (For example, I knew my epochs would all be integer days, so I only allowed eight bytes for Te; I didn't expect more than 99999 observations of an object, so n_u and n_o are five-byte fields, etc..) The fields in the header can include decimal points to indicate alignment (as the angular fields i, Om, om do). Dates are all in YYYYMMDD.DDDD... form.

• At bare minimum, the name, Tp, q, i, Om, om, and e fields have to be filled for each object. That's enough to specify the orbital elements for an heliocentric orbit computed without perturbers and without magnitude parameters. I don't think such elements will actually happen very often, but if they did, you could store them with only these required fields.

In the above example, the data are, in order:

Columns can be added/removed rather freely. I don't expect that first 'central object' column to exist for files of comets/asteroids; those orbits will be assumed to all be heliocentric. Comets would include total and nuclear absolute magnitudes and slope parameters, and (sometimes) non-grav A1, A2, A3 data. Artsats would usually have a column for area/mass ratios.

Records will be fixed-length, with the length determined by the header line. Column widths and the default placement of decimal points are specified with the header line, too (I could have added/reduced precision of any output item just by increasing/decreasing the column size).

While it will be possible to do so, I wouldn't normally mix-and-match objects as I've done in the above example. I expect to have (as MPC does) a file of elements of numbered objects, another for unnumbered asteroids, one for comets, and one for natural satellites, each with appropriate columns. I'll also have one for NEOCP objects. For each of these, there will also be a file containing one-sigma variant orbits for objects for which such orbits can be determined.

• All dates are written in YYYYMMDD.DDDD... form. Tp and epoch are in TDT. The dates of first/last observation will be in UTC... which, I realize, means getting into the absurdity which is the leap second problem. For the nonce, at least, I intend to do what I think everyone else does: hope nobody observes anything at 23:59:60 UTC. (I'd use MJD for much of this, saving three bytes per date and simplifying processing. But people did observe objects long before MJD 0 = 1858 Nov 17.) Other dates which might be stored, still in YYYYMMDD.DDD... format, would be the date/time the orbits were computed and the range of valid dates for the orbit.

• Distances (q and, optionally, a and Q) are in AU. As mentioned above, to avoid loss of precision, the last character in the distance field might be an m, u, n, p, to indicate milliAU, microAU, nanoAU, or picoAU, needed for close-in planetary satellites (Phobos has q=0.000063 AU, for example).

• Elements default to being heliocentric ecliptic J2000. The 'C' column lets one specify non-heliocentric orbits. "Obvious" values we'd need would be for the solar system barycenter, 1-9 for Mercury through Pluto-centric orbits, and other codes for orbiting planet barycenters, planetary satellites (I've computed some lunar flyby orbits, including an impactor one for LCROSS), and probably orbits around asteroids; it might be nice to support elements for binary asteroids. I have no immediate need or plans to do this, but a 'Frame' column could let one specify equatorial elements of date, or body-plane elements, and an 'ElEp' column could allow one to specify epochs other than J2000.

• I'm punting on sigmas and covariances. My workaround is that I will create two files of orbital elements: nominal ones, and a one-sigma "variant" orbit. An 'orbit type' column could indicate a full least-squares fit, or an N-sigma variant, or that the orbital elements are for a Monte Carlo clone or for a statistical or stochastic ranging orbit... but for my own needs right now, just having two files, one with nominal orbits and one with one-sigma variants, will do nicely. (It was the realization that I could do quite nicely with a one-sigma variant orbit, rather than needing a covariance matrix, which allowed me to use this simplified method. I still think we'll need covariances, but they introduce some issues I didn't want to have to worry about just now.) Obviously, whatever covariance data we store would just be more columns.

The sigmas on orbital elements are, implicitly, the differences between the nominal and one-sigma variant orbits.

• I may borrow from IAU2015 a bit so that values constant for all elements could be rendered as a header :

# epoch
! 2457600.5
# G
! 0.15
# Computed
20161113.314
# Computer
E. Jones
# Software
MegaOrbitron 3.4
ObjName|Tp             |H .  |arg peri  |asc node  |incl      |ecc      |q         ^
Larry   20131214.456001 13.34  72.814715  80.314279  20.591701 0.0757051 2.531415926
Moe     20170103.415492 24.13 309.999207 173.087830  34.841162 0.3308349 2.141421358
Curly   20150731.092175  5.33 248.236781 169.862991   2.990102 0.2566013 2.018830831
Shemp   20140222.314159  8.33 265.358979 326.846264  33.287141 0.7142853 0.931732050

In this (made-up) example, all elements are for the same epoch, with the same slope value, computed at roughly the same time, by the same person, using the same software. After that, everything is a fixed-length record; once you've read the header line, you know where all the remaining records will be. I'm in no rush to implement this, though.

5: Two examples (natural satellites, asteroids/comets)

Click here for orbital elements of natural satellites, or here for elements for a mix of asteroids and comets. The natural satellite orbits were automatically generated by the non-interactive version of Find_Orb, using natural satellite astrometry provided by MPC as input. In addition to the columns mentioned above, the natural satellite file has a 'Twritten' column.

The natural satellite orbits should all be good. Comets will need some work, with some being replaced with elements that have non-gravs included.