Performance loss in orbit determination with Solar Radiation Pressure

I noticed a loss of performance compared to previous versions while doing an orbit determination with SRP perturbation activated.

I think they are due to:

  • The calls to ExtendedPVCoordinatesProvider.getPosition(FieldAbsoluteDate, Frame) when getting the position of the occulted body (the Sun, but sometimes the Moon too)
    → I think we should try to reduce these calls as much as possible or even call the "non-fielded" version of the function since I'm not sure we need to field this.
  • Issue #1000 (closed) which now takes the flatness of the occulting body into account in the computation of the lighting ratio of the spacecraft
    → I think users should be allowed to choose the model they want to use (spherical with small computation but less accuracy OR ellipsoidal with heavy computation and high accuracy) since I think that for most usages the ellipsoidal model isn't needed.

What do you think?

Some information I gathered. Here are:

V12 Meas Gen OD
With SRP and ellipsoidal Earth 1.82 41
With SRP and spherical Earth 1.2 40.3
Without SRP 0.1 1.1
V11.3.3 Meas Gen OD
With SRP 0.63 30
Without SRP 0.1 1.1
  • There's definitely a regression in V12 compared to V11, most probably due to the resolution of issue #1000 (closed).
    But still, 30s for a one-day OD with only SRP is still a lot with v11. I remember doing this in less than 10s a few years back, but I can't say which version used to have these performances.
  • Digging a bit deeper, I profiled v12 and v11 versions of the test, and it appears that Orekit spends more than 80% of its time in ExtendedPVCoordinatesProvider.getPosition(FieldAbsoluteDate, Frame) which is, getting the "fielded" position of the Sun at a given date.
    See for example v12 of the profile, here the 3 calls to the function amount for 81% of the time spent: image
  • The call at line 284 of SolarRadiationPressure can use the un-fielded version since we only do a check on the distance here.
    → Changing this results in an OD lasting 30.4s (compared to 41s, so a 25% performance increase)
    Edit: I changed this call because it's really useless to have a Field here (see commit 7bc916aa)
  • The one at line 149 cannot be avoided, it's the computation of the acceleration. But do we really need a FieldAbsoluteDate here??
    → Changing this to AbsoluteDate (with the previous change kept) results in an OD lasting 20s with no change in the results
  • The one at line 108 of OcculationEngine is the same but here the body could be either the Sun or the Moon (or any other body). But do we really need a FieldAbsoluteDate here??
    → Changing this to AbsoluteDate (with again the previous changes kept) results in an OD lasting 6.3s with no change in the results, which is more in the range of what I used to work with.

So, in the end, it's the multiple calls to the fielded version of the Sun position that degrade the performances.
I don't see exactly a test case where the FieldAbsoluteDate instead of AbsoluteDate would have a huge impact on the results but I understand that it's needed.
That being said, could we give the users the possibility to choose which function they want to use? (with a function in the attributes of the classes choosing between the fielded or un-fielded version of ExtendedPVCoordinatesProvider.getPosition method for example?)

Edited by Maxime Journot