Default units

[bjlittle]

Currently iris implements the following default units for its containers (ignoring AuxCoordFactory here, as the units of the resultant derived coordinate is determined from the units of AuxCoordFactory coordinate dependencies)

Class	Default Unit	Abstract
_DimensionalMetadata	no-unit	✅
AncillaryVariable	no-unit
AuxCoord	1
CellMeasure	1
Coord	1	✅
Cube	unknown
DimCoord	1

Are these sensible defaults?

I think that we should answer this question as part of the MVP of 3.0.0.

---

Checkout these related issues/PRs :

• [FB] [PI-3585] Change default loading unit from "1" to "unknown" #3705 "Change default loading unit from "1" to "unknown""
• [PI] Improve load/create to default to "unknown" #3708 "Improve load/create to default to "unknown""

[bjlittle]

Ping @SciTools/iris-devs

[lbdreyer]

My initial reaction is that they should all be "unknown", as it currently is for cubes, for similar reasons that the name is "unknown" unless otherwise specified.

Are there any cases where it would be reasonable for the user to expect a default unit?

[bjlittle]

Are there any cases where it would be reasonable for the user to expect a default unit?

@lbdreyer I'm not 100% confident, but I don't think so... To me it seems sensible to assume a default of unknown, which tells the user that there is no metadata available to specify what the units should be - and this would align with the default philosophy applied to the Cube.

I can't recall the history behind this decision, and I'm sure that it must have been debated at some point. It's probably goes way, way back to the origin of iris... perhaps @rhattersley might have some thoughts, recollections or an opinion to help clarify?

I can only assume that the default of 1 comes from the canonical units reference in CF Metadata Section 3.3 Standard Names... dunno 😕

Otherwise, at the moment I'm erring on the blanket default of unknown for units everywhere...

[rhattersley]

perhaps @rhattersley might have some thoughts, recollections or an opinion to help clarify?

IIRC it comes from section "3.1. Units" that states:

A variable with no units attribute is assumed to be dimensionless.

That said, that statement in the CF conventions strikes me as decidedly questionable! It would have been safer to define a missing units attribute as "the units have not been defined" / "the file is not CF-compliant"... but as you know, that kind of sloppy pattern is all too common in the CF conventions. 😑 Sorry... no more whinging about the conventions, I promise!

My 2p ... the defaults for the in-memory objects should be unknown across the board, and possibly the CF-netCDF loader should impose the 1 interpretation.

[rcomer]

Just looking at some AuxCoords I have where the points are strings. In this case it doesn't really make sense that the units are 1. They aren't a measure, just a label.

[cpelley]

My 2p ... the defaults for the in-memory objects should be unknown across the board, and possibly the CF-netCDF loader should impose the 1 interpretation.

Just to put this on the table.
I would propose that we just raise a warning to the user when there isn't a unit on loading a NetCDF and do away with the CF NetCDF caveat case (i.e. set 'unknown' in all cases of no units).
I think this is more likely to help point people to the fact that they never intended to have dimensionless units in their files in the first place...
(I guess I'm saying that think the CF statement could be more trouble than its worth to maintain)

[stephenworsley]

A variable with no units attribute is assumed to be dimensionless.

From further on in "3.1. Units"...

The Udunits package defines a few dimensionless units...

Two examples of dimensionless units are then given: "1" and "1e-6". I think it is incorrect to equate "dimensionless" with "having '1' as a unit". By my understanding of the CF conventions, I believe it is acceptable (and probably correct) to apply a unit of unknown (or possibly no-unit) when a NetCDF file fails to supply one.

[bjlittle]

After an offline conversation with @stephenworsley, we tended towards the following 1, no-unit and unknown behaviour for units:

• unknown is the default units, exceptions are:
  • string dtype objects default to no-unit
  • flags objects default to no-unit

for saving:

• no-unit is not saved to NetCDF
• unknown is not saved to NetCDF
• 1 is saved as is to NetCDF, be opinionated about these dimensionless units if you care
• the units for string dtype objects are not saved to NetCDF, only if they are either unknown or no-unit
• the units for flags objects are not saved to NetCDF, only if they are either unknown or no-unit

for loading:

• units of 1 are loaded as is
• a lack of units metadata is interpreted as unknown, exceptions are:
  • string dtype objects default to no-unit
  • flags objects default to no-unit

In general:

• we want to preserve metadata units save and load round-tripping
• the user is king / queen i.e., they get what the ask for units metadata-wise
• users are not surprised
• * and / cube arithmetic with units of no-unit is not possible
  • this is in favour of the argument against no-unit being the default units
• don't save out units of unknown, as it's not CF-Conventions compliant
• don't save out units of no-unit, as it's not CF-Conventions compliant (see [PI] Aligning save behaviour of cube with units "unknown" and "no-unit" #3394)
• the CF-Conventions are questionable/unclear in certain units related areas, therefore iris can be opinionated through implementation

[pp-mo]

Nice summary!

( I just deleted previous comments on "units is None". Re-reading, I think you ruled that out. )

[pp-mo]

In view of the now proposed #3705, are we happy that the Coord constructors still give a default units='1' ?
If we were to change that, it's definitely going to affect a lot of people
For instance... #3647 (comment)
... but it does begin to seem a bit illogical.