Max elevation unit test slow for Molniya 1 and Sirius 1

[ryeng]

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]

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 #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 #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]

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:

(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. :-)