GFSForecast radiation variables broken.

[Mutaz-Datatactics]

Description When running CoCiP with GFS (see https://py.contrails.org/notebooks/GFS.html#Run-CoCiP-with-GFS), opening a rad dataset results in the following error:

KeyError: "No variable named 'ulwrf'. Variables on the dataset include []"

This worked until the last update on the 8th of October (v0.54.1). It seems that the loaded dataset is empty.

Details

• Version: 0.54.1
• Module: pycontrails.datalib.gfs
• OS: manjaro
• Reporter: Mutaz-Datatactics

Steps to Reproduce

1. Import GFSForecast (from pycontrails.datalib.gfs import GFSForecast)
2. Initialize a GFSForecast object with time range and rad variables: gfs_rad = GFSForecast(("2022-03-01 00:00:00", "2022-03-01 23:00:00"), variables=Cocip.rad_variables, show_progress=True)
3. Download and open the respective metdataset: rad = gfs_rad.open_metdataset()

Additional Notes

• Running the steps above with the parameter pressure_levels returns ValueError, because it expects a met_variable.

• Met data can be downloaded and opened correctly. Only rad data is broken.

[Mutaz-Datatactics]

it looks to me like the error is in gfs.py in the definition of _download_file. After downloading the file to tmp, the function tries to declare the dataset using

            ds = self._open_gfs_dataset(temp_grib_filename, t)

In _open_gfs_dataset, it checks if ds is None, and if so, sets it to tmpds, which is constructed using the temp_grib_name above. However, the file usually no longer exists by then, and ds is still None. The line

                ds[v.short_name] = tmpds[v.short_name]

Then throws an error, since no variables exist.

[zebengberg]

Thanks for finding this! I've been able to reproduce what you're seeing. I've found that this also fails on earlier versions of pycontrails as well.

[zebengberg]

I think some of the GFS variable names have changed. For a quick fix, see 0ea159610aac2d1bedb65456ae143895195c0b79

I'll get this integrated into pycontrails.