I just pushed a new branch (https://gitlab.orekit.org/orekit/orekit/-/commits/performance) to integrate the new Hipparchus features (i.e.
Gradient, etc.) in Orekit. I performed the changes for the different measurement types and also for the different DS converters. You will see that I declared the old DS converters (i.e. DSConverter, DSSTDSConverter, TroposphericDSConverter and
IonosphericDSConverter) as deprecated and I replaced them by new ones (i.e. NumericalGradientConverter, DSSTGradientConverter, TroposphericGradientConverter and
After doing that and before finishing the the transition, I performed some tests on the Orekit orbit determination. Using
Gradient instead of
DSFactory does not change the accuracy of the tests. That’s a good new!
However I saw some performance issues.
Here the duration of the three Orekit OD tests before performing the modifications:
- W3B OD: 38.739 seconds
- GNSS OD: 25.904 seconds
- Lageos OD: 65.544 seconds
Here the duration of the three same tests using
Gradient instead of DSFactory and DerivativeStructure:
- W3B OD: 135.964 seconds
- GNSS OD: 38.208 seconds
- Lageos OD: 92.618 seconds
I used Yourkit tool to see what happened. I used it on the worst case: W3B OD.
Here the OD profile before the change:
Here the OD profile after the change:
For non-Yourkit users, the main difference between the two runs and the cause of increased computation time is in
HolmesFeatherstoneAttractionModel.gradient(...) method. Precisely, according to Yourkit tool, the cause of the problem is the performance of the
Gradient.multiply(Gradient) method. Yourkit highlights the
line 235 of the
Gradient class (i.e.
result.grad[i] = MathArrays.linearCombination(grad[i], a.value, value, a.grad[i]);)
2 last informations:
- The performance problem is not affecting DSST orbit determination.
- The performance problem occurred just after the migration of the DS converter classes (i.e. after changing the measurement classes, performance where fine).