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
Received on Thu Jul 21 2016 - 10:44:43 BST
