[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orekit Users] DSST execution time



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.