ua-snap / cmip6-utils

Pipelines and utilites for working with CMIP6 data
1 stars 1 forks source link

Inconsistencies GFDL-ESM4 historical data, tasmin > tasmax #33

Closed kyleredilla closed 8 months ago

kyleredilla commented 9 months ago

I have found some inconsistencies in raw CMIP6 outputs with tasmin and tasmax.

It appears that some of the GFDL-ESM4 historical daily tasmin and tasmax data has some cases where tasmin > tasmax. Here is a screenshot, looking at 1850-01-18 DTR:

image

This discrepancy is present in the regridded data as well, which is how I discovered this.

I have not explored other models/scenarios yet, but we should maybe consider performing a scan on the daily data.

At first I though, this might just be a literal edge case though, as we know the boundary pixels of models can be questionable. But then I noticed it does occur further "inside" as well, albeit seemingly less often.

image

Also the discrepancies are not severe. The largest difference across the entire regridded GFDL-ESM4 historical dataset (all days in 1850 through 2014) is only -1.5406494.

I am going to send a message to the contact for the GFDL-ESM4 model and get their thoughts.

(code used in screenshots)

# cell 1
ds1 = xr.open_dataset("/import/beegfs/CMIP6/arctic-cmip6/CMIP6/CMIP/NOAA-GFDL/GFDL-ESM4/historical/r1i1p1f1/day/tasmax/gr1/v20190726/tasmax_day_GFDL-ESM4_historical_r1i1p1f1_gr1_18500101-18691231.nc")
ds2 = xr.open_dataset("/import/beegfs/CMIP6/arctic-cmip6/CMIP6/CMIP/NOAA-GFDL/GFDL-ESM4/historical/r1i1p1f1/day/tasmin/gr1/v20190726/tasmin_day_GFDL-ESM4_historical_r1i1p1f1_gr1_18500101-18691231.nc")

dtr = (ds1.tasmax.isel(time=17) - ds2.tasmin.isel(time=17))
for lat_idx, lon_idx in zip(np.where(dtr < 0)[0], np.where(dtr < 0)[1]):
    print(f"latitude: {dtr.lat.values[lat_idx]}; longitude: {dtr.lon.values[lon_idx]}")

# cell 2
dtr.sel(lat=slice(80, 90), lon=slice(340, 360)).plot(vmax=0)

# cell 3
dtr.sel(lat=slice(80, 90), lon=slice(340, 360)).plot(vmax=0)
kyleredilla commented 8 months ago

We have heard back from the GFDL data contact, this a known issue and is essentially a regridding artifact - will not be corrected / updated.