Hi Karl,
These names are aimed at ice sheet models, not climate models, so I
don't believe we do.
With respect to the definition of ice: it is the opposite. We ask that
firn is output as a separate quantity, not included as part of land_ice.
Hope that helps.
Tamsin
> Date: Wed, 25 Jan 2012 08:43:45 -0800
> From: Karl Taylor<taylor13 at llnl.gov>
> Subject: Re: [CF-metadata] Request for new land_ice and firn standard
> names
> To: cf-metadata at cgd.ucar.edu
> Message-ID:<4F203141.4080904 at llnl.gov>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
> Hello,
>
> There is no mention of snow or surface melt water (ponds). Should
> something explicit be said about including/excluding these in any of
> definitions below? Also, if I understand correctly, I would be explicit
> that
>
> "Land ice" means glaciers, ice-caps and ice-sheets resting on bedrock
> and also includes ice-shelves. "Fern" is included as part of "land ice".
>
> cheers,
> Karl
>
> On 1/25/12 5:44 AM, Tamsin Edwards wrote:
>> Hello,
>>
>> I would like to request the following new standard names and one
>> deprecation. I've attempted to give definitions that are consistent with
>> related names in the table.
>>
>>
>> 1. land_ice_mass_accumulation_rate (m s-1)
>>
>> "Land ice" means glaciers, ice-caps and ice-sheets resting on bedrock
>> and also includes ice-shelves. The accumulation rate is the rate at
>> which ice is added per unit area at the land ice surface.
>>
>> 2. runoff_rate (m s-1)
>>
>> Runoff is the liquid water which drains from land. If not specified,
>> "runoff" refers to the sum of surface runoff and subsurface drainage.
>> The runoff rate is the rate at which water is lost per unit area.
>>
>> 3. land_ice_basal_altitude (m)
>>
>> "Land ice" means glaciers, ice-caps and ice-sheets resting on bedrock
>> and also includes ice-shelves. Altitude is the (geometric) height above
>> the geoid, which is the reference geopotential surface. The geoid is
>> similar to mean sea level. Basal altitude is the altitude of the base of
>> the ice.
>>
>> 4. land_ice_thickness_excluding_firn (m)
>>
>> "Land ice" means glaciers, ice-caps and ice-sheets resting on bedrock
>> and also includes ice-shelves. "Firn" means partially-compacted snow on
>> the land ice surface. "Thickness" means the vertical extent of a layer.
>> Land ice thickness excluding firn means thickness of only the land ice
>> and not the firn layer.
>>
>> 5. firn_thickness (m)
>>
>> "Firn" means partially-compacted snow on the land ice surface.
>> "Thickness" means the vertical extent of a layer. Firn thickness means
>> thickness of the firn layer.
>>
>> 6. land_ice_and_firn_thickness (m)
>>
>> "Land ice" means glaciers, ice-caps and ice-sheets resting on bedrock
>> and also includes ice-shelves. "Firn" means partially-compacted snow on
>> the land ice surface. "Thickness" means the vertical extent of a layer.
>> Land ice and firn thickness means the total thickness of land ice and
>> the firn layer.
>>
>> 7. land_ice_and_firn_thickness_expressed_as_ice_equivalent (m)
>>
>> "Land ice" means glaciers, ice-caps and ice-sheets resting on bedrock
>> and also includes ice-shelves. "Firn" means partially-compacted snow on
>> the land ice surface. "Thickness" means the vertical extent of a layer.
>> Land ice and firn thickness expressed as ice equivalent means the total
>> thickness of land ice and the firn layer if the firn were converted to ice.
>>
>>
>> I would like to propose that land_ice_thickness be deprecated due to
>> vagueness.
>>
>> Best wishes,
>>
>> Tamsin
>>
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:<http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20120125/1c9054df/attachment-0001.html>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 25 Jan 2012 19:16:00 -0500
> From: Randy Horne<rhorne at excaliburlabs.com>
> Subject: Re: [CF-metadata] Non-standard dimensionless vertical
> coordinates
> To: cf-metadata at cgd.ucar.edu
> Message-ID:<27E964AB-8439-4BAE-B103-75F50551E7E8 at excaliburlabs.com>
> Content-Type: text/plain; charset=windows-1252
>
> Further analysis (and help from Steve Hankin) revealed that I had misunderstanding on the constraints associated with the values elements in a coordinate variable could have. Just as long as successive values are increasing or decreasing, the coordinate variable element values are CF compliant.
>
> Once I got past this issue, the rest of CF compliant data declaration fell into place. Here are the key aspects of the CF compliant solution
>
> (1)
> The vertical coordinates associated with the data set is in fact dimensional. The coordinates represent increasing pressure levels in hectopascals (hPa).
> (2)
> The vertical pressure levels reported are not contiguous, and, in fact, represent discrete samples based on need. Thus, the new conventions associated with discrete sampling geometries applies. The feature type associated with our product is "profile".
> (3)
> The axis attribute needed to be set to "Z" to ensure it is clear that the pressure level variable is the vertical dimension coordinate variable.
>
> Following is an example:
>
> attributes:
>
> :featureType = ?profile?;
>
> dimensions:
>
> time = 1;
>
> y = 10;
>
> x = 10;
>
> pressure_levels = 101;
>
> variables:
>
> short profile_data (time, y, x, pressure_levels);
>
> .
>
> .
>
> :coordinates = "time y x pressure_levels";
>
> .
>
> .
>
> float pressure_levels (pressure_levels);
>
> :standard_name = ?...?
>
> :long_name = ?pressure?
>
> :units = "hPa";
>
> :axis = "Z";
>
>
> Note that in this data declaration, the profile_data at the 101 levels in the atmosphere at each x,y in the grid varies most rapidly. This is as a result of the inherent characteristics of the data processing required to generate the product file.
>
>
>
>
>
>
> On Jan 24, 2012, at 1:00 PM, Randy Horne wrote:
>
>> On the program I am working, we have temperature and pressure profile products where data values are generated for multiple pressure levels in the atmosphere (i.e. the z-axis). Dimensionless vertical coordinates as defined in paragraph 4.3.2 of the CF metadata document appears to be the best way to establish coordinates for the data values at the different pressure levels. Unfortunately, the various formula options defined in Appendix D. Dimensionless Vertical Coordinates do not work for the pressure levels that are reported in our temperature and pressure profile products. In fact, because of the non-linear and non-exponential characteristics of the reported pressure levels, it is unlikely any type of simple formula can be constructed to provide a mapping between monotonically increasing integers and reported pressure levels.
>>
>> Any thoughts as to what other options we have to handle this ?
>>
>>
>>
>> ..............End of Message ...............................-->
>>
>>
>>
>>
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
>
>
> ____________________________________
>
> Randy C. Horne (rhorne at excaliburlabs.com)
> Principal Engineer, Excalibur Laboratories Inc.
> voice& fax: (321) 952.5100
> url: http://www.excaliburlabs.com
>
>
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 26 Jan 2012 10:48:14 +0000
> From: Jonathan Gregory<j.m.gregory at reading.ac.uk>
> Subject: Re: [CF-metadata] Regions, Gazetteer, etc
> To: John Graybeal<jbgraybeal at mindspring.com>
> Cc: CF Metadata List<cf-metadata at cgd.ucar.edu>
> Message-ID:<20120126104814.GA16594 at met.reading.ac.uk>
> Content-Type: text/plain; charset=us-ascii
>
> Dear John
>
>> Could you say a bit more about this requirement? In particular, "plain text with nothing but the list in it" and "machine-readable" aren't entirely contradictory, but may preclude more complex representations that are appropriate, no? (I'm not an expert in gazetteer representation, but being able to represent e.g., hierarchies of metadata gets tricky, I'm guessing. Is something like XML or RDF close enough to plain text to meet this goal/requirement?
>
> The main problem I was getting at is that a discursive HTML document is
> difficult for a program to use! A table in XML, for instance, would be OK,
> I agree. If it were primarily in XML, it would be helpful to provide a more
> human-readable version as well (e.g. the discursive HTML form). A plain-text
> file has the advantage of being both human- and machine-readable, doesn't it.
>
> Best wishes
>
> Jonathan
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 26 Jan 2012 10:57:11 +0000
> From: Jonathan Gregory<j.m.gregory at reading.ac.uk>
> Subject: Re: [CF-metadata] mailing list and trac tickets
> To: cf-metadata at cgd.ucar.edu
> Message-ID:<20120126105711.GB16788 at met.reading.ac.uk>
> Content-Type: text/plain; charset=us-ascii
>
> Dear all
>
> Thanks for your replies about this. In an off-list discussion, we are trying
> to work out how to deliver trac tickets to everyone.
>
> Best wishes
>
> Jonathan
>
>
> ------------------------------
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
> End of CF-metadata Digest, Vol 105, Issue 11
> ********************************************
Received on Fri Jan 27 2012 - 02:53:13 GMT
