Skip to content

Fixed issues 1072, 1168 and 1169

Vincent CUCCHIETTI requested to merge vcucchie/orekit:1072-1168-1169 into develop

Hi everyone,

Summary of this mr available below :

  • Added AbstractSolarActivityData and AbstractSolarActivityDataLoader to reduce code duplication

  • Refactored MarshallSolarActivityFutureEstimation and CssiSpaceWeatherData

  • Added tests for multi threading use in CssiSpaceWeatherLoaderTest and MarshallSolarActivityFutureEstimationTest

  • Improved javadoc

Regarding the performance of these classes with this fix, when performing an orbit determination over a one day period :

  1. Using CssiSpaceWeatherData for the atmosphere : without fix = 13s | with fix = 11s
  2. Using MarshallSolarActivityFutureEstimation for the atmosphere : without fix = 10s | with fix = 14.5s I'm still investigating why the second case gets such a huge drop in performance.

Could you check if the current implementation makes good use of the GenericTimeStampedCache @luc ?

closes #1072 (closed), closes #1168 (closed), closes #1169 (closed)

Cheers, Vincent

UPDATE :
After trying out several combinations and looking at the code, i finally figured out how the GenericTimeStampedCache configuration worked.

Also, by combining ideas with @MaximeJ, i was able to completely get rid of the additional computing time when introducing the thread safe cache to the MarshallSolarActivityFutureEstimation class. In fact, we are even slightly faster than before (around 10 %).

With these, the merge is ready for review ! I would like to point out the change that may be the most controversial :

  • Addition of a new constructor argument for GenericTimeStampedCache used to override the computed time step (useful for monthly tabulated data for example). Another possibility would be to create a subclass with this new specific attribute, what do you think ?

Cheers, Vincent

Edited by Vincent CUCCHIETTI

Merge request reports