The numerical computation of the State Transition Matrix has been sped up already on the develop branch w.r.t. 12.0. To go even further, particularly when at least one force does not just depend on position, I suggest to do the following: add a “dependsOnAttitudeRate” method to ForceModel, in the line of dependsOnlyOnPosition. If false for all, then in AbstractGradientConverter, the FieldAttitude will be built by calling getAttitudeRotation on the provider and arbitrarily use zero rate and acceleration (assumed to not be used).
I’ve done some profiling with drag force (box S/C + Harris Priester) and LofOffset, the gain is about 20% of CPU time (on top of the aforementionned improvements already achieved).
And so far I can actually not see any native force model in Orekit depending on the atttitude rotation rate or acceleration (at a fixed date of course).
Thoughts?
Me too, especially if there’s a 20% increase in performance
I have a question though, won’t it cancel out the fictitious “inertial” forces that are computed using \Omega and \frac{d\Omega}{dt} ?
I’m thinking of all the forces that are computed in spacecraft frames (so maneuvers and “box and solar array” SRP and drag).
I’m not sure to understand what you mean by fictitious. You’re talking about forces that are first computed in a frame different than the propagation one and then transformed?
Anyway, as long as getRotationRate/getSpin and getRotationAcceleration on the Attitude or underlying AngularCoordinates are not called in acceleration, it is fined to define a “frozen” orientation.
FYI I have extended the use of dependsOnAttitudeRate in computeDerivatives for (Field)NumericalPropagator.
Basically it removes the unnecessary computations of full Attitude when doing pure integration
