Inconsistent AP Index selection at 3-hour marks in CssiSpaceWeatherData.getAp()
Hello, first off: great library! Thanks for working to make astrodynamics more open source.
I am using Orekit to benchmark/validate a similar open source project in C++: Open Space Toolkit It has been quite helpful so far.
While comparing inputs for the NRLMSISE-00 model, I believe I may have found an edge case in computing the AP Index input array. i.e. this function.
description: If the AP indices are computed at exactly a 3-hour mark (i.e. 00:00, 03:00, 06:00, ...) there may be some inconsistency in the AP index that is returned.
The AP indices provided by Celestrak are specified within 3 hour time ranges, but do not seem to specify inclusivity on the edge of each range:
| AP1 | Planetary Equivalent Amplitude (Ap) for 0000-0300 UT. |
| AP2 | Planetary Equivalent Amplitude (Ap) for 0300-0600 UT. |
| AP3 | Planetary Equivalent Amplitude (Ap) for 0600-0900 UT. |
| AP4 | Planetary Equivalent Amplitude (Ap) for 0900-1200 UT. |
| AP5 | Planetary Equivalent Amplitude (Ap) for 1200-1500 UT. |
| AP6 | Planetary Equivalent Amplitude (Ap) for 1500-1800 UT. |
| AP7 | Planetary Equivalent Amplitude (Ap) for 1800-2100 UT. |
| AP8 | Planetary Equivalent Amplitude (Ap) for 2100-0000 UT. |
(copied from documentation at https://celestrak.org/SpaceData/SpaceWx-format.php)
So it is unclear which AP index should be returned for 0600, for example (AP2 or AP3?). However, I am observing that the selection is inconsistent in Orekit.
example:
The getAp()
function returns an array with the following format:
0 : daily AP
1 : 3 hr AP index for current time
2 : 3 hr AP index for 3 hrs before current time
3 : 3 hr AP index for 6 hrs before current time
4 : 3 hr AP index for 9 hrs before current time
5 : Average of eight 3 hr AP indicies from 12 to 33 hrs
prior to current time
6 : Average of eight 3 hr AP indicies from 36 to 57 hrs
prior to current time
if getAp()
is called for the instant 2021-01-08 00:00:00
the following array is returned:
4, 9, 9, 5, 2, 4.5, 13.25
Checking this against the source file data:
AP1 AP2 AP3 AP4 AP5 AP6 AP7 AP8 APd
2021 01 07 ... 5 6 4 3 2 2 5 9 4 ...
2021 01 08 ... 2 2 2 2 2 0 0 2 2 ...
For the "3 hr AP index for current time" value, 9 is returned, indicating that it is choosing AP8 from the previous day (AP ranges are inclusive on the higher end).
However, for the "3 hr AP index for 3 hrs before current time" value, it is also returning 9, which indicates that it is choosing AP8 again (ranges are inclusive on the lower end).
impact:
This is a somewhat rough comparison, I am comparing to my code which matches quite well when computations do not lie on a 3 hour mark but matches much worse when taken at 0300, 0600, etc.
Calculating density every 3 hours for the range 2021-01-01T00:00:00
-2021-01-11T00:00:00
Starting at 2021-01-01T00:00:00 [i.e. landing on 3 hour marks]:
- matches to a tolerance of 2.472e-14 kg/m^3
Starting at 2021-01-01T01:00:00 [i.e. avoiding 3 hour marks]:
- matches to a tolerance of 1.1004e-15 kg/m^3
Please let me know if there's something I'm missing! I am also happy to provide the code that I am using to produce the Orekit values and my working C++ implementation is here for comparison. Otherwise, thanks again for the great library!
Best, Kyle