Extension to external_variables Syntax for Masks and Area Fractions

[martin.juckes]

Ticket #145, now accepted, proposes a new attribute, external_variables, to indicate when a variable referred to in the cell_measures attributes is in another file. This ticket relates to masks and area fractions used in the cell_methods attribute which may be associated with another variable. For instance, if we have cell_methods = area: mean where sea_ice and, in another file, a variable siconc which contains the sea ice area fraction. At present, there is no way within the convention to indicate, in the file containing the cell_methods statement, that the variable siconc is supplied separately. In earlier CMIP archives it was reasonably easy to determine when a mask or area fraction was available for a particular cell methods operation. For CMIP6 this is not so easy, as there are a substantial number of area fraction arrays covereing different aspects of the cryosphere and land surface.

The proposal is to allow the external_variables attribute to include terms of the form sea_ice:siconc to indicate that an area_type has an associated variable in an external file.

[martin.juckes]

On reflection, the above proposal does not cater for those who may wish to store the mask or area fraction variable in the same file, so it would be better to have a means of identifying this variable without relying on the external_variables attribute. This could be done in the cell_methodsstring, with an extension to the vocabulary for standardized information in parenthesis: area: mean where sea_ice (variable: siconc). The preferred approach would then be for siconc to be a variable in the file, while it would be possible to use external_methods for CMIP files which have the the mask variables in different files. The variable indicated in the (variable: ..) construct should have dimensions compatible with the variable carrying the cell_methods attribute.

[jonathan]

Dear Martin

Thanks for the proposal. It seems to me that this is probably going a bit beyond the role of CF metadata, which is to describe what the data is i.e. the mean within sea-ice areas - that's a sufficient description to distinguish it from other quantities for most purposes. Your aim here is to provide more information about how it was calculated, perhaps to enable further calculations. That could be done, but I'm not convinced of the case for providing special CF metadata for it unless it's an important use-case. An alternative would be to record this information in some unstandardised attribute, such as the history, which is where people do sometimes record how variables were calculated. This could be standardised by a CMIP6 convention, of course, in which there is a more systematic relationship between quantities requested.

Best wishes

Jonathan

[martin.juckes]

Dear Jonathan,

The specific use-case that motivated this proposal, which I should have included, was analysing some data which was masked by the sea_ice, and wanting to access the appropriate variable describing the mask. The masked area might be the same as the area of data having missing values, but it might not, so the only way to be sure that the analysis deals with the appropriate masked area is to have the array defining the mask. E.g. if there are missing data in the unmaksed area you may want to fill them in.

I think this is at the same level of importance as providing the cell_measures variable: it is a spatially varying field which is critical to analysis of fields which are defined through it.