Hi,

I installed the package on a new python environment (I have tried python 3.8 and 3.10), but I simply get this error when I try to run the example.

Traceback (most recent call last): File "/home/lubuntu/RB/radbelt/test.py", line 1, in <module> from radbelt import get_flux File "/home/lubuntu/RB/radbelt/radbelt/__init__.py", line 15, in <module> from .core import igrf as _igrf, aep8 as _aep8 ModuleNotFoundError: No module named 'radbelt.core'
Any idea what the problem is?
Thank you

In SHELLG we have a do loop that goes from 3 to 3333:

      DO 3 N=3,3333                                              
C*****CORRECTOR (FIELD LINE TRACING)                             
      P(1,N)=P(1,N-1)+STEP12*(5.*P(4,N)+8.*P(4,N-1)-P(4,N-2))    
      P(2,N)=P(2,N-1)+STEP12*(5.*P(5,N)+8.*P(5,N-1)-P(5,N-2))    
...

Note that P(1,N), but P is dimensioned as P(8,100). So, if N ever gets to be > 100, it will go off the end of this array. Maybe the code logic some prevents this from happening (i.e., it always exits the loop before this happens), but it seems suspicious.

FYI

In SHELLG, it seems that the U is never given any values but it used later in the code. What is the intended value of this array in this case?

U only seems to be given values if you call the entry point SHELLC, which doesn't seem ever to be called here.

Perhaps the code is assuming that the compiler will initialize U to all zeros? That's a non-standard assumptions and is not true in general (but might be true for some Fortran compilers, or maybe f2py is adding a compile flag to make that true?).

FYI

I've refactored the Fortran code to modern standards, and you can find it here if you are interested: https://github.com/jacobwilliams/radbelt

Your Python version is very inefficient, I believe because it is reading all the data files every time the get_flux function is called? Unless I'm reading it wrong or calling it incorrectly. See my test case.

Compare to my refactored version:

Python version runtime:           3.514 sec.     409 (cases/sec) <-- reading the files every time
Fortran Function version runtime: 1.622 sec.    1198 (cases/sec) <-- reading the files every time
Fortran Class version runtime:    0.017 sec.  112259 (cases/sec) <-- caching the data from the files

The class version of mine will only read the files once, and store the data in the class so that subsequent calls don't have to read it again. That results in a huge speedup. Something like that could be implemented for the Python wrapper I believe.

This IER in AEP8 should be IERR. IER is never given a value, so it can be anything.

>>> from radbelt import get_flux
>>> from astropy import units as u
>>> from astropy.coordinates import EarthLocation
>>> from astropy.time import Time
>>> coords = EarthLocation(-45 * u.deg, -30 * u.deg, 500 * u.km)
>>> time = Time('2021-03-01')
>>> energy = 20 * u.MeV
>>> get_flux(coords, time, energy, 'p', 'max')  # doctest: +FLOAT_CMP
<Quantity 2642.50268555 1 / (s cm2)>

I ran this code on Ubuntu and I get a different result. Is that expected?

I got "2642.502685546875 1 / (s cm2)" instead of "2642.50268555 1 / (s cm2)"

I am currently creating a test suite to compare the results of the current version of the repo vs my repo where I am converting the Fortran bits to C.

I thought I should start by running the example code and now I am lost without a good reference point.

Add a job to our GitHub Actions pipeline to build binary wheels for Windows.

This is a little tricky due to some rough edges in Windows support in f2py and cibuildwheel. See:

• https://numpy.org/doc/stable/f2py/windows/index.html
• https://cibuildwheel.readthedocs.io/en/stable/faq/#windows-importerror-dll-load-failed-the-specific-module-could-not-be-found

While working on Apple Silicon (#58) and Windows builds for radbelt, it was discovered that some extra steps are needed in both cases.

For Apple Silicon, we need to set up a forked compiler while for Windows, some DLL files need to be linked. While building musllinux wheels, some dependencies are compiled from the source, which can be overcome by linking their pre-compiled versions.

To accommodate all of these steps, we can encapsulate them into reusable GitHub actions as proposed by @lpsinger

The current GitHub workflow file uses cibuildwheel without explicitly specifying combinations of operating systems and architectures. Since cibuildwheel does not expose any way to detect the current target architecture being built, there is no way to utilize custom steps for macOS, Windows, and musllinux as proposed above.

To overcome this limitation, the following can be done:

jobs:
  wheels:
    name: Build wheels
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        include:
          - {os: macos-latest, arch: x86_64, build: "*"}
          - {os: macos-latest, arch: arm64, build: "*"}
          - {os: windows-latest, arch: auto, build: "*"}
          - {os: ubuntu-latest, arch: "auto aarch64", build: "*"}
          - {os: ubuntu-latest, arch: "auto aarch64", build: "*musllinux*"}

    steps:
      - uses: actions/checkout@v3

      - name: Set up QEMU
        if: runner.os == 'Linux'
        uses: docker/setup-qemu-action@v2
        with:
          platforms: arm64

      - name: Set up macOS arm64 compiler
        if: matrix.os == ‘macos-latest’ && matrix.arch == ‘arm64’
        uses: kokroo/cross-compile-fortran-macos@v1

      - name: Set up Windows DLL linker
        if: matrix.os == windows-latest’
        uses: kokroo/fortran-dll-linker@v1

      - name: Set up musllinux pre-compiled packages
        if: matrix.os == ‘ubuntu-latest’ && matrix.build == ‘*musllinux*’
        uses: kokroo/link-precompiled-packages@v1

      - name: Build wheels
        uses: pypa/[email protected]
        env:
          CIBW_ARCHS: ${{ matrix.arch }}
          CIBW_BUILD: ${{ matrix.build }}
          # Skip PyPy wheels
          # Skip 32-bit Intel wheels
          # Skip musllinux unless explicitly overridden by matrix.build
          CIBW_SKIP: '*musllinux* *pp* *_i686'

This kind of workflow will allow us to detect the OS and arch, while allowing for custom build steps in a clean fashion.

As seen here (https://pypistats.org/packages/astropy), astropy is downloaded between 15000 and 30000 times daily, with Windows and macOS users accounting for around 5% each daily, which is significant. Making radbelt available on all these platforms will benefit all these potential users.

Hello I am trying to install radbelt into a conda environement using:
/Users/t/opt/anaconda3/envs/radbelt/bin/pip install git+https://github.com/nasa/radbelt.git

but I get the error:
ERROR: Failed building wheel for radbelt
ERROR: Could not build wheels for radbelt, which is required to install pyproject.toml-based projects

I have also tried installing using the setup.py but I get the message :
/Users/t/opt/anaconda3/envs/radbelt/lib/python3.9/site-packages/setuptools/command/install.py:34: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.

Can anybody help?