I’m back with another performance-related query.
In NumericalPropagator, the default OrbitType is Equinoctial and the default PositionAngleType is True. However, when we look into computeJacobianTrueWrtCartesian, we see that it encapsulates calls to the other two angles. This can lead to non negligible computational overhead. Why not use Mean as the default type? This would have the best performance.
I know that the user can set what they want, but I don’t think people are always conscious of “under the hood” stuff like that.
Bonus question: why are the Gauss equations not explicitly implemented? Instead the Jacobian w.r.t. Cartesian is computed at each integration step. Ok there’s less code to maintain but surely there would be algebraic simplifications that would speed things up no? I guess we’d need a prototype to know for sure.
It’s historical, and it is a bad choice, indeed from a numerical point of view mean anomaly is smoother and easier to integrate (well… it is linear with respect to time). +1 for the change.
We changed it years ago. The reason was that Gauss equations in some sets of parameters are not always available. And in fact, Gauss equations are Jacobians with Keplerian part removed (which is zero for all parameters except anomaly), even if it is not the traditional approach.
If we intend to add new orbital parameters (and this may happen because of CCSDS), we will anyway need the equivalent of Gauss equations/Jacobians and I prefer to maintain only one approach.
I’ve opened an issue for the default PositionAngleType, but it’s breaking at least 60 tests…
I think it would be nice to have explicit Gauss equations for Keplerian and equinoctial elements in Orekit. They’re used a lot, at least in the literature. They are more or less a Jacobian matrix yes (there’s also a frame transformation as they are usually in a local frame). I understand that implementing them for present and future OrbitType would be a pain. But we could have a default method that uses the Jacobian w.r.t. Cartesian (which would remain mandatory) actually, and only some inheritors would overwrite it with explicit algebraic expressions. Anyway there would be a bit of work, so I don’t know.
Actually, if one sets the PositionAngleType to MEAN for example, the OsculatingStateMapper still uses TRUE for some reason and thus time is then lost making conversions in mapArrayToState. That looks like an undesired behaviour doesn’t it?
Edit: even if the StateMapper was using MEAN, I think the constructor of EquinoctialOrbit would make the conversion anyway. So we have two opposite behaviours here: MEAN is the fastest Jacobian computation (because time is the independent variable for integration) but TRUE is the fastest Orbit creation (by design, as the class systematically converts onto this PositionAngle).