Is there a physical reason why the OrbitType in SmallManeuverAnalyticalModel (L122) is forced to Equinoctial if eccentricity is lower than 0.9 ?
I would like to make it configurable for the user (at construction). What do you think?
My problem is that I have a scenario with about 50 000 small maneuvers applied on a KeplerianPropagator and Orekit spends two-thirds of its time converting back and forth between Equinoctial and Keplerian Orbit in SmallManeuverAnalyticalModel.
If I force the OrbitType to Keplerian in SmallManeuverAnalyticalModel it runs fine and it’s much faster!
I’m not really familiar with that class but I’m guessing your proposal is fair, especially if you see no differences. The EQUINOCTIAL type was probably enforced to avoid singularities?
Some additional comments if EQUINOCTIAL was kept though:
have you tried on develop branch? The new cache system in KeplerianOrbit and EquinoctialOrbit should speed things up.
also, a call to removeRates could be used before the conversion, as I’m guessing the bottleneck is the computations of time derivatives.
The change I plan would keep the “default” behavior as it is right now. But a new constructor would allow the user to select the type of orbit, if needed.
I’ve tried and I found a speed-up of 13% with the cache system.
Allowing the choice of orbit type results in a speed-up of 77%.
I haven’t tried this one because the model manipulates generic Orbit objects and it was too much change to try using removeRates from PositionAngleBased interface.
But that’s an interesting idea!
I will open an issue and propose a merge request very soon.