Inquiry about new orbit format

[Bill-Gray]

Hi folks,

As you may (or probably don't) know, I've been attempting to get discussion going about a new orbit format for about four years. At the time I wrote that page, I hadn't used JSON for anything. Having done so since then, I'm basically sold on what you're doing here. In particular, I think your format handles uncertainties better, and JSON is obviously better suited to the Python crowd. (I should note that my modest proposal met with complete silence, so I can't claim popular support for it.)

My first questions would be : are you thinking of this as something built for MPC needs only, or something that could have more general use? With ADES, there was some input from others in the community; is that possible here?

I would understand a desire to develop it within MPC without back-seat drivers intervening, but I'd hate to lose the opportunity to have a format for orbital element exchange for the entire community.

On the chance that some commentary might be welcome, or at least read :

• Yarkovsky is a special case where only A2 is fitted and the force model is 1/r^2. Solar radiation pressure is similarly a special case where only A1 is fitted and the force model is 1/r^2. I would advocate that the available parameters be A1, A2, A3, and DT, with the radial force model being 1/r^2, Marsden-Sekanina, with possible other force model choices (I know some folks are working on comet models for different ices, for example). For 1I/`Oumuamua and 2009 BD, orbits were fitted for A1 and A2 and a 1/r^2 force. For artificial satellites, I routinely fit A1, A2, and A3 with a 1/r^2 force.
• It looks as if you can have any orbit you want, as long as it's heliocentric. A way to specify the object center (solar system barycenter, a planet, possibly the moon) would be welcome. MPC publishes natural satellite orbits and sometimes must handle artsats, so this might serve your needs as well.
• Some orbits are fitted using a debiasing model (FCCT14, ECFF18, and there's an older one whose name I can't find). A flag to specify how debiasing was done, or if it was done, would be good.
• Some comet orbits have been fitted with more than five non-grav parameters. I couldn't say, offhand, just how many we might end up with in the future. But having the covariance indices be two digits instead of one ought to future-proof us nicely.
• An instance where this may be useful, even without exotic force models with five or more added parameters : when Find_Orb computes a covariance matrix, the matrix is first computed in q, e, Tp, i, Omega, and omega. The matrix is then extended to include Q, 1/a, and M (look for "Covariance in 'traditional' elements). The result is, of course, degenerate (unless you delete three columns and rows), but it's really useful to have this so I can show the uncertainties in those added quantities. If this case involved two non-grav parameters, the resulting covariance matrix would be 11x11, and couldn't fit your current scheme.
• You will see that I also output the eigenvectors of the covariance matrix, as well as the eigenvalues. These are very useful in computing variant orbits.

[matthewjohnpayne]

Bill,

Thanks for your comments.

To give an immediate reply to some of your questions:

• "are you thinking of this as something built for MPC needs only, or something that could have more general use?"

  • As per the README, "...we emphasize that the mpc_orb.json format is intended for the generic exchange of orbit data from any source."

• "With ADES, there was some input from others in the community; is that possible here?"

  • Thus far, we have not found any way of stopping the community from providing feedback on any given topic :-)
  • But more seriously, I am definitely open to incorporating some feedback (and have in fact already solicited community feedback specifically w.r.t. this mpc-orb.json format), but I am not interested in turning this into a long drawn out process.
  • So I am happy to try and incorporate some/all of your suggestions where possible.

• "On the chance that some commentary might be welcome..."

  • Many of your suggestions are already on my to-do list, so I'm very happy to incorporate them.
  • I'm going to copy/forward these suggestions into Jira (i'll add you to the Jira Issue) and then use them to set-up development tasks as appropriate: I'm happy to collect suggestions from you in github, but the MPC's workflow is based around Jira, so I need to organize things in there.
  • I'll get back to you if I have any questions that I need to clarify.

M