BUG: read_odim_hdf5 - TypeError: 'numpy.float32' object cannot be interpreted as an integer

[Vforcell]

• Py-ART version: 1.14.6
• Python version: 3.11 (same with 3.10)
• Operating System: Linux / Ubuntu

Description

An error is raised when using pyart.aux_io.odim_hdf5.read_odim_hdf5:

TypeError: 'numpy.float32' object cannot be interpreted as an integer

The line to blame is

pyart/pyart/aux_io/odim_h5.py

Line 333 in 75cb884

start_time = datetime.datetime.utcfromtimestamp(start_epoch)

The datetime.datetime.utcfromtimestamp function doesn't seem to like numpy.float32 dtype anymore.

A fix (that worked for me) is to specify "float64" in the dtype of t_data, instead of "float32":

pyart/pyart/aux_io/odim_h5.py

Line 327 in 75cb884

t_data = np.empty((total_rays,), dtype="float32")

[mgrover1]

Do you have a sample file that could be used here? For testing?

[Vforcell]

radar_file.zip

[Vforcell]

This ODIM .hdf5 file has been produced by the Météo-France quality control chain.

It might be that there is something with the file and the way it encodes time. But I don't see anything wrong on that part.

I think the problem is that float32 type has been somehow deprecated for datetime.datetime.utcfromtimestamp, or it messes up with it.

[kmuehlbauer]

@Vforcell My guess, too, is that it's connected to the dtype. ODIM_H5 is referencing these values as array of double so float64 should work. Maybe this just surfaces now, where more systems really use 64bit resolution.

One special thing is still to this file as it contains a compound type dataset (legend) attached to data7. This part cannot be read by netCDF4, which has to kept in mind when exploring this via xarray or the like (using engine=netcdf4, it might work with engine=h5netcdf).

[tealmill]

ODIM spec explicitly states the time of the startazT and stopazT must be a double aka float64. The array initialization here will coerce it into an array of float32. This seems like a fairly straightforwardly a bug, that array should be initialized as float64 and changing it to such fixes this error.

[Vforcell]

@kmuehlbauer @tealmill thanks for your answers.

@mgrover1 thanks for the Fix being implemented.

Didn't know about the legend type not being read for my files. Thanks for noticing

[mgrover1]

@Vforcell testing on that file to make sure things are fixed before merging