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

NetCDF meteo variable must be last in file structure, otherwise cryptic error #175

Open
moritzshore opened this issue Dec 11, 2024 · 0 comments

Comments

@moritzshore
Copy link

moritzshore commented Dec 11, 2024

Hi, I was busy trying to convert Meteo data from MetNordic to a CWatM compatible format, and I found a quirk in the CWatM code that could be perhaps adjusted to make it more clear whats going wrong:

Essentally, I used R package terra and functions project() and writeCDF() to reproject the MetNordic provided .nc file. This function writeCDF() function appends a "crs" variable onto the file.

     2 variables (excluding dimension variables):
        float precipitation_amount_sum[easting,northing,time]   (Contiguous storage)  
            units: kg/m^2
            _FillValue: -1.17549402418441e+38
            grid_mapping: crs
        int crs[]   (Contiguous storage)  

I then edited the file to replace the "easting" and "northing" with "x" and "y" (otherwise the CWatM code would break, due to line 982 perhaps?:

if value in ["X", "Y", "x", "y", "lon", "lat", "time"]:

After that I figured I was ready to feed the file to CWatM, but got a cryptic error message:

File "C:\Users\mosh\Documents\GIT\CWatM\cwatm\management_modules\data_handling.py", line 989, in multinetdf
    shapey = nf1.variables[value].shape[1]
             ~~~~~~~~~~~~~~~~~~~~~~~~~~^^^
IndexError: tuple index out of range

The reason for the error turns out to be that it takes the last variable from the netCDF file:

value = list(nf1.variables.items())[-1][0] # get the last variable name

...which in my case was crs and does not have x and y definitions in .shape[1]. Reversing the order of the variables to have crs first and precipitation_amount_sum last fixed the issue.

This could be improved by dropping dimensionless variables, or perhaps an error message explaning the issue?

Its also totally possible that I just totally missed some sort of documentation specifying these requirements....

Anyway, just thought I'd mention it, in case it interests you..

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

No branches or pull requests

1 participant