Skip to content

Sample Test Cases

The original STR#3 included several test cases and sample outputs, but only for two sample satellites. Given the number of branches possible in the deep-space case, many more tests are needed to fully test the code. The original cases have been extended over the years as users have encountered real-world situations. The only other official test cases are referenced in AFSPCI 60-102. No publishing information is given in the AFSPCI.

Because the theory is based on analytical expressions, comparisons are relatively simple because the output should be the same from each program. Different programming languages (C++, FORTRAN, MATLAB, or Pascal) and compilers produced very small differences, but these were well below the accuracy of two-line element sets that are commonly used, and below the comparison between differing implementations.

For analysis, the computer code was set up with three primary execution paths. First, there is a “verification” path in which the program accepts an input TLE file that includes start and stop dates and time steps. Mechanizing this step was important to quickly review any changes against “known” test results. The second mode processed the entire space object catalog from one day before to one day after the epoch time. The negative time propagation was chosen to highlight any difficulties in the secular integrator part of the deep-space code — a most convoluted example of programming in the official versions. Several space object catalogs (having about 9000 satellites in them) were tested from the historical database. This provided a quick-look at performance for each of the programs against a wide range of satellite orbits. The third mode of operation is the standard mode whereby input element sets are read, and some operation takes place with the data. We separated the driver and TLE-conversion function from the SGP4 code, to permit a user to modify the driver as needed, without having to change the underlying SGP4 code.

The test cases were divided into two categories. First, there were verification runs that tested the basic algorithm implementation. The second set of tests demonstrates cases that we believe indicate additional technical considerations that AFSPC may have incorporated in their models, or should consider in the future.