[CF-metadata] atmosphere stability indices
Dear all I chose a new subject because these threads about lifted_index, total_totals_ index and Seth's new standard names for CIN etc. are closely related. I agree with the suggestion from Philip to include _from_the_surface on names referring to surface parcels (it was previously clarified that really means from the surface, not surface air i.e. screen height), and omit it when the parcel comes from a different level that is identified by a numeric coordinate. That is consistent with the general pattern that special physical surfaces (such as the surface i.e. bottom of atmos) appear by name in standard_names when relevant, whereas levels specified by coordinates do not. Excuse my making a late suggestion on another matter. I think start and finish are OK but they make it sound like a real trajectory, whereas these are just calculations from the state of the atmos. I would therefore like to suggest source (for start), which has the same sense of where the parcel came from that origin has, but doesn't have the potential confusion. E.g. air_pressure_of_lifted_parcel_at_source. What do you think? As for finish, which names require this? I wonder about using ambient for finish, in cases where the idea is to compare the parcel with the environment at the end of its notional journey. Again, what do you think? Going back to Seth's proposal, I wonder if atmosphere_specific_convective_inhibition atmosphere_specific_convective_available_potential_energy are really best regarded as a trajectory. They are integral quantities. In those two cases, I suggest it would be fairly natural to give them bounds in a vertical coordinate to indicate the limits of integration. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
[CF-metadata] new standard name: atmosphere_stability_k_index
Dear Jonathan This appears to be a very ad-hoc quantity, and I agree it would not make sense to try to devise a general physical name for it. Adding atmosphere_stability, as with the total totals index, provides useful information on what sort of quantity is it, taking a step towards making it self-explanatory. Thanks Jonathan - Forwarded message from Jonathan Wrotny jwro...@aer.com - Date: Wed, 29 May 2013 15:42:05 -0400 From: Jonathan Wrotny jwro...@aer.com User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 To: cf-metadata@cgd.ucar.edu Subject: [CF-metadata] new standard name: atmosphere_stability_k_index Dear CF board: I would like to propose the following standard name: atmosphere_stability_k_index with the associate definition: The atmosphere_stability_k_index is an index that indicates the potential of severe convection and is often referred to a simply the k index. The index is derived from the difference in air temperature between 850 and 500 hPa, the dew point temperature at 850 hPa, and the difference between the air temperature and the dew point temperature at 700 hPa. and the canonical units of: C NOTE: This proposed product using fixed pressure levels of 850, 700, and 500 hPa for calculating the index which are unique to this product, thus these values are included in the definition. Sincerely, Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata - End forwarded message - ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Precise location example
Dear Mike You nailed it, Mike. H.5 is the intended illustration where A9.2.3.2 is referenced. Thanks for pointing out the error. - Steve Thanks for spotting this, Mike. Please could you open a defect trac ticket to have it corrected? Cheers Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] CF-1.6 DSG clarification: time series lat/lon coordinates
Hi Jonathan: On 6/4/2013 4:17 AM, Jonathan Gregory wrote: Dear John Caron and John Maurer I agree with John C that the problem arises when the coordinate variables are not size one. John M's example float lon(lon) ; float lat(lat) ; float alt(alt) ; float temp(time, alt, lat, lon) ; temp:standard_name = ?air_temperature? ; temp:units = Celsius ; temp:coordinates = time lat lon alt ; temp:_FillValue = -999.9; with alt=lat=lon=1 is legal in CF. In fact the coordinates attribute is not needed, because these are all (Unidata) coordinate variables (1D, with name of the variable equal to the name of the dimension). Ignoring the coordinates attribute, this example is fine in COARDS as well. In the data model, lon lat alt time are all dimension coordinate constructs with separate domain axes. But when there are *two* timeseries, you would not have alt=lat=lon=2. That would mean three independent size-2 dimensions. This would also be legal in CF and COARDS, but it means timeseries at a grid of 8 points, not two points. To deal with this situation, we introduce an index dimension of size 2, and make alt lat lon auxiliary coordinate variables of this single dimension. In the data model, there is then only one domain axis for alt lat lon. Back to the case of one timeseries: Example H4 shows scalar coordinate variables for alt lat lon. That is, these size-1 dimensions have been omitted. In this case, the coordinates attribute is needed; that's how scalar coordinate variables are attached to the data variable. In the data model (in my opinion) this is logically equivalent including the size-1 dimensions. Lets see, its currently not legal as a DSG file, according to the spec. The CDM will barf on it, though I could put in a workaround. Should it be legal? That is, should people be allowed to put in extraneous dimensions that only make sense for some values of the dimension length (eg 1 but not 1) ? I think it would be a rather ugly wart, and you would gain no new functionality. I also think it would confuse dimensions with coordinates (which has already happened because the distinction isnt obvious). I think we should try to be clear about the use of dimensions because it makes the data model more powerful. So I would prefer not. Maybe this question raises an issue for chapter 9 and Example H4. The example is following Section 9.2: If there is only a single feature to be stored in a data variable, there is no need for an instance dimension and it is permitted to omit it. The data will then be one-dimensional, which is a special (degenerate) case of the multidimensional array representation. The instance variables will be scalar coordinate variables; the data variable and other auxiliary coordinate variables will have only an element dimension and not have an instance dimension, e.g. data(o) and t(o) for a single timeSeries. In the multidimensional array representation, featureType doesn't have to be coded, because this representation has always existed in CF. We could say that *if* you encode featureType, there *must* be an instance dimension (of size 1 if appropriate) and that alt lat lon must be auxiliary coordinate variables with this dimension. That would be a restriction we don't have in CF 1.6, so it would be a change to CF. What do you think, John C? I think this is a seperate question yes? From my POV, its just a practical question to make things clear between data producer and consumer. I think we allowed the scalar instance coordinates because it was a natural way for producers to think when there was only one feature in the file, ie why do you want me to add this extra dimension? As long as the featureType attribute is present, as well as the coordinates attribute I think the meaning is unambiguous. Requiring a dimension=1 is maybe a bit simpler, but i would still have to deal with the scalar case for versions before we change, so its not really better for me. John Caron ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] CF-1.6 DSG clarification: time series lat/lon coordinates
Dear John C I think the two questions are linked actually. There is nothing wrong with the size-1 dimensions in general, I would say. You could see it as a single point extracted from a larger gridded field (time,atl,lat,lon) in which all the dimensions were originally greater than one. It's legal in the orthogonal multidimensional representation, which is the one representation which has always existed in CF. When we added ch9, we brought that representation into the same chapter. If the CDM doesn't like the orthogonal multidimensional representation for DSG, we could disallow featureType if that representation is used. Then the CDM wouldn't attempt to process it as a DSG. It would be a pity to lose the extra metadata that the featureType provides, though. Best wishes Jonathan - Forwarded message from John Caron ca...@unidata.ucar.edu - Date: Tue, 4 Jun 2013 10:54:45 -0600 From: John Caron ca...@unidata.ucar.edu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 To: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] CF-1.6 DSG clarification: time series lat/lon coordinates Hi Jonathan: On 6/4/2013 4:17 AM, Jonathan Gregory wrote: Dear John Caron and John Maurer I agree with John C that the problem arises when the coordinate variables are not size one. John M's example float lon(lon) ; float lat(lat) ; float alt(alt) ; float temp(time, alt, lat, lon) ; temp:standard_name = ?air_temperature? ; temp:units = Celsius ; temp:coordinates = time lat lon alt ; temp:_FillValue = -999.9; with alt=lat=lon=1 is legal in CF. In fact the coordinates attribute is not needed, because these are all (Unidata) coordinate variables (1D, with name of the variable equal to the name of the dimension). Ignoring the coordinates attribute, this example is fine in COARDS as well. In the data model, lon lat alt time are all dimension coordinate constructs with separate domain axes. But when there are *two* timeseries, you would not have alt=lat=lon=2. That would mean three independent size-2 dimensions. This would also be legal in CF and COARDS, but it means timeseries at a grid of 8 points, not two points. To deal with this situation, we introduce an index dimension of size 2, and make alt lat lon auxiliary coordinate variables of this single dimension. In the data model, there is then only one domain axis for alt lat lon. Back to the case of one timeseries: Example H4 shows scalar coordinate variables for alt lat lon. That is, these size-1 dimensions have been omitted. In this case, the coordinates attribute is needed; that's how scalar coordinate variables are attached to the data variable. In the data model (in my opinion) this is logically equivalent including the size-1 dimensions. Lets see, its currently not legal as a DSG file, according to the spec. The CDM will barf on it, though I could put in a workaround. Should it be legal? That is, should people be allowed to put in extraneous dimensions that only make sense for some values of the dimension length (eg 1 but not 1) ? I think it would be a rather ugly wart, and you would gain no new functionality. I also think it would confuse dimensions with coordinates (which has already happened because the distinction isnt obvious). I think we should try to be clear about the use of dimensions because it makes the data model more powerful. So I would prefer not. Maybe this question raises an issue for chapter 9 and Example H4. The example is following Section 9.2: If there is only a single feature to be stored in a data variable, there is no need for an instance dimension and it is permitted to omit it. The data will then be one-dimensional, which is a special (degenerate) case of the multidimensional array representation. The instance variables will be scalar coordinate variables; the data variable and other auxiliary coordinate variables will have only an element dimension and not have an instance dimension, e.g. data(o) and t(o) for a single timeSeries. In the multidimensional array representation, featureType doesn't have to be coded, because this representation has always existed in CF. We could say that *if* you encode featureType, there *must* be an instance dimension (of size 1 if appropriate) and that alt lat lon must be auxiliary coordinate variables with this dimension. That would be a restriction we don't have in CF 1.6, so it would be a change to CF. What do you think, John C? I think this is a seperate question yes? From my POV, its just a practical question to make things clear between data producer and consumer. I think we allowed the scalar instance coordinates because it was a natural way for producers to think when there was only one feature in the file, ie why do you want me to add this extra dimension? As long as
Re: [CF-metadata] atmosphere stability indices
Dear Jonathan Gregory, Thanks for creating the new thread I see your point on how start and finish could imply a trajectory and that we should avoid this. I like the word source instead of start. Ambient doesn't imply any height, in and of itself. But, since it is used in the standard name and definition, hopefully it is clear to others that it refers to the final pressure level in the notional journey of the lifted parcel, like you say. I'm not sure of the best names for the coordinate variables, but here is my crack at them. Perhaps Seth can chime in and make any suggestions he has - hopefully this doesn't throw off his proposed definitions too much. Associated coordinate variables: Standard_names: air_pressure_of_lifted_parcel_at_source ambient_air_pressure_of_lifted_parcel 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_source and ambient_air_pressure_of_lifted_parcel are the pressure heights at the start and end of lifting, respectively. Canonical units: Pa The only one of the four stability indices that I have proposed which uses these coordinate variables is the lifted index. I will wait to send an updated definition for the lifted index once we have resolved the coordinate variables question. Sincerely, Jonathan On 6/4/2013 5:28 AM, Jonathan Gregory wrote: Dear all I chose a new subject because these threads about lifted_index, total_totals_ index and Seth's new standard names for CIN etc. are closely related. I agree with the suggestion from Philip to include _from_the_surface on names referring to surface parcels (it was previously clarified that really means from the surface, not surface air i.e. screen height), and omit it when the parcel comes from a different level that is identified by a numeric coordinate. That is consistent with the general pattern that special physical surfaces (such as the surface i.e. bottom of atmos) appear by name in standard_names when relevant, whereas levels specified by coordinates do not. Excuse my making a late suggestion on another matter. I think start and finish are OK but they make it sound like a real trajectory, whereas these are just calculations from the state of the atmos. I would therefore like to suggest source (for start), which has the same sense of where the parcel came from that origin has, but doesn't have the potential confusion. E.g. air_pressure_of_lifted_parcel_at_source. What do you think? As for finish, which names require this? I wonder about using ambient for finish, in cases where the idea is to compare the parcel with the environment at the end of its notional journey. Again, what do you think? Going back to Seth's proposal, I wonder if atmosphere_specific_convective_inhibition atmosphere_specific_convective_available_potential_energy are really best regarded as a trajectory. They are integral quantities. In those two cases, I suggest it would be fairly natural to give them bounds in a vertical coordinate to indicate the limits of integration. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] atmosphere stability indices
Another option is to use the term sink instead of ambient, which would be more
parallel to source and attribute less semantic knowledge about the destination
location. Then air_pressure_of_lifted_parcel_at_sink would be a good analog.
('Destination' is another option too.)
On Jun 4, 2013, at 14:02, Jonathan Wrotny jwro...@aer.com wrote:
Dear Jonathan Gregory,
Thanks for creating the new thread
I see your point on how start and finish could imply a trajectory and
that we should avoid this. I like the word source instead of start.
Ambient doesn't imply any height, in and of itself. But, since it is used
in the standard name and definition, hopefully it is clear to others that it
refers to the final pressure level in the notional journey of the lifted
parcel, like you say. I'm not sure of the best names for the coordinate
variables, but here is my crack at them. Perhaps Seth can chime in and make
any suggestions he has - hopefully this doesn't throw off his proposed
definitions too much.
Associated coordinate variables:
Standard_names:
air_pressure_of_lifted_parcel_at_source
ambient_air_pressure_of_lifted_parcel
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_source and
ambient_air_pressure_of_lifted_parcel are the pressure heights at the start
and end of lifting, respectively.
Canonical units: Pa
The only one of the four stability indices that I have proposed which uses
these coordinate variables is the lifted index. I will wait to send an
updated definition for the lifted index once we have resolved the coordinate
variables question.
Sincerely,
Jonathan
On 6/4/2013 5:28 AM, Jonathan Gregory wrote:
Dear all
I chose a new subject because these threads about lifted_index, total_totals_
index and Seth's new standard names for CIN etc. are closely related.
I agree with the suggestion from Philip to include _from_the_surface on names
referring to surface parcels (it was previously clarified that really means
from the surface, not surface air i.e. screen height), and omit it when the
parcel comes from a different level that is identified by a numeric
coordinate.
That is consistent with the general pattern that special physical surfaces
(such as the surface i.e. bottom of atmos) appear by name in standard_names
when relevant, whereas levels specified by coordinates do not.
Excuse my making a late suggestion on another matter. I think start and
finish are OK but they make it sound like a real trajectory, whereas these
are just calculations from the state of the atmos. I would therefore like to
suggest source (for start), which has the same sense of where the parcel
came from that origin has, but doesn't have the potential confusion. E.g.
air_pressure_of_lifted_parcel_at_source. What do you think?
As for finish, which names require this? I wonder about using ambient for
finish, in cases where the idea is to compare the parcel with the
environment
at the end of its notional journey. Again, what do you think?
Going back to Seth's proposal, I wonder if
atmosphere_specific_convective_inhibition
atmosphere_specific_convective_available_potential_energy
are really best regarded as a trajectory. They are integral quantities. In
those two cases, I suggest it would be fairly natural to give them bounds in
a vertical coordinate to indicate the limits of integration.
Best wishes
Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
---
John Graybeal
Marine Metadata Interoperability Project: http://marinemetadata.org
grayb...@marinemetadata.org
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] atmosphere stability indices
Hi Jonathan (G), I had thought we needed the finish level for CAPE and CIN, but after consulting with a colleague, I realize we actually don't need it. For the CAPE CIN calculations, you integrate until the parcel hits equilibrium. I am assured that it will suffice just to mention that in the definition of the standard_name, and that there's no need to record the actual location of equilibrium level as an ancillary coordinate. (It's pretty much always the tropopause, and it's almost never interesting.) So I say let's abandon the air_pressure_of_lifted_parcel_at_finish standard name entirely, and just add a standard_name for the pressure at the start of lifting. I'm equally happy with _at_start, _at_origin, or _at_source for that. If we're worried about being as clear as possible, should we consider air_pressure_of_lifted_parcel_at_start_of_lifting? It's clunky, but unlikely to be misinterpreted... I'll update my proposed names in a separate messages. Cheers, --Seth On Tue, 4 Jun 2013 10:28:50 +0100 Jonathan Gregory j.m.greg...@reading.ac.uk wrote: Dear all I chose a new subject because these threads about lifted_index, total_totals_ index and Seth's new standard names for CIN etc. are closely related. I agree with the suggestion from Philip to include _from_the_surface on names referring to surface parcels (it was previously clarified that really means from the surface, not surface air i.e. screen height), and omit it when the parcel comes from a different level that is identified by a numeric coordinate. That is consistent with the general pattern that special physical surfaces (such as the surface i.e. bottom of atmos) appear by name in standard_names when relevant, whereas levels specified by coordinates do not. Excuse my making a late suggestion on another matter. I think start and finish are OK but they make it sound like a real trajectory, whereas these are just calculations from the state of the atmos. I would therefore like to suggest source (for start), which has the same sense of where the parcel came from that origin has, but doesn't have the potential confusion. E.g. air_pressure_of_lifted_parcel_at_source. What do you think? As for finish, which names require this? I wonder about using ambient for finish, in cases where the idea is to compare the parcel with the environment at the end of its notional journey. Again, what do you think? Going back to Seth's proposal, I wonder if atmosphere_specific_convective_inhibition atmosphere_specific_convective_available_potential_energy are really best regarded as a trajectory. They are integral quantities. In those two cases, I suggest it would be fairly natural to give them bounds in a vertical coordinate to indicate the limits of integration. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] CF-1.6 DSG clarification: time series lat/lon coordinates
Hi Jonathan: If we use the time series featureType as example (from http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#idp8307552) AFAIU, the orthogonal multidimensional representation would be: float humidity(station,time) not float humidity(lat, lon, time) Regards, John On 6/4/2013 11:33 AM, Jonathan Gregory wrote: Dear John C I think the two questions are linked actually. There is nothing wrong with the size-1 dimensions in general, I would say. You could see it as a single point extracted from a larger gridded field (time,atl,lat,lon) in which all the dimensions were originally greater than one. It's legal in the orthogonal multidimensional representation, which is the one representation which has always existed in CF. When we added ch9, we brought that representation into the same chapter. If the CDM doesn't like the orthogonal multidimensional representation for DSG, we could disallow featureType if that representation is used. Then the CDM wouldn't attempt to process it as a DSG. It would be a pity to lose the extra metadata that the featureType provides, though. Best wishes Jonathan - Forwarded message from John Caron ca...@unidata.ucar.edu - Date: Tue, 4 Jun 2013 10:54:45 -0600 From: John Caron ca...@unidata.ucar.edu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 To: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] CF-1.6 DSG clarification: time series lat/lon coordinates Hi Jonathan: On 6/4/2013 4:17 AM, Jonathan Gregory wrote: Dear John Caron and John Maurer I agree with John C that the problem arises when the coordinate variables are not size one. John M's example float lon(lon) ; float lat(lat) ; float alt(alt) ; float temp(time, alt, lat, lon) ; temp:standard_name = ?air_temperature? ; temp:units = Celsius ; temp:coordinates = time lat lon alt ; temp:_FillValue = -999.9; with alt=lat=lon=1 is legal in CF. In fact the coordinates attribute is not needed, because these are all (Unidata) coordinate variables (1D, with name of the variable equal to the name of the dimension). Ignoring the coordinates attribute, this example is fine in COARDS as well. In the data model, lon lat alt time are all dimension coordinate constructs with separate domain axes. But when there are *two* timeseries, you would not have alt=lat=lon=2. That would mean three independent size-2 dimensions. This would also be legal in CF and COARDS, but it means timeseries at a grid of 8 points, not two points. To deal with this situation, we introduce an index dimension of size 2, and make alt lat lon auxiliary coordinate variables of this single dimension. In the data model, there is then only one domain axis for alt lat lon. Back to the case of one timeseries: Example H4 shows scalar coordinate variables for alt lat lon. That is, these size-1 dimensions have been omitted. In this case, the coordinates attribute is needed; that's how scalar coordinate variables are attached to the data variable. In the data model (in my opinion) this is logically equivalent including the size-1 dimensions. Lets see, its currently not legal as a DSG file, according to the spec. The CDM will barf on it, though I could put in a workaround. Should it be legal? That is, should people be allowed to put in extraneous dimensions that only make sense for some values of the dimension length (eg 1 but not 1) ? I think it would be a rather ugly wart, and you would gain no new functionality. I also think it would confuse dimensions with coordinates (which has already happened because the distinction isnt obvious). I think we should try to be clear about the use of dimensions because it makes the data model more powerful. So I would prefer not. Maybe this question raises an issue for chapter 9 and Example H4. The example is following Section 9.2: If there is only a single feature to be stored in a data variable, there is no need for an instance dimension and it is permitted to omit it. The data will then be one-dimensional, which is a special (degenerate) case of the multidimensional array representation. The instance variables will be scalar coordinate variables; the data variable and other auxiliary coordinate variables will have only an element dimension and not have an instance dimension, e.g. data(o) and t(o) for a single timeSeries. In the multidimensional array representation, featureType doesn't have to be coded, because this representation has always existed in CF. We could say that *if* you encode featureType, there *must* be an instance dimension (of size 1 if appropriate) and that alt lat lon must be auxiliary coordinate variables with this dimension. That would be a restriction we don't have in CF 1.6, so it would be a change to CF. What do you
