Re: [Orekit Users] DSST execution time

[MAISONOBE Luc <luc.maisonobe@c-s.fr>]

Christophe Le Bris <chris.lebris@gmail.com> a écrit :

> One precision regarding my previous e-mail: in the test case I provided, I
> forgot to do a first propagation before executing a second propagation that
> gives the reference run time (to avoid "cache" effects).
> It does not change the problem: it's only to get correct automatic checks
> with JUnit.

I got it!

It was a real funny bug. Each time a propagation is started, the  
"beforeIntegration" method of DSSTPropagator is called, which in turn  
calls the "initialize" method for each force models. In the case of  
DSSTCentralBody, this induced initialization of the zonal part and the  
tesseral part. The bug was that during its initialisation, the  
tesseral part "adds" new resonant terms, without clearing its list. So  
in your case, the first time the initilization leads to 4 resonant  
terms be considered (which was correct), but on the second  
initialization the same terms were added a second time, so the array  
contained 8 elements, then 12 elements for the third propagation and  
so on ...

You can fix this by adding the line:

    resOrders.clear();

near the beginning of the private getResonantTerms() method in the  
class TesseralContribution from package  
org.orekit.propagation.semianalytical.dsst.forces. This should be done  
before the loop that adds the resonant terms to the list, of course.

In fact, as some things are cached after the first run (frames  
transforms at Orekit level, and probably compiled code at JVM level),  
the laters runs should be faster than the first ones. On my computer  
the later runs are twice faster.

I will create an issue in the forge (crediting you for spotting the  
issue) and fix it in the development version.

Thanks a lot for the report.

best regards,
Luc

> Christophe



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.