Fitting in different orbital parameter sets

[semaphoreP]

The standard a,e,i,omega,Omega,mtot orbital parameter set is not the most optical to sample in because it has complex covariances. I just thought of one way to implement different sets of orbital parameters and wanted to jot it down.

• Keep our default set of a,e,i,omega,Omega,mtot. We can solve Kepler's equation with them
• Have a second set of orbital elements that we are fitting for. This will be the elements that the priors correspond to.
• Have a function, that given orbital elements of the second set, it will translate to the first set. This way, the sampler will know only about the second set to sample in, while the system class can still work in the first set to keep most of the code the same.

[henry-ngo]

So the end user will only be interacting with this second set of orbital elements? I guess there may be more than one preferred set of orbital elements and each person might prefer different ones, which means we might end up writing many different conversion functions? This is fine---just thinking out loud.

[semaphoreP]

That's a good question I haven't fully considered. I think basically each orbital element set will have a function to translates to/from a,e,i,omega,Omega,mtot. We can then always get from one orbital element set to another in two transformations. Basically I would imagine an orbital element class.

[henry-ngo]

That sounds like a good solution!

[sblunt]

This sounds good to me too. radvel handles this basically the same way, although they have an extra feature that allows you to specify your input basis and your fitting basis. I think we can probably finagle our code so that you just need to specify how the input basis transforms to the orbit-solver basis, and we can handle making sure we fit in the input basis as well.

[semaphoreP]

A good orbital element set could be x,y,r,vx,vy,vr where r = sqrt(x^2 + y^2 +z^2). This way, x,y,vx,vy would be well constrained by the astrometry. For circular orbits, vr = 0, and r~a. In this basis we would have just 1-2 free parameters that are relatively unconstrained rather than 6. This would be good for doing quick leastsq optimization to find a well fitting orbit for starting MCMC or OFTI.

[sblunt]

We also like to add an option to fit in sma/period rather than sma/mtot. This would be useful for shorter-period orbits, including those that have stellar astrometry/radial velocity measurements.

[sblunt]

Addressed in PR #249!!!

[sblunt]

Pulled into main in PR #270