Error reading NetCDF file dimensions with units degrees

[PAGWatson]

🐛 Bug Report

(Edited to show the error is associated with the coordinates having units 'degrees' rather than no units.)
I can create a NetCDF file of a field with 'longitude' and 'latitude' coordinates with units 'degrees' using the netCDF4 module version 1.5.8. Its metadata appears correct according to ncdump and the data it contains looks correct according to ncview. When I read the file using iris 3.1.0, however, it assigns the name 'grid_latitude' to both coordinates.

How To Reproduce

Steps to reproduce the behaviour:

Creating the file, reading it in with iris and printing the cube:

import numpy as np
import iris
import netCDF4

lat_vals=np.arange(-90,90)
lon_vals=np.arange(360)
data_out=np.random.normal(0,1,(len(lat_vals),len(lon_vals)))

fname='test.nc'
f = netCDF4.Dataset(fname, 'w')
lat_dim=f.createDimension('latitude', len(lat_vals))
lats=f.createVariable('latitude', 'f4', ('latitude',))
lats[:]=lat_vals
lon_dim=f.createDimension('longitude', len(lon_vals))
lons=f.createVariable('longitude', 'f4', ('longitude',))
lons[:]=lon_vals
data=f.createVariable('data', 'f4', ('latitude','longitude'))
data[:]=data_out

#Commenting these next two lines makes iris read the file correctly
lats.units='degrees'
lons.units='degrees'

f.close()

cube=iris.load_cube(fname)
print(cube)

This gives the result

data / (unknown)                    (grid_latitude: 180; grid_latitude: 360)
    Dimension coordinates:
        grid_latitude                             x                   -
        grid_latitude                             -                   x

Expected behaviour

That iris would name the coordinates "latitude" and "longitude".

Environment

• OS & Version: CentOS Linux 7
• Iris Version: 3.1.0

[PAGWatson]

Just to add, iris 3.0.4 doesn't seem to have this problem.

[bjlittle]

@PAGWatson You beat me to it 😉

I'm going to regression test against different versions of iris. To me this seems like we've adopted a new default behaviour, which to be honest, has surprised me as much as you... so I'll start digging 🧐

[bjlittle]

@PAGWatson Okay, so I've narrowed down exactly where this regression in behaviour occurs.

Essentially, PR #4198 caused the regression in expected behaviour. This PR was part of the content of iris 3.1, so that agrees with your observation in the comment above.

With commit dccb6a5 we have the behaviour as you've stated in this issue, and the previous commit
0c942c0 gives us the expected behaviour, i.e.,

data / (unknown)                    (latitude: 180; longitude: 360)
     Dimension coordinates:
          latitude                           x               -
          longitude                          -               x

[bjlittle]

@PAGWatson I've added this to the iris 3.2 milestone, so you'll see this fix early next year... the iris 3.2 release is scheduled for Feb-Mar 2022.

See v3.2.x GH Discussions for a pulse on the state of play for the iris 3.2.0 release 👍

[bjlittle]

@PAGWatson Thanks for raising this issue 🍻, and apologies again for the regression.

The sample code that you provided really helped expedite this investigation, so thanks for sharing that - super useful 🤩

[bjlittle]

Ping @pp-mo Heads-up 😉

[PAGWatson]

@bjlittle Great, thanks for looking into this.

[pp-mo]

Just FYI, I am now looking into this.
It is definitely a bug that I introduced #4198 !!
I have a handle on the problem, but it may take a while to sort it out.