Apologies if it’s not the right place and it should be in the Orekit usage. I tried posting in gitlab directly but I had to wait for the account to be approved so let me get it in here first.
We’ve been trying to match orekit propagations with other propagation for integration purposes. In our research, we went down the SpaceWeather usage and we found a possible issue in the MarshallSolarActivityFutureEstimationLoader.
In this module src/main/java/org/orekit/models/earth/atmosphere/data/MarshallSolarActivityFutureEstimationLoader.java · develop · Orekit / Orekit · GitLab , lines 104-140, it’s parsing the Space Weather prediction file, but as the comment says it’s not keeping the decimal part of the year in any group. This part corresponds to the month, but it gives enough information to encapsulate the specific day of the month for which the prediction is supposed to be. This day of the month changes for every new data row, but the current code ignores it and just takes the spelled out month name.
In line 183 of the same module it can be seen that it assumes it’s the first of the month. Both the comment during the parsing and this line indicates that this is intentional, but we wonder if this is the correct behavior.
At the end of the day, this is quite a small difference since predictions are made in a monthly basis so we understand the day-to-day changes are not supposed to be there in such detail. However, since we saw this while comparing numbers I am bringing it up just in case.
Thank you for catching that. I wasn’t aware of this approximation. I don’t know why it’s been done like that. Probably because, as you say, is was considered a small difference since predictions are made on a monthly basis.
It is approved now.
So we should use the decimal part to get the day of the year and the time components. That would give us a proper date instead of using the first day of the month.
I would agree that this the proper way to do it. I’d like to see what the others think though.
I’m curious, what difference does it imply in your research in terms of spacecraft position drift over a time span ?
Thanks for the quick answer to both and for approving the gitlab account. I was not intending to rush, just give context!
We use the python wrapper and we are not very knowledgeable with JAVA so I hesitate to say we can pitch in with a MR, but we will talk about it and see if it’s possible.
I don’t have specific numbers right now since it was a colleague doing the comparison, but I don’t think we were able to get the exact effect this different had in the spacecraft position drift, we had other differences that we are still working through that we are certain have a higher contribution. We found out because we had to implement the Marshall prediction parsing in our other system and as a sanity check we tried comparing Ap and Solar Flux values to the ones orekit reports and we saw minor decimal differences that we couldn’t explain from just parsing the files. I can try to dig if we are able to isolate the effect this would have but as far as we are concerned we are OK with the current setup (we matched our parser to also assume first of the month for now) or with the fix whenever it comes.