⇐ ⇒

[CF-metadata] CMIP6 Sea Ice MIP: Ice thickness

From: Jonathan Gregory <j.m.gregory>
Date: Thu, 21 Jul 2016 17:12:06 +0100

Dear Dirk

I understand your concern, but there are plenty of other instances where
important distinctions are made by coordinates and cell_methods rather than
by standard_name. For example, maximum, minimum, mean and instantaneous
temperatures are distinguished by cell_methods only. I can't think of another
instance where a given geophysical variable has more than one standard name.
I think that the users of the data have to be aware that the standard name
alone is not sufficient. In practice people often also identify variables by
the variable name, although CF does not standardise these, so that is not a
reliable method in general but could work in a particular project.

Best wishes

Jonathan

----- Forwarded message from Dirk Notz <dirk.notz at mpimet.mpg.de> -----

> Date: Thu, 21 Jul 2016 15:32:37 +0200
> From: Dirk Notz <dirk.notz at mpimet.mpg.de>
> To: Jonathan Gregory <j.m.gregory at reading.ac.uk>
> Subject: Re: [CF-metadata] CMIP6 Sea Ice MIP: Ice thickness
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
> Thunderbird/45.2.0
>
> Dear Jonathan,
>
> I appreciate that a CF variable is not solely defined by its variable
> name, but also by its cell_methods.
>
> I hence believe that the question of introducing
> "sea_ice_equivalent_thickness" boils down to a question of the
> overarching CF philosophy:
>
> I agree that usually a new variable name should only be introduced if a
> certain quantity cannot be described by existing variables.
>
> However, I believe that in some cases, introduction of a new variable
> name can also be warranted simply to prevent significant errors that can
> occur because the actual data does not describe the quantity given by
> the variable name because of applied cell_methods.
>
> Even if we can create "equivalent_sea_ice_thickness" from the existing
> variable "sea_ice_thickness", its physical usefulness does not primarily
> relate to the actual sea-ice thickness implied by the variable name.
> Instead, equivalent_sea_ice_thickness is primarily of interest for
> oceanographers to easily appreciate the volume of sea water in the
> vertical column that is on average frozen to sea ice. Given the
> sometimes significant differences in magnitude between actual thickness
> and equivalent thickness, I am worried that by keeping the same variable
> name for such different quantities, significant confusion might arise.
>
> Best,
>
> Dirk
>
>
>
>
> ----
> Dr. Dirk Notz
> http://www.mpimet.mpg.de/~notz.dirk
>
> Am 21.07.2016 um 15:05 schrieb Jonathan Gregory:
> > Dear Dirk
> >
> > I think I get your point, but nonetheless I would say that the "equivalent
> > sea ice thickness" can be correctly described by existing conventions. If the
> > standard_name is sea_ice_thickness and the cell_methods says "area: mean",
> > the interpretation is that the sea_ice_thickness is integrated over the area
> > of the grid box and then divided by the grid box area. That is what you want,
> > isn't it? By contrast the local thickness of sea-ice, at a point, would have
> > cell_methods with "area: point", and the thickness averaged over the sea-ice
> > area is "area: mean where sea_ice". Thus the cases are distinguished by the
> > cell_methods. In the CF convention, the standard_name is only part of the
> > description of the data variable.
> >
> > Best wishes
> >
> > Jonathan
> >
> > ----- Forwarded message from Dirk Notz <dirk.notz at mpimet.mpg.de> -----
> >
> >> Date: Thu, 21 Jul 2016 13:33:55 +0200
> >> From: Dirk Notz <dirk.notz at mpimet.mpg.de>
> >> To: Jonathan Gregory <j.m.gregory at reading.ac.uk>
> >> Subject: Re: [CF-metadata] CMIP6 Sea Ice MIP: Ice thickness
> >> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
> >> Thunderbird/45.2.0
> >>
> >> Dear Jonathan,
> >>
> >> thanks a lot for your guidance. I understand that
> >> equivalent_sea_ice_thickness can be constructed from existing mechanisms.
> >>
> >> However, the definition of equivalent_sea_ice_thickness is not related
> >> to actual sea-ice thickness, but simply defined as sea-ice volume per
> >> grid area. This then only happens to have the same units as
> >> sea_ice_thickness. We hence initially proposed to have
> >> equivalent_sea_ice_thickness recorded as sea_ice_volume, but Alison
> >> pointed out that units of "m" are not possible for any variable that is
> >> called "volume".
> >>
> >> However, given the substantial confusion that arose in some papers
> >> published with CMIP5 data, where people assumed that "sea_ice_thickness"
> >> is actual thickness, we believe that it would be worthwhile to add a
> >> variable with a distinct name to avoid such confusion in the future.
> >>
> >> Best,
> >>
> >> Dirk
> >>
> >>
> >>
> >> ----
> >> Dr. Dirk Notz
> >> http://www.mpimet.mpg.de/~notz.dirk
> >>
> >> Am 20.07.2016 um 15:21 schrieb Jonathan Gregory:
> >>> Dear Dirk
> >>>
> >>> I believe that this distinction can be recorded by the existing mechanisms
> >>> of "where" and "over" in cell_methods, using the existing standard_name of
> >>> sea_ice_thickness. Please see Section 7.3.3 of the CF standard. The grid-box-
> >>> mean sea-ice thickness is "area: mean where all_area_types" and the thickness
> >>> meaned over sea-ice only is "area: mean where sea_ice", I think.
> >>>
> >>> Best wishes
> >>>
> >>> Jonathan
> >>>
> >>> ----- Forwarded message from Dirk Notz <dirk.notz at mpimet.mpg.de> -----
> >>>
> >>>> Date: Tue, 19 Jul 2016 09:53:02 +0200
> >>>> From: Dirk Notz <dirk.notz at mpimet.mpg.de>
> >>>> To: cf-metadata at cgd.ucar.edu
> >>>> Subject: [CF-metadata] CMIP6 Sea Ice MIP: Ice thickness
> >>>> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
> >>>> Thunderbird/38.8.0
> >>>>
> >>>> Dear CF community,
> >>>>
> >>>> traditionally, the variable sea_ice_thickness from CMIP-type model
> >>>> output was calculated by dividing the entire volume of sea ice in a grid
> >>>> cell by the entire area of the grid cell, independent of the area
> >>>> fraction of the grid cell that was actually covered by sea ice.
> >>>>
> >>>> This gave rise to substantial confusion for users who expected that
> >>>> sea_ice_thickness as stored within CMIP simulations refers to the actual
> >>>> sea-ice thickness that is used in the sea-ice model code to calculate
> >>>> heat fluxes, for example, rather than the average ice thickness that the
> >>>> ice would have if it were to cover the entire area of the grid cell
> >>>> while conserving its volume.
> >>>>
> >>>> To prevent such confusion in the future, we would like to add the
> >>>> following variable to the CF convention:
> >>>>
> >>>> 1. equivalent_sea_ice_thickness (new variable with units 'm3 m-2' or 'm')
> >>>> to describe sea-ice volume per grid-cell area
> >>>>
> >>>> The term "Equivalent sea-ice thickness" is known within the sea-ice
> >>>> community to refer to "sea-ice volume per grid-cell area". Ideally, we
> >>>> would have liked to suggest a variable name containing the term
> >>>> "volume", but this seems difficult within the CF convention as then
> >>>> units couldn't be 'm'.
> >>>>
> >>>> Thank you very much for any feedback, help and guidance.
> >>>>
> >>>> Best,
> >>>>
> >>>> Dirk Notz
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> ----
> >>>> Dr. Dirk Notz
> >>>> http://www.mpimet.mpg.de/~notz.dirk
> >>>> _______________________________________________
> >>>> CF-metadata mailing list
> >>>> CF-metadata at cgd.ucar.edu
> >>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >>>
> >>> ----- End forwarded message -----
> >>> _______________________________________________
> >>> CF-metadata mailing list
> >>> CF-metadata at cgd.ucar.edu
> >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >>>
> >
> > ----- End forwarded message -----
> > _______________________________________________
> > CF-metadata mailing list
> > CF-metadata at cgd.ucar.edu
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >

----- End forwarded message -----
Received on Thu Jul 21 2016 - 10:12:06 BST

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:42 BST

⇐ ⇒