search

ciaranbe / pyIGRF

Python 3.7 code for generating spot values for International Geomagnetic Reference Field 13th generation
Other
9 stars 4 forks source link

Too many "IGRF"s #2

Open smithara opened 4 years ago

smithara commented 4 years ago

Various implementations made by individuals, for various languages: https://github.com/search?p=2&q=igrf&type=Repositories The packaged Python ones (what you get with pip install ...) https://pypi.org/search/?q=igrf

So there is already existent in the Python namespace: pip install pyIGRF: https://github.com/zzyztyy/pyIGRF - relies on just Numpy; looks reasonable pip install igrf: https://github.com/space-physics/igrf - more complex architecture; calls the original Fortran code; also has Matlab interface; has plenty of CI stuff

There are several problems here:

  1. which one will people find and use easily (ans: one of those two above)
  2. we need to think about the long-term maintenance (who will update these? how is responsibility managed?)
  3. there ought to be a trusted reference implementation from IAGA that stays stable long-term (though not necessarily in Python)
    1. in this case, there is the Fortran code, which of course can be called from a python package after some wrangling. I guess IAGA would continue to distribute the Fortran code updated with new coefficients, along with a more user-friendly alternative (which naturally will change over time)
    2. it would also be good to include some associated utilities - e.g. writing a IGRF-format coefficient file - plotting power spectra and other diagnostics (what would be useful to the IAGA working groups? and what would be useful for applications of the IGRF?) - so Python makes sense here for a more directly useable tool, and we can bear in mind it might be called from other languages like Julia

https://github.com/ciaranbe/pyIGRF needs some rearranging to package it, set up automated tests, and documentation. But otherwise is more "official" than the others, being connected with IAGA

https://github.com/radars-eceillinois/pyigrf is rather interesting as a more minimal implementation which makes use of scipy.special.lpmn

https://github.com/ESA-VirES/MagneticModel/ is built to do forwards evaluation of all the Swarm models, and also supports IGRF among others. There is significant optimisation in there, but has more complex requirements. It is not yet documented and packaged cleanly but that is planned! It will be a good option where performance matters, but overkill if you only need IGRF.

https://github.com/ancklo/ChaosMagPy is built to support the CHAOS model and has some nice included utilities for field modelling. It would also be easy to add the option to evaluate IGRF to that.

I also note that IGRF is used together with magnetospheric field stuff in the space physics community (e.g. https://github.com/tsssss/geopack)

I am not sure what the route forward is to clear this up (while making use of these existing efforts). I am wondering if it would be good to:

I appreciate this is rather complicated and will take group effort to coordinate (and maybe I am being naive!) but it seems to me that there is opportunity to gather a number of contributors together to share resources that can benefit all in the longer term. I will continue to think on this but I wonder what interest there would be from IAGA & INTERMAGNET (among others) and what crossover there is with existing projects.

See also: https://github.com/geomagpy/magpy/

ciaranbe commented 3 years ago

Thanks for the analysis and comments @smithara. There has been a proliferation of codes that evaluate the IGRF coefficients, so I agree that it should be sorted out. I will take this comment to the IAGA2021 meeting and ask the interested scientists what we should do.

smithara commented 3 years ago

Another to add to the list: Kalle also recently made quite a clean implementation: https://github.com/klaundal/ppigrf

I was part of a discussion about this in the recent CEDAR meeting (slides here). Evidently, making a forwards evaluation is simple but what is lacking is the coordination. Beyond just the forwards evaluation, it would also be useful to gather together some simple utilities like coordinate conversion (geodetic/geocentric..) and an interface for field line tracing directly, etc. It should also be pure Python to avoid more complex maintenance.

We could gather together a list of desired features, and figure out how to transition to something that will fit many use cases, and be reliable and endorsed by IAGA

s-m-e commented 2 years ago

Just came across this discussion - truly wonderful title. May I add one more to the list, pyCRGI (Champ de Référence Géomagnétique International), created by myself ;) ? In all seriousness, it's a lot of implementations. This does not need to be a bad thing - competition is usually good and I like when science gets reproduced. However, what I found when I entered this arena was that few of the many implementations had been properly tested or verified. Besides, almost everyone of them had its smaller or bigger issues, anything from structure, design, speed, packaging, documentation etc. pyIGRF by zzyztyy was by far not the best, but it was (a) the one closest to IAGA's original Fortran implementation and, given the previous constraint, (b) the most "pure Python" one. So I based my work on it. I needed something I could trust, fast and verified. Had I known ppigrf - I probably would not have done it and instead added verification & test code to it. Long story short: If someone wants to coordinate, count me in.

I added a list of alternative implementations to my project.

smithara commented 8 months ago

I've also stumbled across https://github.com/mattkjames7/libinternalfield which is used as part of the JUICE mission (via https://github.com/mattkjames7/JupiterMag). Interesting since it includes a lot of planetary field models.

Since we will be releasing the IGRF 2025 at the end of this year, we ought to get this sorted out by then. We now have the https://github.com/IAGA-VMOD org, so I'd say we should put something there for the authoritative IAGA implementation together with links to some of the other implementations (and why someone might pick one of those instead).

willjbrown88 commented 6 months ago

@smithara @ciaranbe An important point about testing and functionality that I've just come to by roundabout means - most implementations don't perform the time variation calculations, and when they do they do not always get the non-linear time variation of the H, F, I, D components correct, or the stepwise nature of IGRF time variation.

From my (probably incomplete) survey, the official Fortran and C, and this Python implementation are the only ones that calculate the time variation correctly.

The pip pyIGRF version is very commonly used as it's easy to find and install but produces incorrect SV for either side of the main field coefficient change dates (I've raised an issue for this with a fix, but haven't put a pull request together).