Long-term ionospheric correction predictions

Hi,
I am trying to run an orbit determination with range data and I would like to correct for the ionosphere in this. I had a look, the different implementations of IonosphericModel and, if I understand correctly (please let me know), they all seem short-term and are often specifically for GNSS. Are there any ionosphere models (e.g. based on IRI) that can be used without frequent updates of data from external sources?

Cheers,
Mattis

No, there is not such model yet.
Strictly-speaking, the Global Ionosphere Model can be used for long-term as it relies on files that have some time span, but this is only for the past, not for prediction.
As the ionospheric delay main term is inversely proportional to the square of the frequency, it is not specific to GNSS, you can use it for other radio bands, but your mileage may vary.

If you think of a specific public model we could add, feel free to ask for it, or even better contribute it!

Thanks for the quick response. I was thinking of the IRI model, but as this is all fortran (and legacy style) I do not see any straight-forward way of creating an interface or including this into Orekit. I will definitely report back if I find a useful way of doing this.

Hi @mmagg

To create a new ionospheric model in Orekit, one shall implement the IonosphericModel interface. This interface is already implemented by the following models:

  • NeQuick model
  • Klobuchar model
  • Global Ionosphere Map (GIM) based model
  • An estimated ionosphere model for which the VTEC is estimated and a mapping function is applied to take into account the satellite elevation.

As you said, they are all based on external data. Except the estimated model but it is only suitable to orbit determination applications.

Few years ago I had a look on IRI model and if I remember well, the main issue with the model is the copyright of the Fortan code.

Having this model would be a greate addition to Orekit. But we have to be careful if the copyright and the license allow translating the Fortran code to Java

Best regards
Bryan

The copyright is the following:

Copyright (c) International Reference Ionosphere

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, 
INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A 
PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE IRI AUTHORS OR THE 
IRI WORKING GROUP MEMBERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, 
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN 
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
  
Permission is hereby granted, free of charge, to any person obtaining a copy of this 
software and associated documentation files (the "Software"), to use, copy, and modify 
the Software subject to the following conditions: The above copyright notice and this 
permission notice shall be included in all copies or substantial portions of the Software
and the IRI Working Group should be acknowledged in scientific papers that make use of 
the Software and the scientific paper describing the specific version of the IRI model 
should be referenced.

My understanding is that a Java translation of the model is accepted if the above copyright is written at the top of the class.

So +1 for having this model in Orekit. Could you open an issue in our Gitlab repository?

An off course, contribution welcome! :slightly_smiling_face:

Hi Bryan,
I requested an account so I can make open the issue. I also looked into the IRI code some more and while I am used to working with Fortran code like this I would not trust myself to isolate the (presumably relatively small) parts required for the VTEC computation or rewrite this model in Java. Its over 10k lines of fixed-format Fortran with GOTOs, Common block, all variable names are 2-5 characters and settings and parameters are in lengthy arrays that can be challenging for me to trace. I am not saying its impossible to translate, but it definitely goes beyond my abilities. Also if this is niche and there is no very large interest or a much easier way of doing this, I think the effort would be very disproportional.