Dear Richard,
I, for one, agree that clarification is needed, and would encourage you
to open a ticket labeled "defect", since I think all that is needed is
modification of the text (probably along the lines you suggest). No
change/addition to the convention is called for.
thanks for taking the initiative.
best regards,
Karl
On 9/14/12 2:19 AM, Hattersley, Richard wrote:
> Dear Jonathan,
>
> Thanks for clarifying.
>
> The original source of the confusion was example 4.3, where the
> dimensionless vertical coordinate is itself one of the formula terms.
> Similarly for hybrid height (where the "dimensionless" vertical
> coordinate isn't even dimensionless!)
>
> I've been through this discussion with several people prior to bringing
> it to this mailing list, and no one could provide a definitive answer on
> the expected behaviour. But slowly we settled on the definition that you
> have confirmed. So I think CF would benefit from a couple of
> clarifications. Firstly in the written description in section 4.3.2
> (dimensionless vertical coordinate), and the choice of example. And also
> in appendix D, where the description of what constitutes the
> dimensionless vertical coordinate is not consistent across schemes -
> sometimes it's "hidden" inline within the term descriptions; other times
> it's a distinct sentence of its own.
>
> Should I create a trac ticket containing a proposed clarification?
>
> Richard Hattersley AVD Iris Technical Lead
> Met Office FitzRoy Road Exeter Devon EX1 3PB United Kingdom
> Tel: +44 (0)1392 885702 Fax: +44 (0)1392 885681
> Email: richard.hattersley at metoffice.gov.uk Website:
> www.metoffice.gov.uk
>
>
>> -----Original Message-----
>> From: Jonathan Gregory [mailto:j.m.gregory at reading.ac.uk]
>> Sent: 10 September 2012 09:42
>> To: Hattersley, Richard
>> Cc: cf-metadata at cgd.ucar.edu
>> Subject: [CF-metadata] Dimensionless vertical coordinate values
>>
>> Dear Richard
>>
>> On Mon, Aug 20, 2012 at 05:05:52PM +0100, Hattersley, Richard wrote:
>>>
>>> I'm glad you think the first example makes sense - it's the one that
>>> makes most sense to me too! But I'm wondering if one *must* store
>>> ap(z)/p0+b(z) (or a(k)+b(k) if that's the parameterisation
>> in use), or
>>> if one could store something else and still be a valid CF file?
>> Yes, I think one *must* store ap(z)/p0+b(z) or a(k)+b(k) in z
>> because that's
>> what the standard_name and units of the vertical coordinate
>> indicate z to be.
>> In your example
>>
>> float z(z) ;
>> z:standard_name =
>> "atmosphere_hybrid_sigma_pressure_coordinate" ;
>> z:units = "1" ;
>> z:formula_terms = "ap: delta b: sigma ps:
>> surface_pressure" ;
>> z:positive = "down" ;
>>
>> z says it's the atmosphere_hybrid_sigma_pressure_coordinate.
>> I think that
>> ap is the pressure part of the
>> atmosphere_hybrid_sigma_pressure_coordinate and
>> b is the sigma part of the
>> atmosphere_hybrid_sigma_pressure_coordinate. Neither
>> of them alone is the
>> atmosphere_hybrid_sigma_pressure_coordinate, so the
>> standard_name would be wrong if you stored either of the
>> components in z.
>> Also, if you stored the pressure part (ap) in z, the units
>> would be wrong as
>> well; the units say z is dimensionless, but ap is in Pa.
>>
>> If this is right, should we clarify the convention text is some way?
>>
>> Best wishes
>>
>> Jonathan
>>
> _______________________________________________
> 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/20120914/5bc64377/attachment.html>
Received on Fri Sep 14 2012 - 09:19:33 BST
