Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Max elevation unit test slow for Molniya 1 and Sirius 1 #97

Open
ryeng opened this issue Dec 3, 2017 · 2 comments
Open

Max elevation unit test slow for Molniya 1 and Sirius 1 #97

ryeng opened this issue Dec 3, 2017 · 2 comments

Comments

@ryeng
Copy link
Contributor

ryeng commented Dec 3, 2017

The maxelevation-sat unit test takes an order of magnitude longer time for Molniya 1 and Sirius 1 than for any other satellite. Is there potential for some optimization? Or are we just computing more positions? If so, is it necessary?

      Start 27: maxelevation-sat_MOLNIYA_1-29_201509261800
27/32 Test #27: maxelevation-sat_MOLNIYA_1-29_201509261800 ...   Passed    9.22 sec
      Start 28: maxelevation-sat_SIRIUS-1_201509261800
28/32 Test #28: maxelevation-sat_SIRIUS-1_201509261800 .......   Passed    4.43 sec

@bjorgan
Copy link
Member

bjorgan commented Dec 3, 2017

Most of the time used in the test is done in this part https://github.com/la1k/libpredict/blob/master/tests/maxelevation-t.cpp#L240:

It checks that the same max elevation time is produced regardless of which time point you start at (by calculating the max elevation time from ten different starting points (NUM_TIME_STEPS) outside of a pass). It does this for 20 different passes (NUM_PASSES), and the entire test is run twice by CTest. Both constants could probably be reduced. Might not be necessary to do the checks for 20 different passes, 5 or 10 could be enough, and we could reduce the number of time steps to 5.

The orbits also produce weird elevation curves with loads of numerical traps that trigger the worst in the library functions. They have some potential for optimization:

  • The AOS/LOS prediction functions (used by predict_at_max_elevation() for bracketing the maximum), are definitely not efficient right now, and the timesteps used for iterating until pass start/pass end are probably not appropriate for the elevation curves for e.g. Molniya. Would say this is covered by Improve AOS and LOS calculations #18. I have have started working on this. (And also planning to reuse some planned functions from here for bracketing the maximum more efficiently for predict_at_max_elevation())
  • predict_at_max_elevation() uses the bisection method for finding the maximum after having bracketed the maximum, but there are similar alternatives with faster convergence. This part is reusable for AOS/LOS, and can replace bisection method by a different algorithm if need be, for both, once Improve AOS and LOS calculations #18 is solved.
  • I set the required numerical accuracy of predict_at_max_elevation() to FLT_EPSILON. This is probably a bit excessive, it can be reduced.

Would try and see how much AOS/LOS can be improved, and take it from there.

@bjorgan
Copy link
Member

bjorgan commented Dec 28, 2017

More detailed analysis of the time usage:

I ran predict_orbit(...) 144000 times (once every minute for a duration of 100 days) and compared the total calculation time against the time used for each test.

Satellite Test duration time (s) Total calculation time for 144000 calls to predict_orbit (s)
ISS 0.28 0.35
MOLNIYA_1-29 14.25 9.46
ERS-1 0.30 0.33
GPS_BIIA-10 0.49 0.35
SIRIUS-1 6.31 3.54
HINODE 0.28 0.33
VELA-1 0.51 0.34

They aren't directly proportional to the test times, but it is pretty apparent that calculating the orbits for MOLNIYA 1-29 and SIRIUS-1 takes a longer time than the other orbits. The calculation time for these orbits actually also increase with the time since epoch:

molniya_calculation_time_versus_time_since_epoch

(Other satellites are similar to VELA-1.)

Also extracted the number of calls to predict_orbit(...) in the tests, and the span from minimum to maximum time for which the satellite orbit was predicted throughout the test:

Satellite Test time (s) Number of calls to predict_orbit() Day span
ERS-1 0.30 87451 190.44
GPS_BIIA-10 0.49 133947 192.16
HINODE 0.28 82101 190.35
ISS 0.28 81170 190.07
MOLNIYA_1-29 14.25 146776 200.84
SIRIUS-1 6.31 183382 202.61
VELA-1 0.51 142530 218.18

SIRIUS-1 and MOLNIYA has approximately twice the number of calls to predict_orbit(...) as compared to e.g. ERS-1, but so has VELA-1 and GPS-BIAA-10, and probably has to do with the mean motion (inverse of mean period) of the orbits:

Satellite Number of calls to predict_orbit(...) Mean motion
ISS 81170 15.54
HINODE 82101 14.65
ERS-1 87451 14.37
GPS_BIIA-10 133947 2.01
VELA-1 142530 0.23
MOLNIYA_1-29 146776 2.01
SIRIUS-1 183382 1.00

In any case, the higher time usage for MOLNIYA and SIRIUS tests is due to:

  • Higher number of iterations (factor ~2)
  • Higher time usage during calls to sdp4() (factor ~30 for molniya?)

Test time for MOLNIYA is approximately a factor 50 higher than the rest.

We'll see whether I will be able to reduce the number of iterations for AOS/LOS, but it probably won't be by several orders of magnitude. Current AOS/LOS algorithm (and maxele algorithm) isn't necessarily that inefficient. Should probably reduce the requirements of the maxelevation test, or generate special testcase data to reduce the number of calculations. In any case, 190 days... That's a bit outside the valid range of the TLE. :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants