Dear Dirk, Jonathan, Karl,
Thank you for your thorough consideration of the proposed name equivalent_sea_ice_thickness. I wholeheartedly agree with the conclusion that you reached and I have removed this name from the list of proposals.
Best wishes,
Alison
------
Alison Pamment Tel: +44 1235 778065
Centre for Environmental Data Analysis Email: alison.pamment at stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Campus, Didcot, OX11 0QX, U.K.
> -----Original Message-----
> From: CF-metadata [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf
> Of Dirk Notz
> Sent: 21 July 2016 21:43
> To: cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] CMIP6 Sea Ice MIP: Ice thickness
>
> Dear Karl, dear Jonathan,
>
> thanks for your helpful feedback. I in particular appreciate the point
> that these issues arise for a rather large number of additional
> variables, too, and that we hence must be able to expect users to read
> the cell_measures in addition to just the variable name.
>
> In the light of this discussion I hence withdraw the proposed name
> "equivalent_sea_ice_thickness" and we will describe it simply through
> the cell_methods as for CMIP5.
>
> Best,
>
> Dirk
>
>
>
> ----
> Dr. Dirk Notz
> http://www.mpimet.mpg.de/~notz.dirk
>
> Am 21.07.2016 um 18:44 schrieb Karl Taylor:
> > Dear all,
> >
> > I agree that standard name should describe the quantity itself, but not
> > how it's computed.
> >
> > I note that for CMIP5 data we tried to make it clear how the quantity
> > identified by "sea_ice_thickness" was calculated, first by including the
> > cell_measures:
> >
> > time: mean area: mean where sea
> >
> > and then by including a "comment" attribute that reads:
> >
> > "the mean thickness of sea ice in the ocean portion of the grid cell
> > (averaging over the entire ocean portion, including the ice-free
> > fraction). Reported as 0.0 in regions free of sea ice."
> >
> > I think users of this data could easily avoid misinterpreting it simply
> > by reading the attributes describing it.
> >
> > best regards,
> > Karl
> >
> >
> >
> > On 7/21/16 9:12 AM, Jonathan Gregory wrote:
> >> 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 -----
> >> _______________________________________________
> >> CF-metadata mailing list
> >> CF-metadata at cgd.ucar.edu
> >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >
> > _______________________________________________
> > CF-metadata mailing list
> > CF-metadata at cgd.ucar.edu
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Thu Aug 04 2016 - 18:47:54 BST
