Dear Burkhardt,
I think the following is correct, but wait a week or so, to see if anyone sends
a correction.
1) cell_methods:
> cloud cover over several layers is computed by using
> maximum_random_overlap which is very common in atmospheric models.
> However, this is not a valid CF-convention. What shall I do?
I believe that this would be reported as follows (assuming cloud fraction as a
function of layer is named "cl" and the vertical coordinate is "plev":
cl: cell_methods = "plev: sum (assuming maximum random overlap)"
You may place any text you want within parentheses following the method.
>
> 2) boundaries:
> the boundaries of the high/medium/low clouds in our model are (0 hPa,
> 400 hPa)/(400 hPa, 800 hPa)/(800 hPa, ps), where ps is the surface
> pressure. The issue here is that ps is forstly not a constant and
> secondly 2D. In the discussion below it is said that one can also use
> character type for the bounds. Thus would then
>
("top_of_atmosphere","400hPa")/("400hPa","800hPa")/("800hPa","surface_air_pressure")
> be an acceptable solution?
I'm pretty sure CF doesn't permit character type data for bounds; character data
can be used as "labels and alternative coordinates", but I'm pretty sure only
numerical values should be used for the bounds.
One option might be to choose a "surface" pressure well below ground (e.g. 1100
hPa). Clearly there are no clouds below ground, so the low cloud cover is
unaffected by the lower limit. Another option might be to choose a more
standard approx. surface pressure (e.g., 1000 hPa), but then explain in a
"comment" attribute associated with the variable (cl) that the low layer cloud
is for a layer extending from 800 hPa to the surface.
I can't think of any software actually making use of the bounds attribute (in
the case you bring up), except to perhaps label a plot. If that is the case,
then you might simply define an "alternative coordinate" as a string variable,
which might have values something like:
"high (0-400 hPa)", "medium (400-800 hPa)", "low (800 hPa - surface)"
I think Jonathan Gregory is away for a few days, so I would wait until he
returns to get his take on this.
cheers,
Karl Taylor
dimensions:
plev = 3 ; // number of trajectories
times = 20 ;
max_len_parcel_name = 64 ; // max length of trajectory name
variables:
float temperature(parcel,times) ;
temperature:coordinates = "parcel_name lat lon" ;
float times(times) ;
char parcel_name(parcel,max_len_parcel_name) ;
float lon(parcel,times) ;
float lat(parcel,times) ;
Burkhardt Rockel wrote:
> Dear All,
>
> I am looking for a method how to define high, medium, and low clouds in
> CF-conventions. I have found a correspondence (see below) in the
> CF-archive. However, there are still open questions for me:
>
> 1) cell_methods:
> cloud cover over several layers is computed by using
> maximum_random_overlap which is very common in atmospheric models.
> However, this is not a valid CF-convention. What shall I do?
>
> 2) boundaries:
> the boundaries of the high/medium/low clouds in our model are (0 hPa,
> 400 hPa)/(400 hPa, 800 hPa)/(800 hPa, ps), where ps is the surface
> pressure. The issue here is that ps is forstly not a constant and
> secondly 2D. In the discussion below it is said that one can also use
> character type for the bounds. Thus would then
> ("top_of_atmosphere","400hPa")/("400hPa","800hPa")/("800hPa","surface_air_pressure")
> be an acceptable solution?
>
> Regards
> Burkhardt
>
>
>
>
> The help for cloud_area_fraction_in_atmosphere_layer indicates that the
> layer must be specified via an associated vertical coordinate. The
> definition of the quantity is incomplete without this information which is
> what distinguishes the quantities in different variables.
>
> Also note that the long_name attribute is available (and intended) for the
> common usage names. If a single variable is used for all 3 layers the
> long_name could be something like "high/medium/low cloud fraction".
>
> On Tue, Dec 28, 2004 at 03:00:52PM -0500, V. Balaji wrote:
>>/ Jonathan Gregory writes:/
>>/ /
>>/ > Dear Balaji/
>>/ >// /
>>/ > > What happens when I also want to define "middle" and "low" cloud/
>>/ > > amount? Do I define a single field with 3 Z levels?/
>>/ >// /
>>/ >Yes, that's the idea. Alternatively, if you want high, medium and low
> cloud to/
>>/ > be stored in separate data variables, you can have three different
> size-one/
>>/ > dimensions for them, or you can use scalar coordinate variables./
>>/ /
>>/ I'm not sure how to do them in separate data variables... wouldn't it/
>>/ be confusing to have three variables all bearing the standard name/
>>/ "cloud_area_fraction_in_atmosphere_layer"?/
>>/ /As I recall the bounds
>>/ > > Is it possible somehow to associate the words "high", "middle" and/
>>/ > > "low" with the three layers? This is common parlance./
>>/ >// /
>>/ > Yes, that could be done, by defining an auxiliary coordinate
> variable with/
>>/ > the dimension of Z and of character type, containing the descriptive
> strings./
>>/ > However, I think we ought to insist that the Z ranges are precisely
> defined,/
>>/ > and not try to standardise what high, medium and low cloud mean.
> These are/
>>/ > vague terms, and without precise Z ranges attached to them, I don't
> think/
>>/ > there is sufficient metadata to allow you to decide whether
> quantities from/
>>/ > different sources are comparable. What do you think?/
>>/ /
>>/ Correct./
>>/ /
>>/ --// /
>>/ /
>>/ V. Balaji // //Office:// //+1-609-452-6516/
>>/ Head, Modeling Systems Group, GFDL// //Home:// //+1-212-253-6662/
>>/ Princeton University// //Email: //v.balaji at
> noaa.gov/ <http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata>
>>/ /
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Thu Aug 18 2005 - 11:00:40 BST
