I recently upgraded the Orekit version on my code from 13.0.3 to 13.1 and I have seen that some tests for the orbit determination which worked before do not pass anymore. In particular, the estimation of the parameters does not converge (maximum number of iterations reached) when I select Propagation Parameters to estimate. I have one test for the reflection coefficient estimation and another for maneuver thrust estimation. If I remove the estimation of these parameters and leave only the estimation of the 6 orbital parameters, the computation finishes successfully.
My other tests containing the estimation of antenna measurements bias and the estimation of orbital parameters work correctly, so I assume something has changed for the Propagation Parameters.
For information I am using a SequentialBatchLSEstimator.
Yes, if I remove the radiation coeff estimation it converges fine.
It’s the same for the maneuvers estimation test, if I remove the thrust estimation (but still considering the maneuvers for propagation) the estimation converges OK.
And again, the same tests were finishing OK with the previous Orekit version 13.0.3.
My original test uses a max number of iteration of 20. I have increased it to 50 and it doesn’t converge. For information it should converge pretty fast since the measurements have been simulated with little error and the solution is relatively close to the initial values.
Sorry I didn’t read well your message… I have 2 separate tests that don’t work: one with orbit + radiation coeff estimation, the other with orbit + maneuver thrust estimation.
I have never tried to estimate both radiation and thrust at the same time.
Ah ok, but is SRP included when you estimate thrust?
With Orekit 13.1, I added a correction of the STM - used by BLS - when derivatives are reset by an event, which happens for instance whenever entering/exiting eclipse. So i suspect it’s the presence of radiation pressure that alters your results.
Yes, in all my tests SRP is included in the propagation.
For what you say I guess the problem I observe is not caused specifically by the presence of SRP, but more globally due to the fact that I try to estimate some parameters linked to the events? For example trying to estimate the radiation coeff when there are eclipse events, or the maneuvers thrust when there are maneuver events?
Otherwise I don’t understand why when not estimating these parameters (but still considering SRP and maneuvers in the propagation) the estimation finishes correctly.
The partial derivatives are split into two: the orbital ones (the real state transition matrix) and the rest (basically the propagation parameters). As soon as eclipses are present in the dynamics (or maneuver trigger other than purely date-based), these derivatives are now corrected for the switch at each event. Maybe the correction for non-orbital derivatives is noisy or something and leads to divergence in your cases. I would need to investigate numerically.
So that happened for you when using batch least squares on model parameters with solar radiation pressure taken into account.
I’m a bit surprised that this bug didn’t cause failed tests in the estimation package, but hey, it’s also my bad for not better validating things. The original mistake was to forget that stored partial derivatives are always wrt Cartesian coordinates.
Just to let you know that I’ve tested the new version 13.1.2 and all my orbit determination test scenarios work correctly now. Thank you very much for the correction!
Thank you for the message @pol.sola and for the fix @Serrof. I just updated our FDS from Orekit 13.0 to 13.1.1 and many of our orbit determination tests failed. That’s basically the same scenario as you Pol. Fortunately, we by-passed this issue by extending the BatchLSModel.
I can’t wait to upgrade to 13.1.2 and see if we can remove this ugly by-pass!
I confirm, the issue is fixed using orekit 13.1.2 instead of 13.1.1
Thank you again Romain for the fix.
I have now one concern. This issue highlights a lack in our validation. Maybe we should add a new intergration test for orbit determination covering the issue @pol.sola and I encountered. A test that perfoms well for Orekit 13.0, fails for 13.1.1, and come back to normal for 13.1.2.
Yeah it would be good indeed
I actually tried twice to implement such a test and I never managed. I wasn’t getting convergence with equinoctial elements even with 13.0 or 13.1.2…
It would be easier directly starting from your use cases though.
