Bug #360

Cannot perform orbit estimation with both geopotential and solid tides force models

Added by Quentin Rhone 11 months ago. Updated 8 months ago.

Status:ClosedStart date:2017-09-01
Priority:NormalDue date:
Assignee:Luc Maisonobe% Done:


Target version:-


Since v9.0 update, the estimation process behaves oddly when both geopotential and solid tides force models are added to the propagatorBuilder.
The few first iterations seem correct but after 7 or 8 iterations approximately the process slows down a lot until being quasi stopped.
No exception is thrown and no message appears in the console.

I think you can experiment this trouble with Orekit's OD test. I have tried with w3b data. You must activate sun and moon solid tides force model and do not hesitate to activate another parameter driver to get enough iterations to make the lag clear.

Actually the problem is the same as when you add twice a force model (sun attraction for instance). As solidTides class contains an attraction force model and then share the same ParameterDriver, the addition of the solid tides and the geopotential force models acts as if it was two same Force models for the orbit determination.

orbit-determination.in (16.1 KB) Quentin Rhone, 2017-09-04 18:26


#1 Updated by Luc Maisonobe 11 months ago

I am currently not able to reproduce this behaviour using W3B tutorial.

When I add solid tides, orbit determination converges correctly.
When I estimate also one ground station position, convergence is also reached without any problem.

The only case where I see a convergence problem is when I add estimation of transponder delay. However,
this is normal as all ground stations range biases are estimated in this case, so there is an
observability problem: one cannot estimate all additive biases together, at least one must remain
fixed. Even when I estimate transponder delay (which is an on-board range bias) without solid tides
the behaviour is weird, which is expected. If one the other hand I estimate transponder delay but
do not estimate the range bias of one of the stations, everything converges smoothly.

#2 Updated by Quentin Rhone 11 months ago

It is true that I tracked the bug with the transponder delay activated last week; I understand your answer.

Yet I still have the same problem it does not seem related to the transponder delay. You will find attached a version of my config file. The only differences with the version on the forge are : solid tides, fucino & pretoria position estimation and cr estimation activated.
I guess a lack of observability would just have make the algorithm reach the iteration limit but it is not the case here.
The test code is also directly imported from the repository. I've just changed the ECGEM potential file. I am using eigen-6s file. Orekit's version is 9.0 (not the 9.0-snapshot one)
In addition here is what I get in the console. I have added a column with the duration since the beginning. Iterations duration increase a lot from the eighth evaluation :
iteration evaluations ΔP(m) ΔV(m/s) RMS nb Range nb Range-rate nb Angular nb PV clock time(s)
0 1 274.082068049969 182/182 0/0 339/339 0/0 20.5
1 2 109349.078266 4.225872761 6.059169130395 182/182 0/0 339/339 0/0 24.4
2 3 356.574351 0.011194634 4.270107403916 182/182 0/0 339/339 0/0 27.6
3 4 49.449551 0.002972137 0.078143932783 182/182 0/0 339/339 0/0 30.1
4 5 4.746105 0.000396963 0.077926322619 182/182 0/0 339/339 0/0 32.5
5 6 2.617420 0.000086885 0.077926317333 182/182 0/0 339/339 0/0 34.9
6 7 0.100772 0.000004717 0.077926321301 182/182 0/0 339/339 0/0 37.8
6 8 0.000000 0.000000000 0.077926321511 182/182 0/0 339/339 0/0 46.1
6 9 0.063902 0.000002833 0.077926321005 182/182 0/0 339/339 0/0 89.5
6 10 0.032799 0.000001805 0.077926317300 182/182 0/0 339/339 0/0 542.9

I hope it will help you reproduce the bug easily.

Thank you in advance.

#3 Updated by Luc Maisonobe 11 months ago

  • Status changed from New to In Progress
  • Assignee set to Luc Maisonobe

We are working on the issue with Maxime.
It seems related to issue #359 and is a follow-on of issue #347.
Our fix for near infinite recursion obviously failed.

#4 Updated by Luc Maisonobe 10 months ago

  • Status changed from In Progress to Resolved

Fixed in git repository (see 4e88ef7d), merged into develop branch (see 3708181b).

Thanks for the report!

#5 Updated by Luc Maisonobe 8 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF