PV LIB - ECMWF - functionality is not compatible with non-global ERA5 files

[shall-resurety]

Description/Details
When working with ERA5 netCDF files which are not 'global' (i.e. lat -90 to +90 and lon -180 to +180) the pvlib function get_nearest_indices returns incorrect values due to an incorrect derivation of the grid size intervals. The appropriate grid size inside get_nearest_indices the derived ERA5 grid spacing does not correlate with the actual 0.25 degree grid spacing which is represented in all ERA5 netCDF files (geo-subset or otherwise). Ultimately this results in data being returned for the wrong lat and lon position based on a misaligned file index. This is something which could be resolved by ensuring the standard 0.25 degree value is used for the delta_lat and delta_lon values when instantiating a ECMWF object from a geo-subset netCDF file. Thank you.

*** Perhaps this should be a feature request instead but logging as a bug due to the incorrect values being returned 'silently'.

To Reproduce
*Assume you have a geo-subset (CONUS) ERA5 netCDF file path stored in the variable filePath

  met = pvlib.iotools.read_ecmwf_macc(filename  = filePath,
                                      latitude  = 34,
                                      longitude = -101.25)

Expected behavior
The ECMWF object has a lat, lon delta defined as 1.8 versus the correct 0.25 which results with incorrect row indices being used in the met data return and therefore not representing the requested lat and lon position which is input.

[mikofski]

Actually it was only meant for the CAMS: MACC Reanalysis (wiki).

Maybe I should update the read_ecmwf_macc documentation to be more clear about that.

@shall-resurety , @cwhanse , @wholmgren do you all think we should make a new iotool for ERA5 or can we adapt this one to be more flexible for different grids?

I've been eager to add a MERRA2 & CAMS reader to provide global data coverage. CAMS is very fast, and it's easy to use, but lacks temperature.

[shall-resurety]

Thanks for the fast reply. Probably should have been obvious based on the name but it did seem to work on the surface i.e. ran without error so it was assumed to be working as expected despite the mismatch. That being said I think an ERA5 adaptation would be really useful/worth while.

[shall-resurety]

I am going to mark this 'closed' seeing as it is not a bug but there could be a follow on 'feature request' in a separate ticket.

[cwhanse]

Thanks again @shall-resurety for bringing up the issue. Please feel free to open another issue as a feature request. It doesn't commit you to work on it, but of course any contribution is welcome.