Hyperbolic EquinoctialOrbit


I’m wondering what the justification is for excluding hyperbolic EquinoctialOrbit definitions.

Nothing jumps out at me as “problematic” from the equations of motion, conversion between orbit representations, analytic propagation (shiftedBy), etc.

I can see why we would exclude perfectly parabolic trajectories (i.e., a → infinity), and this would be a problem in the constructor that takes a TimeStampedPVCoordinates; i.e.,

public EquinoctialOrbit(final TimeStampedPVCoordinates pvCoordinates,
                        final Frame frame, final double mu)
    final double rV2OnMu = r * V2 / mu;
    // compute semi-major axis
    a = r / (2 - rV2OnMu);

but even the ubiquitous KeplerianOrbit doesn’t handle perfectly parabolic trajectories perfectly (e.g., computeJacobianEccentricWrtCartesianHyperbolic, computeJacobianTrueWrtCartesianHyperbolic, addKeplerContribution all will encounter issues with e == 1)

(aside: it’s interesting that the comparatively simple parabola always seems to make things more difficult)

Thank you for your time!


It’s just a missing feature, probably for historical reasons. I actually opened an issue a while back to implement the hyperbolic case in (Field)EquinoctialOrbit. Contributions welcome.
If you wish you can also open one for the exceptions raised with the parabolic case in KeplerianOrbit.


I’m wondering if any work aside from changing the exceptional conditions - i.e., changing

ex * ex + ey * ey >= 1.0


rV2OnMu > 2


ex * ex + ey * ey == 1.0


rV2OnMu == 2

- would even be necessary. I’d have to do some more reading to be sure.

The semester is winding down, so maybe I can find some time to do that outside of work. I’ve wanted to contribute for a while now! I just never seem to have the time.

I think the conversion routines between argument of longitude would need an update as well.

Ideally you would also need to do the Field equivalent of all that. Although if you’re struggling with that, I guess someone from the dev team could do it later.


1 Like