Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ValueError When Running pymsis.calculate with Documentation Example: Cannot Convert Empty String to int32 #71

Open
ssmong opened this issue Nov 30, 2024 · 4 comments · May be fixed by #72

Comments

@ssmong
Copy link

ssmong commented Nov 30, 2024

SW-All.csv
Issue Summary:
Executing the example code from the PyMSIS documentation results in a ValueError. The error message indicates that an empty string cannot be converted to an int32 at a specific row and column. This issue prevents users from successfully using the pymsis.calculate function as demonstrated in the documentation.

Steps to Reproduce:

  1. Use the following code (identical to the documentation example):

    import pymsis
    import numpy as np
    
    dates = np.arange(
        np.datetime64("2003-10-28T00:00"),
        np.datetime64("2003-11-04T00:00"),
        np.timedelta64(30, "m")
    )
    # geomagnetic_activity=-1 is a storm-time run
    data = pymsis.calculate(dates, 0, 0, 400, geomagnetic_activity=-1)
  2. Run the code in your Python environment.

Expected Behavior:
The pymsis.calculate function should execute without errors and return the calculated atmospheric data based on the provided dates and parameters.

Actual Behavior:
A ValueError is raised during execution:

ValueError: could not convert string '' to int32 at row 24531, column 13.

Error Traceback:

/usr/local/lib/python3.10/dist-packages/pymsis/utils.py:45: UserWarning: Downloading ap and F10.7 data from https://celestrak.org/SpaceData/SW-All.csv
  warnings.warn(f"Downloading ap and F10.7 data from {_F107_AP_URL}")
/usr/local/lib/python3.10/dist-packages/pymsis/utils.py:45: UserWarning: Downloading ap and F10.7 data from https://celestrak.org/SpaceData/SW-All.csv
  warnings.warn(f"Downloading ap and F10.7 data from {_F107_AP_URL}")
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-41-161cc04f4b20> in <cell line: 4>()
      2 dates = np.arange(np.datetime64("2003-10-28T00:00"), np.datetime64("2003-11-04T00:00"), np.timedelta64(30, "m"))
      3 # geomagnetic_activity=-1 is a storm-time run
----> 4 data = pymsis.calculate(dates, 0, 0, 400, geomagnetic_activity=-1)

5 frames
/usr/local/lib/python3.10/dist-packages/numpy/lib/npyio.py in _read(fname, delimiter, comment, quote, imaginary_unit, usecols, skiplines, max_rows, converters, ndmin, unpack, dtype, encoding)
   1014 
   1015         if read_dtype_via_object_chunks is None:
-> 1016             arr = _load_from_filelike(
   1017                 data, delimiter=delimiter, comment=comment, quote=quote,
   1018                 imaginary_unit=imaginary_unit,

ValueError: could not convert string '' to int32 at row 24531, column 13.

Environment Details:

  • Python Version: 3.11.9 (VSCode), 3.10.12 (Colab)
  • PyMSIS Version: 0.10.0
  • Operating System: Window 11 - VSCode and Colab

Attached file is the one

@mananapr
Copy link

mananapr commented Dec 2, 2024

This is an issue at Celestrak's end where they have published empty data under observed values.
I suppose pymsis can add a step where it discards rows with empty values if found under observed data.

EDIT: Looks like celestrak has fixed their CSV. @ssmong - Try re-running your code with the latest CSV

@ssmong
Copy link
Author

ssmong commented Dec 2, 2024

Thanks for your support!

I just re-ran it, and it worked perfectly fine
Always appreciate your awesome library

@ssmong ssmong closed this as completed Dec 2, 2024
@greglucas greglucas linked a pull request Dec 2, 2024 that will close this issue
@greglucas
Copy link
Member

I think we can handle this in the library a little more gracefully too. See #72 for an attempt at skipping those bad lines.

@greglucas greglucas reopened this Dec 2, 2024
@mananapr
Copy link

I think we can handle this in the library a little more gracefully too. See #72 for an attempt at skipping those bad lines.

Hi @greglucas, is there a reason we haven't merged the PR yet?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants