[CF-metadata] Standard_name for cloud-cover by phenomenon
Hei, in grib, clouds are described as low, medium and high clouds, e.g. 73,74,75. Those are described by phenomenon, e.g. high cloud type: Clouds of genera Cirrus, Cirrocumulus and Cirrostratus. low cloud type: Clouds of genera Stratocumulus, Stratus, Cumulus, etc. medium cloud type: Clouds of the genera Altocumulus, Altostratus, etc. (see In CF, this can currently only be expressed by cloud_area_fraction_in_atmosphere_layer and a not very well defined 'vertical' parameter, e.g. by sigma: http://www.ecmwf.int/products/data/archive/data_faq.html#clouddefinitions When translating from grib to CF, this is not very satisfying: Either I add some dummy sigma-values, which will look like I have a model with just three levels, or I use 3 variables, all with the same 'standard_name=cloud_area_fraction' which looses some useful information. In both cases, the data-user will need to know something which cannot be expressed by CF. Looking at the page http://cf-pcmdi.llnl.gov/documents/cf-standard-names/ecmwf-grib-mapping there are mentioned 3 'standard_names' which are not in the standard_name-table yet, and I propose to do so: low_cloud_area_fraction medium_cloud_area_fraction high_cloud_area_fraction in additon (though this is not in grib), I would like to add fog_area_fraction (or surface_cloud_area_fraction). Best regards, Heiko ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Standard_name for cloud-cover by phenomenon
Hello Heiko, I don't have a strong opinion, but am just testing the water ... I wonder how one would define these standard names so that they were correct for all uses, for example from a three layer model to the ISCCP datasets. In your example, would a model_level_number coordinate of [1, 2, 3] fit your needs, possibly with an auxiliary coordinate of ['low', 'medium', 'high']? Would we need a standard name for the auxiliary coordinate, or would a long name suffice? All the best, David Original message from Heiko Klein (11AM 25 Apr 12) Date: Wed, 25 Apr 2012 11:49:06 +0200 From: Heiko Klein heiko.kl...@met.no User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 To: cf-metadata@cgd.ucar.edu cf-metadata@cgd.ucar.edu Subject: [CF-metadata] Standard_name for cloud-cover by phenomenon Hei, in grib, clouds are described as low, medium and high clouds, e.g. 73,74,75. Those are described by phenomenon, e.g. high cloud type: Clouds of genera Cirrus, Cirrocumulus and Cirrostratus. low cloud type: Clouds of genera Stratocumulus, Stratus, Cumulus, etc. medium cloud type: Clouds of the genera Altocumulus, Altostratus, etc. (see In CF, this can currently only be expressed by cloud_area_fraction_in_atmosphere_layer and a not very well defined 'vertical' parameter, e.g. by sigma: http://www.ecmwf.int/products/data/archive/data_faq.html#clouddefinitions When translating from grib to CF, this is not very satisfying: Either I add some dummy sigma-values, which will look like I have a model with just three levels, or I use 3 variables, all with the same 'standard_name=cloud_area_fraction' which looses some useful information. In both cases, the data-user will need to know something which cannot be expressed by CF. Looking at the page http://cf-pcmdi.llnl.gov/documents/cf-standard-names/ecmwf-grib-mapping there are mentioned 3 'standard_names' which are not in the standard_name-table yet, and I propose to do so: low_cloud_area_fraction medium_cloud_area_fraction high_cloud_area_fraction in additon (though this is not in grib), I would like to add fog_area_fraction (or surface_cloud_area_fraction). Best regards, Heiko ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- David Hassell National Centre for Atmospheric Science (NCAS) Department of Meteorology, University of Reading, Earley Gate, PO Box 243, Reading RG6 6BB, U.K. Tel : 0118 3785613 Fax : 0118 3788316 E-mail: d.c.hass...@reading.ac.uk ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Standard_name for cloud-cover by phenomenon
Hi Heiko, I support your proposal to add low_cloud_area_fraction, low_cloud_area_fraction, and high_cloud_area_fraction. Just for information for all: (1) There is something called high cloud etc as Heiko says. (2) It's misunderstanding that whatever cloud located in high layer becomes high cloud. (3) By that misunderstanding parameters like low cloud cover are once noted deprecated in GRIB edition 2. But WMO expert team now understood proper meaning of parameter, so it will be corrected this November. http://www.wmo.int/pages/prog/www/ISS/Meetings/IPET-DRC_Melbourne2011/Documents/IPETDRC-III_Doc2-2_3_AccumulationUnits.docBest Regards,--Eizi TOYODA- Original Message -From: Heiko Klein heiko.kl...@met.noTo: cf-metadata@cgd.ucar.eduSent: Wednesday, April 25, 2012 6:49 PMSubject: [CF-metadata] Standard_name for cloud-cover by phenomenon Hei, in grib, clouds are described as low, medium and high clouds, e.g.73,74,75. Those are described by phenomenon, e.g. high cloud type: Clouds of genera Cirrus, Cirrocumulus and Cirrostratus. low cloud type: Clouds of genera Stratocumulus, Stratus, Cumulus, etc. medium cloud type: Clouds of the genera Altocumulus, Altostratus, etc. (see In CF, this can currently only be expressed bycloud_area_fraction_in_atmosphere_layer and a not very well defined'vertical' parameter, e.g. by sigma: http://www.ecmwf.int/products/data/archive/data_faq.html#clouddefinitions When translating from grib to CF, this is not very sat isfying: Either Iadd some dummy sigma-values, which will look like I have a model with justthree levels, or I use 3 variables, all with the same'standard_name=cloud_area_fraction' which looses some useful information.In both cases, the data-user will need to know something which cannot beexpressed by CF. Looking at the page http://cf-pcmdi.llnl.gov/documents/cf-standard-names/ecmwf-grib-mapping there are mentioned 3 'standard_names' which are not in thestandard_name-table yet, and I propose to do so: low_cloud_area_fraction medium_cloud_area_fraction high_cloud_area_fraction in additon (though this is not in grib), I would like to add fog_area_fraction (or surface_cloud_area_fraction). Best regards, Heiko ___ 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] Standard_name for cloud-cover by phenomenon
Hello David, Cloud types (lo/mid/hi) of ISCCP described at http://isccp.giss.nasa.gov/cloudtypes.html is classification of height of cloud, observed in infrared image of satellite. Heiko is talking about cloud types of the same name, but it's NWP product. They are not necesarily matching to satellite-based classification, rather tuned to imitate classical cloud types, so that the product can be used as substitute of cloud cover in synoptic station reports. For example, if convection is forecast, that will be classified as low cloud, no matter how high the top of the cloud reaches. Best Regards, -- TOYODA Eizi, Japan Meteorological Agency - Original Message - From: David Hassell d.c.hass...@reading.ac.uk To: Heiko Klein heiko.kl...@met.no Cc: cf-metadata@cgd.ucar.edu Sent: Wednesday, April 25, 2012 7:36 PM Subject: Re: [CF-metadata] Standard_name for cloud-cover by phenomenon Hello Heiko, I don't have a strong opinion, but am just testing the water ... I wonder how one would define these standard names so that they were correct for all uses, for example from a three layer model to the ISCCP datasets. In your example, would a model_level_number coordinate of [1, 2, 3] fit your needs, possibly with an auxiliary coordinate of ['low', 'medium', 'high']? Would we need a standard name for the auxiliary coordinate, or would a long name suffice? All the best, David Original message from Heiko Klein (11AM 25 Apr 12) Date: Wed, 25 Apr 2012 11:49:06 +0200 From: Heiko Klein heiko.kl...@met.no User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 To: cf-metadata@cgd.ucar.edu cf-metadata@cgd.ucar.edu Subject: [CF-metadata] Standard_name for cloud-cover by phenomenon Hei, in grib, clouds are described as low, medium and high clouds, e.g. 73,74,75. Those are described by phenomenon, e.g. high cloud type: Clouds of genera Cirrus, Cirrocumulus and Cirrostratus. low cloud type: Clouds of genera Stratocumulus, Stratus, Cumulus, etc. medium cloud type: Clouds of the genera Altocumulus, Altostratus, etc. (see In CF, this can currently only be expressed by cloud_area_fraction_in_atmosphere_layer and a not very well defined 'vertical' parameter, e.g. by sigma: http://www.ecmwf.int/products/data/archive/data_faq.html#clouddefinitions When translating from grib to CF, this is not very satisfying: Either I add some dummy sigma-values, which will look like I have a model with just three levels, or I use 3 variables, all with the same 'standard_name=cloud_area_fraction' which looses some useful information. In both cases, the data-user will need to know something which cannot be expressed by CF. Looking at the page http://cf-pcmdi.llnl.gov/documents/cf-standard-names/ecmwf-grib-mapping there are mentioned 3 'standard_names' which are not in the standard_name-table yet, and I propose to do so: low_cloud_area_fraction medium_cloud_area_fraction high_cloud_area_fraction in additon (though this is not in grib), I would like to add fog_area_fraction (or surface_cloud_area_fraction). Best regards, Heiko ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- David Hassell National Centre for Atmospheric Science (NCAS) Department of Meteorology, University of Reading, Earley Gate, PO Box 243, Reading RG6 6BB, U.K. Tel : 0118 3785613 Fax : 0118 3788316 E-mail: d.c.hass...@reading.ac.uk ___ 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] Standard_name for cloud-cover by phenomenon
Hei David, I'm not familiar with the ISCCP datasets, but in a fast look on there web-page, it seems like the have already a translation to the 3 WMO clouds: http://isccp.giss.nasa.gov/cloudtypes.html It is not that we run a 3 layer model. We compare our 20-130 layer models, and we do it on the basis of the WMO cloud types, so, like ISCCP, we have routines to reduce our model-levels to WMO cloud types. It would of course be possible to introduce a new vertical axis of name 'cloud_type' which is a index list of the different clouds. This would be more difficult for a general reader, in particular parsing the ['low', 'medium', 'high'] axis will be cumbersome and error-prone. On the other hand, CF usually describes different phenomenons with different standard_names, e.g. *_longwave_energy - *_shortwave_energy, swell wave - wave rather than with additional axes. Best regards, Heiko On 2012-04-25 12:36, David Hassell wrote: Hello Heiko, I don't have a strong opinion, but am just testing the water ... I wonder how one would define these standard names so that they were correct for all uses, for example from a three layer model to the ISCCP datasets. In your example, would a model_level_number coordinate of [1, 2, 3] fit your needs, possibly with an auxiliary coordinate of ['low', 'medium', 'high']? Would we need a standard name for the auxiliary coordinate, or would a long name suffice? All the best, David Original message from Heiko Klein (11AM 25 Apr 12) Date: Wed, 25 Apr 2012 11:49:06 +0200 From: Heiko Kleinheiko.kl...@met.no User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 To: cf-metadata@cgd.ucar.educf-metadata@cgd.ucar.edu Subject: [CF-metadata] Standard_name for cloud-cover by phenomenon Hei, in grib, clouds are described as low, medium and high clouds, e.g. 73,74,75. Those are described by phenomenon, e.g. high cloud type: Clouds of genera Cirrus, Cirrocumulus and Cirrostratus. low cloud type: Clouds of genera Stratocumulus, Stratus, Cumulus, etc. medium cloud type: Clouds of the genera Altocumulus, Altostratus, etc. (see In CF, this can currently only be expressed by cloud_area_fraction_in_atmosphere_layer and a not very well defined 'vertical' parameter, e.g. by sigma: http://www.ecmwf.int/products/data/archive/data_faq.html#clouddefinitions When translating from grib to CF, this is not very satisfying: Either I add some dummy sigma-values, which will look like I have a model with just three levels, or I use 3 variables, all with the same 'standard_name=cloud_area_fraction' which looses some useful information. In both cases, the data-user will need to know something which cannot be expressed by CF. Looking at the page http://cf-pcmdi.llnl.gov/documents/cf-standard-names/ecmwf-grib-mapping there are mentioned 3 'standard_names' which are not in the standard_name-table yet, and I propose to do so: low_cloud_area_fraction medium_cloud_area_fraction high_cloud_area_fraction in additon (though this is not in grib), I would like to add fog_area_fraction (or surface_cloud_area_fraction). Best regards, Heiko ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- David Hassell National Centre for Atmospheric Science (NCAS) Department of Meteorology, University of Reading, Earley Gate, PO Box 243, Reading RG6 6BB, U.K. Tel : 0118 3785613 Fax : 0118 3788316 E-mail: d.c.hass...@reading.ac.uk -- Dr. Heiko Klein Tel. + 47 22 96 32 58 Development Section / IT Department Fax. + 47 22 69 63 55 Norwegian Meteorological Institute http://www.met.no P.O. Box 43 Blindern 0313 Oslo NORWAY ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] identification of vector components
Dear Bert a) A rectangular model in some UTM coordinates (or possibly a local derivative of that) in which x for all practical purposes measures distance east and y distance north. If we take the term true longitude in the definition of x_wind loosely, then we would have to write eastward_wind instead of x_wind. However, if true longitude literally means only a coordinate with standard name longitude then we are allowed to use x_wind. I don't know about the UTM in detail, but since it is a projection I guess you would put x_wind. However this use-case points out that what I wrote to Mark wasn't quite right. I suppose that if x was zonal distance and y was meridional distance (not in degrees), the components would be eastward and northward (even though x and y are not longitude and latitude). b) Our model users can create curvilinear grids in lon-lat coordinates. The numerical model doesn't know if the grid that the users created happens to be a rectangular grid in lon-lat coordinates. In 99% of the cases the grid will be curvilinear and hence it does not align with true longitude and thus we should use x_wind for the velocity component (see also case c). However, if the curvilinear grid that the user provides happens to be a rectangular grid then suddenly the program is not allowed to write x_wind anymore, and has to write eastward_wind. This is awkward for the model to check and therefore I would also support the request to allow x_wind to mean wind in the direction of the x axes of the model. But, as I wrote to Mark, the model does have to know what it is doing, because if the grid does not align with lon and lat you must write 2D lon and lat aux coord vars, whereas if the grid is lon and lat you would not write those aux coord vars (since the coord vars are lon and lat). The same distinction can be used to decide which standard names to use. Based on the description the grid x-axis I assume that x_wind may indicate the velocity in i direction in which case we need to define an explicit coordinate variable i(i) with attribute axis=X. Is this correct, or is x_wind intended to be the wind velocity in the local x coordinate direction and not one of the grid directions? I don't know if this is correct, because I am not sure what the distinction is between the i- and x-directions - sorry. Could you explain a bit more, please? While I recognise the point of Mark's proposal, I also agree with the argument that this may not be helpful to users of the data, who are the customers of CF. It is important to know if you are dealing with lon/lat or x/y components, simply because quite a lot of software is based on the former and cannot deal with the latter. So, to be safe, such an application would ignore data which said it was x/y, because it wouldn't know if was actually lon/lat. It's much easier for the data-writer to tell the data-user that the components are lon/lat than for the data-user to infer this from the coordinates. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Ocean CTD data following CF Conventions v1.6
Hi andrew: The file you sent (20110818T001140Z_M_HI504BEN.nc) appears to be a single profile. Assuming that, you would use the following template: http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#idp8363696 note that lat, lon and time coordinates all have to be scalars. John On 4/18/2012 8:24 PM, andrew walsh wrote: Hi John, We have now constructed a real netCDF file for you to check. QC flag variables have been added in. The QC flagging method is based on the proposed IODE scheme in (1) below. Attached are the sample .nc file, text (ncdump) of same and a document specifying the CDL. Thanks and Regards, Andrew Walsh Ref. (1) Konovalov et. al (March 2012), Proposal to adopt a quality flag scheme standard for oceanographic and marine meteorological data, Version 1.2. - Original Message - From: John Caron ca...@unidata.ucar.edu To: andrew walsh awa...@metoc.gov.au Sent: Thursday, April 05, 2012 10:44 AM Subject: Re: [CF-metadata] Ocean CTD data following CF Conventions v1.6 ok On 4/4/2012 6:42 PM, andrew walsh wrote: Hi John, Thank for your offer to check a sample netCDF CTD data file. At moment we don't have some real .nc file but when we do I can send you a file for checking. Andrew - Original Message - From: John Caron To: cf-metadata@cgd.ucar.edu Sent: Wednesday, April 04, 2012 5:55 AM Subject: Re: [CF-metadata] Ocean CTD data following CF Conventions v1.6 Hi all: Lets see, I havent followed the entire conversation, but: 1) Andrew if you can send me a sample file (not just the CDL) I can check if it works in the CDM with the new 1.6 conventions, and maybe give you some advice from my POV. 2) Aggregation in the CDM comes in 2 flavors. 1) The original implementation simply appends multidimensional arrays together, eg joinNew and joinExisting NCML aggregation. I call it syntactic aggregation because it doesnt know what its aggregating, and the homogeneity requirements are strict. 2) Feature Type collections (aka semantic aggregation) are the more recent development. These understand the coordinate information of the data, and so can handle variations in the representation, eg ragged arrays, scalar coordinates, etc. In this case, the CDM understands a dataset as a collection of features objects, which can be stored in a collection of files. The interfaces to these collections is still under development. Most current and future work in the CDM is in this category. John snip ___ 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
