Hi Seth,
Great, thanks again for the suggestions! Also, see another e-mail
thread for the total totals index that I just responded to. I tried to
give my thought process on including (or not including) the "_at_start"
and "_at_finish" standard names for the various stability indices that I
have been proposing. In a nutshell, I thought they were useful for the
lifted index, but not for some other indices I proposed.
I definitely agree with you and Philip with the "_at_start" standard
name vs. using "_at_origin." I included the "_at_start" phrase in the
lifted index definition below.
Sincerely,
Jonathan
On 5/29/2013 2:26 PM, Seth McGinnis wrote:
> Hi Jonathan,
>
> Looks good to me! I'm happy that it's useful for your case as well
> as the ones I'm proposing.
>
> Philip has suggested we switch from _at_origin to _at_start for the
> standard_names, arguing that it's less ambiguous.
>
> Any thoughts on that?
>
> Cheers,
>
> --Seth
>
>
> On Wed, 29 May 2013 11:06:28 -0400
> Jonathan Wrotny <jwrotny at aer.com> wrote:
>> Hi Seth,
>>
>> Finally getting back to you e-mail after a long weekend...
>>
>> You raise a good point about the two levels used for many of the stability
>> indices. You're right, it would be nice to have this information in the
>> definition for the these data products in case data users/modelers need it. I
>> think adding your two proposed standard names for the start and finish height
>> is a good idea. I've taken my proposed definition of lifted index and added
>> the sentence you suggested. Also, I added an additional sentence to discuss
>> the scenario where the parcel is not lifted "from the surface" but from
>> another pressure level. Here is my current proposal:
>>
>> Standard Name:
>>
> temperature_difference_between_ambient_air_and_air_lifted_adiabatically_from_the_surface
>> Definition:This quantity is defined as the temperature difference between a
>> parcel of air lifted adiabatically from the surface to a given air pressure in
>> the troposphere and the ambient air temperature at a given air pressure in the
>> troposphere. It is often called the lifted index (LI) and provides a measure
>> of the instability of the atmosphere. The air parcel is "lifted" by moving the
>> air parcel from the surface to the Lifting Condensation Level (dry
>> adiabatically) and then from the Lifting Condensation Level to a given air
>> pressure (wet adiabatically). Air temperature is the bulk temperature of the
>> air, not the surface (skin) temperature. The term "surface" means the lower
>> boundary of the atmosphere. A coordinate variable of
>> air_pressure_of_lifted_parcel_at_finish can be specified to indicate the
>> specific air pressure that the temperature difference is calculated at.If the
>> start point of the lifted parcel is not the ?surface,? then the phrase
>> ?from_the_surface? is removed from the standard name and a coordinate variable
>> of air_pressure_of_lifted_parcel_at_start can be specified to indicate the
>> specific air pressure at which the parcel lifting starts.
>>
>> Canonical Units:K
>>
>>
>> And, just to include them in this e-mail, the standard names/definitions/units
>> for the two coordinate variables:
>>
>> Standard_names:
>>
>> air_pressure_of_lifted_parcel_at_origin
>> air_pressure_of_lifted_parcel_at_finish
>>
>> Definitions:
>>
>> Various stability and convective potential indices are calculated by
>> "lifting" a parcel of air: moving it dry adiabatically from a starting
>> height (often the surface) to the Lifting Condensation Level, and then
>> wet adiabatically from there to an ending height (often the top of
>> the data/model/atmosphere). air_pressure_of_lifted_parcel_at_origin
>> [finish] is the pressure height at the start [end] of lifting.
>>
>> Canonical units: Pa
>>
>>
>> I will also revise the definition of the total totals index that I recently
>> submitted and includes the coordinate variables in two other stability indices
>> that I will post this week.
>>
>> How does this look now?
>>
>> Thanks again.
>>
>> -Jonathan
>>
>> On 5/24/2013 7:17 PM, Seth McGinnis wrote:
>>> Hi Jonathan,
>>>
>>> I would like to suggest a small modification to your proposal for the
>>> lifted index (LI) standard_name.
>>>
>>> I'm working on proposals for standard_names for CAPE, CIN, LCL, and
>>> LFC, all of which, like LI, are based on lifting a parcel of air
>>> adiabatically from one height to another.
>>>
>>> The unusual thing about these variables is that they're not associated
>>> with a single vertical coordinate, but with two of them: the starting
>>> height and the ending height. So if you want to record both end
>>> points, you need to do it in some way that lets you distinguish them.
>>>
>>> I thought about trying to do it with cell_bounds, but that doesn't
>>> seem like a good fit, because these aren't fields that exists within
>>> the cell and are being summarized, but things that are only defined
>>> relative to those two endpoints. So I think a better approach is to
>>> use a scalar auxilliary coordinate, analogous to the way that
>>> forecast_reference_time is used in example 5.11 in the CF spec.
>>>
>>>
>>> For that, we need two new standard_names:
>>>
>>> air_pressure_of_lifted_parcel_at_origin
>>> air_pressure_of_lifted_parcel_at_finish
>>>
>>> Which would have the following definitions:
>>>
>>> Various stability and convective potential indices are calculated by
>>> "lifting" a parcel of air: moving it dry adiabatically from a starting
>>> height (often the surface) to the Lifting Condensation Level, and then
>>> wet adiabatically from there to an ending height (often the top of
>>> the data/model/atmosphere). air_pressure_of_lifted_parcel_at_origin
>>> [finish] is the pressure height at the start [end] of lifting.
>>>
>>> Both would have canonical units of Pa
>>>
>>>
>>> I would then like to modify the last sentence in the definition of your
>>> LI standard_name to say "A coordinate variable of
>>> air_pressure_of_lifted_parcel_at_finish can be specified to indicate
>>> the specific air pressure that the temperature difference is
>>> calculated at."
>>>
>>>
>>> Does that seem like a good way to handle this aspect of your LI
>>> variable?
>>>
>>> It would then be consistent with other lifted parcel variables (once
>>> they get defined), and if anyone ever wanted to calculate LI from some
>>> starting point other than the ground, they could just lop off the
>>> "_from_the_surface" suffix from the standard_name and add the starting
>>> coordinate. (The wikipedia article on LI talks about it being
>>> calculated from "the portion of the PBL that lies below the morning
>>> inversion", so it seems like a possibility.)
>>>
>>> Cheers,
>>>
>>> --Seth
>>>
>>>
>>>
>>> On Wed, 22 May 2013 12:40:20 -0400
>>> Jonathan Wrotny <jwrotny at aer.com> wrote:
>>>> Hi Jonathan,
>>>>
>>>> Thanks a lot for the background on the CF conventions. This helps me quite
>> a
>>>> bit to understand the ideas behind the process.
>>>>
>>>> Yes, you are right about the surface question. The GOES-R product is not
>>>> referenced to a standard 'surface temperature' quantity, but just the
>> surface,
>>>> in general. So, I think your proposal makes good sense. So, to summarize,
>>>> here the proposed standard name/definition/units for this product:
>>>>
>>>> Standard Name:
>>>>
>>>>
>> temperature_difference_between_ambient_air_and_air_lifted_adiabatically_from_the_surface
>>>> Defintion:
>>>>
>>>> This quantity is defined as the temperature difference
>>>> between a parcel of air lifted adiabatically from the surface to a given
>>>> air pressure in the troposphere and the ambient air temperature at a
>>>> given air pressure in the troposphere. It is often called the lifted
>>>> index (LI) and provides a measure of the instability of the atmosphere.
>>>> The air parcel is "lifted" by moving the air parcel from the surface to
>>>> the Lifting Condensation Level (dry adiabatically) and then from the
>>>> Lifting Condensation Level to a given air pressure (wet adiabatically).
>>>> Air temperature is the bulk temperature of the air, not the surface
>>>> (skin) temperature. The term "surface" means the lower boundary of the
>>>> atmosphere. A coordinate variable of air_pressure can be specified to
>>>> indicate the specific air pressure that the temperature difference is
>>>> calculated at.
>>>>
>>>> Canonical Units: K
>>>>
>>>> Sincerely,
>>>>
>>>> Jonathan
>>>>
>>>>
>>>> On 5/22/2013 12:09 PM, Jonathan Gregory wrote:
>>>>> Dear Jonathan
>>>>>
>>>>> Thanks for your thoughts. Actually I agree with you. I would not try to
>>>> insist
>>>>> on a geophysical name in every case. It might be too contrived and it
>> would
>>>> not
>>>>> be helpful if there was very little chance that the generality would ever
>> be
>>>>> useful. I prefer geophysically orientated general-purpose names whenever
>> we
>>>>> can adopt them, because they are more self-explanatory and because they
>>>> limit
>>>>> the number of names we have to define. We have to be pragmatic, and the
>>>> result
>>>>> is that the standard name table reflects a mixture of approaches, some
>>>> general,
>>>>> some very specific to applications. That's life.
>>>>>
>>>>> If you really mean "the surface", not "surface air" in the meteorological
>>>> obs
>>>>> sense, perhaps it would be clearer as
>>>>>
>>>>>
>> temperature_difference_between_ambient_air_and_air_lifted_adiabatically_from_the_surface
>>>>> That obviously avoids the need for a surface height coordinate. "The
>>>> surface"
>>>>> (the bottom of the atmosphere), being a named well-defined surface, does
>> not
>>>>> need a coordinate. It just has a name, and it appears in many standard
>>>> names.
>>>>> So you have a need for only one coordinate, to specify the level of the
>>>> ambient
>>>>> air. That could be a pressure coordinate or an altitude or anything you
>> like
>>>> -
>>>>> I think you could allow that flexibility in the definition.
>>>>>
>>>>> Best wishes
>>>>>
>>>>> Jonathan
>>>>>
>>>>> ----- Forwarded message from Jonathan Wrotny <jwrotny at aer.com> -----
>>>>>
>>>>>> Date: Wed, 22 May 2013 11:29:34 -0400
>>>>>> From: Jonathan Wrotny <jwrotny at aer.com>
>>>>>> User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130509
>>>>>> Thunderbird/17.0.6
>>>>>> To: Jonathan Gregory <j.m.gregory at reading.ac.uk>
>>>>>> CC: cf-metadata at cgd.ucar.edu
>>>>>> Subject: Re: [CF-metadata] new standard name: lifted_index
>>>>>>
>>>>>> Hello Jonathan,
>>>>>>
>>>>>> I still think the standard names for the stability indices are a bit
>>>>>> of a conundrum, but I do understand the desire to attempt to devise
>>>>>> a general sounding name for each product. I believe that most
>>>>>> physical quantities are general enough to easily fit into the CF
>>>>>> standard naming paradigm, i.e. attempt to phrase a name with general
>>>>>> atmospheric terms combined with ampersands into something that, as
>>>>>> you described it, is almost a description (vs. a name). To me, there
>>>>>> are always some very specific quantities (e.g. stability indices,
>>>>>> NDVI, etc.) which are by definition *not* general and are one-off
>>>>>> ad-hoc quantities. I could see a scenario where these types of
>>>>>> products are their own special category with the CF - and, thus,
>>>>>> have unique, non-generalized, names - while the large majority are
>>>>>> more general and are easily adaptable to the CF naming paradigm. My
>>>>>> take is that you think that this type of product delineation in the
>>>>>> CF is not ideal in order to have cross-discipline use and
>>>>>> consistency for all the standard names, and thus are suggesting to
>>>>>> attempt to generalize each quantity if at all possible. This seems
>>>>>> to work in general but can cause issues with products like the
>>>>>> stability indices. The confusing aspect of this approach is that
>>>>>> now some of the stability index products will have general sounding
>>>>>> names (e.g. the proposed name for the lifted index) versus the total
>>>>>> totals index which is too complex to generalize. I'm not sure if
>>>>>> this is really a problem or not for the data users/modelers, but it
>>>>>> is a little strange. Maybe it is the only way to handle this
>>>>>> somewhat unique situation. Bottom line, I'm OK with your proposed
>>>>>> names - the general one for the lifted index and the specific one
>>>>>> for the total totals index, but wanted to present some of my
>>>>>> thoughts as I've worked through this myself. Maybe you will have
>>>>>> some comments.
>>>>>>
>>>>>> Re: the surface air, question. Yes, I forgot to reply to this
>>>>>> question in my last reply to you. The level of the "surface air' is
>>>>>> not the screen height in the GOES-R product but is from the NWP
>>>>>> surface pressure interpolated to the time of the GOES-R product and
>>>>>> the horizontal spatial grid. This information is not in the
>>>>>> delivered product, however. But, including the pressure level that
>>>>>> the lifted index is calculated could occur with a coordinate
>>>>>> variable. It appears that the proposed definition mentions a
>>>>>> coordinate variable that would include this level.
>>>>>>
>>>>>> Sincerely,
>>>>>>
>>>>>> Jonathan
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 5/21/2013 5:34 PM, Jonathan Gregory wrote:
>>>>>>> Dear Jon
>>>>>>>
>>>>>>> Thanks for considering my comments on this one
>>>>>>>
>>>>>>>> Standard Name:
>> temperature_difference_between_ambient_air_and_surface_air_lifted_adiabatically
>>>>>>> I'm glad you're happy with a general name in this case. I am interested
>> in
>>>>>>> your response to Philip's question about how surface is defined here. It
>>>>>>> might mean "surface air" in the sense of "screen height", I suppose. In
>>>> the
>>>>>>> standard name table, we do not actually have "surface air", because we
>>>> expect
>>>>>>> the actual screen height to be explicitly given as a height coordinate
>>>> (1.5 m
>>>>>>> or whatever). If that is the case, maybe this standard name should
>> depend
>>>> on
>>>>>>> two vertical coordinates, and maybe it should be further generalised to
>>>>>>> ..._and_air_lifted_adiabatically. But that might be too general! What do
>>>>>>> you think?
>>>>>>>
>>>>>>> Best wishes
>>>>>>>
>>>>>>> Jonathan
>>>>>>> _______________________________________________
>>>>>>> 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 Wed May 29 2013 - 12:39:53 BST
