Cell methods are treated inconsistently after saving and re-loading

[schlunma]

Another issue which may prevent the concatenation of cubes:

import iris

# Create 1D cube with coordinate which has a long name with a space
coord = iris.coords.DimCoord([0, 1], long_name='long name')
cube = iris.cube.Cube([1, 2], dim_coords_and_dims=[(coord, 0)])

# Collapse it and print cell_methods
cube = cube.collapsed('long_name', iris.analysis.MEAN)
print(cube.cell_methods)  # gives (CellMethod(method='mean', coord_names=('long name',), intervals=(), comments=()),)

# Save it and check cell methods again
iris.save(cube, 'test.nc')
cube_new = iris.load_cube('test.nc')
print(cube_new.cell_methods)  # gives (CellMethod(method='mean', coord_names=('name',), intervals=(), comments=()),)

Would it be possible to come up with a consistent solution that doesn't change the cell methods? This prevents merge_cube and concatenate_cube operations.

[bjlittle]

@schlunma Thanks for taking the time to report this... l completely agree that this is inconsistent behaviour, and looks like a bug to me.

Let me just confirm, with some further details of the underlying issue and we'll take it from there

[lbdreyer]

@schlunma thanks for reporting this!

Iris follows CF conventions which specify that the name of the cell method should be:

name can be a dimension of the variable, a scalar coordinate variable, a valid standard name, or the word "area".

where, dimension of the variable refers to the name of a dimension in the netCDF file that the cube saves out to; scalar coordinate variable refers to the name of the scalar coordinate variable in the netCDF file ; and valid standard_name refers to the list of approved CF standard names.

Currently, Iris effectively uses what is returned by the name() method on the cube to set the name of the generated cell method. This is fine if the coordinate has a standard_name as name() will return the standard_name. However, as you have found, it causes issues if the coordinate has no standard_name and only contains a long_name, in which case name() returns the long_name as there is no standard_name.
Iris is wrong to be using the long name to set the name of the cell method, as a long name is not approved by the CF conventions and may contain spaces.

In CF, the cell methods are associated with a data variable (represented by a cube when loaded into Iris) using the cell_methods attribute which is a

string attribute comprising a list of blank-separated words of the form "name: method".

As this list is blank-separated, you can imagine the issues that you could run into if you allowed for spaces in the name of the cell_method.

So, the question then is what should Iris do if the coordinate does not have a standard_name and only has a long_name (which may or may not contain spaces). CF gives us other options for approved cell methods names (dimension of the variable, scalar coordinate variable and area) however the first two we will only know when it comes to save time and the last one is only appropriate in certain circumstances. And so it looks like we can't reliably name the cell method to associate it with a coordinate in these cases.

A fix to stop coordinates with only long_names being used to create cell method has gone in (see #3399 for more information) and will be available in Iris 2.3 release. In the meantime I can only suggest, as a workaround, to avoid long_names with spaces.