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:
-
A test generating PV measurements on a day for a LEO satellite and doing an OD on these measurements (force model is Newtonian attraction + SRP)
- In version 12: TestOdPerformancesWithSrp_V12.java
- In version 11: TestOdPerformancesWithSrp_V11.java
-
Some figures, this is the testing time in seconds for each file:
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: -
The call at line 284 ofSolarRadiationPressure
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 aField
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 toAbsoluteDate
(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 aFieldAbsoluteDate
here??
→ Changing this toAbsoluteDate
(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?)