Decide what to do about standard name modifiers units

[lbdreyer]

In #3393 we included support for standard name modifiers. However, that PR, for simplicity, did not include in any special handling of the units.

In the CF Conventions Appendix C it lists the accepted Standard Name modifiers including the associated units.

Standard name modifier	unit
detection minimum	u
number_of_observations	1
standard_error	u
status_flag

u means that the unit it is equivalent to the unit of the unmodified standard_name (e.g. northward_wind has units of m s-1 so northward_wind standard_error would also have units of m s-1).

Note only status_flag and number_of_observations have specified units. Also note that both these are deprecated (See this trac ticket), although only the deprecation of status_flag appears in the actual documentation. I think number_of_observations has been missed off?

The question is how to handle the units?
Should we enforce the behaviour such that if someone renames the cube from
air_temperature -> air_temperature number_of_observations
that it would also change the units?

I'm concerned this may trip some people up:
Currently with standard_name, if some renames the cube, it doesn't have any impact on the units. Below we take a wind cube and rename the cube to air_temperature but the units stay as m s-1 rather than converting to the canonical units of air_temperature

>>> c
<iris 'Cube' of northward_wind / (m s-1) (-- : 1)>
>>> c.rename('air_temperature')
>>> c
<iris 'Cube' of air_temperature / (m s-1) (-- : 1)>

[pp-mo]

Currently with standard_name, if some renames the cube, it doesn't have any impact on the units. Below we take a wind cube and rename the cube to air_temperature but the units stay as m s-1 rather than converting to the canonical units of air_temperature

From a practical point of view, the most likely usage is when a cube is copied and modified to form a template for a new cube.
So I think we should definitely not assign the canonical units : the "correct" answer might be just anything (that is, anything compatible with the canonical unit of the new name).

How about making rename check the old + new canonical units, and if they are not compatible then set the units to None (aka 'unknown').
So for example (as possible future behaviour) ....

>>> cube = Cube([0.], standard_name='air_temperature', units='K')
>>> cube.rename('x_wind')
>>> cube
<iris 'Cube' of x_wind / (unknown) (-- : 1)>
>>> 
>>> cube.units = 'ms-1'
>>> cube
<iris 'Cube' of x_wind_gust / (ms-1) (-- : 1)>
>>> 
>>> cube.rename('y_wind_gust')
>>> cube
<iris 'Cube' of y_wind_gust / (ms-1) (-- : 1)>
>>> 

On the other hand we do have a bit of an inconsistency in current behaviour because we dont' currently check that units are compatible with a standard name (as you pointed out).
Frankly, that could just be changed : I can't see any good argument for allowing it, as it is non-CF -compliant.
That change would actually require us to clear units on an (incompatible) rename, for consistency.

[lbdreyer]

On the other hand we do have a bit of an inconsistency in current behaviour because we dont' currently check that units are compatible with a standard name (as you pointed out).
Frankly, that could just be changed : I can't see any good argument for allowing it, as it is non-CF -compliant.

Agreed, but I don't think it is a simple change. I would argue that it is a breaking change and so needs to wait for Iris 3.

[lbdreyer]

How about making rename check the old + new canonical units, and if they are not compatible then set the units to None (aka 'unknown').

I've thought a little more about this and I'm leaning more against it. As it is only possible to do this for cube's with standard_names I think it could lead to confusion if you are a user that works with both standard_names and long_names and (not necessarily aware of it).
This change would result in the following with you may be suprised by this:

>>> cube = Cube([0.], standard_name='air_temperature', units='K')
>>> cube.rename('x_wind')
>>> cube
<iris 'Cube' of x_wind / (unknown) (-- : 1)>
>>> 
>>> cube = Cube([0.], standard_name='air_temperature', units='K')
>>> cube.rename('east wind') #AKA not a standard_name so no available name-units to check
>>> cube
<iris 'Cube' of east wind / (K) (-- : 1)>
>>> 

[lbdreyer]

Whichever way we decide to go I think this should be dropped from the 2.3 milestone due to:

I would argue that it is a breaking change and so needs to wait for Iris 3.

[bjlittle]

Personally, I'd err on the side of iris being open and flexible, rather than being rigid and strict.

Could we incorporate such runtime compliance checks? Yes. However I think it would be a rather large effort and maintenance overhead, and given the general wooliness of the conventions, it would lead to a lot of inevitable debate and general angst e.g., climatological time coordinates... just sayin' 😅

Naively, I say let the user do what they want, when they want with their data. Perhaps at the very least we could allow them to opt in to a form of strictness for compliance checking on save. We've always strived to have CF compliant netCDF files generated from iris (hence the CF-1.5 version attribute) but why not allow the user to save a cube "as is" to file, CF compliant of not - they may actually have a need for that freedom.

[stephenworsley]

As far as I can tell, the only cases where this would be relevant are for deprecated standard name modifiers so I think we can close this.