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

Re: [Orekit Users] DSST execution time



one observation: it seems linked to the size of the offset in the date.
It seems that the propagation starts from the date that was provided the first time.

For example, to propagate on one year, it takes 2.5s.

If I propagate between years 0 and 1 => 2.5s
If I propagate between years 3 and 4 => 10s

That's just a feeling!

Christophe


2014/1/10 Christophe Le Bris <chris.lebris@gmail.com>
Ok great.
When the state is not changed, the problem is no more present.

But unfortunately, I think there is still another problem somewhere when I use setInitialState.
When I just change the orbit date in the initialState, the execution time increases enormously between 2 runs.

171.0
3125.0
5141.0
7874.0
10234.0

I provide in the mail a test case which is a slight modification of the previous test case, just to change the date of the new initialState.

Thank you!

Christophe




2014/1/10 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.