RC v2.1.0

[aburrell]

Description

Release candidate with updates to IGRF-14, numpy 2 compliance, and Python 3.12 compliance. Also fixes the command-line interface.

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• This change requires a documentation update
• Release candidate

How Has This Been Tested?

Installed locally and ran:

import apexpy
apex = apexpy.Apex()
apex.qd2geo(90, 0.0, 0.0)

Yields: (83.9069595336914, -84.24675750732422, 5.598568350251298e-06) with a date of 2024.99692623

Also:
python -m apexpy geo apex 20240101 --height 300 -i $GITDIR/apexpy/apexpy/tests/test_convert.txt

Yields:

57.64630127 92.66724396
58.70431519 93.03585052
59.75823212 93.43036652

And:
apexpy geo apex 2015 --height 300 -i apexpy/apexpy/tests/test_convert.txt -o apexpy/apexpy/tests/output.txt gives the expected results from the unit tests.

Test Configuration

• Operating system: OS X Big Sur
• Python version number: 3.10
• Compiler with version number: gfortran 14.2.0

Checklist

• Update the version number
• Verify and update Zenodo information in .zenodo.json
• doc tests pass locally
• activate this branch on readthedocs (see CI below)
• Upload the test distribution to the testPyPi server: https://test.pypi.org/project/apexpy/2.1.0rc7/
• Contacted developers and users about the future release
• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules
• Add a note to Changelog.rst, summarising the changes
• Add yourself to AUTHORS.rst and .zenodo.json

[aburrell]

@jklenzing, @pacesm, @indiajacksonphd, @sapols, @sandyfreelance, @Dartspacephysiker, @klaundal, @JouleCai, @smithara, @dcsozturk, @butala you all have actively developed packages that depend on apexpy. I am hoping to get this released at the end of the week, please feel free to take a look and let me know about any concerns.

[ljlamarche]

I won't be able to test this for another few days, but I don't see any issues with a visual inspection of the code. I'll approve as soon as I can confirm it be haves as expected on my computer.

[aburrell]

@ljlamarche the changes @jklenzing made here also remove the 3.12 sometimes-need for rust.

[eelcodoornbos]

For what it's worth, I've installed the rcv2.1.0 version on the machine that processes Swarm data for the timeline viewer (link to relevant code here), and it seems to be working well for 2025 Swarm data.
If I can make one suggestion, it is to include the name "apex" or "IGRF" or something similar in the error message inside the COFRM routine of magfld.f90 when calling for an epoch outside the IGRF time span. That would be very helpful for finding the cause of the error in a large codebase, especially when it is going to be maintained by people who have not done the initial development. The currently used label "COFRM" did not immediately trigger an association with this package/functionality for me.

[aburrell]

Thanks for the suggestion and testing @eelcodoornbos. I made an issue for your suggestion, as to not delay the release of the updated code. It's #151 and I targeted it for the next minor release. Please let me know if you have more suggestions that would improve the codebase.

[ljlamarche]

Ok, I can confirm that this works, both in python 3.12 with the latest version of numpy installed and in an older and well-used (read "lots of nonsense installed in it") python 3.10 environment with numpy 1.24. I think this should be good to publish! Thanks for pulling this much-needed maintenance together!